1. Help Center
  2. EasyDMARC Features Guideline

Analyzing DMARC Aggregate Reports

The DMARC Aggregate Report is a crucial feature in the EasyDMARC platform. If you've correctly updated your DMARC record, including EasyDMARC's "rua" address, you will start receiving DMARC reports in a complicated XML format. Our system parses these reports into easy-to-read and easy-to-understand data.

Before delving into details, here's an example of the XML file format:


XML files contain essential metrics such as IP addresses, SPF & DKIM health, and the disposition of emails. However, reading multiple reports daily, especially when sending numerous emails, can be challenging.

EasyDMARC transforms these reports into user-friendly data, performing additional checks to simplify organizations' analysis and facilitate appropriate actions. Our algorithm categorizes the reports into four tabs: "Compliant," "Non-Compliant," "Threat/Unknown," and "Forwarded." These tabs provide centralized reports based on indicators to help you focus on key aspects of your email authentication metrics and address any issues.

image-png-Jan-18-2024-10-16-59-3147-PM

Report Details

Before we explore the segmentation and the meaning behind each tab, let's thoroughly examine the details of the reports and develop a comprehensive understanding of their significance.

image-png-Jan-18-2024-10-20-14-3826-PM

  • PTR/IP Source: This is the IP address used by your server to send emails. We identify this IP source to provide you with the service name of your ESP.
  • Volume: This indicates the volume of outgoing emails from the given IP address, typically within a 24-hour span.
  • Delivery Status: This represents the disposition of your emails, which can be delivered, delivered to spam, or rejected, based on your applied DMARC policy. Under the DMARC Compliant tab, you will see all your delivered emails.
  • DMARC: This is the final DMARC result, indicating either pass or fail.
  • SPF: This is the final SPF result after checking the results of SPF Alignment and SPF Authentication, showing either pass or fail.
  • SPF Alignment: This checks if the domain found under SPF Authentication is aligned with the Sending Domain. If it matches, then it's a pass.
  • SPF Authentication: This checks if the Return-Path domain in use is whitelisted in the DNS TXT Record, either your own domain or a third-party domain from your ESP. The result can be pass, fail, neutral, temperror, or permerror.
  • DKIM: This is the final DKIM result after checking the results of DKIM Alignment and DKIM Authentication, showing either pass or fail.
  • DKIM Alignment: This checks if the DKIM Signature domain (d=) used matches the Sending domain.
  • DKIM Authentication: This checks if the sent email has a valid DKIM Signature, whether from your own domain or a third-party domain.
  • Reporter: This is the ESP that sent us the DMARC reports, essentially your recipients' servers. They send us the DMARC reports for the emails you've sent to them.
  • Date: This is the date when your emails were sent for that specific report.

Now, let's delve into more crucial details, specifically the distinction between SPF and DKIM Alignment and Authentication, and how these factors determine whether DMARC passes or fails.

To start, we'll explore SPF Authentication & Alignment. Please refer to the screenshot below:

image-png-Jan-18-2024-10-38-42-5025-PM

In this situation, the SPF Authentication Result is marked as "Pass" because the domain notifications.easydmarc.com has an SPF record that includes the given 54.240.8.56 IP address. This explanation is straightforward and easy to understand.

It's important to note that SPF always verifies the domain listed under the SPF Authentication result, and not Sending Domain. While these domains may align at times, it is not always the case.

As previously mentioned, SPF Alignment involves matching the Return-Path domain with the From: address domain.

In these reports, the From: address domain is always referred to as the "Sending Domain." This is the domain used for sending your emails, such as easydmarc.com.

The domain listed under SPF Authentication Result represents the Return-Path domain. This domain is used for handling bounces, and in this case, it is a subdomain called notifications.easydmarc.com.

To summarize, since easydmarc.com is identical to notifications.easydmarc.com (they are the same domain), and EasyDMARC has a relaxed alignment policy, the Alignment in this scenario is considered Passing.

Therefore, we have two pass scenarios: one with SPF Authentication and the other with SPF Alignment. When both of these checks pass, it results in a DMARC Pass in terms of SPF.

Similarly to SPF Authentication & Alignment, the concept applies to DKIM as well. Let's take a look at this screenshot:

image-png-Jan-18-2024-11-11-20-6010-PM

In this case, DKIM Authentication is considered successful because easydmarc.com has a valid DKIM Signature. The private and public key pairs are functioning correctly and are used to sign the emails.

Additionally, DKIM Alignment is passing because the domain used to sign the DKIM matches the Sending Domain, which in this case is easydmarc.com. As a result, DMARC passes in terms of DKIM.

Overall, in this scenario, DMARC passes both SPF and DKIM checks.

Segmentation of Reports

When categorizing the reports, our system organizes them into four tabs: Compliant, Non-Compliant, Threat/Unknown, and Forwarder.

  • Under the Compliant tab, you will find all legitimate sources that use your organization's domain to send emails successfully and pass DMARC. This is indicated by either SPF or DKIM, or both. It is important to note that both Alignment and Authentication must pass for an email to be considered DMARC-compliant.I
  • In the Non-Compliant tab, you'll find legitimate sources that attempt to send emails from your organization's domain but fail DMARC. This suggests issues with both SPF/DKIM Authentication and Alignment. 
    Alignment failure cases are more common in this tab and can be attributed to the use of third-party sources like Sendgrid, Mailgun, and others without authenticating the domain with them. In these instances, these third-party sources use their own domains to handle SPF and DKIM, resulting in DMARC failure. This happens because the sending domain is yours, but the SPF and DKIM handling processes are from the third-party source domain.

image-png-Jan-19-2024-12-17-36-7360-AM

In the provided screenshot, the SPF and DKIM Authentication for mail1.wpengine.com are successful. However, there is a misalignment between the domain used for authentication (mail1.wpengine.com) and the Sending Domain (examp.com). As a result, both SPF and DKIM alignment fail, leading to a DMARC failure.

  • The Threat/Unknown tab contains sources identified by our algorithm as potential hackers or cybercriminals attempting to send fraudulent emails on behalf of your domain.
  • Under the Forwarded tab, you'll find sources that are automatically forwarded by third-party entities. In this tab, SPF will always fail, but DKIM usually passes if implemented in your actual source and message is auto-forwarded without altering its integrity.

Enhanced Tools in Aggregate Reports

We've incorporated additional tools into the aggregate reports to streamline and enhance the process. These include:

  • Email Vendor Identification: In our backend, we have identified over 1,200 email sources. Users can access detailed steps on fixing a source in terms of authentication by clicking the Gear Icon next to each source.
    image-png-Jan-19-2024-12-38-31-2330-AMimage-png-Jan-19-2024-12-39-08-2475-AM
  • IP Blocklisting: For each IP address received in reports, we also check if those addresses are blacklisted in various RBLs. This ensures that our users stay updated on their IP reputation and can take appropriate actions accordingly.
  • Filtering: We provide filtering options for various criteria. This allows users to filter out specific case scenarios for debugging and taking appropriate actions.
    image-png-Jan-19-2024-12-41-04-0744-AM
  • Data Export: We simplify the process of exporting data for presentations to colleagues and managers, making it easy to share relevant information.
    image-png-Jan-19-2024-12-41-43-8270-AM


User Actions and Project Management

  • Always initiate the DMARC implementation with p=none. This won't affect the delivery of Non-Compliant emails. Initial data gathering is crucial to determine the next steps.
  • Focus on Non-Compliant sources as they are failing DMARC checks. Identify sources and fix issues by implementing SPF and/or DKIM authentication and alignment. Users can easily follow the steps by clicking on the Gear Icon for each source.
  • Upon encountering the same sending source under the Compliant and Non-compliant tabs various triggering scenarios are possible. For example:
    -Pay attention to the dates of the reports, as it is possible that the ones failing the DMARC check were yet not configured with the SPF/DKIM protocols and after completing the process, the future reports were stored under the Compliant tab.
    -During the relay process it is possible for the already configured protocols to fail (forwarding, email message modification), and in the absence of DKIM data, the reports get misclassified into Non-compliant, instead of Forwarded tab.
    Both cases do not require action. The only requirement is completing the setup of SPF/DKIM protocols and achieving DMARC compliance.
  • Identify and fix any SPF or DKIM issues under the Compliant sources. DMARC requires either SPF and/or DKIM to pass, and there might be cases where either of the sources is not configured correctly.
  • Monitor data after each fix. Users should ensure that new reports appear under the Compliant tab instead of the Non-Compliant tab, indicating that the source is fixed.
  • Verify that every legitimate source used for sending emails is listed under the Compliant tab.
  • Ensure that every source under the Compliant tab is DKIM aligned/authenticated. While SPF alignment may not be possible with some ESPs due to limitations, DKIM is usually provided by every ESP.
  • After confirmation, users can gradually enforce their policies until p=reject is achieved. Under p=reject, all reports falling under Non-Compliant and Threat/Unknown will fail.