DMARC
The Third-Party Senders Nobody Told You About: Why MSPs Discover SPF Gaps After the Breach, Not Before
October 29, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A client's marketing team signs up for a new email platform on a Tuesday afternoon. Nobody files a ticket. Nobody tells the MSP. Six months later that platform is still sending invoices, newsletters, or password resets under the client's domain, and not one of those messages is reflected in the SPF record the MSP configured at onboarding. This is not a hypothetical. It is the normal lifecycle of a growing business's SaaS stack, and it is quietly becoming one of the more expensive blind spots in managed domain security.
Why Do Unlisted Senders Keep Appearing in Client Domains?
Unlisted senders appear because SPF, DKIM, and DMARC are static records that reflect a single moment in time, while the services a client uses to send mail change constantly. A new CRM, a billing tool, an HR platform, or a help desk gets connected to the domain for outbound mail, and unless someone updates the SPF record and rotates DKIM selectors, that sender exists outside the authentication framework entirely. Google's own setup guidance makes the obligation explicit: domain owners must "update your SPF record" every time they adopt a new mail server or third-party sender, but that update depends on someone remembering to tell IT, which rarely happens in practice.
That gap is not cosmetic. SPF, defined in RFC 7208, caps evaluation at ten DNS lookups and was written as a way for domain owners to declare authorized senders, not to discover them after the fact. Microsoft's own documentation for Exchange Online spells out the same discipline for any organization layering a third-party service into its mail flow, noting that the SPF record requires the standard value for Microsoft 365 plus any additional senders the organization adds on top of it. Every addition is a manual step, and manual steps get skipped.
The Record Nobody Updated Is Still a Liability
The practical result is that most client domains carry a layer of invisible senders, SaaS platforms, marketing tools, and transactional mail services that were connected at some point and never reconciled against DNS. These senders don't show up until a DMARC report flags them, a deliverability problem surfaces, or, worse, an attacker finds the gap first. For an MSP managing dozens of client domains, that invisible layer represents both unmanaged risk and an unbilled service opportunity.
This pattern plays out in two directions, and both are costly for the MSP that isn't watching for them. The first is the embarrassing one: a legitimate sender the client is actively using gets blocked or sent to spam because it was never added to SPF, generating a support ticket that looks like the MSP missed something basic. The second is the dangerous one, and it is the kind of gap that eventually ends up in a breach postmortem rather than a support queue.
What Happens When Attackers Find the Gap First?
Attackers who find abandoned or forgotten DNS records before an MSP does can hijack them to send mail that looks like it originates from a trusted domain, without ever touching the live mail server. Guardio Labs researchers documented this at scale with a campaign they named SubdoMailing, which as reported by Kaspersky involved "over 8000 domains and 13,000 subdomains previously owned by legitimate companies" that attackers repurposed to send spam and phishing mail. Those were not domains with weak SPF records. They were domains with forgotten DNS entries nobody was monitoring at all, which is the same failure mode as an unlisted sender, just discovered by the wrong party first.
Federal civilian agencies were required to close exactly this kind of gap under CISA's Binding Operational Directive 18-01, which mandates that all second-level agency domains have valid SPF and DMARC records in place specifically because unauthenticated mail is trivially spoofed without it. Commercial clients face the identical exposure without a directive forcing the issue, which is precisely why it tends to surface during an incident rather than a planned review.
The Scale of the Gap Is Measurable, Not Anecdotal
It would be convenient to treat this as a rare edge case, but the data on authentication coverage suggests otherwise. Valimail's most recent DMARC research found a significant gap between organizations that have published a DMARC record and those that have actually configured it to block spoofed mail, describing a wide "Enforcement Gap" that leaves a majority of domains exposed to impersonation even where some authentication exists. A domain sitting at a monitoring-only DMARC policy, which is the default and the safest starting posture, will generate aggregate reports that list every sending source hitting that domain, including the ones nobody remembers approving. Most MSPs are not reading those reports closely enough to catch them.
The mechanics of why this keeps happening are structural, not a matter of client carelessness:
- SaaS procurement increasingly happens inside individual departments rather than through IT, so a new invoicing platform or marketing tool gets connected to a domain's sending identity without a corresponding DNS change request.
- SPF's ten-lookup ceiling under RFC 7208 means MSPs who do try to keep records current are often forced to choose between adding a new legitimate sender and staying under the limit, which creates pressure to leave stale includes in place rather than reconcile the full list.
- DMARC reports are machine-readable XML sent daily or more often, and without a parsing tool, the unfamiliar sending sources buried in them simply go unread.
Where the Revenue Sits
None of this is a problem a one-time SPF setup solves. It is an ongoing monitoring requirement, which is exactly the kind of recurring, billable work MSPs are structured to deliver and often aren't packaging as a distinct service. A client's authentication posture on the day of onboarding tells an MSP almost nothing about what that domain will be sending through eighteen months later, and the MSPs who treat domain authentication as a quarterly or annual check are the ones who find out about a new sender during a client's compliance review instead of during a scheduled audit.
The service model that closes this gap looks less like a one-time project and more like continuous DNS and DMARC report monitoring layered on top of the authentication records already in place. That means parsing aggregate reports for new sending IPs, flagging them against known third-party services, and rolling confirmed senders into SPF and DKIM before they become either a deliverability complaint or an attacker's entry point. Framed that way, the work fits naturally into an existing managed security retainer rather than requiring a new sales conversation from scratch.
| Discovery method | Who finds it first | Typical outcome |
|---|---|---|
| Scheduled DMARC report review | MSP | Sender added to SPF, no disruption |
| Client support ticket | Client, reactively | Delayed mail, reputational friction |
| Attacker exploitation | Threat actor | Spoofed mail, incident response, client trust damage |
Building this into a managed offering doesn't require reinventing an MSP's stack. A platform that continuously watches a client's authentication records and flags new or unauthorized senders as they appear turns a reactive scramble into a routine line item, and the getting-started guide walks through how that monitoring gets attached to an existing client domain without disrupting current mail flow. For MSPs weighing whether to fold this into existing security bundles or sell it as a standalone add-on, the pricing page breaks down how coverage scales across a multi-client portfolio. Teams ready to see what unlisted senders are already active across their book of business can start directly from the sign-up page.
The Discovery Timing Problem Is the Real Cost
The core issue is not that third-party senders exist. It is that most MSPs find out about them at the worst possible moment, after a spoofing incident, a failed compliance review, or a client's own security team asks a question the MSP can't answer with current data. Every unlisted sender sitting in a client's mail flow today is a known unknown. The only variable left is who finds it first, and that answer determines whether the discovery becomes a billable improvement or an incident report.
Shifting that timeline from reactive to scheduled is a modest operational change with an outsized effect on both client trust and recurring revenue. It costs an MSP almost nothing to check a DMARC report on a cadence. It costs considerably more, in both remediation hours and client confidence, to explain after the fact why a forgotten sender was never caught.