How to Read DMARC Reports (Those Zipped XML Emails)

How to read DMARC reports — after adding a DMARC record, you started getting daily emails with zipped XML attachments from Google, Microsoft, and others, and you have no idea what they say or whether they matter.

Common signs of this issue

• You need to know how to read DMARC reports: emails keep arriving with subjects like "Report domain: yourdomain.com Submitter: google.com" and a .zip or .gz attachment.
• Opening the attachment shows a wall of XML code full of IP addresses, "pass", "fail", and "none".
• The reports come from Google, Microsoft (Outlook.com), Yahoo, and other mail providers you have never signed up with.
• Some reports show sources or IP addresses you do not recognize, with SPF or DKIM marked as fail.
• Someone set your DMARC policy to p=none months ago and told you to "watch the reports" before tightening it.
• Your inbox is filling up with these reports and you are tempted to just delete the DMARC record.

Safe checks you can do yourself

None of these require sharing passwords with anyone.

• Look up your current record with a free DMARC checker (search "DMARC lookup"). Note the policy (p=none, quarantine, or reject) and the rua= address. That address is where the reports are being sent.
• Do not read the XML by hand. Sign up for a free DMARC report viewer — several email-security companies offer free tiers or free weekly digests (search "free DMARC report analyzer"; limits change, so check what the free plan includes). Most give you a special rua address to add to your DMARC record, then turn the XML into a readable table.
• If you would rather not sign up, many of the same companies offer a one-off XML upload page. Unzip one report and upload it to see the structure before committing to anything.
• In the viewer, look at the list of sending sources — usually grouped by organisation, such as your email provider, your newsletter tool, your website host, your invoicing or CRM system. For each, check whether SPF and DKIM pass and align with your domain.
• Tick off every source you recognise and actually use. Anything legitimate that shows fail is a sender you need to fix — usually by adding it to SPF or turning on DKIM signing in that service's settings.
• For sources you do not recognise, check the volume and the IP owner. A handful of failing messages from random servers around the world is usually spoofing — someone faking your address — which is exactly what DMARC is designed to stop. Failures from a big mail provider in small numbers are often just forwarded mail.
• Watch the reports for at least a few weeks at p=none, covering monthly things like invoices and statements, until every legitimate source passes consistently.
• Then tighten gradually: move to p=quarantine (optionally with a lower pct= value to start), keep watching, and only then consider p=reject. See SPF, DKIM and DMARC explained for the record format.

What this usually means

Those emails are DMARC aggregate reports, sent because your DMARC record includes an rua= address. Each big mail provider that received mail claiming to be from your domain sends you a summary, usually once a day: which IP addresses sent it, how many messages, whether SPF and DKIM passed, whether they aligned with your domain, and what the receiver did with them. They are compressed XML because they are meant to be read by software, not people. They contain no message content, just counts and results.

Reading them comes down to one question per source: is this me, and does it pass? Legitimate senders that pass are fine. Legitimate senders that fail — a newsletter tool never set up for DKIM, a website sending contact-form mail through the host's server, an old invoicing system — are the ones that would be junked or rejected the moment you tighten your policy. Senders you do not recognise that fail are usually spammers spoofing your domain or innocent forwarding, and a strict policy is what protects your customers from the spoofers. Alignment matters as much as pass: a message can pass SPF for your email service's domain but still fail DMARC because that domain is not yours.

The whole point of starting at p=none is to collect this evidence safely. Once the reports show every real sender passing, moving to quarantine and then reject makes it much harder for anyone to send convincing fake invoices or phishing in your name, and receivers such as Gmail and Outlook tend to trust your genuine mail more. Staying at p=none forever meets the basic requirement but leaves your domain open to spoofing — and never looking at the reports means you would not know.

What not to do

• Don't delete your DMARC record just to stop the report emails. Point the rua address at a separate mailbox or a report service instead.
• Don't jump straight from p=none to p=reject without weeks of clean reports. You can block your own invoices, newsletters, and website mail.
• Don't panic about small numbers of failures from unknown IPs. Some forwarding and spoofing is normal; it is what DMARC is for.
• Don't add every unknown IP from the reports to your SPF record. That authorises spammers to send as you.
• Don't try to read the XML files by hand week after week. A free viewer does it in seconds and spots patterns you would miss.
• Don't forget monthly and seasonal senders. A billing system that only sends on the first of the month may not show up in a single week of reports.

When to get help

Bring in help when the reports show a legitimate sender failing and you cannot work out which service it is, when you have more than a few sending tools and cannot get them all aligned, or when you want to move to p=reject and cannot afford to lose invoices or customer mail in the process. It is also worth it if the reports show heavy spoofing of your domain, because customers may already be receiving fake emails that look like they came from you. Someone who reads these reports regularly can map every source in an hour or two, fix the SPF and DKIM gaps service by service, and plan a policy change that tightens protection without surprise bounces.

Glenn, who runs WebsiteSelfHelp, reads DMARC reports and gets small-business domains safely from p=none to full protection. Ask for a direct review, tell him which services send email for you, and you will get a clear picture of what is passing, what is failing, and what it would take to lock things down — no passwords needed to begin.

Frequently asked questions

Related free guides