DMARC

The SPF Blind Spot That Turns Client-Authorized Senders Into Client Complaints

November 12, 2026

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

A client's finance team quietly signs up with a new invoicing platform. Marketing switches email tools for a campaign. A sales ops lead connects a proposal-tracking app that sends follow-ups from the company domain. None of these decisions reach the MSP's ticketing queue, and none of them show up in SPF until a DMARC report flags the failure or, worse, until a customer calls to ask why an invoice "from" the client landed in spam.

This is the gap that shows up again and again in DMARC rollouts: a domain is protected, a sender is legitimate and client-approved, and the two facts never get reconciled in DNS. The fix is mechanical, SPF simply needs the sender's include or IP added, but the breakdown is organizational. Nobody owns the inventory of who sends mail as the client, so the record drifts out of sync with reality until enforcement exposes it, and the client's first call goes to the MSP, not the vendor who should have told someone.

Why does a client-approved sender still fail authentication?

Because SPF does not know what "approved" means. It only knows what's written in a DNS TXT record, and if a sending platform's IP range or include statement isn't there, the message fails no matter how legitimate the business relationship is. SPF authenticates infrastructure, not intent, which is exactly how a marketing team can onboard a tool with full authority and still break deliverability the same afternoon.

The mechanism is well defined. SPF checks the domain in the envelope "MAIL FROM" against the IP addresses and includes published in that domain's record, as described in RFC 7208, the IETF standard that governs SPF evaluation. Google's own admin guidance is direct about the consequence of skipping this step: if an SPF record doesn't reference every service that sends mail for the domain, messages from those senders can fail and be rejected or sent to spam. Microsoft's troubleshooting documentation says the same thing from the other side of the stack, listing a missing third-party include as one of the standard root causes behind SPF failures and the DMARC failures that follow from them in its email authentication troubleshooting guide.

How the gap actually forms

Nobody sets out to leave a sender unauthorized. It happens through a handful of recurring patterns that repeat across almost every client environment an MSP manages.

• A department signs a contract with a SaaS vendor without looping in IT, and the vendor starts sending transactional mail from the client's domain within days of onboarding.
• A legacy platform gets replaced, but the old include is never removed and the new one is never added, so the SPF record silently falls out of date on both ends.
• A well-meaning admin adds a vendor's include and pushes the record past the 10-lookup ceiling, which triggers a permanent error that fails SPF for every sender on the domain, not just the new one.
• A client assumes that because DKIM is set up for one tool, every tool is covered, when DMARC only needs one of SPF or DKIM to align, not both, and that assumption quietly creates a false sense of safety.

That third pattern deserves emphasis because it is almost never understood as a limit until it is hit. RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms, and once a record exceeds that count the receiving server returns a permanent error and treats the authentication check as failed for every sender listed, not just the one that pushed it over. Microsoft's own documentation on SPF for Microsoft 365 customers warns that records referencing multiple third-party domains can rack up DNS lookups quickly, and recommends replacing vendor includes with flattened IP ranges where the vendor offers a stable range to stay under the ceiling.

What happens when attackers find the gap before the client does?

They exploit exactly the authentication inconsistency the MSP left unmonitored. A domain with strong DMARC enforcement but a stale SPF record still presents real openings, either through the unauthenticated sender itself getting spoofed, or through the general confusion a known failure creates when a client starts treating every authentication warning as noise.

Microsoft's security team has documented this pattern directly in production phishing campaigns, describing cases where complex routing and incomplete connector configuration let attackers spoof an organization's own domain in credential-phishing attempts, and recommending strict DMARC reject policies alongside properly configured third-party connectors as the fix, not reject alone, in a 2026 writeup on domain spoofing techniques. The financial stakes behind that advice are not abstract. The FBI's Internet Crime Complaint Center reported business email compromise losses approaching three billion dollars in a single year, a figure that has climbed every year the bureau has tracked it, according to its 2023 Internet Crime Report analysis. Every unauthenticated or partially authenticated sending path on a protected domain is a thread an attacker can pull, and SPF gaps left by legitimate vendors are indistinguishable from SPF gaps left by nobody at all until someone investigates.

The table below shows how the same underlying issue, a sender missing from SPF, produces different outcomes depending on what else is configured.

This is also why federal guidance treats DMARC enforcement as inseparable from ongoing authentication hygiene rather than a one-time deployment task. CISA's Binding Operational Directive 18-01 required federal civilian agencies to move to a DMARC policy of "reject," describing it as the configuration that provides the strongest protection against spoofed email by rejecting unauthenticated messages at the mail server. That directive assumes agencies keep their sender inventories current enough that reject doesn't start blocking their own legitimate mail, an assumption that holds up far less often in the commercial SMB and mid-market world MSPs actually operate in.

Where this becomes a revenue problem, not just a technical one

Every hour an engineer spends diagnosing "why did our newsletter stop arriving" after the fact is an hour that wasn't billed as proactive monitoring, and it's an hour the client remembers as the MSP's mistake rather than their own vendor's oversight. That perception gap compounds over a client relationship. A client who associates DMARC with breakage rather than protection becomes a client who resists the next security initiative, who second-guesses invoices for authentication work, and who tells other business owners that the MSP "broke their email" when the real cause was an unlisted CRM integration three departments never disclosed.

The commercial fix is to stop treating SPF record accuracy as a set-and-forget task and start treating it as a monitored asset, the same way patch status or backup completion gets monitored. MSPs that build this into their standard service catalog can price it as recurring value instead of absorbing it as unbilled firefighting, and tools built specifically for multi-tenant domain oversight make the difference between catching a missing include in a weekly scan and catching it on an angry phone call. ActiScan's getting-started guide walks through connecting client domains so that SPF, DKIM, and DMARC drift gets flagged before enforcement turns a configuration gap into a delivery failure.

Positioning this as a line item rather than a favor also changes the client conversation entirely. Instead of explaining, after the fact, why a vendor's mail started bouncing, the MSP can point to a monitoring plan that already catches these changes, and the pricing page makes it straightforward to scope that coverage across a book of client domains without re-negotiating every engagement individually. For MSPs still handling this manually across spreadsheets and quarterly DNS audits, the fastest way to see the gap across an existing client base is to sign up and run a baseline scan rather than wait for the next client complaint to reveal it.

None of this requires predicting every tool a client will adopt. It requires having visibility into the ones they already use, often before the client's own staff fully remembers what they signed up for last quarter.