DMARC
How MSPs Miss Revenue When DMARC Rejects Clients' Own Internal Email
November 9, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A client calls the help desk because an internal email never arrived. The sending employee is real, the domain is real, the message was never spam. Somewhere between the outbound server and the inbox, a DNS lookup budget quietly ran out, and nobody on the support ticket has any idea that's what happened. This is one of the most common and least understood failure modes in MSP-managed email, and it tends to surface only after a client has already decided the MSP's monitoring isn't catching the things that matter.
The short answer: SPF records have a hard limit of 10 DNS lookups, and every third-party service added over the years (Microsoft 365, Google Workspace, a CRM, a help desk tool, a marketing platform) spends part of that budget through nested includes. Once the budget is exhausted, SPF returns a permanent error, DMARC treats it as a fail, and a policy of quarantine or reject starts discarding legitimate mail with no warning to anyone.
Why Does a Technically Correct SPF Record Still Fail?
Because "correct" syntax and "evaluable" syntax are not the same thing. An SPF record can be perfectly valid DNS and still break authentication for every message a domain sends, simply because evaluating it costs too many DNS queries.
The rule comes directly from the specification. RFC 7208 requires that the limits in section 4.6.4 be followed to prevent denial-of-service conditions, and those processing limits cap SPF evaluation at 10 DNS-querying mechanisms per check. The include, a, mx, exists, and ptr mechanisms, along with the redirect modifier, all count against that ceiling. Static mechanisms like ip4 and ip6 don't, because they resolve nothing. When the ceiling is crossed, the receiving server isn't supposed to guess. It returns a PermError, and most receiving systems treat a PermError exactly like an outright SPF failure, regardless of whether the actual sending IP was perfectly legitimate.
That last detail is what makes this failure mode so dangerous for MSPs. The problem isn't that an attacker spoofed the domain. The problem is that the receiving mail server literally could not finish checking, so it defaults to the least permissive outcome.
How Do Include Chains Quietly Exceed the Limit?
They exceed it through accumulation, not through any single bad decision. Each platform a client adopts over time adds one more include: mechanism, and each of those mechanisms can itself contain nested includes that spend additional lookups without ever appearing in the client's own DNS record.
Microsoft's own guidance is explicit about this mechanics. Microsoft Learn documentation on Microsoft 365 DNS records notes that a domain's SPF record can have a few different inclusions but that the total DNS lookups those inclusions generate can't be more than 10, specifically to prevent denial-of-service conditions. Google gives the same structural warning from the other direction. Google's own setup guidance states that an SPF record can have up to 10 include: tags, which sounds generous until a domain is running Microsoft 365, a helpdesk platform, a CRM, and a marketing automation tool simultaneously, each contributing its own nested chain.
This is precisely why an MSP that added include:spf.protection.outlook.com during onboarding two years ago, then layered in a billing platform's include last year, then a new marketing tool last quarter, can end up with a domain that silently crossed the 10-lookup threshold without a single obviously wrong line in the record. Nobody touched the "broken" include. The tenth and eleventh lookups simply arrived later, from somewhere else entirely.
| Mechanism | Counts toward the 10-lookup limit? |
|---|---|
include: | Yes, plus every nested include inside it |
a, mx, exists | Yes |
redirect modifier | Yes |
ptr | Yes (and discouraged separately) |
ip4, ip6, all | No, these resolve without a DNS query |
What Happens When DMARC Enforcement Meets a Broken SPF Chain?
It depends entirely on whether DKIM can save the message, and for a large share of internal and transactional mail, it cannot. DMARC, as defined in RFC 7489, passes a message if either SPF or DKIM produces an aligned result. If a client's SPF has silently PermErrored and the outbound system in question isn't DKIM-signing with an aligned domain, that message has no path to a DMARC pass at all.
Under a policy of p=reject, the specification states that the mail receiver should reject the message during the SMTP transaction itself, which means the sender often gets a bounce rather than a quiet spam-folder drop. Under p=quarantine, the message typically lands somewhere the recipient never checks. Either way, the mail simply stops arriving, and it stops arriving for every message the broken SPF chain touches, not just the ones from an unfamiliar IP.
This is not a hypothetical edge case for MSP clients. Regulatory guidance has pushed many organizations toward reject-level enforcement precisely because it is the strongest protection against spoofing. The Department of Homeland Security's Binding Operational Directive 18-01 required federal agencies to move to a DMARC policy of "reject" specifically because it provides the strongest protection against spoofed email. Clients in regulated industries, or simply clients that read security guidance and asked their MSP to "turn on DMARC properly," are increasingly running at enforcement levels where a single lookup-budget overrun breaks real mail, not just phishing attempts.
The Revenue Cost MSPs Don't See on the Invoice
The direct cost shows up as unbillable firefighting. A client reports "my email isn't sending," a technician spends an hour checking mail flow rules, mailbox settings, and spam filters before anyone thinks to run an SPF lookup count, and the ticket closes with a one-line DNS fix that could have been caught in minutes by a scheduled check.
The indirect cost is larger and harder to invoice around:
- Missed invoices and password resets erode client confidence in the MSP's "we monitor your domain" claims, even when the monitoring that exists simply wasn't checking this specific condition.
- Clients who self-diagnose the problem (often by Googling "emails not sending DMARC") start to wonder what else isn't being watched, which is a retention risk disguised as a support ticket.
- Every hour spent reactively tracing a PermError is an hour not spent on billable security work the MSP could otherwise be selling as a managed service.
None of this requires a security incident. It only requires a client adding one more SaaS tool to their stack without anyone recalculating the lookup budget that tool just spent.
Building Monitoring Into the Service, Not the Firefight
The fix is less about any single DNS edit and more about treating SPF lookup budget as a monitored metric, the same way disk space or certificate expiry gets monitored. A record that passes today can fail the moment a client's marketing team signs up for a new platform without looping in IT, and that gap is exactly where reactive support models lose money that proactive monitoring would have captured as a renewal-worthy service.
Teams that are still verifying SPF and DMARC posture by hand, client by client, tend to find this exact failure only after a client already noticed it first. ActiScan's approach is built around catching lookup-count creep and chain depth before it crosses the RFC 7208 ceiling, which is the kind of check that belongs in a standing scan rather than a one-time audit. For MSPs standardizing this across a client book, the getting-started guide walks through connecting a first domain and reading the initial chain-depth report, and the pricing page lays out how scanning scales from a handful of domains to a full managed portfolio. Technicians who want to see what a flagged include chain actually looks like before committing to a plan can run a domain through a free check via signup.
Email authentication failures that originate in SPF lookup budgets are entirely preventable, but only if someone is counting the lookups before the tenth one arrives uninvited. For an MSP, that counting is the difference between a client who never notices DMARC was even deployed and one who calls asking why their own invoices bounced.