DMARC report reader

A daily count from each mailbox provider

A DMARC record is a line in your domain’s DNS. One of its tags, rua=mailto:reports@yourdomain.com, asks every provider that receives mail claiming to be from your domain to send a summary to that address. Google, Microsoft, Yahoo and many others do, usually once every 24 hours.

These “aggregate” reports hold no message text and no recipient names, only counts. Each row says that one IP address sent a number of messages with your domain in the From line, and how those messages scored:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>312</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>yourdomain.com</header_from></identifiers>
  <auth_results>…</auth_results>
</record>

A single domain with a few sending services easily gets several files a day, each with dozens of rows. The reader adds them up so you don’t have to.

Why a pass can still fail: alignment

DMARC sits on top of two older checks. SPF asks whether the sending server is allowed to send for the domain in the hidden return address. DKIM asks whether the message carries a valid signature from some domain. Neither one looks at the From line a person reads.

DMARC makes that connection. A message passes DMARC when SPF or DKIM passes for a domain that matches the From line. That match is called alignment. A newsletter service can pass SPF for its own domain and sign every message with its own DKIM key, and still fail DMARC for you, because neither result mentions your domain.

In a report, policy_evaluated holds the aligned results and auth_results holds the raw ones with the domains involved. The reader uses the first for its “Aligned” labels and prints the second as small notes underneath, so you can see which domain passed.

How the reader sorts senders

Rows are merged by IP address across all the files you drop, then grouped by service. If the naming option is on, our server looks up the reverse DNS name and network owner of each address. About thirty common services, from Google and Microsoft 365 to SendGrid, Mailchimp and Amazon SES, are recognized by those names. Each address gets one of five labels:

The summary at the top gives the total volume, the compliant share (green from 98%, orange from 75%), the number of messages from unknown senders and the policy the reports say you publish.

From the table to an enforced policy

1. Fix every “to fix” group. In the service’s settings, look for “domain authentication”, “sending domain” or “DKIM”. It’ll give you two or three DNS records to publish, usually CNAMEs. Once they’re live, the service signs with your domain and the rows turn green in the next reports.
2. Leave forwarding alone. You can’t repair what a third party relays. These rows stay small.
3. Tighten the policy. When your own senders have been compliant for two to four weeks, change p=none to p=quarantine, and later to p=reject. A pct tag below 100 applies the policy to only that share of failing mail. Remove it at the end.

To review the record itself, there’s the SPF, DKIM and DMARC checkup. To write a new one, use the record builder.

The format has its limits. A report covers only providers that send reports and only the period in its date range, and it never tells you which person or campaign a message belonged to. The reader accepts up to 200 files at a time, 50 MB each, and ignores duplicates.