Why is my SPF record showing 'None' and how can I resolve it?
Updated on 21 Oct 2026: We clarified SPF None troubleshooting with DNS publishing checks, negative caching guidance, and precise SPF error definitions.
SPF showing 'None' means the receiving server retrieved no SPF policy for the identity it checked, or it could not extract a valid domain from that identity. In normal mail, the important part is which domain it checked. SPF is evaluated against the SMTP Mail From domain, often visible in headers as Return-Path or smtp.mailfrom, not necessarily the visible From address in the inbox.
The fix is usually straightforward: find the Return-Path domain, query the TXT and CNAME answers for that exact hostname, publish one valid SPF TXT record or the provider-required CNAME, then compare the authoritative answer with more than one recursive resolver. If authoritative nameservers disagree, fix the DNS zone. If only recursive resolvers disagree, check the remaining cache lifetime, including negative caching for a previously missing record, and test again.
- First check: Inspect the message headers and copy the Return-Path or smtp.mailfrom domain exactly.
- Main cause: The checked domain has no TXT record that starts with v=spf1, or DNS returns an inconsistent answer.
- Correct fix: Fix the DNS at the owner name SPF actually checks, then confirm that the same answer appears through authoritative and recursive DNS.
What SPF None means
SPF None is not the same as SPF fail. It means SPF had no policy to evaluate for the checked identity. Usually, a receiver asked DNS for an SPF record and found no TXT value beginning with v=spf1. A TXT value that contains only a provider hostname has no SPF meaning. Less often, the SMTP session did not supply a syntactically valid domain that SPF could check.
The short version
Treat SPF None as an identity and DNS discovery problem first. Do not start by changing DMARC policy or rewriting every sender record. SPF None is an authentication result; DMARC p=none is a monitoring policy, and it does not disable SPF checks.
- None: No SPF policy was retrieved, or no valid domain was available to check.
- Neutral: An SPF policy exists, but it explicitly makes no authorization claim.
- Fail: A policy exists and says the sending IP is not authorized.
- Softfail: A policy marks the sending IP as probably unauthorized, commonly through ~all.
- TempError: A temporary DNS problem stopped the check, so a later retry can succeed.
- PermError: A published policy cannot be evaluated because of invalid syntax, multiple SPF records, excessive DNS lookups, or another permanent policy error.
Authentication result example
Authentication-Results: mx.example.net; spf=none smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
That header means SPF did not authenticate the bounce domain. It does not say the visible sender domain has no SPF record. It also does not say the message failed DMARC, because aligned DKIM passed for the visible From domain. A focused SPF checker helps confirm whether the exact hostname has a usable SPF policy.
For a delivery status notification or another message with a null Return-Path, SPF constructs the Mail From identity using postmaster and the SMTP HELO domain. Check the identity field in Authentication-Results or Received-SPF before assuming the root domain should contain the missing policy.
Why SPF returns None
Most SPF None cases come from checking the wrong domain, omitting a policy on a bounce subdomain, pointing a CNAME to a target with no SPF record, publishing plain text instead of an SPF policy, or receiving an empty or inconsistent DNS answer. NXDOMAIN for the checked domain also produces None.
Flowchart showing how to trace SPF None from message headers to DNS repair.
|
|
|
|---|---|---|
Wrong host | Return-Path or HELO identity | Publish at the checked host |
Missing TXT | DNS TXT answer | Add one SPF policy |
Bad CNAME | Target chain | Use the provider target |
Split DNS | Authoritative answers | Fix the active zone |
Plain text | TXT value | Start with v=spf1 |
Common causes of SPF None and the right repair path.
The most confusing version is intermittent. One DNS path returns a useless TXT value such as a provider hostname, while another returns a CNAME chain that lands on a real SPF record. Some receivers then see SPF None while others see SPF pass. A CNAME must not coexist with TXT or other data at the same owner name, so mixed records need a DNS repair rather than repeated retesting.
Intermittent DNS answer pattern
;QUESTION bounce.example.com. IN TXT ;ANSWER A bounce.example.com. 300 IN TXT "bounce.provider.example" ;ANSWER B bounce.example.com. 300 IN CNAME bounce.provider.example. bounce.provider.example. 300 IN CNAME mail.provider.example. mail.provider.example. 300 IN TXT "v=spf1 include:_spf.example ~all"
Do not confuse None with a broken policy
Two SPF TXT records, invalid syntax in a selected SPF policy, or more than 10 evaluated DNS-querying terms produce PermError. A missing SPF policy at an evaluated include or redirect target also produces PermError. A DNS timeout or SERVFAIL produces TempError. Some dashboards use 'record not found' for several failures, so verify the receiving server's Authentication-Results value before choosing a fix. These distinctions are defined in RFC 7208.
Do not confuse flattening terms
DNS CNAME flattening and SPF flattening are different. SPF flattening replaces DNS-based authorizations with IP mechanisms to reduce lookup use. Those IP addresses need maintenance when senders change them. It does not repair a hostname that sometimes returns the wrong TXT value.
When you need to create an SPF record
If the exact SPF identity has no policy and it should send email, build the record from an inventory of legitimate sending systems. Do not copy a record from another domain or publish a separate SPF TXT record for each provider. The owner name can have other TXT records, but only one SPF policy is permitted at that name.
- Inventory senders: List the mail systems that use this exact Return-Path or HELO domain, using message headers and DMARC aggregate data where available.
- Build one policy: Add the required address and include mechanisms to one v=spf1 TXT record. Keep evaluated DNS-querying terms within the limit of 10 across nested includes and redirects; ip4 and ip6 do not consume this limit.
- Start cautiously: Use ~all during a controlled observation period if the sender inventory is incomplete. This does not guarantee delivery, but it avoids an immediate hard SPF fail for an omitted sender. Softfail does not count as SPF pass for DMARC.
- Confirm real traffic: Send through every legitimate service and confirm SPF pass for the expected smtp.mailfrom domain.
- Set the final policy: Move to -all after legitimate sources are authorized and monitored. This returns SPF fail for unmatched senders; the receiver decides how to handle the message. For a non-sending identity, publish v=spf1 -all instead of leaving the domain at None.
Example staged SPF policy
; Replace _spf.sender.example with your sender's documented SPF domain ; Observation while the sender inventory is verified v=spf1 include:_spf.sender.example ~all ; Alternative final policy after legitimate sources are confirmed v=spf1 include:_spf.sender.example -all
SPF authorizes use of the SMTP Mail From or HELO domain. It protects the visible From domain through DMARC only when SPF passes with the required domain alignment. Keep DKIM enabled as a separate aligned authentication path.
Check how the SPF TXT record is published
A saved DNS entry can still leave receivers reporting 'no SPF record found'. SPF does not inherit a parent domain's policy. Check the exact hostname, including how the DNS editor interprets its name. DNS record naming distinguishes relative hostnames from the zone's full domain name.
|
|
|---|---|
Record type | Use TXT. Publishing only the deprecated SPF record type 99 leaves no TXT policy for receivers to discover. |
Host or Name | If the editor appends example.com, enter bounce for bounce.example.com. Use @ for the zone apex only. Check that the saved name is not bounce.example.com.example.com. |
TXT value | Start with v=spf1 followed by a space or the end of the value. A leading space or mistyped version prevents SPF record selection. |
Long TXT values | The 255-byte limit applies to each character-string, not the entire SPF policy. Split a long value into strings within one TXT record, preserving spaces between mechanisms. |
DNS publishing mistakes that leave SPF missing or invalid.
One TXT record containing two character-strings
bounce.example.com. 300 IN TXT "v=spf1 " "ip4:192.0.2.10 -all"
The strings in this zone-file example join into one SPF policy. They are not separate DNS records. RFC 7208 defines TXT publication and SPF record selection. Replace the example IP address with an authorized sender's public IP.
How to resolve SPF None
Start with the domain SPF actually checks. Use the original message headers because email platforms and inbox interfaces often hide the bounce domain. If the SPF line says smtp.mailfrom=bounce.example.com, that is the name to test.
- Find the identity: Copy Return-Path, Mail From, or smtp.mailfrom from the full message headers. For a null Return-Path, identify the HELO domain.
- Query TXT: Look for a TXT answer that begins with v=spf1 at that exact hostname.
- Check CNAME: If the host is a CNAME, follow the target and confirm the final TXT answer contains an SPF policy.
- Remove conflicts: Do not keep a CNAME and TXT record at the same owner name. For more detail, read about CNAME issues.
- Check existing policies: If DNS returns two v=spf1 records or a policy that exceeds SPF limits, troubleshoot PermError instead of adding another record.
- Fix the active zone: Find the authoritative nameservers and edit that DNS zone, not an old zone or inactive DNS account. A delegated bounce subdomain can have different nameservers from the root domain; if the provider owns the checked domain, ask the provider to repair it.
- Retest in order: Query each authoritative nameserver, compare recursive resolvers, then send a fresh message after cached answers expire.
Useful DNS checksbash
dig +short NS example.com dig TXT bounce.example.com @ns1.dns-host.example +norecurse dig CNAME bounce.example.com @ns1.dns-host.example +norecurse dig TXT bounce.example.com @1.1.1.1 dig TXT bounce.example.com @8.8.8.8 dig +trace TXT bounce.example.com
Keep the full TXT response so you can read the DNS status and authority section. NXDOMAIN means the name does not exist; NOERROR with no TXT answer and no CNAME is a NODATA response. SERVFAIL or a timeout indicates TempError. If a direct authoritative reply contains a CNAME, query its target using the target zone's nameservers.
Good SPF setup
- One policy: The checked hostname has one usable SPF TXT answer.
- Clean CNAME: A delegated bounce host points to the provider's current target.
- Same answer: Authoritative servers agree, and recursive resolvers converge after the previous TTL.
Bad SPF setup
- Plain text: The TXT value is only a hostname and has no v=spf1 policy.
- Mixed records: A CNAME and TXT record exist at the same owner name.
- Split answers: Some authoritative servers find SPF and others return SPF None.
After editing DNS, test the exact bounce hostname again. Do not rely on an email platform setup screen alone, because that screen often checks whether its instructions were entered rather than whether every receiver gets the same SPF answer.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If the checker reports None after you added a record, verify the owner name, record type, and active nameservers. A cached NXDOMAIN or NODATA response can persist after publication. Its negative-cache lifetime comes from the zone's SOA record, not the new TXT record's TTL, as specified in RFC 2308. Lowering the new TXT TTL does not clear an earlier negative answer. There is no universal propagation timer. A root-domain SPF record will not fix a missing policy on a separate bounce subdomain.
Testing after the repair
For a sending identity, a fixed SPF record should pass two kinds of checks: DNS lookup checks and real message checks. DNS lookup checks prove that the record exists and resolves consistently. Real message checks prove that the sending system uses the domain you fixed and that its sending IP is authorized. For a non-sending identity with v=spf1 -all, SPF fail is the intended result.
SPF repair confidence
Use these checks for sending identities to decide whether the SPF None issue is fixed or still active.
Healthy
All checks pass
All authoritative servers agree, recursive resolvers return one valid policy, the policy passes syntax checks, and fresh legitimate messages show SPF pass.
Watch
Mixed evidence
DNS checks pass, but fresh messages still use a different bounce domain or cached answers remain.
Broken
Repair incomplete
An authoritative server still returns no policy, a plain TXT value, a wrong target, or conflicting data. These faults require repair, even if the reported result changes to PermError.
For a wider view, run a domain health check after the focused SPF test. Check for related DKIM or DMARC DNS configuration issues, then verify authentication with a fresh message.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product ties DNS diagnostics to sending sources in DMARC aggregate reports. This workflow shows which source produces SPF None, whether aligned DKIM authenticates the same mail stream, and which owner name needs repair. Reports describe past checks; use fresh messages to confirm the DNS repair before waiting for the next reporting period.
Investigate recurring SPF None results with Suped
In Suped's DMARC platform, open a sending source, select a report row, and choose View detail. Suped's detail view shows the Return-Path domain and sending IP alongside SPF results. Compare the raw SPF result with DKIM alignment, then query current DNS for the affected hostname.
Manual workflow
Manual checks work for a one-off issue when you have access to DNS and the original message headers.
- Narrow repair: DNS queries and test messages can confirm one affected hostname.
- More correlation: You must connect headers, DNS answers, sender ownership, and change history yourself.
Suped workflow
Suped turns recurring authentication results into source-level issues with repair steps and monitoring.
- Source context: DMARC aggregate data groups SPF None results by reported domain and sending IP.
- Hosted changes: After the initial DNS delegation, Suped's Hosted SPF supports sender updates without repeated edits to the public policy.
- Recurrence checks: Monitoring shows whether the same source returns to None after the repair.
If the problem returns at random, first compare the reported Mail From or HELO domains. Different senders can use different identities. For the same identity, compare authoritative answers and cached responses. Investigate intermittent DNS failures when you see TempError; timeouts do not produce the standard SPF None result.
Views from the trenches
Best practices
Check the Return-Path domain first, because SPF is evaluated against that bounce host.
Query TXT and CNAME answers through several resolvers before changing sender settings.
Keep each DNS owner clean: use a CNAME or TXT record at the hostname, never both together.
Treat SPF None as a DNS discovery issue before changing DMARC policy or sender IPs.
Common pitfalls
Publishing a TXT value that only names a provider host creates no usable SPF policy.
Checking the visible From domain hides failures on a separate Return-Path subdomain.
Assuming DNS propagation is the issue can delay fixing records in the wrong DNS zone.
Mixing CNAME and TXT records at one host creates inconsistent answers across resolvers.
Expert tips
Capture message headers before testing, because later retries can use a different path.
Lower TTLs before DNS changes; existing cached answers retain their original expiry time.
If a provider owns the bounce domain, ask them to fix the SPF policy at that exact hostname.
Monitor after repair: DNS timeouts give TempError; missing policies at the checked host give None.
Marketer view
Marketer from Email Geeks says the first check is the Return-Path domain, because SPF is evaluated against the bounce domain used in SMTP rather than the visible sender address.
2025-08-29 - Email Geeks
Marketer view
Marketer from Email Geeks says a TXT record that only contains a provider hostname is meaningless for SPF, even when the hostname itself looks related to email.
2025-08-29 - Email Geeks
Keep SPF None from returning
Review DMARC aggregate data after onboarding or removing a sender, and test the Return-Path domains used by active mail streams. A new provider, an expired delegation, a DNS migration, or a stale secondary zone can reintroduce SPF None without changing the visible From address.
- After sender changes: Confirm the new service uses the expected Mail From domain and passes SPF.
- After DNS changes: Compare every authoritative nameserver before waiting for recursive caches.
- During routine review: Remove inactive senders, check SPF lookup limits, confirm authoritative zones, and investigate new None results by source.
Frequently asked questions
It means the receiver retrieved no usable SPF policy for the checked identity, or it could not extract a valid domain to check. The policy can be missing, published at the wrong hostname, hidden behind incorrect DNS, or stored as plain text that does not begin with v=spf1.
SPF checks the SMTP Mail From or Return-Path domain. If your sender uses bounce.example.com, the SPF policy must resolve for that hostname or its valid CNAME target. With a null Return-Path, check the HELO identity instead.
No. A TXT record must start with v=spf1 to count as an SPF policy. A plain provider hostname in TXT is only text and usually results in SPF None.
No. More than one v=spf1 record at the same owner name normally causes SPF PermError. Consolidate authorized senders into one policy instead of adding another SPF TXT record.
Yes, if aligned DKIM passes for the visible From domain. DMARC needs at least one aligned pass from SPF or DKIM. SPF None still removes one available authentication path.
The timing depends on the previous cached response. An existing TXT answer uses its record TTL; a cached NXDOMAIN or NODATA response uses the SOA-derived negative-cache lifetime. Authoritative nameservers should show the saved change first. Lowering the new TXT record's TTL does not expire old cached responses. Send a fresh message after DNS answers converge.
