How to Read Your DMARC Reports (Plain Guide)

You turned DMARC on, set the policy to none, and now an XML file lands in your inbox every day from Google, Yahoo, Microsoft and a dozen senders you half recognise. It looks like noise. It is not. That XML is a daily report of who is sending mail as your domain and whether it passed authentication. This guide reads one of those reports with you, field by field, in plain words, and tells you what to actually do with what you find.

What a DMARC report is, in one breath

Every report is a summary, not a per-message log. A mailbox provider like Gmail groups together all the mail it saw claiming to be from your domain over roughly 24 hours, then sends you a count: this many messages came from this IP address, here is how SPF and DKIM went, and here is what we did about it. These are called aggregate reports, or RUA reports. They never contain message bodies or subject lines, so there is no privacy problem in reading them.

There is a second, rarer type called a forensic or failure report (RUF) that includes redacted headers of individual failures. Most providers stopped sending those years ago for privacy reasons, so in practice you are reading aggregate XML. Focus there.

The three things every row tells you

Open the XML (or better, paste it into a free DMARC parser so it renders as a table). Each report has a header block and then a set of records. A record is one sending source. For each record, three pieces matter.

• Source IP and count. Which machine sent the mail, and how many messages it sent that day. This is how you spot volume from somewhere you did not expect.
• SPF result and alignment. Did the IP appear in your SPF record, and does the envelope domain match your From domain.
• DKIM result and alignment. Was the message signed with a valid key, and does the signing domain match your From domain.

Pass and fail are not the same as aligned

This trips up almost everyone. A report shows two separate things per mechanism: the raw result (did SPF or DKIM technically pass) and alignment (does the domain it passed for match the domain in the visible From address). DMARC only cares about alignment. You can have SPF pass and still get a DMARC fail, because the SPF passed for a different domain than the one your readers see.

Reading the disposition: what the provider did

The header of each report contains your published policy and each record contains a disposition, which is the action the provider actually took.

You see	What it means
disposition: none	Delivered normally and reported. Your policy is p=none, so nothing was blocked even on failures.
disposition: quarantine	Sent to spam or held. Your policy is p=quarantine and this message failed alignment.
disposition: reject	Bounced before delivery. Your policy is p=reject and this message failed.
dkim: pass / spf: pass	Aligned and authenticated. This is the green you want on your real mail.
dkim: fail / spf: fail	Did not align. Investigate the source IP before you tighten policy.

A worked example

Say a record shows: source 209.85.x.x, count 412, SPF pass and aligned, DKIM pass and aligned. That is Google Workspace sending your normal company mail. Healthy. Leave it.

Now another: source 198.51.100.20, count 1,140, SPF fail, DKIM none. You do not recognise the IP. Two possibilities. Either it is a legitimate service you forgot to authorise (a CRM, a help desk, a newsletter tool sending as you), or someone is spoofing your domain. The volume and the IP owner usually tell you which. Look up who owns the IP. If it is SendGrid or Mailchimp and you use them, you have an authentication gap to fix, not an attack.

What to do with what you find

1. Catalogue your real senders. Spend a week or two on p=none just collecting reports. Every legitimate source should show up. Make a list.
2. Fix the gaps. For each real sender failing alignment, add it to SPF or set up DKIM signing with the right domain. Most ESPs document the exact records to publish.
3. Watch the unknowns. Persistent failing IPs you cannot identify are spoofing attempts. Tightening your policy is what stops them landing in inboxes.
4. Move the policy up. Once your real mail is clean and aligned, go p=none to p=quarantine, then to p=reject. Keep reading reports after each step.

Authentication is one leg of deliverability. The other is sending to addresses that exist and engage. Clean DMARC alignment will not save you if half your list bounces, so pair this work with email list hygiene and a habit of checking addresses before you send. Our free email verifier handles the second part, and the improve email deliverability guide ties both together.

Tools that make this bearable

Raw XML is painful by hand. Free DMARC report viewers turn each report into the table described above and chart volume over time, which is how you actually notice a new spoofing source. You do not need a paid platform to start; you need to read the reports consistently for a few weeks and act on the gaps.

FAQ

Why do I get reports from senders I never emailed?

Those are providers reporting mail sent as your domain, including spoofed mail and forwarded mail. Seeing an unfamiliar provider is normal. What matters is whether the mail from each source aligned, not that the report exists.

My real mail shows SPF pass but DMARC fail. Why?

Almost always an alignment problem. SPF passed for the envelope domain (often the ESP's own domain), but that does not match your visible From domain. Fix it by enabling DKIM signing with your domain, since aligned DKIM survives forwarding better than SPF does.

How long before I can move to p=reject?

There is no fixed clock. Move when your reports show every legitimate source passing alignment for a couple of weeks straight and the only failures are sources you do not recognise. For most domains that is a few weeks to a couple of months. Step through quarantine first rather than jumping straight to reject.