What is SPF?

SPF is the simplest of the three email security technologies — and a prerequisite for DKIM and DMARC.

In a nutshell

SPF stands for Sender Policy Framework. In a TXT record on your domain you publish a list of all servers authorized to send email on your behalf. Receiving mail servers look up that record for every incoming message and check: does the sender's IP appear in your list? If not, the message is treated as suspicious.

Anatomy of an SPF record

A typical SPF record looks like this:

v=spf1 ip4:185.40.10.0/24 include:_spf.google.com include:sendgrid.net ~all

The record consists of several mechanisms:

v=spf1 — version identifier, always first.
ip4:... / ip6:... — single IPs or whole ranges.
a — the domain's A record is allowed to send.
mx — all of the domain's MX servers are allowed to send.
include:... — another domain's SPF record is included (e.g. Google Workspace, Microsoft 365, SendGrid).
~all or -all — default policy at the end: SoftFail (~) or HardFail (-) for any server not listed.

~all vs. -all

Both signal "all other servers are not authorized," but with different severity. ~all (SoftFail) says: "suspicious, but don't reject." -all (HardFail) says: "drop the message outright." Most mail servers treat ~all as a spam indicator but don't reject the message directly. With DMARC p=reject the difference becomes practically irrelevant — DMARC makes rejection binding.

The 10-lookup limit

SPF evaluation may trigger at most 10 DNS lookups. Each include: mechanism counts as one lookup, and the referenced SPF record can have its own includes — which count too. If you pull in three email providers (Google + Microsoft + SendGrid) via include, you blow past the limit almost every time. The SPF record then becomes permerror and is ignored entirely.

Solution: replace includes with direct IP ranges (e.g. via "SPF flattening" tools like DMARCLY or by maintaining the IP lists manually).

Common pitfalls

Multiple SPF records: Only one SPF TXT record per domain is allowed. Multiple records are treated as an error and SPF fails completely.
Missing newsletter tools: Sending newsletters through Mailchimp/Brevo/etc. but not listing them in SPF? All your newsletters land in spam.
Forgotten subdomains: SPF only applies to the exact domain. Subdomains need their own SPF records (or the main domain gets a wildcard MX).
Stale entries: Switching hosts or newsletter tools, leaving the old entry in place — and suddenly the lookup limit is busted.

SPF alone isn't enough

SPF on its own breaks under mail forwarding — when the recipient forwards the message to another address, the sender IP changes and SPF fails, even though the message is legitimate. That's why you also need DKIM (a cryptographic signature that survives forwarding) and DMARC as the bracket that ties SPF and DKIM together and defines the action taken on failure.