How to create a secure SPF record

A secure SPF (Sender Policy Framework) record lists every server allowed to send mail for your domain, stays under the 10 DNS-lookup limit, and ends with -all so unauthorised senders are rejected rather than just flagged. Get any one of those wrong and receiving mail servers either reject legitimate mail or silently let spoofed mail through.

SPF is defined by RFC 7208 (which obsoletes the older RFC 4408), and it's published as a plain DNS TXT record — there's no dedicated SPF record type in active use anymore. This guide walks through building one that's both correct and hard to break.

What is an SPF record, exactly?

An SPF record is a TXT record on your domain that tells receiving mail servers which IP addresses and hosts are authorised to send mail using your domain in the envelope-from (Return-Path) address. When someone emails you claiming to be you@yourdomain.com, the receiving server checks your domain's SPF record to see if the sending IP is on the approved list.

A basic record looks like this:

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

Each piece is a mechanism, evaluated left to right:

Part	Meaning
v=spf1	Required version tag, must be first
ip4:203.0.113.10	Authorises a specific IPv4 address (no DNS lookup needed)
include:_spf.google.com	Pulls in Google's sending ranges (uses a DNS lookup)
-all	Hard-fail everything else — reject unlisted senders

You can check what a domain currently publishes with our free DNS lookup tool, and build a syntactically valid record from scratch with the SPF generator.

Which mechanisms and qualifiers should you use?

SPF mechanisms describe what to check; qualifiers describe what to do when a check matches.

Mechanisms:

• ip4 / ip6 — match a specific address or CIDR block, no lookup cost
• a — match the domain's own A/AAAA record
• mx — match hosts listed in the domain's MX records
• include — pull in another domain's SPF policy (common for Google Workspace, Microsoft 365, ESPs)
• exists — match based on a DNS lookup returning any A record
• ptr — matches based on reverse DNS lookups

Qualifiers, placed before a mechanism:

• + Pass (default, rarely written explicitly)
• - Fail (hard fail — reject)
• ~ SoftFail (accept but mark, often into spam)
• ? Neutral (no real opinion — best avoided)

WarningAvoid ptr entirely. RFC 7208 explicitly marks it as not recommended because reverse-DNS lookups are slow, unreliable, and expensive against the lookup limit.

For the trailing catch-all, use -all once you're confident every legitimate source is listed. ~all is a reasonable staging step while you're still discovering senders, but leaving it as your permanent policy weakens the whole point of SPF — and a stray +all authorises literally anyone to spoof your domain. Treat +all as a critical misconfiguration, not a lenient setting.

The 10-lookup limit — the pitfall that breaks most SPF records

This is the part most teams get wrong. RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups per check. Every include, a, mx, ptr, exists, and redirect counts toward that limit — ip4 and ip6 don't, since they need no lookup.

Go over 10 and the result is a PermError, which receiving servers treat as a broken/failed check — not a pass. This is a genuinely common outage: a domain adds Google Workspace, then Microsoft 365 for a shared inbox, then a marketing platform, a CRM, and a helpdesk tool, each contributing its own nested include: chain, and nobody notices the total lookup count creeping past 10 until deliverability quietly drops.

Two things make this worse:

• mx is a hidden multiplier. Using mx in your SPF record costs one lookup for the MX query itself, plus one more for each MX host it returns.
• Void lookups are capped at 2. A void lookup is any mechanism that resolves to nothing — an include: pointing at a host with no SPF record, or an a/mx for a name that no longer exists. More than two of them also returns a PermError, so a single decommissioned sender you forgot to remove can quietly break the whole record.

Keep it under ten — and keep it lean

You don't get more than 10 lookups, so the record has to be curated, not just appended to:

• Audit your include: chains. Each provider you add nests its own lookups. List every sender that actually sends mail as you and drop the ones that don't — the old CRM, the trial marketing tool, the newsletter platform you left last year.
• Prefer ip4:/ip6: over mx and a. Static IP mechanisms cost zero lookups. Where a sender publishes stable IPs, list them directly instead of leaning on mx, which multiplies with every MX host it returns.
• Flatten with care. "SPF flattening" resolves your includes down to raw IPs to stay under the limit — but those IPs belong to your providers and change without warning, so a flattened record has to be monitored or it silently starts rejecting legitimate mail.

Finish with a hard fail — once you're sure

The last mechanism sets the policy for everything not explicitly allowed:

• ~all (softfail) tells receivers "probably not us, but accept it" — the safe default while you're still finding senders.
• -all (hardfail) tells them "if it's not on this list, reject it." That's the secure end state — but only flip to it once you're confident the record is complete, or you'll bounce your own mail.

And SPF is only one leg of the stool: publish DKIM so your mail is cryptographically signed, and a DMARC policy so receivers know what to do when a check fails — and so you get reports when someone spoofs you.

Don't set it and forget it

A secure SPF record isn't a one-time task. Senders come and go, providers change their IPs, and the lookup count creeps up on its own — and none of it announces itself; you find out when deliverability drops. InfraNest's DNS Security Advisor watches SPF, DKIM and DMARC across every domain you manage, counts your live lookups, and warns you before you cross ten or a void lookup breaks the record — so "secure" stays secure.