How to Read DMARC Reports

So you set up DMARC. (If you haven’t yet, start with SPF, DKIM & DMARC in Plain English.)

A day or two later, your inbox starts filling up with emails from Google, Microsoft and Yahoo with attachments named things like google.com!yourdomain.com!1791331200!1791417599.zip.

Welcome to DMARC reports. They look intimidating, but they’re actually one of the most useful things you’ll get about your email. Let me show you how to make sense of them.

What these reports are

When you add a reporting address to your DMARC record (the rua=mailto: part), the big email providers start sending you a daily summary. These are called aggregate reports, and they tell you:

  • Which servers sent email claiming to be from your domain
  • How many messages each one sent
  • Whether those messages passed SPF and DKIM
  • What the receiving server did with them

They don’t include the content of anyone’s emails. Just the who, how many, and pass or fail.

Don’t read the raw files

The reports are XML files, and reading them by hand is no fun. You don’t have to.

There are services that collect your reports and turn them into readable charts and summaries, such as Postmark’s free DMARC digests, dmarcian, EasyDMARC, and MXToolbox’s DMARC tools. Many have a free plan that’s plenty for a small business.

Set one up, point your DMARC rua address to the address it gives you, and you’ll get a simple weekly summary instead of a pile of zip files.

Tip: Use a dedicated address for reports, like dmarc@yourdomain.com, or the address your report service gives you. You don’t want these clogging your main inbox.

How to read DMARC reports: what you’re seeing

Every sender in your reports falls into one of three groups.

1. Your legitimate senders, passing

Your mailbox provider, your newsletter service, your invoicing tool, all showing pass for SPF and DKIM. This is what you want to see. Nothing to do here.

2. Your legitimate senders, failing

This is the important one. You’ll see a service you recognize (your CRM, your website’s contact form, a help desk) but it’s failing SPF, DKIM, or both.

That means that service isn’t set up correctly to send as your domain. The fix is usually:

  • Add it to your SPF record, or
  • Set up DKIM for that service (look for “authenticate your domain” in its settings)

Until it’s fixed, those emails are at risk of landing in spam, and they’ll get blocked once you tighten your DMARC policy.

3. Senders you don’t recognize

Random servers, often in other countries, sending mail as your domain and failing everything. That’s spoofing: someone pretending to be you.

You don’t need to chase these down. That’s exactly what DMARC enforcement is for. Once your policy is set to quarantine or reject, those messages get sent to spam or blocked.

When to tighten your policy

Here’s the process I use:

  1. Start at p=none just long enough to see your senders. A week or two is usually plenty.
  2. Fix every legitimate sender that’s failing.
  3. Move to p=quarantine. Don’t leave it sitting at none. More and more mail systems treat that as a weak setting.
  4. Keep watching your reports for a few weeks.
  5. When nothing legitimate is failing, move to p=reject for full protection.

What to watch for over time

Once things are set up, check your reports once a month or so. Look for:

  • A new service failing. Someone in your business signed up for a new tool that sends email and didn’t set it up properly.
  • A sudden spike in spoofing. Someone is actively impersonating you. Your enforcement policy is protecting you, but it’s worth warning your customers to watch for fake emails.
  • Your own mail failing after a change. Switching mailbox providers or DNS hosts can break records.

The bottom line

DMARC reports are your window into who’s sending email in your name. Use a report service to make them readable, fix your legitimate senders, ignore the spoofers (enforcement handles them), and tighten your policy step by step.

Want someone to set this up and keep an eye on it for you? That’s something I do for clients at That One Web Guy.

Similar Posts