Publishing a DMARC record with a reporting address means inbox providers start sending you daily XML reports about every source sending mail as your domain.
Almost nobody reads them. The file is machine-formatted, it arrives zipped, and the first time you open one it is not obvious what you are looking at.
That is a shame, because these reports answer a question nothing else does: who is sending mail claiming to be you, and is it passing authentication?
You do not need a paid tool to read one. You need to understand six fields.
Getting the reports
Your DMARC record includes a rua tag with an address:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comReports arrive daily from each provider (Google, Microsoft, Yahoo and others) as zipped XML attachments. One per provider per day per domain.
Send them to a dedicated mailbox. At thirty sending domains this is a lot of mail, and it will bury a real inbox.
The structure
Every aggregate report has two parts.
The metadata block names the reporting provider, the date range, and the DMARC policy they saw published.
The record blocks are the useful part. One per sending source, each containing:
| Field | What it means |
|---|---|
source_ip |
The IP that sent the mail |
count |
How many messages from that IP in this period |
disposition |
What the provider did: none, quarantine or reject |
dkim |
DKIM result: pass or fail |
spf |
SPF result: pass or fail |
header_from |
The domain in the visible From address |
That is genuinely it. Six fields per source, and everything you need is in them.
Reading one by hand
Open the XML in any text editor. For each record block, ask three questions in order.
1. Do I recognise this IP?
Look it up. If it is your sending platform, your mailbox provider or your own infrastructure, fine. If it is not, and the count is meaningful, someone is sending mail as your domain.
2. Did it pass?
You want pass on DKIM, SPF, or both. DMARC passes if either passes and aligns with the From domain.
3. What happened to the mail?
disposition: none means it was delivered despite any failure, because your policy is p=none. Under quarantine or reject it would have been filtered or bounced.
The three failures worth acting on
Your own mail failing
Your sending IP shows spf: fail or dkim: fail on a meaningful count.
Usual causes: SPF record exceeding the ten-lookup limit, which fails silently and is by far the most common. A DKIM key not published for that sending source. Or a configuration change that broke one without anyone noticing.
Why it matters: this is mail you are paying to send, arriving with a visible authentication failure. Fix it before anything else.
Alignment failures
Both SPF and DKIM show pass, and DMARC still fails.
This is the subtle one. DMARC requires the authenticated domain to align with the domain in the visible From address. You can pass SPF for sendgrid.net while your From header says yourdomain.com, and that is a DMARC failure despite the pass.
The fix is usually a custom return-path or signing domain configured at your sending platform so the authenticated domain matches what recipients see.
Unknown senders
An IP you do not recognise, sending as your domain, in volume.
Possibilities, in order of likelihood: a forgotten tool somebody connected years ago; a legitimate service you forgot authorises itself as you; a forwarding service; or actual spoofing.
Most of the time it is the first two and the answer is to authorise or remove it. Occasionally it is the fourth, which is exactly what DMARC exists to surface.
What the reports will not tell you
Which folder mail landed in. DMARC reports cover authentication, not placement. A fully-passing message can sit in spam. For that you need an inbox placement test.
Message content or recipients. Aggregate reports contain no personal data, that is the design.
Why reputation dropped. Authentication is one input among several.
Anything about providers who do not report. Not every receiver sends DMARC reports. Your view is partial.
A workable routine
You do not need to read these daily.
Weekly, five minutes: scan for any source failing in volume, and any IP you do not recognise.
After any change: new sending domain, new platform, added infrastructure. Check reports for the following week specifically.
Monthly: review the whole sending source list. Anything still there that should not be?
If you run many domains, a parsing tool earns its place. For under ten, reading the XML by hand once a week is entirely manageable and gives you a better feel for your own estate than a dashboard does.
Moving past p=none
Most cold senders publish p=none and stop, which satisfies the requirement and does nothing protective. p=none means “report but take no action.”
The progression:
p=none, monitoring only. Start here, stay for at least a few weeks of clean reports.
p=quarantine, failing mail goes to spam. Move here once reports show all your legitimate sources passing and aligning.
p=reject, failing mail is bounced. The strongest signal to providers, and the riskiest if you have a source you forgot about.
Do not skip to reject without reading reports first. That is precisely what the monitoring phase is for, and skipping it means discovering a forgotten legitimate sender by having its mail bounced.
A reasonable pace: a month at none, a month at quarantine, then reject if nothing broke.
The short version
DMARC aggregate reports answer a question nothing else does: who is sending as your domain, and does it pass. Six fields per source, readable in a text editor.
Look for three things, your own mail failing authentication, passes that fail alignment anyway, and IPs you do not recognise. The first is usually an SPF lookup limit, the second usually a return-path configuration, the third usually a forgotten tool.
Send reports to a dedicated mailbox, scan weekly, and use the monitoring period for what it is for: moving from p=none to quarantine to reject once you know every legitimate sender passes.
Next: SPF, DKIM and DMARC explained, or the bulk sender requirements.
Frequently asked questions
How do you read a DMARC report?
Open the XML and look at each record block for six fields: source IP, message count, disposition, DKIM result, SPF result and the From domain. Check whether you recognise the IP, whether it passed, and what the provider did with the mail.
Why does DMARC fail when SPF and DKIM pass?
Alignment. DMARC requires the authenticated domain to match the domain in the visible From address. Passing SPF for your sending platform’s domain while your From header shows your own domain is a DMARC failure.
Do I need a tool to read DMARC reports?
Not under about ten domains. The XML is readable in any text editor and contains six relevant fields. Parsing tools earn their place at larger estates.
Should cold email senders use p=reject?
Eventually, but not immediately. Start at p=none, read reports until every legitimate source passes and aligns, move to quarantine, then reject. Skipping to reject risks bouncing mail from a sender you forgot about.