What is SPF?

What it is#

Sender Policy Framework (SPF) is an email authentication protocol. A domain owner publishes a DNS TXT record that lists the IP addresses and hostnames authorized to send email for that domain. When a receiving mail server gets a message, it checks the envelope sender (the MAIL FROM address in the SMTP transaction) against the SPF record for that domain and decides whether the sending server is authorized.

SPF is one of three core email authentication protocols, alongside DKIM and DMARC. It addresses a specific problem. The SMTP protocol has no built-in mechanism to verify that a mail server is permitted to send on behalf of a domain.

How SPF works#

1. A domain owner publishes a TXT record at their domain: v=spf1 include:_spf.google.com ip4:203.0.113.5 -all
2. An incoming message arrives at the receiver's mail server with a MAIL FROM of [email protected]
3. The receiver queries DNS for example.com and retrieves the SPF record
4. The receiver checks whether the connecting server's IP matches any authorized mechanism in the record
5. The result is one of: pass, fail, softfail, neutral, none, temperror, or permerror

The key mechanisms in SPF syntax include:

• ip4: / ip6:. Explicitly authorized IP addresses or ranges
• include:. Delegates authorization to another domain's SPF record (common for cloud email providers)
• a. The domain's A record IP is authorized
• mx. The domain's MX record hosts are authorized
• -all. Hard fail (reject anything not explicitly authorized)
• ~all. Soft fail (accept but mark as suspicious, commonly used during rollout)

How to check an SPF record#

To verify SPF configuration, query the domain's TXT records: dig TXT example.com. The SPF record starts with v=spf1. Online SPF checker tools validate the record syntax, resolve all include: chains, count DNS lookups, and flag common misconfigurations like exceeding the lookup limit or missing mechanisms for known sending services.

The 10-lookup limit#

SPF has a hard limit of 10 DNS lookups per evaluation. Each include:, a, mx, and redirect mechanism triggers a lookup. Nested includes count toward the total. Organizations that use multiple SaaS email services (marketing platforms, CRM, helpdesk, transactional senders) can easily exceed this limit, causing SPF evaluation to return permerror, effectively the same as having no SPF record at all.

Flattening tools that resolve includes to IP addresses can work around the limit, but they require ongoing maintenance as provider IP ranges change.

What SPF does not do#

SPF checks the envelope sender (MAIL FROM), not the From header that users see in their email client. An attacker can send a message with a MAIL FROM of [email protected] (which passes SPF for evil.com) while setting the visible From header to [email protected]. Without DMARC alignment, SPF alone does not prevent this kind of spoofing.

SPF also breaks on forwarding. When a message is forwarded through an intermediary server, the connecting IP changes but the envelope sender remains the same. The forwarding server's IP is not in the original domain's SPF record, so the check fails. This is a fundamental architectural limitation that DKIM (which survives forwarding) and ARC (Authenticated Received Chain) help address.

Relationship to DMARC#

DMARC requires that either SPF or DKIM passes and aligns with the domain in the visible From header. For SPF to contribute to DMARC alignment, the envelope sender domain must match (or be a subdomain of) the From header domain. This alignment requirement closes the gap where SPF passes on an unrelated domain.

Publishing a strict SPF record is a foundational step in preventing direct domain spoofing. When combined with DMARC enforcement, it ensures that unauthorized servers cannot send email that appears to come from your domain. Monitoring SPF records across your domain portfolio, including parked and inactive domains, helps identify configuration gaps that attackers could exploit.