What does an SPF record look like (SPF record syntax)?

An SPF (Sender Policy Framework, RFC 7208) record is one DNS TXT record published at your domain root. It tells receiving mail servers which hosts are allowed to send mail using your domain. It always starts with the version tag, lists one or more mechanisms that authorize senders, and ends with an all term that says what to do with everyone not listed: v=spf1 include:_spf.google.com ip4:203.0.113.25 -all. Read left to right that means: SPF version 1; authorize all of Google Workspace's sending IPs; authorize the single IP 203.0.113.25; reject everything else.

The mechanisms (what they authorize)

| Mechanism | Authorizes | DNS lookup? | |-----------|------------|-------------| | ip4:203.0.113.0/24 | An IPv4 address or CIDR range | No (free) | | ip6:2001:db8::/32 | An IPv6 address or range | No (free) | | a | The domain's own A/AAAA records | Yes | | mx | The hosts in the domain's MX records | Yes | | include:_spf.google.com | All IPs authorized by another domain's SPF | Yes (plus its nested lookups) | | redirect=_spf.example.com | Hands evaluation to another domain's record | Yes |

ip4: and ip6: are literal and cost nothing. Everything else costs at least one DNS lookup, and SPF caps you at 10 lookups total — exceed it and the record returns PermError.

The qualifiers (the policy)

Every mechanism can carry a qualifier prefix; the one on the final all term sets the default for unlisted senders:

| Qualifier | Result | Meaning | |-----------|--------|---------| | -all | Fail | Reject anything not listed. Use this in production once your senders are complete. | | ~all | SoftFail | Accept but mark as suspicious. A testing/transition state. | | ?all | Neutral | No assertion. Offers no protection. | | +all | Pass | Authorizes the entire internet to send as you. Never use this. |

So -all is a hardfail and ~all is a softfail. The practical advice: start at ~all while you confirm every legitimate sender, then tighten to -all. +all defeats the whole point of SPF — the SPF generator shows an explicit warning if you select it.

Worked examples

A small business on Google Workspace plus one transactional ESP: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 -all

A domain that sends no mail at all (a parked domain locked down against spoofing): v=spf1 -all

A domain authorizing its own mail servers by MX plus Microsoft 365: v=spf1 mx include:spf.protection.outlook.com ~all

Rules that trip people up

• Exactly one SPF record per name. Two v=spf1 TXT records on the same domain cause PermError and both are ignored. To add senders, merge them into one record with multiple include: mechanisms.
• SPF checks the envelope sender, not the visible From: header — which is why DMARC alignment is needed on top of SPF.
• Subdomains need their own record. SPF at example.com does not cover mail.example.com.
• Keep it under 10 DNS lookups and reasonably short for resolver compatibility.

Build and verify

Build a valid record interactively with the SPF generator — it has provider presets, a live lookup counter, and a length check — then validate the published record with the SPF checker, which resolves the full nested include graph and counts your real lookups. For the underlying concepts, read the SPF guide.