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.

Unitpost · July 27, 2026

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:

Bash

dig TXT yourdomain.com +short

# Or, if dig isn't available:
nslookup -type=TXT yourdomain.com

You 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 is looked up on the envelope domain (MAIL FROM / Return-Path), which is not always the visible From domain.

For Unitpost, SPF is a TXT on `unitpost.yourdomain.com` with value `v=spf1 include:amazonses.com ~all`. It is not `include:spf.unitpost.com` on the apex — that include does not exist and will look like “record not found” or permerror. Apex SPF for Google Workspace / another ESP can stay untouched.

For a domain you send from directly:

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

A common UI foot-gun is typing the full domain in a field that already appends it, producing yourdomain.com.yourdomain.com.

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.

Cause 5: the TXT is quoted or split wrong

Some DNS UIs want the value with quotes (`"v=spf1 …"`), some strip them. If `dig TXT` shows a value split across two strings, or missing `v=spf1`, the record is not what you typed. Re-enter it as a single TXT. Do not create a second SPF record to “fix” a quoting mistake.

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.

Why does Gmail say SPF record not found when I added a TXT?

Receivers look up the MAIL FROM / Return-Path host, not always the From domain. If you send through Unitpost, SPF lives on unitpost.yourdomain.com (v=spf1 include:amazonses.com ~all), not as include:spf.unitpost.com on the apex — that hostname does not exist. Query the host your DNS instructions actually gave you.