If your domain has a DMARC record and someone's address is in it, that person gets mail every day with subjects like Report Domain: yourcompany.com Submitter: google.com and a zipped XML attachment. Ten or more a day is normal. They are not spam, they are not an attack, and they are not meant for a human. Here is what they are and what to do about them.
What a DMARC aggregate report is
Your DMARC record tells the world's mail providers what to do with mail that claims to be from your domain but fails authentication, and where to send a summary of what they saw. That summary is the aggregate report. Every provider that received mail from your domain yesterday, Google, Microsoft, Yahoo, the German and Czech free-mail providers, anyone running a modern mail system, sends one report per day covering the mail it handled. Each report is an XML file, compressed, attached to an otherwise empty message.
Inside is a count of messages by sending address, with the SPF and DKIM results for each and what the receiver did about failures. That is genuinely valuable: it is the only way to see who is sending mail as your domain, including the legitimate services you forgot about and the attackers you never knew about.
Why the reports should not go to a person
The address in the record's rua= tag is where the reports go. Setting it to a real person's mailbox is a common mistake, usually made when the record was first created. The result is a daily pile of attachments nobody opens, and because the reports come from dozens of unrelated senders with near-identical subjects, they look exactly like a snowshoe spam campaign to a filter that does not know better.
Two better options:
- A DMARC reporting service. Several vendors offer a reporting address; you put theirs in your record and read charts instead of XML. Some are free at small volumes.
- A dedicated mailbox that nobody reads day to day, with the reports processed by a tool. Fine if you have someone who will actually look.
Changing the rua= address is a one-line DNS change at your domain registrar or DNS host. It does not affect mail delivery.
How a filter should treat them
Here is what happened on our side. One customer's record pointed at an executive's mailbox, and Yahoo alone sent eleven reports a day, one for each Yahoo-hosted domain that had received her company's mail. Our campaign detection saw dozens of near-identical messages from dozens of senders, concluded it was a spam wave, and began graduating them to confirmed spam. Reports from the German and Czech free-mail providers scored high on their own because a report body mentions "unauthorized" mail and names the provider in the sender's display name, both of which look like brand impersonation out of context.
The fix is structural recognition. A genuine aggregate report has a shape defined by the standard: the subject form, an attachment named receiver!domain!start!end.xml.gz, and an XML body with a <feedback> element naming a domain the recipient actually owns. OpenEFA now recognises that shape, confirms the sender's own authentication passes, checks the message carries no lure of its own (no login link, no phone number to call, no urgency), and then scores it as the routine report it is and exempts it from campaign detection.
What the reports told this customer
Once the reports were being read instead of quarantined, one finding mattered: an e-commerce platform was sending order emails as the customer's domain without DKIM alignment, and because the domain's policy was p=reject, Yahoo had rejected about 150 of those order emails in a month. Nobody had noticed, because the rejections showed up only in the reports nobody opened. The fix is on the platform side (a DKIM record for the platform in the customer's DNS), and the reports are how you find out it is needed.
A short checklist
- Look up your DMARC record (any online DMARC checker will show it). If rua= points at a person, move it.
- Read the reports, or let a tool read them, for a month before tightening policy. Look for legitimate services failing alignment.
- Move from p=none to p=quarantine to p=reject only after the reports show your legitimate senders aligned.
- If your filter is holding the reports, it is treating them as a campaign. It should not be; that is what the fix described above is for.
Details of this and other October changes are on the What's New page.