DMARC

The Silent Authentication Gap: When Clients' Own Systems Break SPF and DKIM

October 20, 2026

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

A managed service provider sets up SPF, DKIM, and DMARC for a client once, watches the reports settle into a clean pattern, and moves on to the next ticket. Nine months later the client's accounting platform migrates to new outbound mail servers during a routine infrastructure upgrade, and every invoice it sends starts failing authentication at the recipient's mail server. Nobody changed the DNS. Nobody filed a ticket. The MSP simply never knew the vendor moved.

This is the core failure mode worth naming directly: authentication gaps rarely open because an MSP configured something wrong. They open because a third-party system the client depends on, a billing platform, an ERP module, an accounting tool, changes its own sending infrastructure without telling anyone downstream, and the client's SPF or DKIM records quietly stop reflecting reality.

Why Does a Billing Platform's Infrastructure Change Break Authentication?

SPF authorizes senders by listing specific IP addresses or including another domain's SPF record. When a transactional vendor rotates its outbound IP ranges, migrates to a new sending domain, or spins up new regional infrastructure, any client record that references the old addresses stops matching. Google's own troubleshooting guidance for Workspace admins is explicit that domains using outside services to send mail "must specify these services in one SPF record," and that a neutral, softfail, or fail result often means a legitimate sender's IP simply isn't listed anymore, as noted in Google Workspace's SPF troubleshooting documentation. The vendor hasn't done anything wrong from its own perspective. It changed infrastructure the way any growing SaaS platform periodically does. The client's DNS record just never heard about it.

DKIM has a parallel failure path. If the transactional platform rotates its signing keys or migrates to a new signing domain as part of an infrastructure change, messages signed with the new key won't validate against whatever public key the client published, or the signature may not exist at all if the new sending path bypasses DKIM signing during a transition period. Either failure alone can be absorbed by DMARC's relaxed alignment. Both failing together, during the same migration window, is what pushes real invoices into spam or outright rejection.

The SPF Record Problem MSPs Don't See Coming

Most MSPs who deploy DMARC for clients already know about the SPF 10 DNS lookup limit defined in RFC 7208. What gets missed is how a routine vendor infrastructure change interacts with that limit long after the initial setup is finished. Each include: mechanism in an SPF record costs at least one lookup, and nested includes inside a vendor's own record can add several more without that cost ever showing up in the client's own DNS editor, a dynamic explained clearly in Courier's breakdown of the SPF permerror failure mode.

A client running a CRM, a help desk, a marketing platform, and a billing system easily accumulates enough nested includes to sit at eight or nine lookups with no visible slack. When the billing vendor then migrates infrastructure and asks the client to add a new include or an additional IP block, that single change can push the record past ten lookups and trigger a permerror, a result that functions as a total SPF failure for every sender in the record, not just the new one. Valimail's analysis of this pattern notes that once a domain is "already at 7-10 lookups, adding a single new sending service" can be enough to block mail that had been authenticating correctly for years, as described in Valimail's guide to the SPF lookup limit.

The failure is silent in the specific sense that matters to an MSP's workflow: no alert fires in the client's inbox, no ticket gets opened by the vendor, and the DNS record that was correct on the day it was written looks exactly the same six months later. It is still wrong, just wrong for a new reason.

How Would an MSP Even Know This Happened?

The only reliable early signal is DMARC aggregate reporting, because it is the one mechanism designed specifically to tell a domain owner what is actually sending mail on their behalf, independent of what anyone remembers configuring. RFC 7489 describes the aggregate report's purpose as giving domain owners "precise insight into authentication results" and the corrective action that follows from them, a design detail laid out in the DMARC specification itself.

In practice, this means an MSP watching aggregate reports across a client portfolio would see a new, unrecognized sending IP appear under the client's domain, often weeks before a human at the client company notices invoices bouncing. Without that report flow, the first signal is almost always a client's own customer calling to ask why a payment reminder landed in a spam folder. By then the authentication gap has likely existed for days or weeks.

A few patterns are worth watching for specifically across a client book:

• A known transactional sender's volume in DMARC reports drops sharply while an unfamiliar IP in the same general range starts appearing, which usually indicates a mid-migration vendor rather than a new threat.
• SPF results shift from pass to permerror across an entire domain rather than failing for just one sender, which points to the lookup limit rather than a single bad vendor.
• DKIM results go from consistently aligned to intermittently missing for one specific mail stream, which often tracks a signing-key or signing-domain change on the vendor's side.

Building Vendor Change into the Authentication Operating Model

Treating SPF and DKIM as a one-time deployment task is the root operational mistake, not a lack of technical knowledge. NIST's guidance on trustworthy email makes the same point from the standards side, recommending that organizations using third-party senders should actively confirm that mail from those parties continues to pass authentication checks, rather than assuming a correct configuration persists indefinitely, per NIST Special Publication 800-177. That confirmation has to be recurring, because the vendor's infrastructure is not static even when the client's business hasn't changed at all.

For an MSP managing dozens or hundreds of client domains, this only scales as a scheduled process, not a memory. A recurring domain scan that diffs current SPF includes and DKIM selectors against the last known-good state turns an invisible drift into a dated alert an engineer can act on before a client's finance team starts fielding complaints from their own customers. ActiScan's scanning cadence is built around that kind of continuous comparison, and new technicians onboarding client domains can see the full workflow in the getting-started guide.

The operational checklist that holds up across client portfolios looks like this:

• Pull DMARC aggregate data at least weekly, not just at initial setup, and flag any new sending IP automatically rather than relying on a human to notice it.
• Keep a documented inventory of every transactional vendor per client, including which ones use SPF includes versus static IPs, since static IP vendors fail differently than ones using dynamic ranges.
• Set a lookup-count ceiling well below 10 for every client SPF record, so there is margin when a vendor adds a new include during its own migration.
• Confirm DKIM key rotation schedules with major transactional vendors where that information is published, rather than discovering a rotation after signatures start failing.

None of this guarantees a client's authentication will never break, since the vendor side of the relationship is outside any MSP's direct control. What it does is shrink the time between a vendor's infrastructure change and the MSP's awareness of it, which is the only part of this problem an MSP actually governs. Portfolios that scan across many client domains on a predictable schedule, rather than relying on a client to report a problem, tend to catch these gaps in days instead of discovering them through a support escalation weeks later. Firms evaluating how that kind of scanning cadence fits their client load can review plan structures on the pricing page or start a trial through the signup page to see the drift detection in action against a live client domain.

The underlying lesson is simple even if the failure mode is not: a client's transactional systems are owned and operated by someone else entirely, and that someone else has no obligation, and often no mechanism, to tell the MSP when infrastructure changes. Building the assumption of silent vendor drift into routine scanning, rather than treating SPF and DKIM as settled once they pass, is what separates a portfolio that catches these gaps early from one that learns about them from an angry client.