Making DMARC reports readable

Once you publish a DMARC record with a reporting address, some mail providers may send you reports about who is sending email using your domain. Those reports are the thing that tells you whether it's safe to tighten your policy.

Two limits on that worth knowing before you rely on it. Sending reports is not compulsory, so you hear from the providers that choose to, not from every receiver your mail reaches. And if the address is on someone else's domain — any reporting service — that domain has to publish a record authorising reports for you, or receivers are required to ignore the address entirely. The check tells you whether that authorisation is in place.

So a quiet reporting period is not the same as a clean one. If no reports have arrived, the likeliest explanations are that the address isn't working or isn't authorised — not that nobody is sending as your domain. Silence is not the evidence you tighten a policy on.

Why the reports are hard to read

DMARC reports arrive as zipped XML attachments, built for software rather than people. A typical one looks like this:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>27</count>
    <policy_evaluated><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
  </row>
</record>

So "publish a DMARC record and read the reports" isn't advice you can act on with a normal inbox. You need something to turn those files into a summary, which is what the services below do. Most of them will email you one once a week.

Where to point your reports

The address in your DMARC record's rua= tag is where reports get sent. Two things to know about it:

• It should be a mailbox that exists. If it doesn't, what happens depends on your mail host. With a catch-all address the reports may land there, but most providers reject mail to unknown addresses, and that rejection goes back to whichever provider generated the report rather than to you. So you would never know the reports were being lost.
• You can list more than one address, separated by commas, so reports can go to a service and to a mailbox of your own at the same time.

If you use a reporting service, it gives you an address to paste in. Sending reports to an address on someone else's domain normally requires that domain to publish a small record granting permission, and the services handle that for you.

Options we've checked

Terms change, so confirm the current details before signing up. Checked July 2026.

Cloudflare DMARC Management

Free on all Cloudflare plans, including the free one, but it only works if your domain's DNS is already hosted at Cloudflare. If the check said your DNS is at Cloudflare, start here, because there is nothing extra to sign up for.

EasyDMARC

Has a free tier covering one domain and 1,000 messages a month, with 14 days of history. That is enough to start investigating and see your day-to-day senders. Note the history limit against the point below: fourteen days cannot show you a sender that only fires quarterly, so don't read a clean fortnight as a complete inventory. Paid plans start around £36 a month if you need longer history or more domains.

dmarcian

Their free plan is for personal, non-business use, so it isn't the right fit for an organisation. They do state that they offer special pricing for nonprofits, government and educational organisations, so it is worth asking them directly what that comes to. Paid plans otherwise start at $24 a month, with a 30-day trial.

If you have technical help available

Anyone comfortable running a small script can parse the reports themselves rather than using a service. Open-source tools exist for this. Worth asking whoever manages your website, if you have someone.

Where you're heading

The destination is p=quarantine, which sends forged mail to spam. That stops someone impersonating your organisation, and it's far enough for most. The stricter p=reject refuses forged mail outright, but the current DMARC standard (RFC 9989, §7.4) says domains whose people post to mailing lists should not publish it, because a list relays your message from its own servers while leaving your address in the From line, so genuine mail sent that way is refused too.

If you do decide on reject later, the same section is explicit that SPF alone will not carry it: a domain publishing p=reject has to have working DKIM, because DKIM is the one of the two that survives forwarding. It also asks you to spend at least a month at p=quarantine, comparing the reports against your month at p=none, before going further.

How long to monitor

There is no fixed answer, and that is not a dodge — it depends on how often your organisation sends. What you are waiting for is coverage, not a date on the calendar: a list of sources you recognise, all passing, with anything failing that you do recognise fixed before you tighten the policy. Tightening is what turns those failures into undelivered mail.

Be aware of what a monitoring window cannot show you. Anything that sends rarely — annual tax receipts, a quarterly campaign, an occasional mail-merge from someone's laptop — may simply not appear during it. Rather than relying on the window alone, ask around: who sends email using our domain? Finance, fundraising and campaigns will often each name something the others didn't know about.

Back to the check