DMARC Report Reader
DMARC aggregate reports arrive as unreadable XML in a zip file, every day, from every mailbox provider you send to. Drop one here to see it as a table: who is sending mail as your domain, how much of it authenticates, and which sources are failing.
Parsed entirely in your browser. The report never leaves your device and we store nothing from it.
Where these reports come from
The rua= address in your DMARC record is an instruction to every receiving mail server on
the internet: tell me what you saw. They comply, daily, with an XML summary of every message that claimed
to be from your domain — how many, from which addresses, and whether SPF and DKIM lined up.
It is the only view you get of mail sent as you by servers you do not control. The catch is
that it arrives in a format built for machines, so most people set up DMARC, watch the reports pile up
unread, and never move past p=none.
Read several before changing anything. One report is one provider’s view of one day. A legitimate sender that only mails on Mondays will be absent from most reports and look like an unknown source when it does appear. Watch for a fortnight before tightening a policy.
Reading the result
The pass rate
The share of messages where SPF or DKIM passed and aligned with your From domain. Either one is enough. If this sits near 100% across several reports, your policy can be tightened safely.
Failing sources
The important column, and the one the report cannot interpret for you. A failing source is one of two things:
- A legitimate sender you forgot about. The invoicing system, a newsletter tool, a helpdesk, a form on an old site. This is the usual answer, and the fix is to authorise it.
- Someone sending mail as you. Less common, more interesting.
Telling them apart means looking at the address. The table links each one to a WHOIS and reputation lookup, which usually settles it in a few seconds — a sending address belonging to a company you recognise is your forgotten system.
Disposition
What the receiver actually did: none delivered it, quarantine sent it to
spam, reject refused it. At p=none everything says none, including
forgeries — which is exactly why p=none protects nothing.
What this can’t tell you
- Message content, subjects or recipients. Aggregate reports contain none of it — only counts grouped by sending address. That is by design.
- Whether a failing source is malicious. It reports the address and the result. Judging intent is yours.
- Anything about mail sent to domains that do not report. Most large providers send reports; many smaller ones do not, so the picture is partial.
- Forensic detail. That is the separate
ruf=failure report, which most providers no longer send at all for privacy reasons.
What to do with what you find
| What the report shows | Next step |
|---|---|
| Near 100% pass, several reports running | Move from p=none to
p=quarantine with pct=25, then raise it. |
| A failing source you recognise | Add it to SPF, or set up DKIM signing with that provider. Do this before tightening the policy. |
| A failing source you do not recognise | Look up the address. Most turn out to be a forgotten tool. If not, tightening the policy is what stops it. |
| SPF fails, DKIM passes | Normal for forwarded mail. DKIM survives forwarding, SPF does not — this is why DMARC accepts either. |
| Everything fails | Your own sending setup is misconfigured. Fix that before going anywhere near enforcement. |
Check the policy that produced these reports.
DMARC Checker Email Header Analyzer IP ReputationFrequently asked questions
Why do I get so many reports?
One per provider per day, and you are sending to more providers than you think. This is why people
point rua= at a dedicated mailbox rather than one they read.
Is it safe to open these?
The XML itself is inert data. Ordinary caution about attachments from unknown senders still applies, and this page parses the file locally rather than executing anything in it.
SPF fails but DKIM passes. Is that a problem?
No. DMARC needs one of the two to pass and align. That pattern is the signature of forwarded mail, where the forwarding server is not in your SPF record but the DKIM signature travels intact.
Can I stop the reports?
Remove rua= from your DMARC record and they stop. You then have no visibility at all,
which is a poor trade — point them at a separate mailbox instead.