How to read your DMARC reports and actually act on them

For brands using email communications as an effective channel for reaching out to their subscribers, clients, or customers, email authentication is one of the major factors to focus on. Email authentication secures the brand’s domain from spoofing, protects recipients from phishing emails, increases email deliverability, and helps maintain a good sender reputation.

Properly authenticated emails are prioritized by inbox providers, resulting in higher open rates and conversions. Thus, companies implementing strong authentication for their domains may see better financial results than those overlooking this aspect.

Why every domain needs DMARC

Email authentication is configured using three protocols: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

While SPF and DKIM are widely used by senders, DMARC is sometimes missed, although it is now required for bulk senders. Not all companies realize the importance of the DMARC authentication protocol and the benefits it provides to senders. 

DMARC is the third layer of email authentication that connects SPF and DKIM. When an email passes email authentication by DMARC, this confirms the message's authenticity and integrity and helps email receivers decide how to handle the message.

For companies, the implementation of DMARC authentication provides the following benefits:

• control over unauthenticated emails;
• protection against spoofing and phishing;
• better email deliverability;
• higher sender reputation;
• eligibility for BIMI; 
• detailed reporting.

What DMARC reports actually tell you

DMARC supports two types of reports: aggregate and forensic. The types of reports received is specified by the DMARC tags included in a DMARC record:

• the rua= tag specifies the email addresses for aggregate reports;
• the ruf= tag specifies the email addresses for forensic reports.

Aggregate DMARC reports

These are summary reports sent daily by receiving inbox providers. Aggregate reports are sent regardless of email authentication outcomes and provide insights into:

• who is sending emails on behalf of the domain;
• whether anyone is spoofing the domain;
• whether emails pass SPF and DKIM authentication;
• whether emails are aligned with SPF and DKIM;
• how many emails fail authentication;
• whether emails are received as spam or rejected;
• which provider generated the report.

Forensic DMARC reports

Unlike aggregate reports, forensic reports are triggered only when SPF or DKIM fails. They can provide:

• the source IP;
• the reported domain;
• the date the message was sent;
• the email “From:” address;
• the email “To:” address;
• email authentication results.

Because of privacy concerns, most inbox providers currently do not send forensic reports. Email senders are encouraged to read their aggregate reports to monitor their domains’ health and activity.

Analysis of DMARC reports can help senders determine who is actually sending emails on behalf of the domain, how many emails are sent, and whether there are any email authentication breaches that must be addressed.

How to read your DMARC reports

Instead of sending a separate report for every single message, providers group similar messages into a single XML file based on three main characteristics:

• the sending IP address (the server that originated the email);
• the Header From domain (your domain);
• the authentication outcomes (DKIM/SPF results and alignment).

The number of aggregate reports received daily depends on how many emails a domain sends. High-volume senders may end up with thousands of XML files in their mailboxes every day.

Understanding DMARC report tags

Each XML file includes a range of tags containing information about the domain’s activity. Understanding what each tag means makes it easier to identify unauthorized sending sources and to determine and fix email authentication issues.

The most important aggregate report tags can be described as follows:

• <org_name>: the name of the inbox provider that sent the report;
• <date_range>: the time period covered by the report;
• <domain>: the name of the domain from which the emails analyzed in the report were sent;
• <p>: the DMARC policy applied to emails sent from the domain that fail DMARC;
• <sp>: the DMARC policy applied to emails sent from subdomains that fail DMARC;
• <source_ip>: the IP address from which the emails analyzed in the report originated;
• <count>: the number of emails grouped into a single report;

<policy_evaluated> block:

• <disposition>: the action taken by the email receiver after evaluating the alignment (helps to identify whether the emails were delivered, quarantined, or rejected);
• <dkim>: the DKIM alignment result (pass/fail);
• <spf>: the SPF alignment result (pass/fail);
• <envelope_from>: the domain name in the Return-Path header field (also known as Mail From, Envelope From, or the SPF domain and used to verify SPF alignment);
• <header_from>: the domain name in the visible From field of the email (used for SPF and DKIM alignment);

<auth_results> block:

• <dkim>: 
  • <domain>: the domain name that signed the email using DKIM (specified by the d= tag in the signature);
  • <selector>: the DKIM selector used to locate the DKIM record;
  • <result>: the DKIM authentication result for the specified selector (pass/fail);
  • <human_result>: an optional tag that provides a human-readable explanation of why DKIM authentication failed;
• <spf>: 
  • <domain>: the domain name evaluated for the SPF authentication check;
  • <result>: the SPF authentication result (pass/fail).

How DMARC tags work together: DMARC report analysis guide

To make use of the information provided in DMARC aggregate reports, it is important to understand how different tags are connected and influence the authentication results.

Below is a DMARC report analysis workflow recommended for domain administrators and marketing specialists responsible for domain configuration and protection:

Step 1. Analyze email sources and volume

The first thing to do is to create a list of all email service providers sending emails on behalf of your domain, which appears in the <domain> tag in the report. Include all the systems that may be using the domain, such as CRM platforms, marketing tools, HelpDesk systems, warmup services, and payment systems.

When the list is complete, look through the aggregate report and notice:

• source IP addresses;
• message counts.

Questions to ask:

• do I recognize this sender?
• is it a normal volume?

If both answers are “yes”, go to Step 2.

If the source IP address is unfamiliar and/or if the sent volume is much higher than normal, investigate this further.

The actions to take:

• verify all email accounts using the domain for signs of security breaches or compromise;
• verify your email infrastructure for any new senders you may not be aware of;
• verify email authentication records set up for the domain. 

Step 2. Verify DKIM authentication result

Find the <dkim> tag in the <auth_results> block. Note the value in the <result> tag: pass or fail.

If DKIM authentication results in “pass,” go to Step 3.

If the result is “fail,” look at the description in the <human_result> tag if it is included in the report.

Common errors returned when a DKIM authentication fails include body hash did not verify, no key for signature, signature verification failed, DKIM validation failed, message failed DKIM authentication, selector not found, public key unavailable, bad rsa signature.

The following actions may be taken:

• ensure the DKIM signing is enabled in the email service provider associated with the source IP;
• verify whether a DKIM record for the respective domain is published in DNS;
• regenerate the DKIM key pair for the respective email provider and update the DKIM public key in DNS.

Step 3. Verify SPF authentication result

Look at the <SPF> tags in the <auth_results> block. Note the value in the <result> tag: pass or fail.

If SPF authentication results in “pass”, go to Step 4.

If the result is “fail”, note the domain name used in the <domain> tag. This is the domain name that was evaluated for the SPF authentication check.

Also, look at the value in the <scope> tag to understand where that domain was pulled out.

The mfrom value indicates that the domain name for the SPF authentication check was pulled out from the Mail FROM or Return-Path header field.

The helo value means that the domain name for the SPF authentication check was pulled out from the HELO/EHLO hostname provided by the sending server during the SMTP connection. Typically, this is the domain name used in the email’s From field.

Once you understand which domain causes SPF authentication failures, you may take the following actions:

• verify whether an SPF record for the respective domain is published in DNS;
• ensure that you have a single SPF record published in DNS;
• ensure that you have all your legitimate email sources listed in the SPF record;
• test the SPF record with an SPF checker tool to see whether its syntax is correct and the 10-DNS lookup limit is not exceeded;
• optimize the SPF record if the 10-DNS lookup limit is exceeded;
• ensure that both Return-Path and Header From domains have valid SPF records.

Step 4. Focus on DKIM alignment

An email passes DMARC authentication when it passes SPF alignment, DKIM, or both. The majority of email messages pass DMARC based on DKIM alignment because email providers sign outbound emails with DKIM on behalf of the sender’s domain. 

SPF alignment passes when the sender configures a custom Return-Path or Mail FROM domain that matches the From email domain. However, not all email service providers support this configuration.

Therefore, it is recommended to focus on DKIM alignment first.

The alignment results are shown in the <policy_evaluated> block in an aggregate report.

Note the value in the <dkim> tag.

If it is “pass”, go to Step 5.

If DKIM alignment fails, investigate it further.

The most common reasons why DKIM alignment fails include:

• DKIM authentication fails;
• the d= tag domain does not match the Header From domain;
• the strict DKIM alignment mode is set up by a DMARC record.

The following actions may be taken:

• verify that the DKIM signing is enabled in the respective email sender;
• verify that a valid DKIM record is published for the analyzed domain in DNS;
• match the domain shown in the <header_from> tag to the domain shown in the <dkim> block;
• check the <adkim> tag in the <policy_published> block to see which DKIM alignment mode is specified:
  • adkim=r: indicates a relaxed mode, which means the organizational domains used in the d= signature tag and the Header From field must match;
  • adkim=s: indicates a strict mode, which means the domains used in the d= signature tag and the Header From field must match precisely.

If the adkim tag is not included in the DMARC report, it can be assumed that a relaxed DKIM alignment mode is applied:

• if the DKIM alignment mode is set to “relax”, verify that the organizational domains used in the d= signature tag and the Header From field match;
• if the DKIM alignment mode is set to “strict”:
  • verify that the domains used in the d= signature tag and the Header From field match precisely; or
  • remove the adkim=s tag from the DMARC record published for the analyzed domain to apply the default relaxed mode.

Step 5. Look at SPF alignment

If emails successfully passed a DKIM alignment check, SPF alignment may be ignored. However, it is recommended to pass SPF alignment too in order to increase the likelihood that email will pass DMARC and prevent occasional failures because of DNS problems or DKIM resolving issues.

To find out if the analyzed emails passed an SPF alignment check, note the value in the <spf> tag in the <policy_evaluated> block.

If it is “pass”, there are no authentication issues to address.

If SPF alignment fails, the following actions are recommended:

• note the domain name used in the <envelope_from> tag;
• note the domain name used in the <header_from> tag;
• if the Envelope From domain belongs to the email service provider, read the provider’s documentation or contact the provider directly to identify whether you can change the Envelope From domain to your custom domain;
• if the ESP does not support the use of custom Envelope From domains, ignore SPF alignment failures and focus on DKIM alignment;
• if the ESP supports the use of custom Envelope From domains, follow their guidelines and set up your main domain used in the <header_from> tag or its subdomain as the Envelope From domain.

It is important to note that the possibility of using subdomains depends on the SPF alignment mode specified in a DMARC record.

Check whether the <policy_published> block has an <aspf> tag specifying the SPF alignment mode:

• aspf=r: indicates a relaxed mode, which means the organizational domains used in the Envelope From (Return-Path, Mail FROM) field and the Header From field must match;
• aspf=s: indicates a strict mode, which means the domains used in the Envelope From (Return-Path, Mail FROM) field and the Header From field must exactly match.

If there is no <aspf> tag, it can be assumed that a relaxed SPF alignment mode is applied by default. Thus, the use of subdomains for “Envelope From” is possible.

Move gradually towards enforcement

Some organizations aim to apply a DMARC enforcement policy immediately in an attempt to prevent possible email spoofing and ensure better domain protection. However, this is not a recommended practice because it puts legitimate emails at risk if they fail DMARC.

The following scenario is recommended:

1. Start with the p=none policy to collect and analyze the reports.
2. If the reports collected for 2–3 weeks show DMARC PASS for legitimate sources, change the policy to p=quarantine.
3. Monitor email authentication outcomes for 2–3 weeks longer.
4. If DMARC failures for legitimate sources are detected, temporarily roll the policy back and address the issues.
5. If emails sent by legitimate IPs pass DMARC, change the policy to p=reject.

This gradual move and rollback, if needed, decreases the risk of legitimate emails being quarantined or rejected.

Red flags that require immediate action

DMARC reports can send signals indicating serious issues with email authentication or suggesting domain spoofing activity.

Here are the red flags that should alert you:

1. Large email volumes from unfamiliar IPs

Most of the time, these are spoofed emails sent on behalf of your domain. It is important to verify email authentication for legitimate sources and enforce the policy to block malicious messages.

2. Sudden volume increases from known IPs

This might be due to occasional legitimate sending or email account compromise. In the latter case, investigate and fix the breach.

3. Increased authentication failures for known IPs

If your legitimate emails sent by the analyzed provider normally pass authentication, but suddenly a lot of emails start failing, this may be because of the following: 

• expired DKIM keys;
• change in the SPF record (the sender is removed or the 10-DNS lookup limit is exceeded);
• more than one SPF record is published;
• SPF and DKIM alignment failures;
• message modification in transit.

Ignoring these signals can lead to serious reputation and deliverability problems in the future. 

How automated tools help in DMARC report processing

The manual process of parsing and analyzing DMARC reports becomes time-consuming and error-prone as report volumes increase.

Automated DMARC report processing tools like DMARKOFF convert raw data into clear analytics, helping organizations quickly identify domain spoofing, determine and fix authentication problems, and safely enforce DMARC policies.

The benefits of using automated DMARC report processing tools include:

1. Automated XML parsing and data extraction

DMARC tools automatically check designated mailboxes for report emails, extract compressed XML files, pull out data from the XML files, and write the extracted data into centralized databases. This eliminates manual work and greatly saves time.

2. Data sorting and consolidation

DMARC tools automatically group data by domains, reporting providers, sending sources, and email authentication outcomes, making it easier to analyze the results.

3. Real-time visibility and troubleshooting tips

Automated report processing tools provide a comprehensive view of email sources for each analyzed domain, including details for each source:

• email volume sent during the selected period;
• the DMARC compliance rate;
• SPF/DKIM authentication rates;
• SPF/DKIM alignment rates. 

In case a failure is detected, some automated tools can take steps to fix the issue. This enables security teams to quickly identify anomalies and resolve them.

4. Email spoofing detection

DMARC tools can automatically determine whether a sending IP address is legitimate or unknown, allowing senders to quickly detect domain spoofing attempts and phishing campaigns sent by unauthorized third-party senders.

5. Historical trend analysis

Modern DMARC tools maintain long-term data, allowing domain owners to compare monthly authentication performance. Some systems are integrated with AI tools to allow data analysis and investigation while providing troubleshooting recommendations.

6. Alerting and reporting

Automated tools can send alerts on different events indicating potential email authentication issues or harmful activity, for instance, when:

• SPF and DKIM records break;
• DMARC compliance drops below thresholds;
• email volume from unauthorized sources increases;
• SPF/DKIM authentication fails for legitimate sources.

Scheduled weekly or monthly reports can also be generated automatically.

7. Safe DMARC policy enforcement

According to our email security statistics report, only 18.2% of the top 10 million domains have valid DMARC records, and just 7.6% enforce them. Automated DMARC report analysis helps determine when legitimate email sources are fully authenticated, reducing the risk of blocking valid messages during policy enforcement.

8. Reduced operational costs

A process that might otherwise take hours per day to perform manually can be completed in minutes with automated processing, greatly reducing human errors.

Wrapping up

Reading and interpreting DMARC reports is the only way to gain complete visibility into your domain’s email ecosystem. It transforms email security from a guessing game into a controlled, data-driven process in which you know exactly who is sending messages on your behalf and whether they are authorized to do so.

If you have never analyzed an aggregate report before, the sheer volume of raw data can feel intimidating. Do not let that stall your progress. Start by opening your latest aggregate report and checking whether you recognize every sending IP and whether your legitimate sources are passing DKIM alignment. Focusing on these two critical elements alone helps you clear the initial confusion and quickly spot the most dangerous gaps.

Fixing even one misconfigured legitimate source is a major win for your deliverability. As you clean up these errors and see your DMARC PASS rates consistently stabilize, you will gain the confidence needed to move beyond passive monitoring and safely enforce stricter policies without risking your valid business emails.

Organizations managing multiple domains and sending high volumes of emails are encouraged to use automated DMARC report processing tools available on the market. DMARC tools can be easily integrated into a company’s workflow, ensuring routine report processing, consolidating the data in comprehensive dashboards, and providing real-time analytics with recommended actions.