What does SPF neutral mean and how do I fix a broken SPF record?
Published 14 Jul 2025
Updated 15 Oct 2026
12 min read
Summarize with
Updated on 15 Oct 2026: We clarified SPF neutral troubleshooting and added the correct way to split long SPF TXT records.
SPF neutral means the receiving mail server found an SPF record, but that record gave no clear pass or fail decision for the sending IP. This is a completed check with no authorization assertion; it does not establish SPF pass. A common cause is an SPF record ending in ?all, which means "neutral for everything else." Neutral alone does not tell a receiver to deliver or reject the message.
The fix is to check the domain SPF actually evaluated, publish one valid SPF TXT record for that domain, include every approved sender, stay within the 10-term DNS lookup limit, and set an explicit policy for unmatched senders, directly or through a valid redirect= delegation. For most production domains, that means moving away from ?all once you have mapped your senders.
- Immediate answer: SPF neutral is a valid no-assertion result. Investigate it when approved mail should pass.
- Domain to check: SPF checks the bounce domain, also called the MAIL FROM or Return-Path domain.
- Result to target: Use SPF pass for approved mail, then decide between softfail and fail for everything else.
- DMARC caveat: DMARC can still pass through DKIM, but neutral SPF gives DMARC no SPF pass to use.
What SPF neutral means
SPF (Sender Policy Framework) is a DNS-based authorization check. The receiver asks whether the sending IP is allowed to send mail for the bounce domain. The answer comes from the SPF TXT record. A neutral result is different from a hard failure, a soft failure, and a missing record. It says the record owner chose not to state whether that sender is authorized. The receiver then applies its own filtering policy alongside DKIM, DMARC, reputation, and message signals.
|
|
|
|
|---|---|---|---|
+ | Pass | Authorized | Default when a qualifier is omitted |
~ | Softfail | Probably not authorized | Cautious rollout or softfail policy |
- | Fail | Not authorized | Strict policy |
? | Neutral | No assertion | Intentional no-assertion policy |
No SPF record found | None | No policy retrieved | Not configured |
SPF qualifiers and the separate none result
Neutral is not a pass
RFC 7208 requires receivers to handle neutral like none. Neutral means a policy made no assertion. None usually means no SPF record was retrieved; malformed policies and duplicate SPF records produce permerror instead.
Typical neutral SPF recordDNS
v=spf1 include:_spf.google.com ?all
That record says Google Workspace is allowed if its include matches, but every other source gets neutral. If the tested source does not match the include, the receiver reaches ?all and records SPF neutral. That is why a domain can look "configured" in DNS and still fail to give receivers a useful signal.
Changing ?all to -all only changes unmatched mail to fail. To get pass, the legitimate sending IP must match an authorization mechanism before the final all. A matching mechanism with a ? qualifier also returns neutral, even if the final policy is -all.
Why SPF neutral appears after a DNS fix
A DNS edit can leave SPF neutral unchanged when it updates the wrong domain or leaves the actual sender reaching a neutral mechanism. A saved DNS change does not prove that the sending IP is authorized. Duplicate SPF records are a separate fault and normally produce permerror rather than neutral.
Looks fixed in DNS
- Record exists: A TXT record begins with v=spf1.
- Provider included: The record references Google Workspace or another sender.
- Public DNS checked: A DNS query returns the new SPF value for the evaluated domain.
- Status changed: The header now says neutral, but approved mail still lacks SPF pass.
Still broken in mail flow
- Wrong domain checked: The SPF edit was made on the visible From domain instead of the evaluated bounce domain.
- Neutral qualifier: The record ends in ?all and makes no assertion about unlisted senders.
- Missing source: The sending IP is not covered by any mechanism.
- Separate lookup fault: Too many evaluated DNS lookup terms produce permerror, rather than neutral.
The biggest trap is checking the wrong domain. SPF does not authenticate the visible From address. It authenticates the bounce domain. If you add an SPF record to example.com but the message uses bounce.example.net in Return-Path, the receiver checks bounce.example.net. This is also why sender IP checks can look confusing when the domain being tested is not the domain you expected. SPF records are not inherited automatically by subdomains. For an empty MAIL FROM, such as a bounce message, SPF uses the HELO/EHLO domain. If a provider owns the evaluated domain, configure a custom MAIL FROM or Return-Path where supported instead of editing an unrelated record.
SPF neutral troubleshooting flowchart: message headers, Return-Path, SPF policy, sender match, final qualifier, and retest.
Do not start by editing DNS again. Start with the actual message headers, because they show which domain was evaluated, which IP sent the message, and the reported SPF result. They do not always identify the matching mechanism. Without that evidence, the next DNS change is guesswork.
How to fix a broken SPF record
Use the same repair sequence for SPF neutral, SPF none, softfail surprises, and structurally broken records. The sequence keeps the work grounded in the message that failed instead of a stale list of senders.
- Pull headers: Open the full header for a real message that shows SPF neutral.
- Find the SPF identity: Look for smtp.mailfrom in the receiving provider's Authentication-Results, then compare it with Return-Path. Check smtp.helo when MAIL FROM is empty.
- Check DNS: Use the SPF checker or query DNS directly for that exact domain.
- Keep one policy: Publish SPF only as a TXT record and keep one SPF policy at the evaluated owner name. Other TXT records can remain.
- Add approved senders: Authorize only services that use this MAIL FROM domain. Use the provider's documented include, or ip4: and ip6: for controlled sending servers; check IPv6 as well as IPv4.
- Choose the policy: Use ~all during staging, then -all when all legitimate senders are accounted for and you intend a fail policy. For redirect= delegation, set the policy at the target; adding all to the redirecting record disables the redirect.
- Retest mail: Send a new message, read the new headers, and confirm SPF pass for the right domain.
Illustrative message headers: SPF neutral with DMARC passtext
From: sender@example.com Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.receiver.example; spf=neutral smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Here SPF checked bounce.example.com, while DKIM allowed DMARC to pass for example.com. Use Authentication-Results added by the receiving mailbox provider and the connecting IP reported by that receiver; forwarded messages can contain earlier results.
DNS checksBASH
dig +short TXT bounce.example.com nslookup -type=TXT bounce.example.com
Replace bounce.example.com in these commands with the exact evaluated domain. Suped's SPF checker helps identify duplicate records, invalid mechanisms, and include chains that exceed lookup limits. A missing all mechanism is valid with redirect=; without a redirect, unmatched senders receive neutral.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Match the repair to the result in the new header. Unexpected neutral on legitimate mail calls for checking sender coverage and qualifiers. Temperror usually points to a transient DNS failure, so retry before editing the record. Permerror requires a permanent fix such as correcting syntax, merging duplicate SPF records, or reducing lookup-causing terms.
After the DNS record is clean, the real proof is a fresh message. Cached DNS, old test messages, and headers copied before the fix can make the result look unchanged. Allow existing DNS cache entries to expire according to the previous TTL, then send again and read the new Authentication-Results line.
Duplicate SPF records break evaluation
Do not publish one SPF record for Google Workspace and another for a marketing platform. SPF requires one record per owner name. Combine authorized mechanisms into one SPF TXT value.
How forwarding affects SPF and DMARC
Forwarding can turn legitimate mail into an SPF neutral or fail result because the final receiver checks the forwarder's connecting IP against the original bounce domain's SPF policy. That IP usually is not authorized by the original sender. An SPF record ending in ?all can turn this mismatch into neutral, but weakening the policy does not repair forwarding.
- Confirm the path: Read Received and Authentication-Results headers to see whether a forwarder changed the connecting IP.
- Do not authorize strangers: Do not add an unrelated forwarding server to your SPF record just to force a pass.
- Protect DMARC with DKIM: Use DKIM signing with a domain tied to the visible From domain so DMARC can pass when the signature survives forwarding.
- Fix controlled forwarding: If you operate the forwarder, Sender Rewriting Scheme (SRS) gives the rewritten bounce domain its own SPF check. This does not create SPF alignment with the original From domain.
When SPF pass counts toward DMARC
DMARC passes when either SPF or DKIM passes with the required domain match. For SPF, relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. An SPF pass for an unrelated provider bounce domain does not satisfy DMARC. SPF pass also does not guarantee inbox placement.
Correct SPF record examples
These examples are patterns, not copy-and-paste answers. Your correct record depends on the bounce domain and the systems that send mail for that domain. The structure is useful: start with v=spf1, list approved senders, and finish with an explicit policy, or use redirect= to delegate the policy.
Google Workspace onlyDNS
v=spf1 include:_spf.google.com -all
Google Workspace and controlled sending serversDNS
v=spf1 include:_spf.google.com ip4:192.0.2.10 ip6:2001:db8::10 ~all
Policies to review when approved mail does not passDNS
v=spf1 ?all v=spf1 include:_spf.google.com ?all v=spf1 include:_spf.google.com v=spf1 include:_spf.google.com +all
The first pattern authorizes nothing but is syntactically valid. The second gives a clear pass only when Google matches, then gives neutral for everything else. The third has neither a final all mechanism nor redirect=, so unmatched senders get the implicit neutral result. The fourth permits every sender and should not be used. A valid redirect= policy can omit all; adding all makes SPF ignore the redirect. The IP addresses in the controlled-server example are reserved for documentation. Replace them with actual outbound server addresses.
Policy choice matters
- Choose neutral deliberately: A final ?all is a valid no-assertion policy, but it does not authorize unlisted legitimate senders.
- Use softfail for a cautious rollout: A final ~all tells receivers unlisted senders are probably not approved.
- Use fail when ready: A final -all says unlisted senders are not approved.
- Avoid pass-all: A final +all defeats the purpose of SPF.
How to fix SPF TXT records over 255 characters
The 255-byte limit applies to each string inside a DNS TXT record, not the complete SPF policy. RFC 7208 permits multiple strings within one TXT record. Receivers join them without inserting spaces, so preserve spaces between mechanisms.
Multiple strings in one TXT recordDNS
example.com. IN TXT "v=spf1 ip4:192.0.2.10 " "ip6:2001:db8::10 -all"
This short zone-file example shows the format; both strings belong to one record. DNS panels handle quoting differently, so follow your host's instructions. Do not create separate SPF records. Splitting strings does not reduce the 10-term DNS lookup count.
When the problem is the lookup limit
SPF permits up to 10 evaluated terms that cause DNS lookups. Include, redirect, exists, a, mx, and ptr terms count toward that limit, including terms reached through nested includes. The initial SPF TXT retrieval does not count toward this limit, and ip4, ip6, and all do not consume it. The count depends on terms actually reached during evaluation, rather than the number of raw DNS packets. When a team adds Google Workspace, Microsoft 365, helpdesk mail, CRM mail, and marketing mail into one record, the record can exceed the 10 lookup limit.
SPF lookup headroom
The 0-7 and 8-10 bands are review guidelines. The protocol limit is 10 evaluated DNS lookup terms; an evaluation that exceeds it returns permerror.
More headroom
0-7
Room for added terms; other SPF errors still need checking.
Limited headroom
8-10
Small provider changes can break SPF.
Limit exceeded
11+
Evaluation exceeds the permitted total.
Void lookups need a separate check. A void lookup returns no records or a name error. SPF implementations are advised to limit these responses to two, and an implementation that enforces the limit returns permerror when it is exceeded. Stale include, a, mx, redirect, and exists targets can consume that allowance.
The practical fix is to remove unused senders, configure separate MAIL FROM subdomains with their own SPF policies where the provider supports it, and use SPF flattening when the record has too many active senders to stay healthy by hand.
Flattening needs maintenance
Manual flattening can go stale when a provider changes IP ranges. If you flatten SPF, automate updates or use hosted management so the flattened IP list stays current.
How Suped fits into the fix
A simple neutral SPF record can be fixed with one careful DNS edit. Ongoing sender control is harder. Suped is our DMARC reporting and email authentication platform. Use its DMARC reports to identify sending sources and review SPF failures after a DNS repair. Reports arrive on reporting intervals, so use fresh message headers for immediate verification.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped's Hosted SPF lets you manage authorized senders after the initial DNS setup and maintains flattened provider IP ranges as they change. This supports ongoing sender management when repeated manual SPF edits are difficult to maintain.
For initial DNS triage, use Suped's domain health checker to review authentication records, then investigate message-level results in headers and DMARC reports.
SPF repair checklist
Verify the repair with fresh messages from each active sending service. An SPF pass for one source does not prove that every approved sender is covered.
Final checklist
- Header verified: The SPF domain in Authentication-Results is the domain you fixed.
- Record clean: Only one SPF TXT record exists for the tested domain.
- Senders covered: Every legitimate source using the evaluated domain is authorized and stale sources are removed.
- Policy chosen: Set ~all or -all in the sender policy when appropriate, or use a valid redirect= delegation. Confirm approved mail passes before tightening the policy.
- Lookup count safe: The record evaluates no more than 10 lookup-causing terms and avoids excess void lookups.
Frequently asked questions
SPF neutral is a valid result, but it is a problem when approved mail should pass. Check for ?all, another mechanism with a ? qualifier, or an unmatched sender reaching the implicit neutral default. Neutral alone does not require rejection.
Receivers must handle neutral like none, but the diagnostic meaning differs. None usually means no SPF record was retrieved. Neutral means a policy was found but made no assertion. A malformed SPF policy or duplicate SPF records produce permerror, not none.
Use ?all when you deliberately want no assertion for unmatched senders. Use ~all for a cautious softfail policy and -all when you intend a fail policy after accounting for legitimate senders. None of these endings creates SPF pass for a missing sender.
A message whose sending IP matches an ordinary include:_spf.google.com mechanism passes before SPF reaches ?all. If it is neutral, check the actual MAIL FROM domain, connecting IP, and qualifiers. A Google include on a different domain does not authorize the tested message.
Yes, DMARC can pass through DKIM when DKIM passes for a domain tied to the visible From domain. SPF neutral does not give DMARC an SPF pass to use.
The final receiver sees the forwarding server's IP, which is usually absent from the original bounce domain's SPF policy. Use aligned DKIM to support DMARC through forwarding, and do not authorize arbitrary forwarders in your SPF record.
