Complete SPF record setup guide, including syntax explanation and best practices
Configure DANE for SMTP with TLSA records to enforce secure delivery
Set up MTA-STS policy with Cloudflare for secure SMTP delivery
If you publish a DMARC record with a rua= address, inboxes send you a compressed XML file every day. Most teams open one, see a wall of IP addresses and counts, then close it. That is a waste: an aggregate report is the only honest answer to "who is sending mail as my domain, and does it pass?"
This guide covers the six fields that carry almost all of the signal, the three patterns that explain most reports, and how to move from p=none to enforcement without breaking legitimate mail.
A report is a gzipped XML file named after the reporting organisation and the date range. Inside, the structure repeats: one <feedback> element, one <policy_published> block describing the policy the receiver saw, and one <record> element per source IP per evaluated message group.
| Element | What it tells you | How to use it |
|---|---|---|
report_metadata/date_range | The UTC window the report covers | Reports are usually issued once per day per receiver, so do not expect real-time data |
policy_published | The p=, sp=, pct=, adkim, aspf values the receiver applied | Confirms which policy version produced this data, not what you think you published |
record/row/source_ip | The sending IP being judged | This is the unit of investigation, not the domain |
row/count | Messages from that IP in the window | Sort by this first; a single failed message is noise, ten thousand is an incident |
policy_evaluated | The receiver's DKIM and SPF verdict, plus the disposition taken | Tells you whether mail was delivered, quarantined or rejected |
auth_results | The raw DKIM and SPF results, including the authenticating domain | Shows why alignment failed, not just that it did |
policy_published first. If it shows p=none, nothing was blocked and the report is purely diagnostic. If it shows p=quarantine with pct=10, only a tenth of failing mail was affected.source_ip and sum count. One IP can appear in many records with different header-from domains.policy_evaluated/dkim and policy_evaluated/spf. Both pass means aligned and safe. Both fail at volume means either spoofing or a sender you forgot about.auth_results only for the failing rows. This is where you see whether DKIM failed because of a missing selector or because the signing domain does not align.Your ESP or mail server is aligned. Nothing to do except keep the record in your baseline so a future failure stands out.
Either someone is spoofing your domain, or a business unit signed up for a tool nobody told you about. Check whether the IP belongs to a known provider before assuming abuse. If it does not, this is exactly the traffic DMARC exists to stop, and it is your argument for moving to quarantine.
Usually a forwarder or a mailing list: the message survived, but the envelope domain changed. DKIM alignment still carries the message. Confirm with the Header Analyzer before changing any record. If forwarding is core to your flow, evaluate ARC rather than weakening SPF.
Do not jump from p=none to p=reject. Run p=none long enough to see a full weekly cycle, including any monthly invoicing or newsletter job. Then move to p=quarantine; pct=10, confirm that quarantined volume matches sources you already know, and raise pct in steps. Only move to reject when the failing sources in your reports are ones you have deliberately decided to block.
Use the DMARC Report Analyzer to parse a report without reading raw XML, the DMARC record checker to confirm what you actually published, and the Email Health check for a combined view of SPF, DKIM, DMARC and DNS.
Most receivers send one aggregate report per day per domain. If reports stop entirely, verify that the rua mailbox still accepts mail and that the DNS record was not overwritten during an unrelated change.
Check the envelope sender, not the visible From address. An SPF record authorises the domain used in MAIL FROM. If a relay rewrites that domain to something you do not control, SPF fails even though the message is legitimate.
No. A report is plain XML, so a parser is enough. Paid services mainly add retention, alerting and cross-domain dashboards, which only matter once you are monitoring several domains at once.