SPF - Sender Policy Framework

SPF (Sender Policy Framework) is a DNS TXT record that lists authorized mail servers for a domain. Receiving mail servers check whether an incoming email was sent from a server listed in this record—and may reject it or mark it as spam if it was not.

SPF is one of the three building blocks of email authentication. The other two are DKIM (cryptographic signature) and DMARC (policy and reporting). All three are necessary for complete email protection.

How SPF works

1. Sender sends email from info@beispiel.de via server 203.0.113.10
2. Receiving mail system queries DNS for TXT beispiel.de
3. SPF record reads: v=spf1 ip4:203.0.113.0/24 -all
4. IP 203.0.113.10 is within the allowed range → SPF pass
5. If it is not within the allowed range → SPF fail

Important: SPF checks the envelope From address (technical SMTP MAIL FROM), not the visible From: header in the email. An attacker can pass SPF and still display a false From: header—which is why DMARC (alignment check) is absolutely necessary.

SPF Record Syntax

v=spf1 [mechanisms] [modifier]

Mechanisms

Mechanism	Meaning
ip4:203.0.113.0/24	IPv4 address or range
ip6:2001:db8::/32	IPv6 address or range
include:_spf.google.com	Inclusion of another domain’s SPF record
a	The A record of your own domain
mx	All MX records of the domain
all	Matches all sources not previously matched

Qualifiers (before the mechanism)

Qualifier	Meaning	Recommendation
+ (default)	Pass - source is authorized	For allowed sources
-	Fail (hard fail) - source is not authorized, rejection	For all at the end
~	Soft fail - not authorized, but do not strictly reject	Only as a temporary measure
?	Neutral - no statement	Avoid

Recommended pattern:

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

The 10-DNS-Lookup Limit

SPF allows a maximum of 10 DNS lookups per SPF check. Each include:, a, or mx mechanism counts as one lookup. With many cloud services (Google Workspace, Microsoft 365, Salesforce, HubSpot, Zendesk...), this limit is quickly reached—and SPF aborts with a PermanentError, leading to delivery issues.

Solution: SPF flattening (resolving all includes to direct IP addresses) or using SPF macros. Regularly check with tools like MXToolbox or dmarcian.

Common SPF Errors

Missing -all at the end: Without a trailing qualifier, every server is implicitly neutral—the SPF record provides no protection.

~all instead of -all: A soft fail means recipients will still deliver the email (albeit marked as spam). Only useful during the transition phase.

Forgotten unknown mail sources: Marketing automation, CRM, ERP, ticketing systems—all send emails under the company name and must be included in the SPF record.

Subdomains: SPF records do not automatically apply to subdomains. mail.example.com needs its own SPF record.

SPF in conjunction with DMARC

SPF alone is not sufficient because:

1. SPF checks the Envelope-From, not the visible From header
2. SPF often fails with email forwarding (e.g., alumni addresses)

DMARC resolves both issues: It requires SPF alignment (the Envelope-From and From headers must belong to the same domain) and specifies what should happen if alignment fails.

Recommended implementation path:

1. Set up SPF with -all
2. Enable DKIM for all mail sources
3. Enable DMARC with p=none and collect reports
4. Gradually tighten DMARC to p=quarantine → p=reject

Further information: DMARC Wiki article | DKIM Wiki article