What is SPF (Sender Policy Framework)?

SendStreak Academy

Sender Policy Framework (SPF) is an email authentication method that allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. It works by publishing a DNS TXT record that lists permitted sending IP addresses and hostnames. When a receiving mail server gets a message, it checks the sender’s domain for an SPF record and verifies that the sending server’s IP is included. If it is not, the message fails SPF and is more likely to be rejected or marked as spam.

SPF is defined in RFC 7208 and is one of three core email authentication mechanisms alongside DKIM and DMARC. Together, they form the foundation of modern email deliverability.

How SPF works

The SPF check happens early in the SMTP transaction, before the message body is transferred:

The sending server connects and issues MAIL FROM:<[email protected]>.
The receiving server extracts the domain from the envelope sender (the Return-Path, not the From header).
It performs a DNS lookup for a TXT record at example.com.
It compares the sending server’s IP address against the mechanisms listed in the SPF record.
The result (pass, fail, softfail, neutral, or none) is recorded in the Authentication-Results header.

A critical detail: SPF validates the envelope sender (SMTP MAIL FROM), not the From header that recipients see. This distinction is why SPF alone cannot prevent display-name spoofing — that is where DMARC comes in.

SPF record syntax

An SPF record is a single DNS TXT record published at the root of your domain. Here is a typical example:

v=spf1 include:_spf.sendstreak.com include:amazonses.com ip4:203.0.113.5 -all

Breaking this down:

Mechanism	Meaning
`v=spf1`	Required version tag. Must be the first element.
`include:_spf.sendstreak.com`	Authorize all IPs listed in SendStreak’s SPF record. Used when sending through a third-party service.
`include:amazonses.com`	Also authorize Amazon SES’s sending IPs.
`ip4:203.0.113.5`	Authorize a specific IPv4 address (e.g., your own mail server).
`-all`	Fail any server not explicitly listed. This is a hard fail.

The trailing all mechanism defines what happens to unauthorized senders:

+all — Allow all (defeats the purpose of SPF; never use this).
~all — Soft fail. The message is accepted but marked as suspicious. Common during initial setup.
-all — Hard fail. Unauthorized senders are rejected. Recommended for production domains.
?all — Neutral. No opinion either way.

Common SPF mistakes

Too many DNS lookups. SPF records are limited to 10 DNS lookups (including nested include references). Exceeding this causes a permerror, and the SPF check fails entirely. Each include, a, mx, and redirect mechanism counts as one lookup. ip4 and ip6 do not count because they require no DNS resolution.

To check your lookup count, use a tool like dig or an online SPF validator:

dig TXT example.com +short

Using a or mx mechanisms unnecessarily. These are convenient but each consumes a DNS lookup. If you know the IP addresses, use ip4 or ip6 directly.

Forgetting the envelope sender. SPF checks the MAIL FROM domain, not the From header domain. If your application sends email where the bounce address is on a different domain than the From address, you need SPF records on both domains.

Multiple SPF records. A domain must have exactly one SPF TXT record. Publishing two causes a permerror. If you need to authorize multiple services, combine them into a single record using include mechanisms.

SPF and email forwarding

SPF has a known limitation with email forwarding. When a message is forwarded by an intermediary server, the sending IP changes to the forwarder’s IP, but the envelope sender domain remains the same. Since the forwarder’s IP is not listed in the original domain’s SPF record, the check fails.

This is one reason SPF alone is insufficient and why DKIM (which survives forwarding because it is tied to the message content, not the sending IP) and DMARC (which can accept a message if either SPF or DKIM passes) are essential complements.

How SPF fits into the authentication stack

SPF is the first layer of defense. In a properly configured domain:

SPF verifies the sending server is authorized (IP-based check).
DKIM verifies the message was not tampered with (cryptographic signature).
DMARC ties them together with a policy and adds alignment — ensuring the domain in the From header matches the domains checked by SPF and DKIM.

All three results are visible in the email headers under Authentication-Results. For transactional email, passing all three is effectively a requirement for inbox delivery with major providers like Gmail, Outlook, and Yahoo.