Five things nobody tells you
about DMARC reports.
No jargon, and none of it takes long. The technical evidence is further down if you want it.
- 1
There is a report about your domain. Every day.
Google, Microsoft, Yahoo and the rest each keep a daily tally of every message that claims to come from you — real or forged. They have been writing it since the day you registered the domain.
- 2
It is not written for you to read.
It arrives as a compressed machine file. Not a summary, not a chart — a wall of tags meant for software. Nobody reads these by hand, including the professionals.
<record><row><source_ip>45.9.148.203</source_ip> <count>47</count><policy_evaluated><disposition> none</disposition><dkim>fail</dkim><spf>fail</spf>
- 3
It cannot see inside your email.
No subject lines. No messages. No attachments. Nothing from your mailbox, ever. It is a tally of who claimed to be you and whether they proved it — closer to a visitor log than to your inbox.
- 4
One is nearly useless. A year of them is the whole picture.
Any single day is noise you cannot act on. The value is only in the pattern across months — which is exactly why they get pointed at some forgotten inbox and never opened again.
- 5
So we read all of them, and stay quiet.
The usual answer to this is a dashboard — charts you have to remember to go and look at, which is the same job handed back to you in a nicer font. We read every report against everything your domain has already done, and say nothing unless something genuinely changed. Nothing to check, nothing to keep up with.
If that answered it, you can start watching a domain or run a free check — no account needed for the check. The rest of this page is the evidence: a real report in full, the complete list of what one can and cannot contain, and how the first weeks actually go. It is more technical, and you do not need it.
One report, start to finish.
This is a real aggregate report in the standard format, covering a single day for one domain. Nothing is elided — what you see is the entire file.
A gzipped XML attachment, once a day, from every major mail provider that saw mail claiming to be from you. Here is a real one, unpacked — this is the entire file:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>8241947265340192837</report_id>
<date_range>
<begin>1753142400</begin>
<end>1753228800</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.example</domain>
<adkim>r</adkim>
… 79 more linesNobody reads these by hand. That is the whole problem — and the reason most people point their reports at an address where they quietly pile up forever.
The same file, decoded. Three rows covering 1,427 messages — because a report groups messages by the server that sent them, not one line per email.
- 209.85.220.411,284 messagesspf=passdkim=passThis is you · Google Workspace
Your own staff mail, leaving through your mail provider, fully authenticated. In a healthy report this is nearly all of the volume.
- 198.61.254.1296 messagesspf=faildkim=failA service you use · An invoicing service you signed up for
The service authenticated itself correctly — its own SPF and DKIM passed. But it proved it was the invoicing service, not that it was you. DMARC only counts authentication that's aligned with your domain, so this lands as a fail. Real mail you sent, failing anyway.
- 45.9.148.20347 messagesspf=faildkim=failNot you · Unknown — no relationship to you
Someone with no connection to your domain sent 47 messages wearing your name. Because the policy here is p=none, every one of them was delivered normally. This row is the thing you cannot learn any other way.
That middle row is the one people find surprising: mail you genuinely sent, from a service you genuinely signed up for, failing DMARC anyway. And the last row is the one you cannot learn any other way — nothing in your own mail system ever sees it, because those messages never touched your servers.
“So what am I actually handing over?”
Reasonable thing to ask before pointing a feed of anything at a company you just met. The answer is unusually easy to verify, because the report format is a closed specification — there is a fixed list of fields, and it is short.
The mail provider identifying itself and the 24-hour window it covers.
Public DNS. Anyone in the world can already look this up.
The server that connected, how many messages it sent, and whether they authenticated.
Domains only — never addresses. Even the optional recipient field is the receiving domain (gmail.com), never a person.
Which key signed, which domain was checked, and whether each check passed.
The report format is a closed specification (RFC 7489, Appendix C). There is no field for any of this, so no provider can put it in one:
- Subject lines
- Message bodies or any content
- Attachments
- Recipient email addresses
- Sender email addresses
- Message headers
- Anything at all from your mailbox
Pointing reports at us grants no access to your mail, your mailbox, or your DNS. It is one public TXT record saying where statistics should be delivered, and you take it back by deleting that record.
DMARC does define a second, rarer report type — failure reports, the ruf tag — and those can include message headers and subject lines. They are a genuinely different privacy proposition. We never ask for them: the record we generate for you contains rua only, and there is a test in our codebase that fails the build if that ever changes.
Why one report tells you almost nothing.
A single day is a snapshot with no context. A sender you have never seen before looks identical to one that shows up every Tuesday — until you have enough Tuesdays to tell them apart.
- Day 0You publish one line
A single TXT record in your DNS naming where reports should go. Nothing about how your mail is delivered changes — this record only affects reporting.
- Within 48 hoursThe first reports arrive
Google, Microsoft, Yahoo and the rest each send a daily summary of mail they saw carrying your domain. The first one is usually the first time anyone has seen the full list of what sends as you.
- Weeks 1–3A baseline forms
Repetition is what makes reports meaningful. Once we have seen your normal senders across enough days, we know what your domain looks like on an ordinary Tuesday — which is the only way anything can later stand out.
- OngoingMostly silence, on purpose
Every new report is compared against that baseline before anything is written. Reports that match it are filed without a word. You hear from us when a sender appears that has never appeared before, or when something that was working stops.
Which is why we did not build another dashboard
Parse the XML, draw the charts, and hand you a dashboard.
Genuinely better than a folder of gzip files. But the work of noticing still lands on you, and a chart of mostly-normal weeks is one more thing to remember to check. Miss a fortnight and you have learned nothing.
Read every report against your domain's own history, and stay quiet unless something changed.
The comparison is deterministic — established senders, failures already known to be chronic, ordinary volume. Reports matching that baseline are filed without a word. Only a genuine departure is handed to an AI analyst, which reads it in the context of everything your domain has done before and writes to you about what changed.
So the promise is not “we will send you reports.” You can already have that problem for free. The promise is that you will hear from us rarely — and that when you do, it will be worth the interruption.
Getting them pointed somewhere useful.
Enrolling a domain generates a reporting address unique to you, so arriving reports can be attributed to your account. Publishing it is one DNS change that affects reporting only — it cannot bounce, delay, or reroute a single piece of real mail, it grants no access to anything, and deleting that one record is how you leave.
Not ready to decide? The free check reads your current DNS and grades it without an account — including who, if anyone, is collecting your reports today.