Email · 8 min read

What Your DMARC Reports Are Trying to Tell You

DMARC email authentication deliverability SPF DKIM

If you’ve set up DMARC, you’re probably receiving reports. You’re probably also ignoring them — an inbox full of XML attachments from Google, Microsoft, and Yahoo that look like cryptographic noise.

That’s a missed opportunity. DMARC aggregate reports are the closest thing email has to server logs for your sending reputation. They tell you exactly who is sending mail under your domain name, how the big receivers are authenticating it, and — if you know how to read them — where the cracks in your sending infrastructure are.

Here’s what they’re actually telling you.

How reports work

Every mailbox provider that supports DMARC sends you a daily report covering the previous 24 hours of mail they received claiming to be from your domain. Gmail sends one. Outlook sends one. Yahoo sends one. Each is an XML file covering that provider’s view of your traffic: which IP addresses sent mail, how many messages from each, and whether they passed SPF, DKIM, and DMARC.

You’ll receive reports from any provider listed in your DMARC record’s rua= tag. If you haven’t set one, you’re not getting reports — and you’re flying blind.

The one distinction that unlocks the whole thing

Before getting to what the reports reveal, there’s a distinction most people miss — and it unlocks everything else: the difference between auth_results and policy_evaluated.

auth_results shows the raw authentication results: did DKIM pass cryptographically? Did SPF pass for the envelope-from domain? These are technical checks in isolation.

policy_evaluated shows whether those results actually satisfied DMARC — which requires not just passing, but also aligning with your From: domain. You can have SPF pass in auth_results and still fail in policy_evaluated. This happens constantly with ESPs: they authenticate using their own bounce domain, which passes SPF for their domain, but doesn’t align with yours.

DMARC passes if at least one mechanism — DKIM or SPF — both passes and aligns. Either is sufficient. Both failing means DMARC fails.

When you’re reading a report and wondering why a source you trust is failing, the answer is almost always here.

Signal 1: Someone is sending mail as you

Look for IP addresses you don’t recognize with high message counts and failures on both SPF and DKIM. That pattern — unknown source, no authentication — is the clearest indicator of spoofing or phishing attempts using your domain.

This is the signal that justifies DMARC enforcement entirely. At p=none, you’re watching the spoofing happen but not stopping it. Moving to p=reject means those messages never reach a recipient’s inbox.

Cross-reference unfamiliar IPs against their ASN (autonomous system number) — most report analysis tools will surface this. IPs from cloud hosting providers, foreign infrastructure, or known spam networks with no business relationship to your domain are your red flags.

Signal 2: One of your legitimate senders is misconfigured

This is the most common reason senders stall at p=none: there’s a source in their reports they recognize — a CRM, a transactional email provider, a marketing automation platform — that’s failing DMARC alignment.

The fix is almost always one of two things: the ESP needs a custom bounce domain on your domain (to get SPF alignment), or you need to add their DKIM signing key to your DNS (to get DKIM alignment). Usually you need both, but either one passing is enough.

The goal is that every IP representing a legitimate sending service shows DMARC pass in your reports. Until then, you can’t move to enforcement without collateral damage.

Signal 3: Your own infrastructure has authentication problems

Your own mail servers — the ones handling corporate email, transactional notifications, anything sent directly from your own IP ranges — should show clean DMARC pass every day. If they don’t, you have an infrastructure problem that affects your reputation independent of anything else.

Common causes: a DKIM key rotation that wasn’t completed across all sending servers, a selector that’s in DNS but not configured in the mail server, or an SPF record that doesn’t include all the IPs you’re actually sending from. These failures affect every message from those servers, not just bulk sends.

Signal 4: Your policy coverage

If you’re running at p=quarantine; pct=25, your reports show you what percentage of your total volume is passing versus failing across all sources. That data lets you make a risk-adjusted decision about raising the pct percentage.

The math is simple: if 96% of your volume comes from five IP ranges all showing DMARC pass, you have very high confidence that raising pct to 100 won’t affect legitimate delivery. If there’s a long tail of sources you haven’t fully audited, that’s your sign to keep investigating before moving forward.

One trap worth naming: p=quarantine; pct=0 looks like enforcement in your DNS but is functionally identical to p=none. It’s theater. Don’t let your DMARC record sit there indefinitely.

Tools that make this manageable

Reading raw XML by hand is nobody’s idea of a good time. A few options depending on your needs:

  • Postmark DMARC — Free, email-based digest, zero setup friction. You forward reports to their address and they send you a weekly summary. Good starting point if you want low overhead.
  • dmarcian — The professional standard. Founded by one of the DMARC spec authors. Free plan covers small volume; paid tiers start around $20/month. Excellent at identifying the ESP or infrastructure behind each IP range.
  • Valimail Monitor — Free dashboard, strong at recognizing sending services by their infrastructure. Better visualization than Postmark if you want a web-based view.
  • parsedmarc — Open source Python tool for technical teams who want to self-host and push data to Elasticsearch or Splunk.

For one-off debugging, dmarcian’s XML-to-human converter (paste raw XML in, get a readable table out) and MXToolbox’s report analyzer are both free and require no account.

Pick whichever one gets you from XML to readable tables with the least friction — the tool matters far less than the habit of actually looking.

The enforcement reality

Since 2025, this is no longer optional for bulk senders. Google, Yahoo, and Microsoft have all implemented DMARC requirements for senders exceeding 5,000 messages per day to their consumer addresses. Non-compliant mail faces rejection.

p=none is now correctly understood as a monitoring phase — the starting point of a process that should end at p=reject. The reports you’ve been receiving are your roadmap for that journey: they show you exactly what needs to be fixed before you can enforce.

In my experience running email infrastructure at scale, the path to p=reject is shorter than most senders expect. The common pattern is two or three misconfigured legitimate senders, a handful of non-sending internal services that need SPF/DKIM locked down, and one surprise (an IT tool or partner integration nobody remembered). Fix those, watch the reports clear up, then enforce.

The reports have been telling you all of this. You just have to read them.