DMARC

The DMARC Handoff Problem: Why Inherited Policies Cost More Than New Ones

September 29, 2026

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

A new client arrives with a DMARC record already in DNS. On paper, that looks like a head start. In practice, it is often the opposite: a partial deployment left at p=none for years, an SPF record stitched together by three different vendors, and nobody left at the company who remembers why any of it is configured the way it is. The previous provider's invoice said "DMARC implemented." It rarely said "DMARC understood."

Why does inheriting a DMARC record cost more than starting from zero?

Because a blank DNS zone has no history to reverse-engineer, while an inherited one does. Every include: statement in an old SPF record, every stale DKIM selector, and every pct= tag was a decision someone made for a reason that is no longer documented. An MSP has to figure out what is safe to remove before it can figure out what to add, and that discovery work does not show up on the original vendor's invoice.

This is the trap: the original deployment, the part that looks like the expensive step, is usually the fast part. Publishing a TXT record takes minutes. The part nobody bills for properly is the audit that has to happen before any policy change is safe, tracing every legitimate sending source, matching it against what is actually authorized, and deciding what a stale entry from a decommissioned marketing platform is still doing in the SPF chain.

What actually breaks in a half-deployed setup?

The most common failure mode is a domain stuck at p=none indefinitely. RFC 7489 defines none as the policy under which the domain owner requests no specific action be taken regarding delivery of messages, which is exactly why so many previous vendors left it there: it generates reports without ever risking a delivery failure, and it is easy to sell as "DMARC is live." The official DMARC specification treats none as a monitoring stage, not an end state, but plenty of legacy deployments never move past it because nobody went back to read the aggregate reports.

The second failure mode is SPF that has silently broken. RFC 7208 is explicit that SPF implementations must limit the total number of DNS-interrogating mechanisms to ten during evaluation, and if that limit is exceeded the check must return a permanent error. Years of bolted-on include: statements for every CRM, helpdesk tool, and marketing platform a client has ever tried push many inherited records past that ceiling, and the SPF standard itself makes clear that a permerror is not a soft warning, it is a failed check.

A third pattern shows up in DKIM: selectors pointing at key pairs for services the client stopped using years ago, still published in DNS, never rotated, never removed. None of these are visible from outside without pulling the actual records and correlating them against a current list of what the business sends mail through today.

The audit is the expensive part, not the record

Here is the direct answer: publishing or editing a DMARC, SPF, or DKIM record is trivial. What costs real time is reconstructing the sending inventory an inherited domain depends on, verifying which entries in an old SPF chain are still legitimate, and confirming DKIM alignment before tightening a policy that could otherwise silently drop a client's invoices or payroll email.

That reconstruction work is invisible until an MSP tries to move a client from p=none toward enforcement. Google's own guidance for high-volume senders requires a DMARC record for anyone sending more than 5,000 messages a day to Gmail accounts, but explicitly notes that the enforcement policy itself can still be set to none while the sender authenticates its mail, which is precisely why so many domains meet the letter of a compliance deadline without meeting its intent. Google's email sender guidelines describe the baseline requirements clearly, but they do not describe the discovery work needed to get an old, undocumented domain to that baseline safely.

For MSPs, that discovery work typically includes:

• Pulling every historical SPF include and testing whether the underlying vendor is still contracted
• Cross-referencing DKIM selectors against active mail platforms and rotating or retiring the rest
• Reviewing weeks of aggregate DMARC reports before touching the policy tag, since a single billing cycle rarely captures irregular senders like year-end mailings or annual renewal notices

Federal guidance backs up the caution here. CISA's Binding Operational Directive 18-01, aimed at civilian agencies, required setting a DMARC policy of "reject" for all second-level domains and mail-sending hosts, but it phased that in with an interim step at p=none specifically so agencies could observe traffic before enforcing anything. If a federal timeline builds in a monitoring period before enforcement, a commercial MSP inheriting an undocumented domain from another provider has even less excuse to skip it.

A comparison of what gets skipped

The pattern in that table is consistent across the inherited-domain cases MSPs run into: the visible line item was the cheap step, and the step that actually protects the domain from spoofing was the one nobody scoped.

Why this matters more now than it did two years ago

Mailbox providers have raised the floor. Gmail and Yahoo's 2024 bulk sender requirements pushed DMARC from a nice-to-have into a de facto delivery requirement for anyone sending meaningful volume, and Microsoft's own documentation on setting up DMARC in Microsoft 365 frames the same validation as protection against business email compromise and phishing that spoofs a company's own domain. That framing matters for MSPs specifically, because a domain inherited mid-deployment is often the one most exposed to exactly that kind of impersonation, since its policy never reached the enforcement level that would actually block a fraudulent message.

The operational reality is that a client rarely knows which parts of their existing DNS were finished and which were abandoned mid-project. An MSP that treats the audit phase as a quick verification step before jumping to policy changes is the one that ends up debugging a support ticket months later, tracing a bounced invoice back to an SPF chain nobody actually inventoried. Tooling that continuously scans a domain's SPF, DKIM, and DMARC posture and flags stale or orphaned entries turns that audit from a one-time forensic exercise into an ongoing baseline, which is a large part of what a scanning platform like ActiScan is built to automate for MSPs managing dozens of client domains at once.

Building the audit into the standard onboarding

The fix is procedural, not technical. Every new client engagement should include a mandatory discovery phase before any DNS record is touched, treating an existing DMARC record as unverified until proven otherwise rather than assuming the previous vendor did the work correctly. That phase should be scoped and billed separately from the policy work that follows it, because conflating the two is exactly how the audit cost gets absorbed silently into a fixed-price onboarding fee.

Documenting that discovery process once, as part of a repeatable playbook, is far cheaper than rediscovering it for every inherited domain. Teams that want a structured starting point can walk through ActiScan's getting-started guide to see how the audit and monitoring phases are sequenced before any policy tag changes. For MSPs scoping this work across a client base rather than a single domain, it is worth comparing how audit and monitoring time is priced on the pricing page against what an internal analyst would spend doing the same reconciliation by hand.

None of this guarantees a clean migration. Some inherited domains have sending sources so tangled that full reconciliation takes weeks, not days, and a policy move to reject still carries risk even after a careful audit. What a structured discovery phase does is make that risk visible and priced, instead of leaving it as an unbudgeted surprise three weeks into a project that was scoped as "just update the DMARC record." MSPs that want to see what a properly instrumented audit looks like against their own client domains can start with a signup and run the scan against an inherited domain before making a single DNS change.

The lesson for the industry is simple to state and hard to practice: a DMARC record already existing in a domain's DNS is not evidence that the domain is protected. It is evidence that someone, at some point, started a project. Whether they finished it is the only question that actually matters, and answering it is where the real cost of the engagement lives.