SPF's +all Catch-All Turns Includes Into Open Trust
A hand-edited SPF record with a permissive +all catch-all or an unscoped third-party include mechanism can let any tenant on a shared ESP IP pool pass SPF as your domain. DMARC alignment then rubber-stamps spoofed mail, and standard mail filtering never sees the forgery as anomalous.
At a glance
- Unsafe setting
- SPF record terminates in +all or chains unscoped third-party includes from shared-IP ESPs.
- Failure trigger
- A tenant sharing the same ESP IP pool sends mail, or the includes exceed the ten-lookup limit and resolve to permerror.
- Blast radius
- Spoofed mail passes SPF and DMARC alignment as if sent from the legitimate domain, or legitimate transactional mail bounces silently.
- Recommended control
- Terminate SPF with -all, dedicate IPs or subdomains per ESP, and enforce DMARC with strict alignment (aspf=s).
Fix commands and configuration
dig TXT yourdomain.comspf-expand-allThe Trap
An SPF record ending in +all instead of -all, or an SPF chain built from unscoped third-party include: mechanisms pointing at shared-IP email service providers.
The Default State
Marketing platforms and CRM vendors (Mailchimp, SendGrid, Salesforce Marketing Cloud, HubSpot) publish onboarding snippets such as v=spf1 include:sendgrid.net ~all. When deliverability tickets come in, junior admins frequently swap ~all for +all to stop SPF softfails appearing in logs, treating it as a quick fix rather than a policy change. Over time, procurement adds more SaaS tools, each contributing its own include:, and nobody removes the ones no longer in use. The record grows into a chain of six or seven includes, none scoped to specific sending IPs.
The Blast Radius
SPF’s include mechanism does not vet the sender, it defers trust to whatever IP ranges the included domain’s own SPF record authorises. Shared-IP ESPs serve thousands of tenants from the same pool, so any customer of that same SendGrid or Mailchimp account tier can send mail that passes SPF as your domain, because the receiving MTA only checks whether the source IP appears in the resolved SPF tree, not who owns the sending account. Add a +all catch-all and the SPF check becomes unconditionally true regardless of source IP, meaning even non-affiliated infrastructure passes. Once DMARC is configured with relaxed SPF alignment (aspf=r), any authenticated envelope-from subdomain match forces a DMARC pass, and phishing mail lands in inboxes with a green padlock-equivalent authentication result. Separately, stacking includes without pruning frequently breaches the RFC 7208 ten-DNS-lookup ceiling, producing a silent permerror that some receivers treat as an outright fail, bouncing legitimate transactional mail during a busy sending period with no alert raised.
The Lead Mechanic Fix
Run dig TXT yourdomain.com and manually resolve every nested include with a tool like spf-expand or Kitterman’s SPF Record Testing Tool, counting lookups. Terminate the record with -all, never +all or bare ~all in production. Remove any ESP include no longer in active use, and for remaining shared-pool vendors, request a dedicated IP or dedicated sending subdomain (e.g. bounce.mkt.yourdomain.com) with its own SPF and DKIM selector, then set DMARC to aspf=s (strict alignment) so only exact From-domain matches pass. Enforce p=reject once alignment is confirmed via aggregate reports.