How to Read a DMARC Report (and Act on It)

If you have published a DMARC record and switched on aggregate reporting, XML files start arriving in your inbox within a day or two. They look intimidating, but every report answers one simple question: who is sending email using your domain, and does that mail pass authentication? Once you can read the answer, DMARC stops being a mystery and becomes the most useful deliverability tool you have.

What a DMARC aggregate report actually contains

An aggregate (RUA) report is an XML file, usually zipped, sent once a day by each mailbox provider that received mail claiming to be from your domain. It does not contain the content of any email. It is a statistical summary: for each sending IP address, it lists how many messages were seen and whether they passed SPF and DKIM, with alignment.

The three things worth finding in every report are:

• The source IP — the server that sent the mail.
• The disposition — what the receiver did (none, quarantine or reject), based on your policy.
• SPF and DKIM results, with alignment — the heart of the report.

Alignment is the part people miss. A message can pass SPF and still fail DMARC, because DMARC requires the authenticated domain to match the domain in the visible From: address. SPF checks the hidden envelope sender; DKIM checks the signing domain. DMARC passes only if at least one of them both passes and aligns with your From: domain.

Reading the result for a single sender

For each IP, you are really sorting mail into three buckets:

1. Legitimate and aligned — your own mail servers, plus any service you authorised (your marketing platform, help desk, invoicing tool). These should pass. Good.
2. Legitimate but failing — a service that genuinely sends on your behalf but is not set up correctly. This is the bucket that matters most. It is why you start DMARC at p=none: so you can find these before you start blocking mail.
3. Unauthorised — servers you do not recognise, failing authentication. Some of this is spam or spoofing attempts; some is forwarding. This is the mail your policy is designed to stop.

Your job during the monitoring phase is to empty bucket 2 — fix or authorise every legitimate sender — until only buckets 1 and 3 remain.

Fixing the common failures

Most failures come down to a handful of causes:

• A new sending service with no SPF or DKIM. Add the provider's include: to your SPF record and publish the DKIM key they give you.
• SPF passes but does not align. The envelope domain belongs to the provider, not you. Enable DKIM signing with your own domain, which is the reliable way to achieve alignment.
• Forwarded mail. Forwarding breaks SPF because the forwarding server becomes the new sender. DKIM usually survives forwarding, which is another reason DKIM alignment is the goal rather than relying on SPF alone.

Work through the reports for two to four weeks. When every legitimate stream passes and aligns, you can tighten your policy.

Moving from monitoring to enforcement

DMARC has three policies, and you move through them in order:

• p=none — monitor only. Nothing is blocked; you just collect reports.
• p=quarantine — failing mail goes to spam. A safe middle step.
• p=reject — failing mail is refused outright. The end goal, and the only policy that fully stops spoofing of your domain.

Do not jump straight to reject. Move to quarantine once the reports are clean, watch for a couple of weeks, then move to reject. If you ever see legitimate mail being quarantined, drop back a step and fix the sender first.

A quick workflow

1. Publish SPF, DKIM and a p=none DMARC record.
2. Collect aggregate reports for a few weeks.
3. For every sending IP, confirm it is yours or an authorised service, and make sure it passes with alignment.
4. Fix the stragglers — usually by turning on DKIM signing.
5. Move to quarantine, then reject.

You do not need to parse the XML by hand. Paste a domain into a DMARC checker to see the current record and what each tag means, use a DMARC record generator to build or tighten the policy, and verify SPF and DKIM separately so you know which half of authentication is doing the work. The reports tell you who; those tools tell you how to fix it.

Enforced DMARC does two things at once: it stops other people sending mail as you, and it quietly improves your own deliverability, because receivers trust a domain that authenticates every message.