How to read DMARC reports

To read a DMARC report, look at each source IP address, the message count, and the SPF and DKIM alignment results beside it. Rows where at least one of SPF or DKIM passes in alignment with your From domain are compliant; rows where both fail are either a legitimate sender you have not authorised yet or someone spoofing your domain.

That is the whole job in one sentence, but the raw material makes it feel harder than it is. Aggregate reports arrive as XML attachments with unfriendly filenames, and a busy domain can receive dozens per day. This guide explains where the reports come from, what each part of the XML means, how to interpret the pass and fail columns, and which findings deserve your attention first.

Where do DMARC reports come from?

When you publish a DMARC (Domain-based Message Authentication, Reporting and Conformance) record with a rua tag, you are asking receiving mail servers to send you a summary of every message they saw claiming to be from your domain. Google, Microsoft, Yahoo and many other providers honour this and send an aggregate report, typically once every 24 hours per receiver.

A minimal record requesting reports looks like this:

_dmarc.example.co.uk.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk"

Each report covers one receiver's view over one reporting window. So if Google, Microsoft and Yahoo all handled mail claiming to be from your domain yesterday, you get at least three separate reports, each describing only the mail that particular receiver processed. No single report is the full picture; the value comes from aggregating them. Not every receiver participates, but the large mailbox providers that handle most of the world's mail all do.

Note that aggregate (rua) reports contain counts, IP addresses and authentication results, never message content. The separate failure report type (ruf) can contain message data, but few receivers send it.

What does the XML actually contain?

Every aggregate report follows the schema defined in RFC 7489 and has three parts:

• Report metadata: the organisation that generated it (for example google.com), a report ID, and the date range the report covers.
• Published policy: the DMARC policy the receiver saw when it evaluated your mail, including p, sp, pct, and the alignment modes adkim and aspf. This is useful for confirming that a recent record change has propagated.
• Records: one <record> block per unique combination of source IP and authentication outcome. This is where you spend your time.

Here is a simplified record block, the kind of row you will read hundreds of:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>127</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.co.uk</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.co.uk</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Reading it: 127 messages arrived from IP 209.85.220.41 with example.co.uk in the From header. DKIM passed and was aligned, SPF passed but was not aligned (more on that distinction next), so DMARC passed overall and the disposition was none, meaning the mail was delivered normally. A fuller field-by-field walkthrough is in our aggregate report anatomy guide.

How do I interpret the pass and fail columns?

The single most common reading mistake is confusing raw authentication results with aligned results. A report shows you both, and they answer different questions.

• Raw results (the auth_results section) tell you whether SPF and DKIM passed at all, for whatever domain they were evaluated against.
• Evaluated results (the policy_evaluated section) tell you whether each check passed and aligned with your From header domain. This is what DMARC actually cares about.

In the example above, SPF passed for bounce.mailer.net, the Return-Path domain used by a sending service. SPF (Sender Policy Framework) always checks the RFC5321.MailFrom domain, not the visible From header. Because bounce.mailer.net does not match example.co.uk, the pass does not align, and the evaluated SPF result is fail. DKIM (DomainKeys Identified Mail) passed with d=example.co.uk, which does match, so the evaluated DKIM result is pass.

DMARC needs only one aligned pass. SPF-aligned or DKIM-aligned, either is enough. So the row above is fully compliant, and the SPF fail is not a problem to fix, though adding an aligned SPF path gives you resilience if DKIM ever breaks. If the alignment logic is new to you, DMARC alignment explained covers it properly.

The four row patterns you will see

Evaluated DKIM	Evaluated SPF	DMARC outcome	What it usually means
pass	pass	pass	Fully authenticated source, ideal state
pass	fail	pass	Common for sending services with their own Return-Path, or forwarded mail where DKIM survived
fail	pass	pass	DKIM missing, misconfigured, or broken in transit; SPF alignment is carrying you
fail	fail	fail	An unauthorised legitimate sender, badly broken authentication, or spoofing

How do I work out what a source IP is?

The report gives you an IP address, not a name, so identification is the real work. For each significant source:

1. Reverse DNS lookup. A PTR record like mail-sor-f41.google.com or o1.ptr.sendgrid.net often identifies the operator immediately.
2. WHOIS the IP range. If there is no useful PTR, the registered owner of the address block (Microsoft, Amazon, a hosting company) narrows it down.
3. Check the auth_results domains. The SPF domain and DKIM d= and selector in the record often name the service even when the IP does not. A selector like k2 or an SPF domain of sendgrid.info is a strong fingerprint.
4. Ask internally. Marketing platforms, CRMs, helpdesks, invoicing tools and monitoring systems all send mail that IT did not set up. A short survey of teams often explains a mystery source faster than any lookup.

Expect to find more senders than you knew about. That discovery is the main purpose of the monitoring phase, and finding all your email senders goes deeper on the process. Sources you cannot identify at all deserve their own treatment; see unknown sources in DMARC reports.

What should I act on first?

Do not try to chase every row. Sort your failing sources by volume and work down the list in this order:

1. High-volume failing sources you recognise. A legitimate service failing DMARC at scale is your biggest risk when you eventually enforce, because that mail would be quarantined or rejected. Fix it by setting up DKIM signing with your domain at the provider, or adding their include to your SPF record where alignment allows.
2. Low-volume failing sources you recognise. Same fix, lower urgency. These are often internal systems, printers, or a tool one team quietly adopted.
3. Failing sources you cannot identify. Some are abuse of your domain, which DMARC enforcement will eventually block; that is the system working. Others are forwarding: a recipient auto-forwards your mail, the forwarder's IP fails SPF, and if the body was modified DKIM fails too. Forwarding patterns typically show up as many distinct IPs each sending one or two messages. Why forwarding breaks SPF explains the mechanics.
4. Passing sources. Nothing to do, but note which ones rely on a single aligned mechanism, since they have no safety net.

A practical benchmark: when your known senders are consistently above roughly 98 percent aligned and the remaining failures are recognisable as forwarding or abuse, you are in good shape to start moving from p=none towards enforcement.

Why do the numbers never quite add up?

A few quirks trip people up when they compare reports against their own sending logs:

• Reports lag. Most receivers report on a 24-hour cycle, and some arrive a day or two after the window they describe. Yesterday's campaign appears gradually, not immediately.
• Coverage is partial. Only receivers that generate reports appear. Mail to small servers and some corporate systems is invisible to you, so report totals will undercount real volume.
• Counts are per receiver. A message sent to five Gmail recipients may appear as a count of five in Google's report. Reports count messages processed, not campaigns sent.
• Windows differ. Report date ranges are in UTC and do not align with your local day or your sending schedule.

None of this undermines the data. Trends across days and weeks are reliable even when a single day's totals look odd.

Do I need a tool, or can I read the XML by hand?

Reading a handful of reports by hand is worthwhile at least once, because it teaches you exactly what the data means. It does not scale. A modest domain can receive thousands of records per week across many gzipped attachments, and the questions you actually need answered (which sources are failing, is this IP new, has alignment improved since last month) are aggregation questions that XML files answer badly.

Most organisations point the rua address at a DMARC monitoring service such as DMARCHub, which collects the reports, resolves IPs to named senders, and tracks alignment over time in a readable dashboard (see /features). Whatever tooling you choose, the reading skills are the same: identify the source, check aligned SPF and DKIM, and prioritise high-volume legitimate failures.

Frequently asked questions

How often do DMARC reports arrive?

Most receivers send one aggregate report per domain per 24-hour period, and the DMARC specification treats daily reporting as the norm. You will receive one report from each participating receiver that handled mail claiming to be from your domain that day, so busy domains receive many reports daily and quiet domains may receive none at all on some days.

Why am I getting DMARC reports for a domain that sends no email?

Reports are generated for any message that claims your domain in the From header, whether or not you sent it. Reports for a dormant domain mean someone else is using its name, which is exactly why non-sending domains need a locked-down DMARC policy of their own.

Can DMARC reports contain personal data?

Aggregate reports contain source IP addresses, domains, counts and authentication results, but no message bodies, subject lines or recipient addresses. IP addresses can be personal data in some legal frameworks, so treat report data with normal care, but there is no message content in the aggregate stream.

What does disposition mean in a DMARC report?

The disposition is what the receiver actually did with the failing mail: none (delivered normally), quarantine (typically sent to spam) or reject. It usually mirrors your published policy, but receivers may apply local overrides, for example delivering a mailing-list message despite a reject policy, and the report records the override reason when they do.