DNSVerdictAll toolsGuidesHow it works

DMARC reports explained: rua, ruf and external addresses

Published · Updated

rua reports are periodic XML summaries (usually daily) from receivers that list which IP addresses sent mail as your domain and whether SPF and DKIM passed with alignment. ruf reports are per-message failure copies, which most receivers no longer send for privacy reasons. If your report address is on a different domain than the one being reported, that other domain must publish a TXT record under _report._dmarc, or receivers drop the address. Check what your record asks for with the DMARC checker.

Which RFC defines what

Under DMARCbis, RFC 7489 was split into three documents, all May 2026: RFC 9989 (the protocol and the rua / ruf tags), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). RFC 7489 is obsolete but its format is what many receivers still send.

Aggregate reports (rua)

Enable them with a tag in the record. Receivers must support mailto: (RFC 9989 §4.7):

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Reports normally arrive gzip- or zip-compressed as email attachments. One report covers one policy domain and one reporting period (RFC 9990 §3.1). The XML structure:

ElementWhat it tells you
report_metadataWho sent the report (org_name, email), report_id, date_range as epoch seconds
policy_publishedThe policy the receiver saw: domain, p, sp, np, adkim, aspf, fo, testing, discovery_method (RFC 9990 §3.1.1.5)
record/row/source_ipThe connecting IPv4 or IPv6 address
record/row/countNumber of messages from that IP in the period
row/policy_evaluateddisposition (none, quarantine, reject), and DMARC-level dkim and spf results (pass or fail), plus an optional reason such as local_policy, mailing_list, policy_test_mode, trusted_forwarder
identifiersheader_from (required), optionally envelope_from, envelope_to
auth_resultsRaw dkim (domain, selector, result) and spf (domain, result) outputs, before alignment

Reports from receivers using the older schema use the same core structure; element names such as testing and np are DMARCbis additions, so older reports omit them.

Reading a row

<row><source_ip>203.0.113.7</source_ip><count>412</count>
  <policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>pass</spf></policy_evaluated></row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results><spf><domain>example.com</domain><result>pass</result></spf></auth_results>

Here SPF passes and is aligned, so DMARC passes, and the DKIM failure is irrelevant. Compare policy_evaluated with auth_results to see alignment problems: if auth_results says pass but policy_evaluated says fail, the passing domain does not match the From domain. That pattern is explained in DMARC fails although SPF and DKIM pass.

Work through the sources by volume. Known senders that fail need fixing; unknown IPs with large counts are either forgotten services or abuse. Raw XML is tedious at scale, and a report-processing service or a script parsing the XML saves time; those services see your reports and sender IPs, which is a privacy trade-off. The next step is moving the policy toward enforcement.

Failure reports (ruf)

ruf asks for message-level reports when a message fails, with options set by fo (RFC 9989 §4.7; RFC 9991 §2). They may contain headers and body parts. RFC 9991 §7.1 warns they “may include PII and non-public information”, and says many large providers limit or disable them. RFC 9989 §10.2 states “most Mail Receivers refuse to send them out of privacy concerns.” So publishing ruf yields little, and if you do receive reports, treat the mailbox as holding personal data: restrict access, set retention, and check your privacy policy. Per RFC 7489 §6.3, fo=1 asks for a report on any underlying failure and the default fo=0 only when all mechanisms fail to produce an aligned pass; RFC 9989 §4.7 lists the values 0, 1, d and s.

External destinations

If the rua address is at another domain, receivers verify consent first. For blue.example.com reporting to red.example.net, the receiver looks up a TXT record at blue.example.com._report._dmarc.red.example.net that begins with v=DMARC1. A wildcard *._report._dmarc.red.example.net authorizes any domain. If the check fails, the URI is ignored (RFC 9990 §4; failure reports use the same pattern in RFC 9991 §5).

; published by the report receiver (red.example.net)
example.com._report._dmarc.red.example.net.  3600  IN  TXT  "v=DMARC1"

Report services normally tell you the exact record, and publish the wildcard on their side. If reports from a service never arrive, a missing authorization record is the first thing to look at. A report address inside the same organizational domain as the policy domain needs no authorization record. The legacy equivalent is RFC 7489 §7.1.

FAQ

I set rua but received nothing after a week. Check the address spelling, the mailto: prefix and external authorization. Not every receiver sends reports, and small ones do not.

Do aggregate reports contain message content? No. They are statistics. RFC 9990 §7.2 says they hold domain-level aggregate data, though RFC 9989 §10.1 notes small senders may reveal limited sending patterns.

Can I send reports to two addresses? Yes, comma-separated: rua=mailto:a@example.com,mailto:b@example.net. Each external address needs its own authorization.

Sources

Tools used

DMARC Record CheckerEmail Header Analyzer