What DMARC reports do and do not tell you

3 June 2026 · 11 min read

There is a moment, a few weeks into running DMARC, where the data starts to feel like a deliverability dashboard. You open an aggregate report, you see row after row of dmarc=pass, the green percentages climb towards 100, and a comforting thought forms: my email is getting through. It is a natural reading. It is also wrong, and the gap between what DMARC reports actually measure and what people assume they measure causes a surprising amount of wasted effort and false confidence.

DMARC reports answer one question, and they answer it well: of all the messages claiming to be from your domain that a given receiver saw, how many passed authentication and alignment, and from which sources? That is enormously valuable. It is the feedback loop that lets you move a domain from p=none to p=reject without cutting off your own newsletters or your invoicing system. But "passed authentication" and "landed in the inbox" are two different events, measured by different systems, for different reasons. A message can pass DMARC perfectly and still go straight to spam. A message can land in the inbox while your reports show a worrying pile of failures somewhere else entirely.

This article is about reading DMARC reports for exactly what they are worth: no less, because the data is genuinely powerful, and no more, because over-reading it leads you to chase problems that do not exist and ignore the ones that do. If you have not published a record yet, run the DMARC checker first to see what is live, then come back. If you already have reports landing and want to make sense of them, this is the mental model to bring.

What a DMARC report actually measures

When a receiving mail server such as Gmail, Yahoo or Microsoft 365 accepts a message whose visible From: header claims your domain, it runs DMARC. Three things get evaluated:

• Did SPF pass for the envelope sender, and is that domain aligned with the From: domain?
• Did DKIM pass on at least one signature, and is the signing domain aligned with the From: domain?
• Given those two results, does the message satisfy your DMARC policy?

DMARC passes if either SPF or DKIM passes with alignment. The receiver then records that outcome, the source IP, the counts and the authentication details, and once a day it rolls all of that into an XML aggregate report and sends it to the address in your rua tag. If you want the deeper anatomy of those reports, the aggregate vs forensic reports guide walks through every field, and the glossary entry for DMARC defines each tag.

Notice what is in that list and what is not. The report tells you about identity and authentication. It tells you which servers sent mail as you, whether those servers were authorised, and whether the cryptographic and path-based proofs lined up. It is a security and configuration signal. It is the closest thing you have to a complete census of who is sending email under your domain name, including the senders you forgot about and the ones you never authorised.

What it does not contain is any verdict from the receiver's spam filter. The report is generated after DMARC evaluation but it carries no information about whether the message was placed in the inbox, the spam folder, the Promotions tab, a quarantine, or silently dropped for content reasons. That decision happens in a completely separate part of the receiver's pipeline, and it is never reported back to you through DMARC. There is no field for it. There never has been.

The crucial distinction: passing is permission, not placement

Here is the cleanest way to hold the two ideas apart.

Authentication answers the question "is this really from you?" DMARC, SPF and DKIM are all mechanisms for proving identity. When they pass, the receiver knows the message genuinely originated from a source you authorised. That is a yes/no fact, and DMARC reports it faithfully.

Placement answers the question "do my users want this?" That is a judgement call made by the receiver's reputation and filtering systems, weighing dozens of signals: your domain and IP reputation, historical engagement (do people open and reply, or delete and complain?), content, sending volume and cadence, spam-trap hits, list hygiene, the presence of unsubscribe headers, and much more. Authentication is one input to that judgement, but it is far from the only one.

So passing DMARC is best understood as permission to be judged on your merits, not as a guaranteed seat in the inbox. It clears the identity bar. It removes one major reason a receiver might distrust you. But it does not vouch for your reputation, and reputation is what actually decides placement.

The inverse is the part people find counter-intuitive: a message that fails DMARC is not necessarily blocked. Under p=none nothing is enforced at all, so a failing message is delivered exactly as if DMARC did not exist, the receiver simply notes the failure in its report. Even under p=quarantine or p=reject, individual receivers apply their own logic, local allow-lists, mailing-list exceptions and trust overrides that can let a "failing" message through, or treat a "passing" one with suspicion for unrelated reasons. The policy is a strong request, not a hard guarantee, in either direction.

A worked example: 100% pass, still in spam

Imagine a small company sends its monthly newsletter through a marketing platform. Everything is configured correctly: SPF lists the platform, DKIM is signed with an aligned domain, DMARC passes. The aggregate reports are immaculate, a wall of dmarc=pass from Google and Microsoft alike.

Then someone notices the newsletter keeps landing in Gmail's spam folder. The DMARC reports show nothing wrong, because from DMARC's point of view nothing is wrong. The authentication is flawless. What the reports cannot see is that the company bought an email list two years ago, has a 0.4% complaint rate, and almost nobody opens the newsletter. Gmail's filter has learned that mail from this domain is unwanted, and it acts on that regardless of how cleanly the message authenticates.

No amount of staring at DMARC reports will surface that problem, because it is not an authentication problem. The fix lives in list hygiene, engagement and reputation, not in DNS records. This is the single most common way people over-read their reports: they treat a perfect DMARC pass rate as proof of good deliverability and then cannot understand why mail still goes to spam. The report was never measuring deliverability. It was measuring identity.

The opposite trap: failures that do not matter

The mirror-image mistake is panicking at failures that have no bearing on your real mail. Open almost any aggregate report from a domain that sends meaningful volume and you will find failures. The instinct is to treat every red row as a deliverability emergency. Most of them are not, and learning to triage is half the skill of reading reports.

Three categories of failure routinely show up and routinely mislead:

• Forwarding. When someone forwards your message, or a mailing list relays it, SPF almost always breaks because the forwarding server is not in your SPF record. DKIM often survives forwarding, which is exactly why DMARC accepts a pass from either mechanism. But you will still see SPF failures in your reports for forwarded mail. These are expected, usually harmless, and not something you can or should "fix" in most cases. If DKIM is passing and aligned, DMARC still passes overall.

• Pure spoofing and abuse. A large slice of failures, sometimes the majority of volume, comes from sources that have nothing to do with you: spammers and phishers sending from random servers using your domain in the From: line. These failures are not a bug in your setup. They are DMARC doing its job, catching impersonation. The correct response is not to make them pass, it is to move to p=reject so receivers throw them away. Counting this junk against your "pass rate" gives a misleadingly grim picture.

• A genuinely misconfigured legitimate sender. This is the failure that actually matters, and it hides among the other two. Somewhere in the noise is your billing provider, your CRM, or a support tool that really is sending as you but was never authorised in SPF or set up to sign with DKIM. This is the needle you are looking for.

The whole point of reading reports is to separate that third category from the first two. A raw pass-rate percentage flattens all three together and tells you almost nothing useful. The empty or confusing reports guide covers the related case where the data looks alarming simply because it is sparse or comes from one odd source.

How to read reports without over-reading them

A disciplined reading process keeps you focused on decisions rather than anxiety. Here is the order that works.

1. Group by sending source, not by pass/fail. The useful unit is "which service is this?", not "what is the overall percentage?". Cluster the IPs and identify each one: your mail platform, your transactional sender, your office suite, your support desk. A pass rate means nothing until you know whose mail it describes.

1. Identify every legitimate source and make sure it is aligned. For each service you actually use, confirm it passes SPF or DKIM with alignment. If a real sender is failing, that is your work item: add it to SPF, set up DKIM signing, or fix the alignment. The common mistakes guide and the SPF checker and DKIM checker help here.

1. Set aside forwarding and unknown abuse. Once your known senders are aligned, the remaining failures are overwhelmingly forwarding (harmless) or impersonation (the thing you want blocked). Neither is a reason to delay enforcement.

1. Watch the trend, not a single report. One report from one receiver on one day is a snapshot. The signal you care about is movement over weeks: is the share of aligned, legitimate mail stable and complete? Has a new unidentified source appeared? Trends catch the new SaaS tool marketing signed up for last Tuesday that nobody told IT about.

1. Make the enforcement decision. When every legitimate source is accounted for and aligned, you are ready to tighten the policy, regardless of the headline pass rate including spoofed junk. Moving from p=none to p=reject safely is its own topic, covered in how to reach p=reject without breaking email.

If you would rather not parse XML by hand, the DMARC report analyzer groups everything by source and flags the failures that actually need attention, which is precisely the triage described above.

What DMARC reports genuinely tell you well

It would be a mistake to come away thinking the reports are weak. They are the best visibility you will ever get into one specific, important thing: the complete set of senders using your domain. Use them for what they are excellent at.

• Sender discovery. Reports reveal every server sending as you, including shadow IT, legacy systems and forgotten integrations. This census is impossible to assemble any other way, and it is the foundation of a safe enforcement rollout.
• Configuration validation. They confirm whether your SPF and DKIM are actually working in the wild, as receivers see them, not just whether the records look right in a checker. A record can be syntactically perfect and still fail alignment in practice; reports catch that.
• Spoofing visibility. They quantify how much impersonation your domain attracts, which is both a security signal and the justification for moving to enforcement.
• Policy verification. The report echoes back the policy each receiver saw, which catches stale DNS caches and propagation problems.
• Regression detection. Once you are at enforcement, a sudden rise in failures from a known-good source is an early warning that a vendor changed something. This is exactly what continuous monitoring is for, turning a daily XML chore into an alert that fires only when something genuinely changed.

That last point is worth dwelling on. Reading reports manually is fine for the initial rollout, but the real long-term value is catching regressions: a mail provider rotates a DKIM key, an SPF include silently breaks past the ten-lookup limit, a new sender appears. Those events are invisible until the next report, and easy to miss in a sea of XML. Emailed change alerts exist precisely so you do not have to read every report to notice the one that matters.

Where deliverability actually lives

If DMARC reports do not measure inbox placement, what does? The honest answer is that no single free signal does, but several adjacent ones get you much closer, and they live outside the DMARC reporting channel.

• Reputation and complaints. Engagement, complaint rates and spam-trap hits drive placement. Some providers expose this through their own postmaster tools and feedback loops, which are separate systems from DMARC reporting.
• TLS-RPT. If you publish a TLS-RPT record, you get reports about TLS negotiation failures on inbound mail, a transport-layer signal that has nothing to do with DMARC but affects whether mail arrives at all. The MTA-STS checker and the MTA-STS product page cover the encryption side.
• Direct testing. Sending test messages to seed addresses across the major providers and observing where they land is crude but tells you something DMARC never will: actual placement.
• BIMI. Once you are at enforcement, BIMI can display your logo in supporting inboxes, which is an authentication-gated brand feature rather than a deliverability lever, but it is the kind of upside that only becomes available after you have used your reports to reach p=reject cleanly.

The point is not that DMARC reports are inadequate. It is that deliverability is a multi-layered outcome, and DMARC handles exactly one layer, identity, extremely well. Asking it to also report inbox placement is like asking a passport to tell you whether you will enjoy the country. It verifies who you are. What happens next depends on a lot more than the document.

The practical takeaway

Read your DMARC reports as a map of who sends mail as you and whether they are authenticated, because that is what they are. Use them to discover every legitimate sender, align it, watch for new and unknown sources, and build the confidence to move from p=none to p=reject. That is the job they were designed for and they do it better than anything else.

Do not read them as a deliverability scorecard. A 100% pass rate does not promise the inbox, and a wall of failures does not condemn you, most failures are forwarding or spoofing, not broken mail. When placement is the problem, look to reputation, engagement and list hygiene, not to your DNS records.

If you want the triage done for you, the DMARC report analyzer turns raw XML into a sources-and-failures view, and continuous monitoring turns the daily report habit into change alerts that only fire when something real shifts. And if you would rather hand the whole identity layer to a service that takes your domain from p=none to p=reject without an email outage, that is exactly what the done-for-you products are built to do.