Reading a DMARC report
DMARC reporting is the stream of daily files that receiving providers send you as soon as you publish a DMARC record with a reporting address. Each file lists, per sending server, how many messages were sent on behalf of your domain and whether SPF and DKIM passed. The files look unreadable, but they answer one question you cannot answer any other way: who is sending mail with your name on it?
Where the files come from
Your DMARC record contains a "rua" address. Every large provider that receives mail from your domain sends a summary there once a day: a compressed XML file attached to an automated message. If you send to many different providers, you therefore receive several files a day. They only cover messages that carried your domain in the From field, even if you did not send them yourself. That is precisely what makes them valuable.
What they contain
Per row, or "record", you see:
- The IP address of the server that sent.
- The number of messages from that address in the period.
- Whether SPF passed, and for which domain.
- Whether DKIM passed, and with which selector.
- Which decision the recipient took: deliver, quarantine, or reject.
Nothing about the content of the messages, nothing about the recipients. It is a count, not a copy. That is why you can safely have them processed by an external service.
What you use them for
To discover who is sending on behalf of your domain. In practice that is more systems than anyone lists in advance. A sample of what organisations find: the invoicing package that mails invoices, the webshop, a contact form on an old website, a ticketing system, the multifunction printer that forwards scans, a service a colleague set up three years ago. And now and then: a server in a country where you do no business, abusing your domain for phishing.
How to read a report
- Group by IP address and look up who owns it. Most addresses you will recognise by the name of the service.
- Look at the rows where both SPF and DKIM fail. Those are either systems you forgot to configure, or forgers. The volume helps: a hundred messages a day from your hosting company is a forgotten system; ten thousand from an unknown address is abuse.
- Watch for rows where SPF fails but DKIM passes. That is often forwarded mail, and perfectly normal. DKIM survives forwarding, SPF does not.
- Watch for rows where DKIM fails but SPF passes. That points to a system that is in your SPF but has no DKIM key, or uses the wrong selector.
An example: a small business switches on DMARC and after a week sees three senders. The sending platform (everything passes), Microsoft 365 (everything passes) and an unknown address with forty messages a day where everything fails. It turns out to be the website of a subsidiary, sending its forms straight from the web server. Nobody knew it was still running.
The method
First set DMARC to none with reporting on: nothing changes in delivery, you are only watching. Collect for a few weeks. Make sure every legitimate sender authenticates correctly, by adding it to your SPF and giving it a DKIM key. Only then tighten to quarantine, and once the reports stay clean for weeks, to reject. Anyone who reverses this order usually blocks their own invoicing package. How to set up the records themselves is explained under SPF, DKIM and DMARC.
Who reads them for you
The raw files are not meant to be read by hand. Anyone sending more than a few hundred messages a day receives too many files to click through. Use a service that summarises them into an overview per sender, or ask your email provider. At 2Mail you can see per domain in the dashboard whether SPF, DKIM and DMARC are correct and how your messages arrive at recipients, so you only need the reports to track down unknown senders. If you would like help interpreting a report, get in contact.
Frequently asked questions
I am not receiving any reports. What is wrong?
Usually a typo in the rua address, a missing "mailto:" in front of it, or a reporting address on another domain that does not explicitly grant permission. Also check that the reports are not landing in the spam folder of the reporting mailbox.
What is the difference between rua and ruf?
Rua are the daily summaries this article describes. Ruf are forensic reports per individual failed message; most providers no longer send them for privacy reasons. Start with rua.
How long should I stay on none?
Until you have found and corrected all legitimate senders, and the reports have shown no unexpected failures for at least two weeks. For a small organisation that is often a month; for a large one with many systems, longer.