Pedro Paiva

Email learning series

SPF: which servers are allowed to send for a domain?

By Pedro Paiva

A receiving server sees a connecting IP and an SMTP envelope sender. SPF lets it ask whether that IP is authorized to send for the envelope domain. It doesn’t directly authenticate the From address displayed by the mail client.

Name the identity before reading the policy

For MAIL FROM:<bounces@example.org>, the relevant domain is example.org. Receivers can also check the EHLO identity. When the reverse-path is null, SPF uses the HELO domain for the MAIL FROM check, with the defined postmaster local part. A result without an identified domain and IP is incomplete evidence.

All DNS answers here are fictional. Documentation IPs are used only to demonstrate evaluation:

example.org. TXT "v=spf1 ip4:192.0.2.10 ip6:2001:db8::10 include:sender.example.net -all"
sender.example.net. TXT "v=spf1 ip4:198.51.100.20 -all"
Connecting IP Identity Evaluation Result
192.0.2.10 MAIL FROM example.org ip4 matches, implicit + pass
2001:db8::10 MAIL FROM example.org ip6 matches, implicit + pass
198.51.100.20 MAIL FROM example.org include target returns pass pass
203.0.113.40 MAIL FROM example.org no earlier match; -all fail

Mechanisms are evaluated left to right until a match. include matches when the target policy returns pass, not simply when the target domain has an SPF record. A child fail, softfail or neutral means the include does not match; errors have their specified propagation rules. redirect supplies another policy when the current mechanisms don’t match, and isn’t reached if all already matches.

a authorizes address records for the named domain, while mx authorizes addresses of its mail exchangers. Publishing an MX for inbound email doesn’t automatically authorize outbound servers unless your SPF policy includes that mechanism. Avoid adding a or mx without intending their effect.

Qualifiers and results are not delivery decisions

The qualifiers are + pass, - fail, ~ softfail and ? neutral; omitted qualifiers mean +. A receiver decides how these results affect acceptance alongside its other policies.

none means no applicable SPF policy was found; temperror indicates a transient evaluation problem such as DNS failure; permerror indicates a policy that cannot be correctly evaluated, for example multiple SPF records or exceeded limits. softfail is a weaker negative assertion than fail, while neutral makes no authorization assertion. None of these tells us the message reached an inbox.

Publish one SPF TXT policy per domain. Splitting one TXT record into quoted strings is different from publishing two competing SPF records. A second competing policy isn’t a way to extend the first.

Count evaluated DNS terms, including nested policies

RFC 7208 limits SPF evaluation to ten DNS-causing terms: include, a, mx, ptr, exists, and redirect. It is not a simple count of DNS packets. Terms evaluated inside included or redirected policies count toward the same budget. ip4, ip6, and all do not consume that term limit. The ptr mechanism is discouraged.

For a synthetic chain where each policy contains only an include of the next policy, followed by -all, the first ten includes consume ten terms. Reaching an eleventh include causes permerror even if its target would authorize the IP. Early matches can end evaluation sooner, so trace the actual evaluated path. Address-query sublimits for mx and ptr, and the recommended limit of two void lookups, also matter. Do not describe ten as a universal allowance for ten DNS packets.

Forwarding changes the connecting IP

Suppose 192.0.2.10 sends a message with an example.org envelope, then a forwarder at 203.0.113.40 sends it onward without changing that envelope. The final receiver checks the forwarder’s IP against example.org, yielding fail for our fixture. This doesn’t prove the original sender was unauthorized.

Some forwarders rewrite the envelope sender to a domain they control. That can make SPF pass for the forwarding domain but doesn’t authenticate the original visible From. DKIM can survive forwarding when the signed content stays intact; DMARC examines alignment with visible From.

For SES, use its documented SPF and custom MAIL FROM guidance for the identities you actually use. Copying the illustrative record above into a real domain would authorize documentation addresses, not SES.

References