DMARC

Why DMARC Enforcement Quietly Drifts Back to p=none

October 7, 2026

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

A domain reaches p=reject after months of careful rollout. The project gets marked closed, the ticket is archived, and everyone moves on to the next client. Eighteen months later, a phishing email spoofing that exact domain lands in a customer's inbox without friction, because the DMARC record now reads p=none. Nobody changed it on purpose. Nobody noticed it change at all. This pattern, not a one-time misconfiguration, is the more common failure mode in managed DMARC programs, and it is almost entirely invisible to an MSP that only checks in during onboarding.

The short answer: DMARC enforcement regresses because p=none has no expiration, no owner requirement, and no alert mechanism built into the record itself. Once aggregate reports stop being read, nothing in the DNS, the mailbox, or the client relationship forces anyone to notice when a record is weakened, replaced, or dropped during a routine DNS change.

Why does enforcement regress after a domain reaches p=reject?

Enforcement regresses because DMARC was never designed to be self-maintaining. The specification defines a policy state and a reporting channel, but it places the obligation to read those reports, and to defend the policy against future change, entirely outside the protocol. A record sitting at p=reject looks identical in DNS to one that was just published yesterday. There is no version history, no built-in alert if it is edited, and no signal that distinguishes a deliberate rollback from an accidental overwrite.

In practice, the record gets touched by people who were never part of the original rollout. A new website vendor exports and reimports the DNS zone during a migration and drops the DMARC TXT record along with it. A marketing platform's setup wizard writes its own _dmarc entry without checking what already exists. An employee troubleshooting a bounced email "fixes" the record by setting it back to none, because none is what every quick DMARC tutorial recommends as the safe starting point, and nobody tells them the domain had already graduated past it. None of these actors are acting maliciously. They are acting on partial information, in a system with no enforcement memory.

What breaks when nobody is reading the aggregate reports?

The reporting loop that was supposed to catch regressions goes silent, because the same lack of ownership that lets the policy drift also lets the reports pile up unread. Aggregate reports (RUA) are the only mechanism DMARC provides for a domain owner to see what is happening to their mail stream, and they only have value if someone is parsing them on a recurring basis, not just during the initial rollout window.

This is not a hypothetical concern. Independent tracking cited by Dark Reading found that the share of DMARC-enabled domains with an enforced policy actually fell, from a high of 18% to less than 14% in roughly a year, even as overall DMARC adoption was climbing because of the Google and Yahoo bulk sender requirements that took effect in 2024. Adoption and enforcement are not the same curve, and in that window they moved in opposite directions. More domains published a record. Fewer of them kept it at a level that actually blocked spoofed mail.

Industry-wide numbers make the base rate clear. Red Sift's global tracking of DMARC adoption found that as of December 2025, only 14.9% of domains in a 73.3 million domain sample had even started their DMARC journey by publishing a policy of at least p=none, and the same dataset showed that only 2.5% of all domains, around 1.8 million, had reached p=reject. The gap between those two figures is almost entirely domains stalled, or returned, to monitoring mode.

Why do mandates hold enforcement and voluntary programs don't?

Enforcement holds where there is a recurring compliance check and an external party with the authority to flag regression, which is exactly what voluntary MSP engagements usually lack after the initial project closes. The clearest contrast is the US federal government, where CISA's Binding Operational Directive 18-01 required agencies to publish a DMARC record within 90 days and move to a policy of "reject" for all second-level domains within one year, with the aggregate reports routed to a central federal reporting mailbox rather than left to each agency's own inbox.

That structure matters more than the mandate itself. A central recipient for aggregate reports means someone outside the domain owner is also watching the data, which makes a silent regression back to p=none visible to a party with the standing to raise it. Most MSP clients have no equivalent. The MSP configured the record, the client approved moving to enforcement, and then the relationship often shifts to ticket-based support where DMARC is nobody's recurring line item.

Mailbox providers apply a lighter version of the same pressure, but it caps out at a low bar. Google's bulk sender guidance requires authenticated domains to maintain SPF and DKIM, and specifies that bulk senders must have a DMARC record with at minimum a policy of none to stay compliant. That threshold protects against a domain having no record at all, but it does nothing to stop a domain from dropping from reject back to none, because none still technically satisfies the requirement.

The MSP visibility gap

The structural problem for MSPs is that DNS monitoring and DMARC reporting are usually treated as two separate workflows, when a drift event shows up cleanly in both. A record change appears instantly in a DNS lookup. A drop in enforcement also shows up in the next aggregate report cycle as a shift in the disposition field from "reject" back to "none." A monitoring approach that checks only one of those two signals will eventually miss a drift event that the other would have caught immediately.

Common regression triggers an MSP needs to watch for include:

• A client-side DNS provider migration that does not carry every TXT record into the new zone
• A marketing or helpdesk platform's auto-configuration wizard overwriting the existing _dmarc record
• An internal IT change made by someone unaware the domain had already reached enforcement
• A client offboarding or vendor transition where DMARC ownership was never explicitly reassigned

Relying on the third row of that table, the reactive one, is how most regressions actually get discovered today, usually well after the exposure window has already mattered.

Closing the gap without adding headcount

None of this requires an MSP to staff a team that reads raw XML every morning. It requires treating policy state as a monitored metric with the same discipline as uptime or patch compliance, rather than a one-time deliverable that gets checked off at rollout. A recurring DNS check compares the live record against the last known approved state, flags any change in the p= tag, and ties that flag to an alert rather than waiting for the next monthly report to surface it. That single control catches the DNS-provider-migration and wizard-overwrite scenarios before a single piece of spoofed mail goes out, which is the whole point of having reached enforcement in the first place.

For MSPs standing up or auditing this capability, ActiScan's getting-started guide walks through configuring that recurring check alongside aggregate report ingestion so both signals feed the same alert queue instead of living in separate tools. Teams evaluating how this fits into existing per-client billing can review the tiered options on the pricing page, and those ready to put continuous policy monitoring in front of a client portfolio can get started directly from the signup page.

DMARC enforcement is not a milestone that, once reached, stays reached on its own. It is a state that has to be defended against the ordinary churn of DNS changes, vendor swaps, and staff turnover that every client domain goes through over time. The domains that hold their enforcement level long-term are, almost without exception, the ones where somebody, or something, is still watching after the rollout project ends.

Further Reading

• dev.to
• www.zoho.com