Reading your own email authentication reports

The problem

If you publish a DMARC record (the published policy that tells mail providers what to do with mail that fails authentication) with a reporting address, the world's mail providers will send you XML every day describing who has been sending mail as your domain and whether it authenticated. Add a TLS-RPT record and they will also tell you when a connection to your mail servers could not be encrypted properly.

Almost nobody reads any of it. The reports arrive as compressed attachments, in a schema designed for machines, at a volume that makes manual review pointless within about a week. So the usual outcome is a mailbox filling with evidence that nobody looks at, and a domain owner who believes they have visibility because they configured the record.

Why it mattered

Publishing the record is the easy half. The record is a request for evidence; it does not itself protect anything. The protection comes from moving your policy from p=none to something enforcing, and you cannot responsibly do that until you know which of your own legitimate senders would break. That knowledge is in the reports.

So the choice is not "read the reports or don't". It is "read the reports, or leave the policy permanently at the setting that enforces nothing".

The options

A commercial DMARC service. Genuinely good, and the right answer for most organisations. Rejected here because it means pointing the reporting address at a third party, which hands them a continuous feed of who sends mail on your behalf — for a domain whose whole business is other people's trust.
Read them by hand, occasionally. Free, and honest about the effort. Rejected because occasional reading of a continuous signal is how you find out about a problem a month after it started.
Ingest them from the mailbox they already arrive in. The reports are already being delivered somewhere. Treat that mailbox as the queue.

What I chose, and why

Mailbox-driven ingestion. A scheduled poll reads the reporting mailbox, extracts attachments, parses the aggregate reports, and writes the results somewhere queryable. The mailbox is the interface, which means no sender anywhere has to change anything and there is no endpoint to secure.

The unglamorous majority of the work was attachment handling. Reports arrive gzipped and zipped; some arrive with filenames that hint at the format and some arrive with filenames that lie or are absent entirely, so the extractor had to stop trusting the filename and look at the content. That single assumption — that the sender will name the file usefully — accounted for more failed reports than anything else.

The part I did not expect

Parsing the reports turned out to be the beginning rather than the end. A DMARC report tells you what happened to mail claiming to be from your domain. It does not tell you whether your published DNS is currently correct, and the two questions get confused constantly.

So the pipeline grew a second half: live DNS scanning that checks what is actually published for the domains in scope, and enriches each finding with it. A report saying authentication failed means something quite different depending on whether the relevant record exists, is malformed, or was changed last Tuesday. Later this became a scheduled audit of published DNS across the whole estate, rather than only the domains that happened to appear in a report.

That is the useful generalisation: an inbound evidence feed is only as good as your knowledge of the configuration it is evidence about. Without the second half you are reading verdicts without knowing what was on trial.

What I would do differently

I would have built the DNS side first. It is smaller, it produces value immediately with no ingestion pipeline at all, and it is the context that makes the reports legible. I built it second because the reports were the visible problem, and the visible problem is not always the one to start with.

I would also be careful about how this reads as a recommendation. For most organisations a hosted DMARC product is the better trade, and choosing to build was justified by a specific reluctance to route the reporting stream through someone else, plus the fact that the mailbox ingestion machinery already existed for other reasons. Neither of those transfers automatically.

Email authentication usually surfaces during a diagnosis as "our invoices go to spam" rather than as a security question. The same pipeline's cost story is a pipeline that cost more asleep than awake, and its housekeeping nearly deleted it in the cleanup job that came for production.