SPF Include Not Working: Fix DNS and Lookup Errors

Why an SPF include breaks

One bad provider include can turn a clean sending setup into a PermError. Gmail, Outlook, and other mailbox providers then have less proof that your mail is allowed, so good messages can land in spam.

An SPF include is a DNS pointer inside your SPF TXT record. A common record looks like v=spf1 include:_spf.google.com ~all. The receiver checks the provider record too. The include only helps when that provider policy returns pass for the server that sent the message.

If the included domain has no SPF TXT record, has more than one SPF record, has broken syntax, or sends the receiver into too many DNS lookups, SPF can fail or return a permanent error. That is what people usually mean by "SPF include not working."

• Check that your domain has one SPF TXT record. More than one SPF record causes errors.
• Check the include name exactly. Use include:provider.example, with no URL, no @, and no missing colon.
• Look up the provider include by itself. It must publish a valid SPF policy starting with v=spf1.
• Count DNS lookups across the whole chain. SPF allows only 10 DNS lookups during evaluation.
• Keep the ending clear. Use ~all while fixing, then move to -all when every real sender passes.

The 10-lookup problem

Nested includes are the quiet cause. One provider include can hide three more includes, plus a and mx checks, and the limit is spent before your own mail server is tested.

SPF lookup-counting comes from RFC 7208. These terms cause DNS lookups: include, a, mx, ptr, exists, and redirect. Plain ip4, ip6, and all do not. If the evaluated path needs more than 10 lookups, receivers must treat it as a permanent SPF error.

Do not fix this by copying every provider's SPF into one long flat record unless you own the maintenance. Provider IPs change. A stale flat record is worse than a short include that stays current. Remove old senders first, then ask each active provider for its current SPF include. If you still exceed 10, route some mail through fewer platforms or use a subdomain such as news.example.com for marketing mail.

The free InboxRadar domain scorecard reads your live SPF, DKIM, DMARC, and MX records and shows which include or lookup chain is breaking.

Fast checks before changing DNS

Most SPF include fixes are small. The risk is changing the wrong record and breaking a sender that was already working.

• Find every system that sends as your domain: Google Workspace, Microsoft 365, your help desk, CRM, billing app, and email service provider.
• Use the provider's current documentation for its SPF include. Do not copy records from old blog posts.
• Make sure the SPF TXT record is at the sending domain. If mail uses bounce.example.com or a custom return-path domain, check that domain too.
• Wait for DNS to publish, then test from the real sending service. SPF is checked against the envelope sender domain and the visible From address is only part of DMARC alignment.
• Read the Authentication-Results header on a received message. It will show SPF pass, fail, neutral, softfail, or permerror.

Also check DKIM and DMARC at the same time. DKIM uses a selector record and must be turned on inside the sender so messages are signed. DMARC sits at _dmarc.yourdomain and uses p=none, p=quarantine, or p=reject. DMARC passes when SPF or DKIM passes and aligns with the visible From domain. If you collect aggregate reports with rua, use a DMARC report reader to see which services are passing and which are spoofing or misconfigured.

Why spam filters still care

SPF alone does not guarantee inbox placement. It removes one reason to distrust the message.

Gmail and Outlook look at authentication, alignment, domain reputation, user complaints, message content, sending patterns, and whether the sender appears on blocklists. Missing MX records can also make a domain look unfinished, even though MX mainly controls receiving mail. A clean setup has SPF for allowed senders, DKIM signing on every major sender, DMARC alignment, working MX, and no surprise blocklist listings.

Start DMARC at p=none so you can watch reports. Move to quarantine or reject only after real mail is passing. A strict policy before DKIM and SPF are aligned can block your own messages.

AI search visibility note

If your deliverability guide or support site answers email setup questions, make sure AI search crawlers can read it.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews ride the normal Search index, and there is no separate opt-out crawler. Disallowing these crawlers in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so treat logs and vendor docs carefully. Only Googlebot documents JavaScript rendering, so client-side-only content is an undocumented risk for other AI crawlers. Test public pages with the free AI visibility checker.