Cause · impact · fix
spf=none
A receiver looked for an SPF record on your sending domain and found none, so SPF neither passes nor fails — it simply does not apply. Here is why, what it costs you, and how to publish one.
What it means
The cause.
spf=none is the result a receiver records in the Authentication-Results header when it cannot evaluate SPF at all. RFC 7208 defines it precisely: either no valid domain name could be extracted from the SMTP session, or no SPF record was retrieved from DNS for that domain. In practice it almost always means the second case — the domain in your Return-Path (the envelope MAIL FROM) has no published TXT record beginning with v=spf1.
SPF authenticates the envelope sender, not the visible From: address. So spf=none is about the domain in your Return-Path, which is often a subdomain or a sending platform's bounce domain rather than the address your recipient sees. A brand-new domain, a subdomain you never configured, or a record that was deleted or never propagated all produce the same none result.
none is not an error. It is distinct from softfail, fail, permerror and temperror: the receiver is not saying your record is broken or that you failed a check, only that there was nothing to check. It stays none on every message until an SPF record exists and resolves for that exact domain.
Why it matters
The impact.
On its own, none is neutral — but DMARC does not treat it kindly. DMARC passes only when SPF or DKIM passes and aligns with your From: domain. spf=none contributes nothing to the SPF leg, so unless DKIM is signing and aligning, the message has no passing, aligned authentication and DMARC fails.
That is the real cost. Since the 2024 Gmail and Yahoo bulk-sender rules, any domain sending in volume must have SPF and DKIM in place and must pass DMARC; Microsoft has since aligned. A domain showing spf=none with no DKIM to fall back on will see mail filtered to spam or rejected outright. Even below the bulk thresholds, none weakens your standing with every receiver that scores authentication.
What to do
The fix, in order.
Work top to bottom, then re-check — DNS changes take a few minutes to take effect.
- 1 Confirm which domain is failing. Open a message that shows spf=none and read the Return-Path or smtp.mailfrom value in Authentication-Results — that is the domain the receiver checked, and it is often a subdomain or your platform's bounce domain, not your From: address. Publish SPF for that exact domain.
- 2 List every service that sends as you. Gather all sources that send mail from the domain: your mailbox provider (Google Workspace, Microsoft 365), plus any CRM, newsletter tool, helpdesk or transactional platform. Each publishes an include: mechanism you will add to one record.
- 3 Publish a single SPF TXT record. Add one TXT record at the sending domain that lists those sources, for example v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. Use exactly one record, one v=spf1 and one all mechanism. Start with ~all (softfail) while you confirm every source is covered, then move to -all once you are sure.
- 4 Keep the record under 10 DNS lookups. Every include:, a, mx and redirect costs a DNS lookup, and SPF caps the total at 10. Add only the services you actually send through, or you trade spf=none for a permerror.
- 5 Set up DKIM alongside SPF. SPF breaks on forwarding, so DKIM is what keeps DMARC passing when a message is relayed. Enable DKIM signing at your provider so DMARC has two aligned legs to lean on, not one.
- 6 Verify once DNS has propagated. Give DNS a few minutes, then run the domain through the SPF checker to confirm the record resolves, has no syntax errors and stays under 10 lookups. Send a test message and check that Authentication-Results now reads spf=pass.
Confirm the error is gone.
Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.
Common questions