SPF (Sender Policy Framework)
SPF is a DNS-based email authentication protocol that specifies which mail servers are authorized to send emails on behalf of a domain.
SPF (Sender Policy Framework) is a DNS-based email authentication protocol (RFC 7208) that allows domain owners to explicitly specify which mail servers are authorized to send emails on behalf of their domain. Receiving mail servers can use the SPF record to verify whether an incoming email originates from an authorized server.
How SPF Works
SPF operates exclusively at the DNS level and checks the technical sender of an email (the so-called envelope sender or return path), not the visible From: header.
SPF verification process:
1. Email arrives at the receiving mail server
Envelope-From (MAIL FROM): absender@beispiel.de
2. Receiving server extracts the domain from the Envelope-From
→ Domain: example.de
3. DNS lookup:
example.de IN TXT "v=spf1 ip4:203.0.113.0/24 include:spf.mailprovider.com -all"
4. Comparison: Does the incoming server’s IP address match?
→ Is the IP listed in the SPF record? → SPF pass
→ Is the IP not listed in the SPF record and the qualifier is -all? → SPF fail
5. Result in the email’s Received-SPF header:
Received-SPF: pass (example.de: IP 203.0.113.42 is a permitted sender)SPF Record Syntax
An SPF record is a DNS TXT record under the domain that appears in the Envelope-From field.
Basic structure:
v=spf1 [mechanisms] [qualifier]all
Qualifier (prefix before each mechanism):
+ (pass) Sender is authorized (default if no qualifier)
- (fail) Sender is NOT authorized → reject
~ (softfail) Sender likely not authorized → accept, flag
? (neutral) No statement → accept
Common combination: -all at the end (hardfail for all unlisted servers)Mechanisms in Detail
ip4: - IPv4 address or network
v=spf1 ip4:203.0.113.42 -all
v=spf1 ip4:203.0.113.0/24 -all (entire /24 network)
ip6: - IPv6 address or network
v=spf1 ip6:2001:db8::1 -all
v=spf1 ip6:2001:db8::/32 -all
a - A/AAAA record of the domain
v=spf1 a -all
(authorizes the IP address to which example.com points)
v=spf1 a:mail.example.com -all (explicit hostname)
mx - MX records of the domain
v=spf1 mx -all
(authorizes all servers from the MX records)
include: - Include SPF record from another domain
v=spf1 include:spf.protection.outlook.com -all
(Microsoft 365: authorize all MS servers)
v=spf1 include:_spf.google.com -all
(Google Workspace)
exists: - Domain existence check (rarely used)
v=spf1 exists:%{i}.authorize.example.de -all
redirect= - Reference to another SPF record (replaces -all)
v=spf1 redirect=spf.parent-domain.de
(no own mechanisms, fully delegated)
all - Catch-All (always the last mechanism)
-all Hardfail: reject everything else (recommended)
~all Softfail: mark everything else as suspicious
?all Neutral: no statement (weak protection)
+all Pass: everything allowed (pointless, do not use!)Practical Examples
Simple domain with its own mail server:
v=spf1 ip4:203.0.113.42 -all
Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Google Workspace:
v=spf1 include:_spf.google.com -all
Combination: own server + Microsoft 365 + marketing tool:
v=spf1 ip4:203.0.113.42 include:spf.protection.outlook.com include:em.sparkpostmail.com -all
Domain that does not send emails itself (e.g., subdomain):
v=spf1 -all
(explicit: no one is allowed to send email for this domain)The SPF Lookup Limit
SPF allows a maximum of 10 DNS lookups per validation. Each include:, a, mx, exists:, and redirect= mechanism consumes one lookup. ip4: and ip6: do not consume any.
Lookup Limit Issues:
Counting (Example):
v=spf1
include:spf.protection.outlook.com → +1 lookup (+ lookups in the MS record!)
include:_spf.google.com → +1 lookup (+ lookups in the Google record!)
include:em.sparkpostmail.com → +1 lookup
include:mail.zendesk.com → +1 lookup
a:webserver.example.de → +1 lookup
mx → +1 lookup
-all
→ Total: 6 direct + nested lookups → quickly over 10!
Consequence of exceeding the limit:
→ SPF check ends with "permerror" (permanent error)
→ Many mail servers treat permerror as softfail or fail
→ Legitimate emails may end up in spam!
Solution: SPF Flattening
→ Resolve all IP addresses from include: chains
→ Use direct ip4:/ip6: entries
→ Drawback: If the provider changes IPs, the SPF record must be updated manually
→ Tools: mxtoolbox.com/spf, dmarcian SPF Surveyor
Alternatively: SPF macros for dynamic checks (advanced)SPF Alignment
For DMARC, not only the SPF result is relevant, but also the SPF alignment: The domain in the Return-Path (Envelope-From) must match the domain in the visible From: header.
SPF Alignment Examples:
Relaxed Alignment (Standard):
From: absender@beispiel.de
Return-Path: bounce@mail.beispiel.de → PASS (same org domain)
Return-Path: bounce@anderedomain.de → FAIL
Strict Alignment:
From: absender@beispiel.de
Return-Path: bounce@beispiel.de → PASS (exactly the same)
Return-Path: bounce@mail.beispiel.de → FAIL (subdomain is not sufficient)
Typical alignment issue with email marketing:
From: newsletter@beispiel.de
Return-Path: bounce-123@em.mailchimp.com
→ SPF pass for mailchimp.com, but DMARC alignment FAIL for example.de!
Solution: Configure a custom Return-Path with the provider
→ Return-Path: bounce@bounces.beispiel.de (CNAME pointing to Mailchimp)Limitations of SPF
What SPF DOES NOT protect against:
Forwarding:
→ When Server A forwards an email to Server B,
the envelope sender (Return-Path) changes
→ SPF check on Server B fails (incorrect IP for Return-Path domain)
→ Common issue with mailing lists and email forwarding
→ DKIM is significantly more robust here
Display Name Spoofing:
→ SPF checks the technical sender (Envelope-From), NOT the From: header
→ An attacker can set From: ceo@beispiel.de, while SPF passes for a
different domain (e.g., attackerdomain.com)
→ SPF passing does not mean: "The From: header is legitimate"
→ Solution: DMARC with alignment check
Compromised authorized server:
→ If an authorized server is hacked, attackers can
send valid SPF-passing emails
→ SPF only proves: "This IP is authorized" — not: "No abuse"
No integrity check:
→ SPF does not check whether the email was altered during transmission
→ DKIM provides this cryptographic integrity checkSPF and the complete authentication stack
SPF is the foundation of email authentication, but it only provides full protection when combined with DKIM and DMARC:
Recommended order of implementation:
Step 1: Create an SPF record
→ Inventory all sending servers and services
→ Publish an SPF record with -all
→ Check the lookup count (maximum 10!)
Step 2: Enable DKIM
→ Set up DKIM signing on all sending mail servers
→ Publish DNS TXT records for all selectors
Step 3: Implement DMARC
→ Start with p=none (reporting only, no rejection)
→ Analyze reports (rua=mailto:dmarc@beispiel.de)
→ Gradually transition to p=quarantine, then p=rejectA missing or incorrectly configured SPF record is one of the most common reasons why legitimate emails end up in the spam folder or why your own domain is misused for phishing attacks. According to DMARC.org, over 50% of all domains worldwide have either no SPF record or an incorrect one.
