DMARC report reader
Aggregate reports arrive as XML nobody wants to read, usually zipped, from a dozen receivers a week. Drop one in and see who is sending as your domain, what authenticated, and what to fix first.
- Parsed in this tabThe file never leaves your machine
- .xml, .gz and .zipStraight from the mail attachment
- Alignment computed hereNot taken from the reporter's own verdict
or paste the XML
The distinction most readers get wrong
A DMARC report carries two different results for SPF and two for DKIM, and they are routinely different:
| Field | What it is |
|---|---|
auth_results/spf/result |
The raw result. Did SPF pass for the envelope sender? |
policy_evaluated/spf |
The aligned result. Did the domain that passed also match the
From: header domain? |
A source can show auth_results/spf/result = pass and
policy_evaluated/spf = fail at the same time. SPF authenticated correctly; the
MAIL FROM domain just does not align with what the recipient sees. That is a
completely different fix from "SPF is broken", and reading the wrong field sends you to fix
the wrong thing.
This tool computes alignment itself from auth_results, the
From: domain and the published adkim and aspf modes,
then compares that to what the reporter claimed. When the two disagree, it says so.
What each result means
| Result | What to do |
|---|---|
| Aligned | SPF and DKIM both align. Nothing to do. |
| DKIM aligned | Fine. DKIM survives forwarding, which is the one that matters. |
| SPF only | Passes today and fails the moment someone forwards it. Get DKIM signing and aligning for this source. |
| Forwarded | SPF broke in transit and DKIM carried it, or the receiver said so outright. Expected behaviour, not a problem to solve. |
| Unauthenticated | Neither aligned. Either the source needs configuring or it is not yours. Identify it before you change policy. |
What a report cannot tell you
- It is not your pass rate. One report is one receiver over one window. Gmail's view of your mail is not the internet's view of your mail.
- An unrecognised source is not a spoofer. It is far more often a vendor somebody set up and forgot about. This tool will never label a source as spoofing, because the data cannot support it.
- DKIM validity is the receiver's verdict, not a check. Aggregate reports carry no message content, so nothing here re-verifies a signature.
- Sender names are a courtesy. They come from reverse DNS, which is set by whoever controls the IP block and is not authenticated. A name that could not be forward-confirmed is marked.
Where to get your reports
They arrive at whatever address is in the rua= tag of your DMARC record.
If you do not have one, that is worth fixing first: enforcing a policy with no aggregate
reporting means enforcing without being able to see what you are enforcing, which
20.8% of enforcing domains are doing right now. The
domain check will tell you whether yours is set.