SPF records explained

The short version

SPF is published as a TXT record beginning with v=spf1. A receiving mail server compares the connecting sender against the mechanisms in that policy.

A simple record might authorise specific IPv4 addresses, an MX provider or another provider's SPF policy, then finish with an all mechanism that describes how other senders should be treated.

Common SPF mechanisms

ip4 and ip6 authorise address ranges directly. a and mx use DNS records from the domain. include evaluates another domain's SPF policy, which is common for third-party mail platforms.

The final all mechanism matches anything not already matched. Qualifiers such as -all and ~all express fail and softfail behaviour.

SPF checks the envelope identity, not necessarily the visible From

This is one of the most important SPF details. SPF normally authenticates the domain used in the SMTP envelope sender, sometimes called the Return-Path, rather than simply checking the address a user sees in the message's From header.

DMARC adds an alignment requirement so a passing SPF or DKIM identity also relates to the visible From domain.

Common SPF problems

1. Publishing more than one SPF policy. A domain should not publish multiple competing v=spf1 records.
2. Forgetting a legitimate sender. Marketing, ticketing and transactional mail systems may all need authorisation.
3. Too many DNS-dependent mechanisms. SPF evaluation has a limit on mechanisms and modifiers that cause DNS lookups, so long chains of includes can fail evaluation.
4. Assuming SPF survives every forward. Forwarding can cause the new connecting server to fall outside the original sender's SPF policy.

SPF is not a spam score

A passing SPF result means the sender was authorised for the SPF identity being checked. It does not prove the message is wanted, safe or genuinely associated with the visible brand. Receivers combine authentication with reputation, content and many other signals.