Learn · Email authentication
Why am I getting DMARC report emails?
An email arrives with a subject like Report Domain: yourdomain.com Submitter: google.com and a .zip or .gz attachment full of XML. Then another. Then five a day, from companies you've never dealt with. Nothing is broken, nothing has been hacked, and you are not being phished. Someone published a DMARC record for your domain with your address in it, and the internet is doing exactly what that record asked.
The short answer
Your domain has a DNS record at _dmarc.yourdomain.com containing a rua=mailto: tag pointing at your address. rua stands for Reporting URI for Aggregate data. Every mailbox provider that receives mail claiming to be from your domain reads that tag and emails you a daily summary of what it saw.
That's the entire mechanism. The reports are the point of DMARC, not a side effect of it — without them you'd be enforcing a policy with no idea what it was blocking.
You can confirm it in ten seconds: run your domain through the free DMARC checker. It shows the live record and the exact rua= address the reports are being sent to.
Is this phishing?
Almost certainly not, and there's a decisive way to tell rather than guess. A DMARC report is boring by design: no links, no login prompt, no invoice, no urgency. Just a compressed XML attachment and a subject line naming your own domain.
Three checks settle it:
- Does your domain actually publish a
rua=address, and is it this mailbox? If yes, the mail is expected. If your domain publishes no DMARC record at all, then something claiming to be a DMARC report has nothing to report about — treat it with suspicion. - Does the attachment parse as a DMARC aggregate report? Drop it into the free DMARC report analyzer. It runs entirely in your browser — the file is never uploaded anywhere — and a real report renders as a table of sending IPs. A fake one won't parse.
- Does the message ask you to do anything? Real reports ask for nothing. Any DMARC-themed email with a "click here to view your report" link, a login page, or an attachment that isn't XML deserves the suspicion you're already feeling.
Who sends them
Any mailbox provider that evaluates DMARC can report, and hundreds do. In practice most domains hear overwhelmingly from a handful of large receivers, plus a long tail of universities, hosting companies and security appliances. Each has its own filename convention and its own quirks:
- DMARC report from google.com — the highest-volume reporter for most domains, and usually the first one to arrive.
- DMARC report from enterprise.protection.outlook.com — Microsoft's filtering front end, and the submitter name that confuses people most.
- DMARC report from Yahoo — one of the two receivers whose 2024 bulk-sender rules made DMARC mandatory in the first place.
- DMARC report from amazonses.com — a report about mail into Amazon SES, which is not what most people assume when they see the name.
- DMARC report from mimecast.org — a security gateway reporting on behalf of the organisations behind it.
Seeing a name you don't recognise is normal. The reporter is whoever received mail claiming to be from you, not someone you have a relationship with.
Why so many, and why every day
Each report covers roughly one UTC day at one receiver. So the count scales with the number of distinct providers your mail reaches — not with how much mail you send. A domain sending a handful of messages a week can easily receive several reports a day, because its mail (and mail forged in its name) lands at several providers.
Expect the first one 24 to 48 hours after publishing the record. Volume then ramps over a week or two as more receivers notice you.
What's actually inside
Unzip one and you get XML with three parts: who is reporting and for which day, the DMARC record they saw published for your domain, and then one block per sending IP address — how many messages it sent as you, whether SPF and DKIM passed and aligned, and what the receiver did about it.
That last part is the whole value. The report is a list of every server on the internet sending mail with your domain in the From address, including the ones you forgot you'd authorised and the ones that were never yours. DMARC aggregate reports explained walks the format field by field.
What they don't contain: message bodies, subject lines, or recipient addresses. Aggregate reports are counts and authentication results, which is what makes them safe to collect at volume.
What to do about the flood
There are three honest options, and only one of them is a good idea.
Read them by hand
Workable for about a week. Decompress each file, read the XML, look up each IP, decide whether it's yours. The questions you actually need answered — which service is this IP? what share of my mail is aligned? what breaks if I move to p=reject? — need every report parsed and compared over time, which is where hand-reading falls apart. If you just want to see inside the one in your inbox right now, the report analyzer does it in your browser for free.
Delete the DMARC record
The reports stop, and so does your only visibility into who is impersonating your domain. This is the worst available trade: you keep every risk and give up the instrument that measures it. Don't.
Point rua= at something that reads them for you
Change one DNS record so the reports go to a monitoring service instead of your inbox. Every report is parsed, sending IPs are resolved to named services, and you get a dashboard and an alert instead of a daily pile of ZIP files. Canny Pigeons does this free for one domain, hosted DMARC included — you never see another XML attachment.
If you didn't publish the record
Sometimes the reports arrive at a shared mailbox and nobody knows who set it up. Look at the live record — the DMARC checker shows it — and you'll see the rua= address that's routing them to you. Then decide deliberately: keep them and put them to work, or repoint them. What you shouldn't do is filter them into a folder nobody opens, which is the most common outcome and leaves the domain effectively unmonitored.
And if the record says p=none, the reports are the only thing DMARC is currently doing for you. Nothing is being blocked. DMARC policies explained covers the walk from there to enforcement.
Free checks: Report analyzer DMARC checker SPF checker DKIM checker