SPF Explained: How Sender Policy Framework Protects Your Domain

• SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses are authorised to send email on behalf of your domain. Receiving servers check this record to verify that an email actually came from a permitted server.
• SPF only checks the envelope sender (Return-Path), not the header “From” address that users see. This is a key limitation that makes SPF insufficient on its own without DKIM and DMARC.
• SPF records have a hard 10 DNS lookup limit defined by RFC 7208. Exceeding this limit causes SPF to return a PermError, failing authentication for every message from your domain.
• SPF adoption is high-research shows 86% to 96% of domains have SPF records published. However, only a fraction enforce strict email authentication with DMARC, leaving many domains vulnerable to impersonation.
• SPF is the first line of defence but not a complete solution. It must be combined with DKIM and DMARC for comprehensive email authentication.

1. An email is sent from a server on behalf of your domain.
2. The receiving mail server looks up the SPF record for the domain in the Return‑Path (envelope sender).
3. The sending IP address is checked against the authorised IPs listed in the SPF record.
4. A result is determined: pass, fail, softfail, neutral, or none.

v=spf1 [mechanisms] [qualifier]all

v=spf1 ip4:192.0.2.1 -all

v=spf1 include:_spf.google.com -all

v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.google.com include:mailgun.org ~all

• Audit and remove unused include statements for services you no longer use.
• Consolidate multiple include statements where possible.
• Use an SPF flattening service to resolve include chains into direct IP addresses, eliminating lookup overhead entirely.
• Budget for 7–8 lookups to leave headroom.

1. Use only one SPF record per domain-multiple records cause a PermError.
2. Keep it simple-stay well below the 10‑lookup limit. Budget for 7–8 lookups to leave headroom.
3. Start with ~all (soft fail) during implementation to avoid blocking legitimate email while you verify all sending sources.
4. Move to -all (hard fail) after you are confident your SPF record lists every legitimate sending service.
5. Audit all sending sources-include all email marketing platforms, transactional email providers, CRMs, and cloud platforms.
6. Document your SPF record-maintain a record of what each include statement represents.
7. Test before deploying-use online tools and command‑line validation.
8. Combine with DKIM and DMARC-SPF alone is insufficient.

• MXToolbox SPF Check
• SPF Validation Tool
• Google Admin Toolbox

dig TXT example.com +short | grep spf

Authentication-Results: spf=pass smtp.mailfrom=example.com;

• SPF authorises sending IPs through DNS TXT records, providing the first layer of email authentication.
• SPF only checks the envelope sender, not the header From address. This is a key limitation that makes SPF insufficient on its own.
• SPF records have a hard 10‑lookup limit defined by RFC 7208. Exceeding this causes permanent failure.
• SPF adoption is high-86% to 96% of domains have SPF records. However, 67.9% of domains have clean SPF, meaning 1 in 3 have at least one issue.
• Use ~all (soft fail) during implementation, then move to -all (hard fail) after verification.
• SPF is not a complete solution. It must be combined with DKIM and DMARC for full protection.

• RFC 7208 – Sender Policy Framework (SPF)
• RFC 6376 – DomainKeys Identified Mail (DKIM)
• RFC 7489 – DMARC
• BIMI Specification