DMARC

The Gap Between "Has a DMARC Record" and "Actually Protected" Is Where MSPs Live

August 27, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

A domain can have a syntactically perfect DMARC record, pass every lookup tool's green checkmark, and still let an attacker send convincing spoofed mail from it tomorrow morning. That is not a hypothetical edge case. It is the default state of most published DMARC records on the internet right now, and it is the single most common misunderstanding MSPs run into when a client says "we already have DMARC set up."

What Does It Actually Mean to Be "Protected" by DMARC?

A domain is meaningfully protected by DMARC only when its policy is set to quarantine or reject and its SPF and DKIM records are correctly aligned, not merely present. A record published with p=none asks receiving servers to take no enforcement action at all, so failing messages are delivered exactly as if DMARC didn't exist. Per RFC 7489, the policy only produces any effect on delivery once it moves past monitoring mode, and until then the domain owner is simply collecting data, not blocking spoofed mail.

That distinction sounds obvious once it's spelled out, but it explains why "we have DMARC" and "we're protected" have become two different claims in practice. The gap between them is not a rounding error. It is where a large share of the internet's published DMARC records currently sit, and where MSPs spend most of their actual operational time.

The Scale of the Gap

The numbers back this up more starkly than most MSPs expect. A December 2025 analysis from Red Sift, based on a sample of 73.3 million domains, found that only 14.9% of domains had implemented any DMARC policy at all, and just 2.5% had reached the strictest enforcement level of p=reject. That means the overwhelming majority of domains with a record still haven't crossed into enforcement.

EasyDMARC's 2025 adoption report, drawn from the top 1.8 million domains, tells a similar story from a different angle. Among domains that had published DMARC, 508,269 were still sitting at monitoring-only p=none while only 350,513 had moved to active quarantine or reject enforcement. Roughly six in ten DMARC records in that dataset were still doing nothing but watching.

The visibility side is just as thin. More than 70% of DMARC-enabled domains studied were found to be missing reporting (RUA) tags entirely, which means the domain owner has no aggregate report feed telling them who is sending mail as their brand, legitimate or not. A record with a policy tag but no rua tag is a lock with no way to check who's been trying the door.

Why Records Get Stuck at p=none

Nobody deploys DMARC intending to leave it at p=none forever. It gets stuck there for structural reasons that have nothing to do with negligence.

The most common cause is that moving to enforcement without complete visibility into every legitimate sending source breaks real mail. Marketing platforms, invoicing tools, helpdesk software, and forwarded mail from acquired subsidiaries all send "from" the domain in ways that may not be authorized under the existing SPF record or signed with an aligned DKIM key. Jump straight to p=reject without accounting for all of them, and the business's own legitimate mail starts bouncing, which is precisely the outcome that makes a client revert the change and distrust the next attempt.

SPF has its own quiet failure mode that compounds this. RFC 7208 caps SPF evaluation at 10 DNS-querying mechanisms, and exceeding that limit forces a permanent error regardless of whether the sending source was legitimate. Domains that have accumulated years of include: statements for every SaaS tool the business has ever adopted routinely blow past that ceiling without anyone noticing, because the record still looks fine in a text editor. It only breaks at evaluation time, silently, for some percentage of mail.

How Do MSPs Tell the Difference Between Published and Enforced?

The check is straightforward but rarely automated by the tools MSPs already use for other things. It requires reading the actual p= value in the DNS record, confirming SPF and DKIM alignment rather than just their presence, and verifying that aggregate reports are actually flowing in and being reviewed.

None of that shows up in a basic "does this domain have a DMARC TXT record" scan, which is exactly the kind of surface-level check that produces false confidence. A domain can return a valid, well-formed DMARC record and still fail every one of the three tests above. The table below breaks down what each policy stance actually delivers operationally.

Google's own sender guidance underscores why the policy value matters beyond the compliance checkbox. Google's guidelines confirm that for bulk senders, both SPF and DKIM must be set up, but a p=none policy still satisfies the minimum bar as long as the domain in the From header is properly aligned. That means a domain can technically clear Google's bulk sender requirement while remaining fully unprotected against spoofing everywhere else, which is a distinction plenty of clients miss when they hear "we're compliant with Google's rules now."

Where This Leaves MSP Operations

This is the part of the job that doesn't show up in a one-time audit. DMARC enforcement is not a project with a completion date. It's an ongoing operational state that has to survive new SaaS tools being adopted, marketing platforms being swapped, and employees leaving who were the only ones who knew a particular sending source existed.

NIST's guidance on trustworthy email frames SPF, DKIM, and DMARC as a set of complementary mechanisms for authenticating a sending domain rather than a single switch to flip, and that framing matters operationally. Each piece can degrade independently: a DKIM key can expire, an SPF include can disappear when a vendor changes infrastructure, a rua address can start silently bouncing. A record that was fully enforced and monitored six months ago can quietly regress to something far weaker without anyone changing a line of DNS on purpose.

For an MSP managing dozens or hundreds of client domains, that means the deliverable clients actually need is not "DMARC was set up" but ongoing verification that the policy, alignment, and reporting are all still doing what they're supposed to. Getting a client from a bare record to real enforcement is a staged process, and a practical getting-started guide is generally more useful than trying to jump straight to p=reject on day one. The stages matter more than the speed.

Pricing this work also has to reflect that it's recurring, not a one-time deliverable. Reviewing what a domain scanning platform charges for continuous monitoring across a book of client domains, as laid out on most pricing pages in this category, tends to make the recurring-service argument clearer to clients than any amount of explanation about alignment tags. The record is cheap to publish. Keeping it enforced and monitored is the actual service, and it's worth structuring engagements, and rates, around that reality rather than the one-time setup.

For MSPs evaluating whether their current toolset actually distinguishes "has a record" from "is enforced," starting with a domain audit rather than a records lookup is the more honest first step. Teams that want to see where their client portfolio currently stands against the policy, alignment, and reporting checks described above can walk through the process by creating an account through signup and running the comparison directly.

The gap between a published record and genuine protection isn't closing on its own. It's closing one client, one enforcement rollout, and one monitored rua feed at a time, and that slow, unglamorous work is exactly the space MSPs are positioned to own.