SPF Record Syntax: Complete Reference

Record location

Publish SPF as a single TXT record on the domain that appears in the SMTP envelope-from (Return-Path), usually the root domain or a dedicated bounce subdomain.

Version token

Every record must start with v=spf1 followed by a space and one or more mechanisms. Only one SPF TXT per domain. Two records = permerror.

How receivers evaluate

Receiving MTAs fetch the TXT record, parse mechanisms in order, and match the connecting IP against each mechanism until one matches or the record ends with the default result from all.

SPF is not inbox placement

SPF pass authorizes an IP for the envelope domain. DMARC still requires alignment with the visible From: header. SPF pass alone does not guarantee inbox placement.

Each mechanism can be prefixed with a qualifier. Default qualifier is + (pass), usually omitted.

Common mechanisms

• ip4:203.0.113.0/24 — authorize IPv4 range
• ip6:2001:db8::/32 — authorize IPv6 range
• a — authorize A record IPs of current domain (1 lookup)
• a:mail.example.com — authorize A record of named host (1 lookup)
• mx — authorize MX host IPs of current domain (1+ lookups)
• include:spf.protection.outlook.com — delegate to another SPF record (1 lookup + nested)
• exists:macro — advanced, rare in SMB records
• all — always matches; must be last mechanism

The all mechanism (non-negotiable on sending domains)

• -all hard fail: unauthorized IPs should be rejected (use on production senders in 2026)
• ~all softfail: weak signal; acceptable only during short migration windows
• ?all neutral: useless for security

RFC 7208 caps DNS lookups during SPF evaluation at ten. These mechanisms consume lookups:

• include: (each one, plus whatever nested includes expand to)
• a, mx, ptr, exists

Exceeding ten triggers permerror. Receivers treat the SPF result as broken. DMARC fails if you rely on SPF alignment.

Real-world stack that breaks

M365 (include:spf.protection.outlook.com) + Google (include:_spf.google.com) + Mailchimp + HubSpot + Zendesk + Salesforce + legacy ESP + mx + a on the same root domain often crosses ten without looking "too long" in the TXT field.

Fix strategies

1. Remove dead includes from retired tools.
2. Split mail streams: corporate on root, marketing on mail.domain.com with its own SPF and its own 10-lookup budget.
3. SPF flattening (replace nested includes with IP lists) as last resort with documented maintenance.

Deep dive on permerror: zerohook.org/blog/spf-permerror-too-many-dns-lookups and zerohook.org/fix/spf-permerror

redirect=

Delegates the entire SPF check to another domain's record. Example:

v=spf1 redirect=_spf.example.net

The evaluated domain must have no other mechanisms besides v=spf1 and redirect. Misuse causes permerror. Common on child domains managed by a parent.

exp=

Specifies a domain whose TXT provides an explanation if SPF fails. Almost never needed for SMB mail. If present, it consumes a lookup.

Most production records should use includes and -all, not redirect, unless your DNS architect documented why.

M365 only (single path)

v=spf1 include:spf.protection.outlook.com -all

Publish at root yourdomain.com TXT if all mail flows through Microsoft 365.

M365 + one ESP

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

Replace Mailchimp include with your ESP's documented include host. Count nested lookups before publish.

Common M365 mistakes

• Publishing SPF on the wrong domain (marketing subdomain sends but SPF only on root)
• Forgetting to remove Google's include after migrating off Workspace
• Leaving ~all because "it was recommended in 2018"

In Microsoft 365 admin, outbound mail uses Exchange Online IPs covered by spf.protection.outlook.com. Third-party connectors need their own includes.

Google Workspace only

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

Google + ESP

v=spf1 include:_spf.google.com include:sendgrid.net -all

Verify SendGrid's current include string in their docs; includes change more often than you expect.

Subdomain sending

If marketing sends from news.yourdomain.com, publish a separate SPF on that subdomain. Do not keep stacking includes on root "because it is easier."

1. Multiple SPF TXT records on one name. Merge into one.
2. Missing v=spf1 or typo v=spf1 with wrong spacing.
3. Duplicate mechanisms that break parsers on strict receivers (rare but real).
4. Empty include: or include pointing at a domain with no SPF.
5. Lookup overflow from nested includes (most common in 2026).
6. String splitting across multiple TXT strings incorrectly in DNS (some hosts concatenate; some do not).

Validate before and after every change at zerohook.org/spf-checker. Paste the full record in Validate mode, not just dig output with quotes mangled.

SPF syntax mastery does not replace DKIM or DMARC. Gmail and Yahoo bulk sender rules expect all three in 2026. SPF permerror on root can still damage domain reputation even when DKIM passes on a subset of mail.