How to read DMARC reports

Once your DMARC record includes a rua address, email providers start sending you reports about mail that used your domain. Those reports show who is sending as yourbusiness.com, including services you forgot about and anyone pretending to be you. (What is DMARC?)

The reports arrive as compressed XML files, which look intimidating. You only need a handful of the fields, and a viewer can read them for you. If you haven't published a DMARC record yet, start with how to stop email spoofing and come back once reports arrive.

What is a DMARC aggregate report?

An aggregate report is a summary from one receiving email provider, usually covering one day, of every message it saw that claimed to come from your domain. RFC 9989, the current DMARC standard, replaced the older RFC 7489 and says providers should send these reports at least once every 24 hours. The report format itself is defined in a companion document, RFC 9990.

Each report is an email with an XML attachment, usually gzip-compressed. Microsoft notes that the subject line names the provider that sent the report and the domain it covers. You get one report per provider per day, so the number grows with how many different providers you email. Google says large organizations can receive hundreds or even thousands a day. A small business will see far fewer.

Not every provider sends reports. The standard recommends it but doesn't require it, so treat your reports as a sample of your mail, not a complete record.

Google and Microsoft both recommend sending reports to a dedicated mailbox or group rather than someone's personal inbox. If you don't have one yet, create a shared mailbox such as dmarc@yourbusiness.com and point your rua tag at it. Microsoft suggests reviewing the reports weekly while you set up DMARC, and monthly once things are stable.

If the reports go to an address at a different domain, that domain has to say it accepts them. Google's example: for reports about yourbusiness.com sent to an address at otherdomain.com, otherdomain.com publishes a TXT record named yourbusiness.com._report._dmarc.otherdomain.com with the value v=DMARC1;. Without it, providers won't deliver the reports.

What's inside the XML file?

Here is a shortened report with one record. Real reports often have many records, one for each sending server and result.

<feedback>
  <report_metadata>
    <org_name>Example Mail Provider</org_name>
    <date_range>
      <begin>1792540800</begin>
      <end>1792627199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourbusiness.com</domain>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourbusiness.com</header_from>
      <envelope_from>bounces.newsletter-service.example</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourbusiness.com</domain>
        <selector>news</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounces.newsletter-service.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

What each part tells you:

• report_metadata names the provider that sent the report and the period it covers. The begin and end times are Unix timestamps (seconds since 1970), which a viewer converts for you.
• policy_published repeats the DMARC record the provider found for your domain.
• source_ip is the server that sent the mail, and count is how many messages it sent as your domain in that period.
• policy_evaluated is the DMARC verdict. Its dkim and spf values say whether each check passed and was aligned, meaning the domain it checked matches the domain in your From address.
• disposition is what the provider did with those messages: none, quarantine or reject. Reports built on the newer standard can also say pass.
• identifiers shows the From domain people see (header_from) and the behind-the-scenes sender domain SPF checked (envelope_from).
• auth_results holds the raw SPF and DKIM results before alignment, along with the domain each check used and the DKIM selector.

The example shows the pattern Microsoft calls the classic alignment problem. SPF passed in auth_results, but only for the newsletter service's own domain, so it fails in policy_evaluated. The messages still pass DMARC because DKIM passed and aligned. Only one of the two has to.

How do I tell my real senders from spoofers?

Sort every sending source in your reports into one of three groups. Working through it once gives you a list you can reuse every time you check.

1. Write down every service that should send email as your domain: your mailbox provider, plus tools like a newsletter service, online store, booking system or invoicing app.
2. Match each source in the report to one of those services. A viewer usually shows the company that owns each IP address, which saves you looking them up.
3. Mark the sources that belong to your services and pass DMARC. These need nothing from you.
4. Mark the sources that belong to your services but fail DMARC. This is your to-do list. Microsoft's usual fixes are turning on DKIM signing with your own domain inside that service, or adding the service to your SPF record.
5. Whatever is left, sources you don't recognize that fail both checks, is likely spoofing. Microsoft flags a high message count from an unknown IP address as a sign of a possible spoofing campaign. Microsoft's guidance is that these need no action from you, because a stricter DMARC policy is what stops them.

Forwarded mail is the one gray area. When a mailing list or a recipient's forwarding rule passes your message along, SPF usually fails, and DKIM can fail if the content was changed. Microsoft describes this as normal for forwarded mail. You can't fix it from your end, which is one reason to make sure your own mail carries a DKIM signature: RFC 9989 notes that DKIM signatures generally stay valid when mail is relayed.

Set aside a short session this week to go through your latest reports and write down every service you find.

Do I need a DMARC report viewer?

You can open the XML in a text editor, but RFC 9989 recommends having a machine parse the reports rather than reading them by eye. You have a few options.

• Use a free online viewer that turns an uploaded report into a table. This works well when you have a handful of senders and are still at p=none.
• Build your own. Microsoft suggests automation with PowerShell or Power BI, and Google suggests loading the XML into a database or applying an XSL style sheet to turn it into a web page.
• Pay a DMARC reporting service to collect reports for you, combine them across providers and flag failing senders. Google recommends using one, and Microsoft points to DMARC reporting vendors in its Microsoft Intelligent Security Association (MISA) partner catalog.

With a service, your reports go straight to the provider: you add its address to your rua tag, and the service's own domain publishes the authorization record that lets it receive reports for yours. Before you sign up, read how it stores and uses that data.

For most small businesses, a free viewer is enough while you set things up. Consider a paid service if your report volume grows or you'd rather have alerts than check by hand.

Check your DMARC policy and reporting address

Our free checkup shows your DMARC policy, whether reports are turned on, and how your SPF and DKIM look, then explains what to fix.

• Free check
• No signup
• No changes to your website

Get your free report in seconds.

Your website address

Check my website

When is it safe to move from p=none to quarantine or reject?

At p=none, which RFC 9989 calls Monitoring Mode, you get reports but providers are asked to do nothing special with fakes. Your reports tell you when it's time to move on.

Don't rush this. RFC 9989 says it can take many months of reports before some domains are sure all their mail is authenticated. If people at your business post to mailing lists, the standard advises against p=reject, and says a domain that wants it anyway should first spend at least a month at p=none, then an equally long period at p=quarantine. It also says a domain at p=reject must not rely on SPF alone to pass DMARC, which in practice means signing your mail with DKIM.

When you're ready, replace your existing record rather than adding a second one:

Older guides, including some provider documentation, suggest easing in with values like pct=25. RFC 9989 retired the pct tag because providers applied in-between percentages inconsistently. Its replacement is a testing flag, t=y, which asks providers to apply one level below your stated policy, so quarantine is treated as none and reject as quarantine.

If real mail starts landing in spam after you tighten the policy, step back to the previous setting, fix that sender, and try again. Our fix guide for a DMARC policy that isn't enforced yet has the exact records for each host.

What are forensic (ruf) reports, and are they private?

Failure reports, often called forensic reports, describe individual messages that failed DMARC and arrive soon after the failure. You request them with a ruf tag. Unlike aggregate reports, they can include header fields or even the whole message, so RFC 9991 warns they may contain personal information about your staff or customers.

Many providers don't send them. Microsoft 365 doesn't send failure reports even when a ruf address is published, and RFC 9989 notes that providers concerned about privacy either redact them heavily or skip them entirely.

For a small business, leave ruf out of your record. Microsoft suggests starting with rua only and adding ruf later if you need it. If you do turn failure reports on, send them to a mailbox only one or two people can open.

Aggregate reports carry far less. RFC 9990 says they contain domain-level authentication data, not personal information. RFC 9989 adds that in a small organization, even a summary from one receiving domain can reveal sensitive business information, so keep the report mailbox limited to the people who need it.

What should you do next?

1. Check that your DMARC record includes a rua address with our free DMARC checker.
2. Fix the senders that fail. On Microsoft 365, start with DKIM for Microsoft 365. If SPF is the problem, SPF too many DNS lookups covers a common cause.
3. Once your reports are clean, move to p=quarantine, then p=reject, using the steps in DMARC policy not enabled.