There is a quiet arithmetic oddity in our DNS census of the Tranco top-1M. As of the 2026-07-05 snapshot, 623,370 domains publish SPF, and when we classify which ESPs each record authorizes, the provider shares sum to well over 100%. Amazon SES alone is at 6.21%, SendGrid at 4.75%, Mailgun at 4.10%, Mailchimp at 3.69% — and the list keeps going long past the point where the percentages could describe exclusive choices.
The explanation is that they are not exclusive. A single SPF record routinely authorizes three, four or five sending services at once. The modern company does not have an ESP; it has a sending stack. This article maps what that stack typically contains, why it happened, and how to run one without tripping over SPF's least forgiving rule.
The stack has three lanes — plus the senders you forgot
Look inside a typical multi-sender SPF record and the structure is consistent:
- Marketing mail — newsletters, promotions, lifecycle campaigns. This is the lane people mean when they say "our ESP": Mailchimp, Brevo, HubSpot and their peers.
- Transactional mail — receipts, password resets, notifications. Increasingly routed through infrastructure providers: SES, SendGrid, Mailgun, Postmark. The unbundling that made SES the #1 ESP happened in this lane.
- Support and CRM mail — the lane nobody plans but everybody has. Helpdesk replies from Zendesk, sequences and quotes from Salesforce or HubSpot. These platforms send from your domain, so they live in your SPF record like any ESP.
The third lane is bigger than most marketers realize. Zendesk appears in 3.87% of SPF records (up from 3.05% in 2022), Salesforce in 2.62% (up from 1.11%), and HubSpot in 3.18%. Every one of those is a service sending on the company's behalf, sharing the same domain reputation as the newsletter.
Why the single-ESP company disappeared
Three forces made multi-ESP the default rather than the exception. First, specialization: marketing clouds are mediocre at high-volume transactional delivery, and infrastructure pipes have no campaign tooling, so companies stopped forcing one product to do both jobs. Second, SaaS sprawl: every department now buys tools that happen to send email — the helpdesk, the CRM, the billing system — and each one requests an SPF include during onboarding. Third, risk isolation: separating lanes means a marketing-side reputation problem does not take down password-reset delivery, especially when each lane sends from its own subdomain.
The multi-ESP tax: SPF's 10-lookup limit
The stack model has one hard constraint that predates all of it. RFC 7208 caps SPF evaluation at 10 DNS lookups — and every include:, a, mx, redirect=, exists: and ptr mechanism costs at least one, with nested includes counting too. Blow past the limit and receivers return PermError, which many treat as an authentication failure for your entire domain.
A five-provider record can burn through the budget faster than it looks, because one marketing-suite include may expand into several nested lookups. A stack accumulated tool by tool over five years is exactly how domains end up there. The failure mode and its workarounds — flattening included — get a full treatment in our 10-lookup-limit deep dive; the short version of stack hygiene:
- Audit annually. Pull your SPF record and match every include to a tool you still pay for. Departed vendors leave lookups behind.
- Use subdomains as lane separators.
mail.example.comfor marketing,tx.example.comfor transactional: each subdomain gets its own SPF record with its own 10-lookup budget, and its own reputation. - Count before you add. When the next SaaS tool asks for an include, check your current lookup count first — not after the PermError.
# Count what's in your record today
dig +short TXT example.com | grep spf1
# Each include:/a/mx/redirect/exists costs a lookup — nested ones tooSplitting senders does not split accountability. DMARC evaluates everything sent as your domain, and mailbox providers score the domain across all lanes. A misconfigured helpdesk or an over-aggressive CRM sequence tool degrades the same reputation your newsletter depends on.
Verify the stack end to end
The operational blind spot of multi-ESP is that each lane gets tested by a different team, usually at setup time, and then never again together. Mail from your marketing ESP may land in the inbox while helpdesk replies from the same domain land in spam — and no single dashboard shows you that. The fix is to placement-test each sending path separately: send a probe through the marketing platform, the transactional pipe and the support tool to seed mailboxes at the major providers, and compare where each one lands and how each authenticates. Do it after every stack change, and check your own domain's SPF sprawl against the wider population in the daily email infrastructure report.