The SPF Record: How to Set It Up Correctly (and Why Yours Might Be Broken)

SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers are allowed to send email “from” your domain. When a receiving server sees mail from an IP outside that list, it treats the message as suspicious — and Gmail and Outlook increasingly route such mail straight to spam.

A working example

v=spf1 include:_spf.google.com include:zoho.com ip4:203.0.113.10 -all

• v=spf1 is the version tag and is mandatory.
• include: pulls in another service’s SPF record (here Google Workspace and Zoho).
• ip4: authorises one specific IPv4 address.
• -all at the end means “everyone else is forbidden”. Use ~all (softfail) only during a testing window, then harden it.

The failure modes that matter

Two SPF records on one domain: an instant, permanent fail — receivers evaluate both records and the result is PermError, which is worse than having no SPF at all. Merge them into one record.

The 10-lookup limit: every include:, a, mx and redirect counts toward a ceiling of 10 DNS lookups per evaluation. Services with nested includes burn through the budget quickly; when you exceed 10, the whole record fails. Flatten the record or remove services you no longer use.

The forgotten sender: your newsletter platform, your billing system, your CRM — each one sends as your domain, and each one missing from SPF produces softfail mail. This is why the correct procedure is to enumerate every sending service first and write the record once.

After any change in your sending stack — a new ESP, a migration, an added relay — re-check the record. The WhoDNS email records tool validates your SPF syntax, expands the includes to show the actual lookup count, and confirms the record resolves as receivers would see it.

🔗 Related tool: Generate and check your email records