Reading DMARC reports: who sends mail in your name
What the XML files from Google, Microsoft and others contain, how to tell your own services from forgers, and which rows to fix before moving to p=reject.
Once your domain publishes a DMARC record with a rua= address, the big mailbox providers start sending you a report every day: a compressed XML file per provider, listing every server that sent mail claiming to come from your domain, and whether that mail passed. Most people open one, see a wall of XML, and never open another. That is a pity, because these files answer the one question that matters before you enforce DMARC: who sends mail as us, and are they all legitimate?
Where the reports come from
The record that asks for them looks like this:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"Google, Microsoft (Outlook.com and Microsoft 365), Yahoo, Orange, GMX, Mail.ru, Comcast and many others honour it. Each sends one aggregate report a day, usually as a .zip or .gz attachment. A small company receives five to fifteen a day. If the address is on another domain (a reporting service, for example), that domain must publish an authorisation record, or providers will not send anything; the DMARC checker tells you whether it does.
What is in a report
Under a short header (who sent the report, which period, which policy they saw), the report is a list of rows. Each row says:
- source IP: the server that handed the mail to the provider;
- count: how many messages that server sent in the period;
- disposition: what the provider did (
none,quarantine,reject); - DKIM and SPF results, both raw and aligned, and the domains they were checked for;
- header from: the domain in the visible From address.
The column that matters is the aligned result. DMARC passes when SPF or DKIM passes for a domain that matches the From address. A newsletter sent by Mailchimp can pass SPF for mcsv.net and still fail DMARC, because mcsv.net is not your domain.
Sorting the rows into three piles
Open your reports in the free DMARC report reader (everything stays in your browser) and sort the senders.
1. Your own services, passing. Your mailbox provider (Google Workspace, Microsoft 365), your CRM, your invoicing tool, all with DKIM aligned. Nothing to do.
2. Your own services, failing. This is the pile to fix before you enforce. Typical cases:
- a newsletter or CRM tool that signs with its own domain instead of yours: set up its custom domain authentication (two or three CNAME records it gives you), then DKIM aligns;
- a website contact form sending through the web host’s server: send it through your real mail provider instead, or add the host to SPF and enable DKIM;
- an old service you forgot about, still sending invoices: either configure it, or stop it.
3. Strangers. Servers in countries where you have no business, residential addresses, hosts you have never heard of, all failing. That is spoofing, or a misconfigured server somewhere that thinks it is you. You do not fix it; you block it, by moving to p=quarantine and then p=reject once pile 2 is empty.
Forwarding: the false alarm
A message you sent to a customer who forwards everything to another mailbox arrives at the second provider from the customer’s server. SPF fails (the customer’s server is not in your SPF), but DKIM usually survives forwarding and keeps DMARC passing. Rows with SPF failing, DKIM passing and a known forwarding provider are normal. Rows where both fail after forwarding usually come from mailing lists that rewrite messages; there are few of them, and enforcing DMARC is still the right choice.
What “good” looks like
After a few weeks of fixing, a healthy domain shows:
- more than 99% of the volume passing DMARC with DKIM aligned;
- every failing source either unknown (spoofing) or a forwarder;
- no service of yours left in pile 2.
That is the moment to move on, step by step, as described in From p=none to p=reject.
Why people stop reading them
The reports arrive in a shared mailbox, as attachments, every day, forever. Reading them by hand does not last. Perimetry Cloud gives each domain its own report address, reads every report as it arrives, groups the senders by service (Google, Microsoft, Mailchimp…), and tells you when a new source appears or when the share of mail that fails changes. It also says when it is safe to tighten the policy, and by how much.