Troubleshooting
How to fix an SPF record that isn't found
An SPF record that isn't found is almost always one of four things: DNS hasn't propagated yet, the record is on the wrong host, it's split across multiple TXT records, or you have two SPF records where only one is allowed. Check with dig TXT yourdomain.com and confirm exactly one record starts with v=spf1.
How to fix an SPF record that isn't found
Why an SPF lookup returns nothing even after you've added the record, and how to diagnose it: propagation, wrong host, quoting, and the one-SPF-record rule.
SPF (Sender Policy Framework) is a TXT record listing which servers may send mail for your domain. Receiving servers look it up on every message. When the lookup fails, your mail either lands in spam or is rejected outright — so this is worth getting exactly right.
First, check what DNS actually returns
Do not trust your DNS provider's UI. Query the record the way a receiving server does:
dig TXT yourdomain.com +short
# Or, if dig isn't available:
nslookup -type=TXT yourdomain.comYou are looking for exactly one string beginning with v=spf1. If you see nothing, work through the causes below in order.
Cause 1: DNS hasn't propagated
New records take time to become visible, governed by the zone's TTL. Most providers publish within minutes, but a long TTL on a previous record can delay visibility for hours. If you just added the record, wait and re-query before changing anything else — repeatedly editing a propagating record is how people end up with duplicates.
Cause 2: the record is on the wrong host
SPF for a domain must live on the domain itself — the host field should be @ or blank, not www and not the selector name. A very common mistake is entering the full domain in a provider UI that already appends it, producing yourdomain.com.yourdomain.com.
- Root domain (yourdomain.com): host is @ or empty
- Subdomain (mail.yourdomain.com): host is mail
- Never put an SPF record on www — mail isn't sent from there
Cause 3: more than one SPF record
A domain may have only ONE SPF record. Two records is a permanent error, and most receivers treat it as no SPF at all rather than picking one. This happens when you add a new provider without merging into the existing record.
Merge, don't add
If a record already exists, add the new include: to it rather than creating a second record. Two providers become one record: v=spf1 include:one.example include:two.example ~all
Cause 4: too many DNS lookups
SPF allows a maximum of 10 DNS lookups when evaluating a record. Each include:, a, mx, ptr, and exists: mechanism costs at least one, and includes nest. Exceed 10 and evaluation returns permerror, which behaves like a failure. If you have accumulated includes from several providers, remove ones you no longer send from.
Should the record end in ~all or -all?
~all is a softfail: mail from unlisted servers is accepted but marked suspicious. -all is a hardfail: reject it. Start with ~all while you confirm every legitimate sender is listed, then move to -all once you're confident. Going straight to -all is how teams accidentally block their own invoicing system.
Frequently asked questions
How long does an SPF record take to work?
Usually minutes, and up to 48 hours in the worst case. The delay is governed by the TTL of the record you replaced, not the new one. Query with dig TXT yourdomain.com rather than resending test mail — that tells you the state of DNS directly.
Can I have two SPF records?
No. The spec allows exactly one TXT record starting with v=spf1. Two is a permanent error and most receiving servers treat it as if you had no SPF record at all. Merge multiple senders into one record using several include: mechanisms.
Do I need SPF if I already have DKIM?
Yes, in practice. They prove different things — SPF authorises sending servers, DKIM cryptographically signs the message — and DMARC alignment needs at least one of them to pass with the visible From domain. Gmail and Yahoo's bulk-sender requirements expect both.