What does a DMARC aggregate report actually contain?

Counts of messages grouped by source IP address and result, for one receiver over one window. Each record gives the header From domain, the SPF and DKIM outcomes, whether each aligned, and the disposition the receiver applied. There is no subject, recipient or message body — aggregate reports are statistical, not forensic.

Why does a report show SPF passing but DMARC failing?

Because the SPF pass was for a different domain than the one in the header From. The auth_results block reports the mechanism outcome; policy_evaluated reports alignment. A platform sending with its own bounce domain passes SPF for that domain and aligns with nothing, so DMARC then depends entirely on an aligned DKIM signature.

Why do I receive no RUF failure reports?

Most large receivers do not generate them. A failure report describes an individual message sent to one of their users, which is a privacy disclosure they are unwilling to make routinely. Publishing ruf is harmless, but a DMARC rollout has to be planned around aggregate reports, which are sent widely and daily.

Can I send DMARC reports to an address at a different domain?

Yes, but the destination domain must authorise it. It publishes a TXT record at the reported domain's name, then _report._dmarc, then its own domain, with the value v=DMARC1. Without that record, conforming receivers withhold the reports, which is what stops a domain directing its report volume at somebody else.

DMARC aggregate reports: reading an RUA file

What arrives, and how often

Once a domain publishes a rua address, participating receivers begin sending an aggregate report covering the messages they saw with that domain in the header From. The default interval, and in practice the only one widely honoured, is daily — the ri tag requests something else, and receivers are free to ignore it.

A report is an XML document, normally gzipped and attached to a message. The filename follows a convention of the reporting receiver, the reported domain, the start and end of the window as UNIX timestamps, and a unique identifier, which makes the attachments sortable without opening them.

Reports describe aggregate counts, not individual messages. There is no subject line, no recipient and no body — a DMARC aggregate report cannot tell you what a message said, only how many messages from a given IP address authenticated and what the receiver did about it.

The shape of the file

Every report has three parts: metadata identifying the receiver and the window, a copy of the DMARC policy as the receiver read it, and a series of record blocks. Reading the policy_published block first is worth the ten seconds: it tells you what the receiver believed your record said, which occasionally differs from what you think you published.

One record block from an aggregate report: 418 messages from a single IP address, both mechanisms passing and aligned.

<feedback>
  <report_metadata>
    <org_name>receiver.example.net</org_name>
    <report_id>18397265104928</report_id>
    <date_range><begin>1785974400</begin><end>1786060800</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>quarantine</p><sp>reject</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.25</source_ip>
      <count>418</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><selector>s2026a</selector>
        <result>pass</result></dkim>
      <spf><domain>example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Reading a record block

Each record groups messages that shared a source IP address and produced the same result. The count is the number of messages, not a percentage, and the two blocks below it answer different questions.

The policy_evaluated block is the DMARC verdict: its dkim and spf elements report alignment, not merely whether the mechanism passed, and disposition reports what the receiver did — none, quarantine or reject. The auth_results block is the raw mechanism outcome, including the domain each result was for.

The gap between those two blocks is where most of the useful information lives. A record showing spf pass in auth_results and spf fail in policy_evaluated is a message that authenticated correctly for a domain other than the one in the header From. Nothing is broken in that provider's SPF; the problem is alignment, and the fix is DKIM signing with your domain rather than more entries in your SPF record.

What the pass rates tell you

Aggregating the record blocks by source gives a per-source pass rate, which is the number a rollout is actually steered by. Every sending source is listed with its volume and SPF, DKIM and DMARC pass rates, so you can see what aligns before you tighten the policy.

Read volume and rate together. A source with three messages and a zero pass rate is a curiosity; a source with forty thousand messages and a 94 per cent pass rate is a system that mostly works and fails on a specific path — usually forwarding, which strips the SPF pass and leaves DKIM to carry the message alone. A source at exactly zero across a large volume is either an impersonator or a platform nobody configured.

Do not expect the totals to match your own sending logs. Reports come only from receivers that produce them, so a report covers a large share of consumer mailbox traffic and almost none of the mail delivered to small self-hosted domains.

Sources you will see, and what they usually are

Your own mail platform, at high volume with both mechanisms aligned. This is the baseline everything else is compared against.
A forwarding host, at low volume with SPF failing and DKIM passing. Nothing to fix; this is DKIM doing the job it exists for.
A third-party platform passing DKIM for its own domain and failing alignment. Fix by having the platform sign with your domain and a selector of yours.
A source that passes SPF through a shared provider range but has no DKIM signature at all. Alignment may hold today and will not survive a forward.
An unfamiliar IP address with a small, steady volume and no passes. Usually a spoofing attempt, occasionally a system a department bought without telling anyone.
Reports listing your own domain as the source with a failing result, which normally means a message was modified in transit rather than forged.

RUA and RUF

The rua tag requests aggregate reports; the ruf tag requests failure reports, which are per-message and contain header information, and sometimes more, from an individual message that failed. RUF is described alongside RUA in RFC 7489 and is rare in practice.

The reason is straightforward: a failure report about a message sent to somebody's mailbox is a disclosure about that person's mail, and most large receivers decided some time ago that they would not send them. A domain may publish ruf and receive nothing at all, and should assume the rollout has to be driven by aggregate data.

Where failure reports are generated, they follow the abuse reporting format, and the fo tag selects the conditions under which one is wanted — fo=1 asks for a report whenever any mechanism fails, which is considerably more traffic than the default fo=0.

Receiving reports at another domain

Sending reports to an address outside the domain being reported on requires the receiving domain to agree, or anyone could point a high-volume domain's reports at a victim. The agreement is a DNS record published by the destination.

The name is the reported domain, then _report._dmarc, then the destination domain, and the value is a DMARC version tag. Without it, conforming receivers will not deliver reports to the external address, and a rollout stalls with an empty inbox that looks exactly like a domain nobody spoofs.

Published by example.net to authorise reports about example.com being sent to an address at example.net.

example.com._report._dmarc.example.net. IN TXT "v=DMARC1"

From report to change

A report is only worth receiving if it changes something. The loop is short: identify a source, decide whether it is yours, and then either make it align or accept that it will be rejected.

Match every source IP address to an owner before deciding anything. Reverse DNS and a WHOIS lookup on the address usually name the platform outright.
For sources that are yours and unaligned, prefer DKIM. It survives forwarding and it does not consume an SPF lookup.
For sources that pass SPF through a shared range, add DKIM anyway. A pass that depends on a range shared with other customers is weaker than a signature.
For sources that are not yours, do nothing except tighten the policy. Enforcement is the response to impersonation; there is no takedown step in DMARC.
Re-check after each change against the next reporting cycle, and only then move the policy on.

Check this on your own domain. The dmarc record checker reads the live records and reports what a receiver would see.

Open the dmarc record checker

Common questions

What does a DMARC aggregate report actually contain?: Counts of messages grouped by source IP address and result, for one receiver over one window. Each record gives the header From domain, the SPF and DKIM outcomes, whether each aligned, and the disposition the receiver applied. There is no subject, recipient or message body — aggregate reports are statistical, not forensic.
Why does a report show SPF passing but DMARC failing?: Because the SPF pass was for a different domain than the one in the header From. The auth_results block reports the mechanism outcome; policy_evaluated reports alignment. A platform sending with its own bounce domain passes SPF for that domain and aligns with nothing, so DMARC then depends entirely on an aligned DKIM signature.
Why do I receive no RUF failure reports?: Most large receivers do not generate them. A failure report describes an individual message sent to one of their users, which is a privacy disclosure they are unwilling to make routinely. Publishing ruf is harmless, but a DMARC rollout has to be planned around aggregate reports, which are sent widely and daily.
Can I send DMARC reports to an address at a different domain?: Yes, but the destination domain must authorise it. It publishes a TXT record at the reported domain's name, then _report._dmarc, then its own domain, with the value v=DMARC1. Without that record, conforming receivers withhold the reports, which is what stops a domain directing its report volume at somebody else.

Keep reading

Related checks, definitions and guides.

Turning DMARC XML into a list of things to fix