What is inside the file
Once a day, the mailbox providers your recipients use send your domain an XML file listing every IP address that sent mail carrying your domain, how many messages each one sent, and whether that mail passed SPF and DKIM in a way that counted. Those files are DMARC aggregate reports, they arrive because your DMARC record publishes a rua address, and they are the only view anyone gives you of who is sending as you.
They arrive gzipped, with a filename nobody designed for humans, and most people delete a few before asking what they are. This walks through one report field by field, then through the decisions the reports exist to support. It assumes you own the domain and can change its DNS, and that you have already published something at _dmarc. DMARC stands for Domain-based Message Authentication, Reporting and Conformance, and the reporting half is the part almost nobody uses.
Two kinds of report, and you probably only see one
Aggregate reports are the daily XML summaries, requested with the rua tag. Failure reports, requested with ruf, are per message and contain parts of the message itself. In practice almost nobody receives useful volumes of the second kind, because most large receivers do not send them, so treat aggregate reports as the whole of what you get.
That shapes what the data can tell you. Aggregate reports count messages by source and result. They do not contain subject lines, recipients, or the message body, and they cannot tell you which specific email bounced this morning.
The filename tells you the window before you open anything
The naming pattern is set out in RFC 9990, the aggregate reporting specification, as receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension, where the extension is xml or xml.gz. Following that pattern, a day of reporting from Google for example.com arrives as google.com!example.com!1789948800!1790035200.xml.gz.
Those two numbers are Unix timestamps for the start and end of the window, which is usually 24 hours. Compression is not optional in the specification: the report data must be gzipped, on the practical grounds that an uncompressed report can be too large for the receiver on the other end to process. To read one, unzip it and open the XML in a text editor. It is verbose rather than complicated, and a domain with three senders produces a short file.
policy_published is your own record read back to you
The first block after the report metadata is the receiver telling you what it found in your DNS when it made the decision. It carries domain and p as required fields, and optionally sp, np, adkim, aspf, discovery_method, fo and testing.
Read this block first, every time. It is the cheapest way to catch a DNS mistake, because it shows the policy a real receiver resolved rather than the one you believe you published. If you changed your record on Tuesday and Thursday’s report still shows the old policy, you have a propagation or a syntax problem, and that outranks anything else in the file.
Each record is one sending source for the period
Then comes a list of record elements, and this is the body of the report. Every record contains row, identifiers and auth_results.
Inside row you get three required pieces: source_ip, the address that connected; count, how many messages came from it in the window; and policy_evaluated, which holds the disposition the receiver applied, plus its dkim and spf verdicts. Under identifiers sits header_from, the domain your recipients actually see, with envelope fields as options.
auth_results is the evidence, policy_evaluated is the verdict
This pair confuses almost everybody the first time, and the difference is the single most useful thing to understand about these files.
auth_results reports the raw authentication checks: which domain DKIM signed for, with which selector, and what SPF returned for the envelope sender. policy_evaluated reports something narrower, which is whether those results aligned with the domain in the From header. A message can show a DKIM pass in auth_results and a DKIM fail in policy_evaluated, and that is not a contradiction. It means the signature was valid and belonged to somebody else’s domain.
Alignment is the part people misread
DMARC requires what RFC 9989 calls identifier alignment between the domain in the From header and an authenticated identifier. If one or more of those identifiers aligns, the message passes. You do not need both SPF and DKIM to pass, you need at least one of them to pass and to match.
Both adkim and aspf default to relaxed, written r, which accepts a match at the organizational domain level. Under relaxed alignment, a DKIM signature from mail.example.com aligns with a From address at example.com. Under strict, written s, it does not. Most domains should stay relaxed, and most alignment failures in a report are a subdomain or a vendor signing with its own domain rather than yours. That distinction is the same one that makes the SPF record itself pass while DMARC still fails.
Turning a week of reports into changes
The reports are not the work. The work is the short list of decisions they support, and for most domains that list stops changing after about a month.
Sort by count, not by failure
The instinct is to jump to the failures. Resist it for ten minutes and sort by count instead, largest first. That ordering tells you what your domain really sends, which is usually the first honest inventory anybody has had of it.
Three or four sources will cover the overwhelming majority of your volume: the mailbox provider, whatever sends receipts, the marketing platform. A long tail of single digit counts follows. The tail is where the surprises live, but the head is where your business risk lives, because a policy change breaks the head first.
Every source falls into one of three buckets
Yours and passing. Yours and failing. Not yours. Put every source into one of those before touching your policy, and write the list down somewhere that is not your inbox.
Yours and failing is the bucket that takes the work: an application sending directly from a server nobody added to the record, a helpdesk signing with its own domain, a subdomain with no DKIM at all. Not yours splits again, into forwarding, which is harmless, and genuine abuse, which is not. Telling those two apart is mostly a matter of looking at whether the same source also carries a passing DKIM signature from you.
Forwarding shows up as failure and is not your fault
When somebody forwards your message, the forwarding server relays it from its own address, so SPF fails. Mailing lists do the same thing and often rewrite the message as well, which can break the DKIM signature too. Both produce failures in your reports for mail you sent correctly.
This is the strongest practical reason to sign everything with DKIM. A signature travels with the message and usually survives a plain forward, so the message still aligns after SPF has stopped being useful. A domain relying on SPF alone turns every forwarded message into a coin toss, and the reports will show you exactly how often that coin is flipped.
The pct tag is gone, and t is how you test now
If you are reading older guides, this will save you an afternoon. RFC 9989 was published in May 2026 and obsoletes RFC 7489, and one of its changes is the removal of the pct tag, which used to let you apply a policy to a percentage of mail. Appendix A.6 of the new specification is titled Removal of the pct Tag.
What replaces it is the t tag, which signals whether you want the policy in p, sp or np to be applied at all, or whether you are still testing. The practical effect is that the old habit of creeping from pct=10 upward no longer exists. You move between policies, and you use test mode while you are not ready for the one you have published.
When it is safe to leave p=none
The specification is direct that you should start at p=none, precisely so the reports can audit your own mail streams before anything is enforced. The question is when to stop.
A reasonable bar: every source in your yours and passing bucket has been passing for several consecutive weeks, nothing in yours and failing is still sending real mail, and you have looked at a week that contains your heaviest sending day rather than a quiet one. Monthly invoicing runs and seasonal campaigns are the classic thing to miss, because they appear in the reports once a month and break on the month you enforce. Move to quarantine first, watch, and only then consider reject. While you are there, decide on np as well, which sets the policy for non-existent subdomains and costs you nothing because nothing legitimate sends from them.
The sources you cannot identify
You will have a few. A cloud IP range with a handful of messages, no DKIM signature, no obvious owner. Before assuming it is abuse, check the boring explanations: a monitoring tool that emails alerts, a former employee’s automation, a plugin on a website sending through the host’s default mailer, a scanner. A reverse lookup on the address and a note of the sending volume settles most of them in a minute.
The pattern that matters is volume with no pass and no plausible owner, sustained over days. That is worth treating as someone using your domain, and it is one of the arguments for enforcement rather than a reason to delay it. If the mail is not yours and it is not authenticated, a policy of reject is the thing that stops it.
Reading them every week is the job
None of this is difficult once. It is difficult forty times, which is the number of weeks between the month you set DMARC up and the month a new tool starts sending as you without telling anyone. The reports keep arriving, the XML does not get more readable, and the review quietly stops happening.
That is the part Email Authentication is built around. We find every service that sends as you, put one clean SPF record in place, sign each sender with DKIM, and publish DMARC, then read the reports each week so an unauthorized sender is something you hear about from us. Nothing is enforced before your real mail passes: the record moves to quarantine and then reject when the reports show it is safe, with 90 days of history behind the decision. If you want to see how that compares with a plugin that publishes records or with doing it in house, the authentication comparisons lay it out, and deliverability is the layer that takes over once the records are right and mail still lands in junk.
Two neighboring things worth fixing while you are in the DNS. Mail sent by your website through the server’s default mailer is a frequent entry in the failing bucket, which a real sending path such as Email Delivery for Cloudflare or a proper transactional email setup removes. And if the record you are editing is hard to find or nobody is sure who controls the zone, that is a DNS problem wearing an email costume, which the rundown of DNS record types is a decent place to start on.
