DMARC Reports 101: How to Decipher the Results

Introduction

Assuming you’ve set up an email address to receive DMARC aggregate reports, are you reviewing them regularly? Do you find the format confusing? Are you able to navigate the reports to determine what’s sent out claiming to be from your domain? Or are you left trying to decode the data and wondering where to start? If any of this sounds like you, don’t worry, you are not alone.

In this article, you’ll learn exactly how to read your DMARC aggregate reports. You’ll learn how to navigate the format and what to focus on. By the end, you’ll know exactly how to decipher the reports and spot any issues that need your attention. By regularly monitoring your DMARC reports, you’ll stay on top of exactly who is sending with your domain.

What’s DMARC?

Domain-based Message Authentication, Reporting, and Conformance, better known as DMARC, is one of three email authentication protocols. SPF and DKIM are used to authenticate the email while DMARC checks alignment and provides reporting. In short, the domain that the message is received from must align with SPF and/or DKIM, if signed. If alignment fails, the domain’s DMARC policy is applied. The policy tells the receiver how the domain would like the email handled should alignment fail

Why is DMARC important? Beside defining policy for authentication failures, It’s also the reporting mechanism that provides insight into what mail box providers receive claiming to be from your domain SPF tells the receiver who is allowed to send email on your behalf, DKIM protects your messages to ensure they have not been tampered with during transit. Together, all three help identify email spoofing, phishing, and spam.

DMARC provides for receivers to send domain owners two types of reports: aggregate and forensic. Both reports provide visibility into what mailbox providers receive from your domain. Due to scope, this article will focus only on the aggregate reports.

DMARC Aggregate Reporting

When you set up your DMARC record in DNS, you specify tags with your reporting preferences. The tags instruct mail box providers where to send the reports and which types of misalignment you want to be notified about.

The DMARC aggregate report provides insight as to how successful your domain’s protection efforts have been with MBPs. But in order to take advantage of this resource, you need to tell mail box providers where to send the reports. The reports also require regular review to be of any benefit to your email deliverability efforts.

The rua tag provides the email address where receivers should send the aggregate reports. Once a day, you’ll receive a compressed file (zip) containing an XML report from each MBP that has received email claiming to be from your domain(s).

Once the report is extracted, you’ll have access to a file with an XML extension. The XML format is the reason most people struggle to make sense of the reports. That’s because reading the content can be a bit challenging if you’ve never worked with raw XML. XML was designed to be human-readable, but not necessarily human-friendly. The XML format is optimized for machine processing for reliable parsing and utilization.

However, don’t let this small challenge stop you. With just a little practice, you can decode your reports. The time invested will allow you to discover the wealth of information the aggregate reports contain. Learning this skill will allow you to get the complete picture about how well your email authentication efforts are actually performing. The reports will also alert you to any spoofing attempts that could negatively impact your brand.

Without further ado, let’s jump in headfirst by looking at a sample DMARC aggregate report.

DMARC Aggregate Sample

Below is a sample of what a DMARC aggregate report looks like in the raw. For now, just give it a quick scan. Don’t spend too much time on it initially. Everything will be broken down into the relevant parts and the report’s content will start to make sense.

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>123456789</report_id>
    <date_range>
      <begin>1753142400</begin>
      <end>1753228799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.0.0</source_ip>
      <count>27</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>selector_1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>192.0.0.1</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>      
      <spf>
        <domain>badguys-r-us.io</domain>
        <scope>mfrom</scope>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Report Sections

The key sections of the report that we will focus on follows:

• Report Metadata
• Policy Published
• Record
  • Row
  • Identifiers
  • Authentication Results

Report Metadata

If you are familiar with metadata, that is “data about data,” it provides what one might expect. The report metadata shows who sent the report, a report id and the date range the report covers.

The organization that sent the report is found in the <org_name> tag, the report id (<report_id>) and the date range (<date_range>) the report covers.

<report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>123456789</report_id>
    <date_range>
      <begin>1753142400</begin>
      <end>1753228799</end>
    </date_range>
  </report_metadata>

In this example, the report is from Google <org_name>google.com</org_name> and some not so helpful contact information. Note that the email address is “[email protected]” meaning it is not an address that is monitoring replies. However, a more helpful link is provided: how to set up DMARC to prevent spoofing, phishing and spam in the extra contact info tag.

Also note the inside the date range tag <date_range>, there are<begin> and <end> tags that contain a long numeric value. These are Unix timestamps, also known as epoch time. Epoch time is the number of seconds that have elapsed since January 1, 1970.

Not terribly helpful in the current format without translation. But I’ve done the translation for this example. The report covers from a start and end time of midnight – 23:59:59 on July 22, 2025 respectively.

Policy Published

The <policy_published> section reflects the published DMARC policy the receiver found and used for your domain with the alignment details during the report’s stated date range

Note that the policy here is just an example and will likely differ from the policy published for your specific domain. The pertinent information from our example can be found below:

<policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>

In our example, the policy published has the following tags:

• <domain>: domain where the policy is published
• <adkim>: identifier for DKIM alignment
• <aspf>: identifier for SPF alignment
• <p>: policy for top/root level domain
• <sp>: policy for subdomains
• <pct>: percentage of the records that should be impacted by the policy

Let’s walk through each section below.

<domain> – this data reflects the domain or subdomain where the receiver found the policy referenced. This will typically be your root domain but could be a subdomain.

<aspf> SPF Alignment Identifier compares the domain that passed SPF, normally the envelope MAIL FROM / Return-Path domain, against the domain in the From: header.

• r (relaxed): In relaxed mode, the domain in the “from” header and the domain for the SPF record can be different at the subdomain level. For example, if the “from” domain is sub.example.com and the SPF domain is example.com. In relaxed mode, that’s considered aligned. This is the default value if no tag is present.
• s (strict): In strict mode, the domain in the “from” header and the domain in the SPF record must be exactly the same, including subdomains. From our example above, sub.example.com and example.com are different in strict mode and would not be aligned.

<adkim> – DKIM Alignment Identifier compares the domain in the DKIM signature’s d= tag against the domain in the From: header.

• r (relaxed): In relaxed mode, the domain in the “from” header and the domain in the DKIM signature will be considered valid even if they are different at the subdomain level. For example, an email originating from [email protected] will be in alignment with a DKIM signature from sub.example.com or example.com This is the default value if no tag is present.
• s (strict): In strict mode, the domain in the “from” header and the domain in the DKIM signature must be the same. For example, an email originating from [email protected] would not be in alignment if signed with a DKIM from sub.example.com. It will only align if signed with the DKIM from example.com.

<p> (Domain Policy) tag represents the policy for the root domain, with <sp> covering subdomains (Subdomain Policy). Valid values for policies are shown below:

• none: The receiver should not take any action on messages that fail DMARC authentication. This is often used for monitoring and reporting only purposes.
• quarantine: The receiver should treat messages that fail DMARC authentication with caution, typically by moving them to the spam or junk folder.
• reject: The receiver should reject messages that fail DMARC authentication and not deliver them to the recipient’s inbox.

<pct> (Percentage) tag specifies the percentage of messages that should be subjected to the DMARC policy. The percentage is a number from 0 – 100 and the purpose is to allow domain owners to gradually apply the DMARC policy to a percentage of their emails, helping to prevent accidental filtering of legitimate emails.

** Note that the pct tag was deprecated as of May 2026. See DMARC Update for more information.

To put this together, in our example, alignment for both SPF and DKIM has a value of “r”, meaning the alignment is “relaxed.” Alignment that is relaxed will allow the information in the “from” header to pass for both the root level domain and any subdomains.

The policy for both domain (p) and subdomains (sp) is set to the value of “quarantine.” This policy tells receivers that any emails failing authentication should be considered suspicious and will likely be delivered to the junk/spam folder or quarantined.

Finally, the pct tag indicates that the stated policy should be applied to 100% of messages that fail. Again, its common to see this at percentages other than 100% during testing or roll outs as a hedge to allow some percentage of the mail through.

Record

Now we are down to the meat and potatoes of the report. The record section contains important information about who is sending emails claiming to be from your domain. It also contains the identifier contained in the header and the authentication results for both SPF and DKIM.

A sample record section follows:

<record>
    <row>
      <source_ip>192.0.0.0</source_ip>
      <count>27</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>selector_1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Row

The <row> tag provides the IPs of the sending servers, the quantity or number of messages received, the action taken (disposition) along with a pass/fail status for DKIM and SPF.

The row tag is comprised of the following tags:

• <source_ip>: The IP address of the server sending the messages
• <count>: How many messages were received from that IP.
• <policy_evaluated>: Container that holds the actual DMARC evaluation outcome for those messages.
  • <disposition>: What action the receiver took (none, quarantine, or reject).
  • <dkim>: Whether DKIM passed or failed for the evaluated messages.
  • <spf>: Whether SPF passed or failed for the evaluated messages.

<row>
      <source_ip>192.0.2.0</source_ip>
      <count>27</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
</row>

Source and Count

In the example above, 27 messages were received, as indicated by the tag <count>. The messages were sent from a server with an IP of 192.0.2.0 <source_ip>, which was changed in this example to protect the server’s identity.

Policy Evaluated

The <policy_evaluated> section contains the final DMARC evaluation results for SPF and DKIM and what action the receiver took, known as the disposition.

Disposition

Describes the action the receiver took with the message. Typically one of the following values:

• None: The disposition value of none means the receiver allowed the message to be delivered normally and then handled by their spam filters.
• Quarantine: the message was delivered to spam/junk or quarantined for extra scrutiny. The recipient should be able to find it as it was allowed in, but should be treated with caution.
• Reject: this status means the receiver rejected the message and did not attempt to deliver. The message bounces and the recipient doesn’t know the message was received/rejected.

SPF – Policy Evaluated

The result of the evaluation the receiver performed when applying your DMARC policy. Specifically, whether SPF both authenticated successfully and aligned with the From domain.

• Pass: SPF successfully authenticated and aligned with the domain.
• Fail: Either SPF failed authentication or did not align.

DKIM – Policy Evaluated

The result of the evaluation the receiver performed when applying your DMARC policy. Whether DKIM authenticated successfully and aligned with the From domain.

• Pass: At least one DKIM signature authenticated and aligned with the From header
• Fail: No DKIM signature was found that was authenticated and aligned.

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>pass</spf>
</policy_evaluated>

From our example, both DKIM and SPF passed with a disposition of “none.” Note that a disposition of none does not mean the message made it into the recipient’s primary inbox. That is not necessarily the case. If just means the email aligned and then is passed off to the MBP’s spam filtering for further processing. The spam score combined with other things like sender reputation, content of the email, and past engagement will determine where the email lands.

Identifiers

The identifiers tag lists the domain that the receiving mail server extracted from the message. It also represents the domain that was used to evaluate DMARC authentication and alignment.

• <header_from>: contains the domain that was extracted from the header. It contains the visible email address that is displayed to the recipient. SPF and DKIM alignment will be matched against this domain.
• <envelope_from>: this is an optional tag and if it exists, is pulled from the MAIL FROM or Return Path.

<identifiers>
    <header_from>example.com
    </header_from>
</identifiers>

The <identifiers> section provides a useful mechanism to investigate potential spoofing attempts. It shows the domain that is visible in the From header (<header_from>) and, when present, the domain showing in the MAIL FROM / Return-Path (<envelope_from>).

A difference between these two domains is common, especially when the message is coming from legitimate ESPs, third-party tools, forwarding, etc.

However, when a mismatch in domain is combined with an SPF and DKIM misalignment, then you have a very strong indicator of unauthorized sending or domain spoofing.

To recap, a mismatch in the <header_from> and <envelope_from> does not necessarily indicate a spoofing attempt. ESPs, third-party senders and email forwarding can be responsible for mismatches.

As a general rule of thumb, to identify spoofing attempts, SPF and DKIM alignment failures with the domain mismatch is typically a very good indicator of unauthorized sending.

Authentication Results

This section reports the authentication results evaluated by the receiving server.

<auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>selector_1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
</auth_results>

In the example above, between the dkim tag <dkim>, the message was signed by DKIM with the selector “selector_1” as shown in <selector>selector_1</selector>. The authentication passed as indicated by <result>pass</result>.

SPF authentication was also successful for the messages from the domain example.com <domain>example.com</domain> and the authe
pass

• <dkim>
  • <domain>: The domain that signed the message, identified by the signature’s d= tag.
  • <result>: Indicates the evaluation status of the signature verification.
  • <selector>: The selector, identified by s= tag, used by the receiving mail server to locate the public key in DNS.
• <spf>
  • <domain>: The domain that was checked for SPF. Normally the Return-Path / MAIL FROM domain, sometimes the HELO/EHLO domain.
  • <result>: Indicates the evaluation status of SPF.
  • <scope>: Almost always mfrom envelope sender or occasionally helo.

DKIM – Auth Results

The DKIM section in <auth_results> will list the domain that signed the message and the selector that the receiver used to locate the public key in DNS. The <result> shows whether the DKIM signature verified successfully using the public key located with the selector.

A list of valid values in the <result> tag of the DKIM section follows:

SPF – Auth Results

The SPF section in <auth_results> will list the domain and the result of the evaluation of the SPF check.

A list of valid values in the <result> tag of the SPF section follows:

The first example showed that 27 emails from 192.0.0.0 passed alignment for both SPF and DKIM. Next, let’s look at an example that actually failed alignment.

<record>
<row>
<source_ip>192.0.0.1</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>badguys-r-us.io</domain>
<scope>mfrom</scope>
<result>none</result>
</spf>
</auth_results>
</record>

The pertinent information from the record above follows in the table below:

<row>
<source_ip>192.0.0.1</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>

From the information in <row> above, 2 messages sent from a server with IP address of 192.0.0.1 failed alignment for both SPF and DKIM. The disposition reported by the receiver tells us that the messages were quarantined, meaning they likely ended up in a junk or spam folder.

<identifiers>
    <header_from>example.com</header_from>
</identifiers>

In the identifiers section, the header from used the domain example.com. In a real report, this will be your domain, but it is the address that is displayed to the user.

<auth_results>      
  <spf>
    <domain>badguys-r-us.io</domain>
    <scope>mfrom</scope>
    <result>none</result>
  </spf>
</auth_results>

The domain evaluated by SPF is badguys-r-us.io and was the origin of the envelope/return path. You will know this due to the <scope> having the value of mfrom, which mean “Mail From.” It is the value that was extracted from the SMTP envelope return-path during the email delivery handshake. The <result> tag value of none means that no SPF record was published for badguys-r-us.io.

Unless badguys-r-us.io is a vendor that should be sending email out on your behalf, then this is clearly an example of spoofing, to try to trick the recipient into thinking the email was from example.com as this is the domain in the header_from.

SPF authentication failed because example.com does not designate badguys-r-us.io to send on it’s behalf in their SPF record. DKIM failed as the message was not signed with a valid selector published in example.com’s DNS. With both SPF and DKIM failing, the receiver quarantined the messages per the DMARC policy published for example.com.

When reviewing the records, look at <auth_results> first to see why authentication succeeded or failed (wrong domain, broken signature, missing record, temporary DNS issue, etc.). Next, look at the <policy_evaluated> section to see if SPF and DKIM were in alignment and what action (disposition) the receiver took on the emails.

Note that while this example demonstrated a spoofing attempt, failures can also highlight misconfiguration and omissions from your email authentication protocols.

First thing to do is identify the IP. You can use tools like WHOIS or reverse DNS to find out the source. If it belongs to a known vendor you are using, then fix the alignment. Most third-parties will provide an include that resolves back to their list of sending IPs. Simply add that include line to your SPF. You can also add any custom DKIM used by your vendor by adding a TXT record to your DNS that contains the selector and public key.

For example, let’s take it the other way and have the IP resolve back to your ESP. Once you verify the IP as belonging to a vendor you currently work with, then check with the vendor to see what IPs or includes should be added to your SPF record. Also, if the vendor provides any custom DKIM selectors for signing emails (they should), then get the selector(s) published in DNS for your domain.

If you don’t recognize the IP and have confirmed it does not belong to an entity that should be be sending mail on your domain’s behalf, then treat it as an unauthorized spoofing attempt. What you don’t want to do in here is add the IP spoofing your domain to your SPF record. This is where setting up an email address to collect forensic reporting will be useful. This can be accomplished with the ruf tag.

For spoofing attempts, tighten up your domain policies to at least quarantine and move to reject. Once the spoofers realize their attempts to send fraudulent email from your domain are being rejected, you should see the volume drop and eventually fall off from the reporting.

Summary

With DMARC being one of the three email authentication protocols impacting deliverability, you know the importance of monitoring your reports to stay on top of your email deliverability game.

We’ve covered how much useful data is in the DMARC aggregate report and how you can decipher it to turn it into information to gauge your alignment with SPF and DKIM. And to keep abreast of spoofing attempts using your domain.

Armed with this knowledge, you can now look at a DMARC aggregate report, traverse the raw XML in report to derive insights. What was maybe daunting and mysterious just a few minutes ago is now well within your ability to determine who is sending email on behalf of your domain and your email authentication alignment.

Regular review of your DMARC aggregate reports shows when your mail is fully aligned, so you can move from p=none to p=quarantine, then finally to p=reject, with complete confidence.

If you’re new to email marketing, want a deeper dive or need a refresher, check out our post Unleash Deliverability Magic to learn more how you can make it into your audience’s primary inbox.

Don’t want to read through XML reports? I get it. It’s not for everyone. If this is you, then you’ll want to check out our DMARC Aggregate Report Analyzer tool, where you can upload your XML aggregate report and have the decoding done for you via our web application.

If anything odd turns up in your reports that wasn’t discussed in this post or you need an expert to look over your setup, ThunderSteed has you covered.

Whether you’re facing challenges requiring an email deliverability audit to get your messages into the primary inbox or just want another set of eyes to look your DMARC aggregate reports over, use the buttons below to get your audit or schedule your free consultation.