MSP Operations

The Silent Revenue Leak: Why MSPs Are Leaving Money on the Table by Not Monitoring Email Authentication Decay Post-Enforcement

September 29, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

A managed service provider spends weeks getting a client's domain to DMARC enforcement. SPF is tightened, DKIM keys are published, the policy moves from p=none to p=quarantine to p=reject. The invoice goes out, the project is marked complete, and everyone moves on to the next ticket. Nine months later, a marketing vendor changes its outbound IP range, the client's SPF record silently exceeds its lookup limit, and half of their invoice emails start landing in spam. Nobody notices until a customer complains about a missed payment reminder.

That gap between "deployed" and "still working" is where MSPs are quietly losing money. Authentication decay happens because SPF, DKIM, and DMARC records depend on external factors, vendor IP changes, key rotation schedules, new SaaS tools, that shift long after go-live, and because most MSP contracts bill for the initial setup rather than the ongoing verification that it still holds.

What Causes Authentication Decay, and Why Does Enforcement Make It Worse?

Authentication decay is the slow drift of SPF, DKIM, and DMARC records away from the sending infrastructure they were built to describe. It gets worse after enforcement because a policy at p=reject doesn't just flag broken mail, it silently discards it, so failures stop generating visible bounce complaints and start generating invisible deliverability losses instead.

SPF is a common failure point because it has a hard structural limit. The specification defined in RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms, and every additional include for a new marketing platform, CRM, or helpdesk tool pushes a domain closer to that ceiling. Once it's crossed, the record returns a permanent error and authentication fails for every message from that domain, not just the ones from the new vendor.

DKIM has its own decay clock. Keys that go unrotated for years become a liability rather than a safeguard, which is why the Messaging, Malware and Mobile Anti-Abuse Working Group publishes dedicated best-practice guidance on DKIM key rotation recommending organizations rotate keys on a regular cadence rather than leaving them static indefinitely. Most client environments never get that second look after the initial signing key goes live.

How Big Is the Gap Between "Deployed" and "Still Enforced"?

The gap is larger than most MSPs assume because the bar for enforcement keeps moving even after a client's domain clears it. Google's bulk sender rules and the federal government's own mandate both illustrate how authentication requirements are treated as an ongoing compliance posture, not a one-time checkbox.

Google's guidance to senders is explicit that meeting the bar once isn't the same as staying compliant. Google's own sender guidelines state that senders should set up SPF or DKIM authentication and keep DNS records like PTR entries valid on an ongoing basis, and Google recommends bulk senders actively use Postmaster Tools to confirm they continue to meet those requirements rather than assuming a past pass carries forward indefinitely, as described in its sender requirements and Postmaster Tools FAQ.

The federal government took the same view years earlier. When the Department of Homeland Security issued Binding Operational Directive 18-01 in 2017, it required federal agencies to move to DMARC enforcement, and the directive frames this as a standing security posture for enhancing email and web security across executive branch domains, not a one-time deployment milestone. Agencies that hit enforcement in 2018 were still expected to maintain it years later as their mail infrastructure changed.

The underlying standard itself hasn't stayed static either. In 2026, the IETF published RFC 9989 and companion documents, formally moving DMARC from an informational specification to a Proposed Standard and obsoleting the original RFC 7489 that most existing deployments were built against. A record that was correct against the letter of the original spec can still need review against the clarified guidance in its successor.

Why Don't MSPs Catch This Before Clients Do?

Most MSPs don't catch decay early because the billing model doesn't ask them to look. DMARC rollout is typically scoped and priced as a project with a defined end date, and once the client signs off on enforcement, there's rarely a recurring line item tied to verifying the record still matches reality six or twelve months later.

That structural gap shows up in a few predictable ways across client environments:

• A client adds a new email marketing platform or CRM integration and nobody updates the SPF include list, pushing the record past the ten-lookup ceiling.
• DKIM selectors from a decommissioned platform stay published in DNS indefinitely, widening the attack surface without adding any authentication value.
• A subdomain spun up for a new product or acquisition never gets its own DMARC policy, leaving it exposed even though the primary domain is enforced.
• Cloud migrations change outbound mail server IPs and the SPF record isn't updated until deliverability visibly drops.

Each of these is invisible from the client's side until it produces a support ticket, a missed invoice, or a spoofed email that gets through. By the time that happens, the MSP is doing unbilled incident response instead of billing for a monitoring contract that could have caught the drift months earlier.

The Recurring Revenue Sitting Inside the Decay Problem

The fix isn't a bigger one-time project, it's a shift in what gets billed. Continuous authentication monitoring turns a client's domain health into a recurring service line rather than a project that closes out and disappears from the invoice.

Positioning this as an ongoing service also changes the client conversation from "we fixed your email security" to "we keep your email security correct as your business changes," which is a much easier renewal to justify. MSPs that package continuous scanning into their existing security stack tend to find it easier to defend margin, since the labor is automated detection rather than manual re-audits every time a client complains about deliverability.

Platforms built for this exact gap, including ActiScan, are designed to sit on top of a client's existing DNS and flag SPF lookup counts approaching the limit, DKIM keys past their rotation window, and subdomains missing DMARC coverage before those issues turn into missed invoices or phishing incidents. For an MSP evaluating whether to add this as a line item, the pricing page breaks down how monitoring scales per domain versus per client, which matters when a single MSP might be watching authentication records across dozens of tenants at once.

Getting a monitoring program running doesn't require re-doing the original DMARC project. The getting-started guide walks through connecting existing client domains to continuous scanning without touching the records that are already working, and provider teams that want to see how the alerting and reporting look in practice can move straight to the signup page to start a domain audit.

What This Means for MSP Contracts Going Forward

Authentication decay isn't a hypothetical risk model, it's a predictable outcome of DNS records depending on external systems that change without notice. Vendors rotate IPs, keys age past their useful life, and standards bodies keep refining the specification years after most domains were configured against an earlier version of it.

The MSPs capturing the most value from email security aren't the ones with the cleanest initial DMARC rollout. They're the ones who turned that rollout into a subscription, billing for the ongoing certainty that a client's authentication posture still matches what was deployed on day one. Every domain sitting at enforcement without a monitoring contract attached is a renewal conversation that hasn't happened yet, and in most MSP books of business, that conversation is worth more over three years than the original project ever was.