SPF syntax and the 10-lookup limit

Definition and scope

Understand SPF mechanisms, recursive includes, void lookups and permanent errors.

Use this reference to establish the meaning and limits of the result before changing production configuration.

How it works

SPF authorizes servers for the SMTP envelope identity. ip4 and ip6 are local data; include, a, mx, exists, ptr and redirect can require DNS. Evaluation follows nested policies and stops at the first matching mechanism.

How to read it

The RFC limit is 10 lookup-causing terms across the complete evaluation, not ten visible tokens in the root record. More than two void lookups should also be treated as an error. Qualifiers mean pass (+), fail (-), softfail (~) and neutral (?).

Correct and incorrect examples

Compare the normalized examples. Technical values are illustrative and use documentation ranges or reserved names.

Correct

v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all

Incorrect or misleading

v=spf1 include:a.example include:b.example … include:k.example +all

Element	Role	Example
ip4 / ip6	0 DNS terms	ip4:192.0.2.0/24
include	1 + nested terms	include:_spf.example.net
a / mx / exists	1 DNS term	mx:example.com
ptr	Deprecated	ptr
redirect	1 + nested terms	redirect=_spf.example.net
all	0 DNS terms	-all

Common problems

Long include chains, duplicated SPF records, redirect loops, deprecated ptr and +all commonly create unreliable authorization. A TXT record may use several 255-byte strings; joining them is valid, while publishing several separate SPF records is not.

Practical checklist

Count recursively before adding a sender, replace broad includes with stable IP ranges where maintainable, finish with an intentional all policy, and test MAIL FROM and HELO identities during changes.

Standards and primary references

These primary specifications define the protocol behavior. Provider documentation may add operational requirements but cannot replace the standard.

RFC 7208