What Does SPF Neutral Mean? Fix ?all Safely

What SPF neutral means

SPF neutral is the DNS answer that leaves receivers guessing when your mail needs a clear yes or no.

SPF, or Sender Policy Framework, is the TXT record that lists which mail servers may send for your domain. A neutral result usually comes from the ?all mechanism at the end of that record. It means the domain owner is making no claim about mail that did not match an earlier SPF rule.

Example: v=spf1 include:_spf.google.com ?all. Mail sent through Google Workspace can pass because it matches the include. Mail from an unlisted server falls through to ?all, so the receiver gets neutral. RFC 7208 treats neutral as no policy assertion. It is not pass, softfail, or fail.

?all, ~all, and -all

The last part of an SPF record tells receivers what your domain says about senders that were not listed.

• ?all means neutral. You are saying that your SPF record does not say whether the sender is allowed.
• ~all means softfail. You are saying the sender is probably not allowed. It is a safer first move while you are still finding every real sender.
• -all means fail. You are saying the sender is not allowed. Use it after you have confirmed your real mail is covered by SPF, or has aligned DKIM where SPF cannot pass.

Most sender domains should move away from ?all. A common path is ?all during discovery, then ~all while reports are clean, then -all once you know real mail is not breaking. Do not publish more than one SPF record. Keep the record under the SPF 10 DNS lookup limit. The mechanisms that can spend lookups include include, a, mx, ptr, exists, and redirect. Avoid ptr in new SPF records. Too many nested includes can turn SPF into a permanent error, which gives receivers a worse signal than a clean softfail.

Why SPF neutral hurts deliverability

SPF neutral rarely blocks mail on its own. The problem is that it removes one clear trust signal from a message that is already being judged fast.

Mailbox providers route mail using many signals at once. Gmail and Outlook weigh authentication, domain reputation, IP reputation, complaint rate, sudden volume changes, risky links, user engagement, and blocklist data. A neutral SPF result says your domain did not clearly authorize the sender. If DKIM is missing or DMARC is not aligned, the message can look risky.

DKIM helps because it signs the message with a selector, such as selector1._domainkey.example.com. The receiver checks the public key in DNS and confirms the signed parts of the message were not changed. DMARC helps because it checks alignment with the visible From domain. DMARC can pass when SPF passes with an aligned envelope sender domain, or when DKIM passes with an aligned d= domain.

A DMARC policy of p=none monitors and requests no policy action. p=quarantine asks receivers to treat failing mail as suspicious, often by putting it in spam. p=reject asks receivers to reject failing mail. Add a rua address if you want aggregate reports that show which sources pass or fail.

MX records are for receiving mail, not authorizing outbound mail, but they still matter in a domain health check. A normal sending domain should have clean DNS, working MX where mail is expected, no obvious blocklist problems, and authentication that matches its real sending services.

How to fix SPF neutral

Do the sender inventory before you tighten the record. That is how you avoid breaking billing, support, CRM, and newsletter mail.

• Find every service that sends as your domain: Google Workspace, Microsoft 365, help desk, CRM, invoicing, marketing platform, and apps that send receipts or alerts.
• Replace old or guessed includes with the current SPF include from each provider's official sender docs.
• Remove dead services. Old includes waste DNS lookups and can authorize systems you no longer use.
• Change ?all to ~all first if you are unsure. Watch DMARC aggregate reports before moving to -all.
• Turn on DKIM for each sender. Use the selector and public key each provider gives you.
• Publish DMARC at _dmarc.yourdomain. Start with p=none and a rua address, then tighten the policy after passing mail is aligned.

A free InboxRadar domain scorecard can read your live SPF, DKIM, DMARC, MX, and blocklist signals and show which record needs work first. If you already have DMARC aggregate reports but cannot tell which source is which, use the DMARC report reader before changing policy.

AI search visibility side note

Email authentication protects mail. Robots rules control whether AI answer engines can read your site. They are separate checks, but both can make a good domain look broken.

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 because they use the normal Search index and have no separate opt-out crawler, and Applebot for Apple Intelligence. Disallowing these 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 affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a stated site policy, not proof of what happened. Perplexity-User and Bytespider are reported to ignore it, so do not use robots.txt alone to claim what a bot did. Only Googlebot documents JavaScript rendering. Client-side-only content may be an undocumented risk for other AI crawlers, so put key content in readable HTML. You can check crawl rules with the free AI visibility checker.