SPF (Sender Policy Framework)

SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It allows domain owners to specify which mail servers are authorized to send emails on behalf of their domain.

SPF works by publishing a DNS TXT record that lists the IP addresses, hostnames, and third-party services authorized to send email for the domain. When a receiving mail server gets an email, it checks the sender's IP against the SPF record of the domain in the envelope sender (MAIL FROM / Return-Path).

How SPF Works

1. You publish an SPF record in your domain's DNS: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all
2. A receiver gets an email with Return-Path: user@yourdomain.com
3. The receiver queries DNS for yourdomain.com TXT and finds the SPF record
4. The receiver checks if the connecting IP matches any authorized source
5. Result: pass, fail, softfail, neutral, temperror, or permerror

An SPF record always starts with v=spf1 and contains one or more mechanisms, each optionally preceded by a qualifier.

Mechanisms

Qualifiers

Real-World Examples

# Basic: Google Workspace only
v=spf1 include:_spf.google.com -all

# Multiple services: Google + Mailchimp + own server
v=spf1 ip4:198.51.100.10 include:_spf.google.com include:servers.mcsv.net -all

# Soft fail during rollout (monitoring phase)
v=spf1 include:_spf.google.com include:amazonses.com ~all

One of the most common and critical SPF issues is the 10 DNS lookup limit. RFC 7208 specifies that SPF evaluation must not require more than 10 DNS lookups. If your SPF record exceeds this limit, the result is permerror — and many receivers will treat this as a failure.

What Counts as a Lookup?

How to Solve "Too Many Lookups"

1. Flatten includes: Replace include: with the actual IP ranges. Use SPF Flattening tools.
2. Remove unused services: Audit which third-party senders you actually use.
3. Use ip4/ip6 directly: These don't count toward the limit.
4. Use subdomains: Send marketing emails from marketing.example.com with its own SPF record.
5. Avoid mx and a: These often waste lookups; use ip4: directly instead.

Issue 1: Multiple SPF Records

A domain must have exactly one SPF record. Having two or more SPF TXT records is a permerror.

# WRONG: Two separate records
v=spf1 include:_spf.google.com -all
v=spf1 include:amazonses.com -all

# CORRECT: Combined into one
v=spf1 include:_spf.google.com include:amazonses.com -all

Issue 2: Exceeding the 255-Character String Limit

DNS TXT records have a 255-byte string limit. For longer SPF records, split into multiple strings within the same record (DNS handles concatenation).

Issue 3: Using +all

Never use +all — this authorizes the entire internet to send email as your domain. Always use -all or ~all.

Issue 4: Forgetting Third-Party Senders

Common third-party services that need to be in your SPF record:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Amazon SES: include:amazonses.com
• Mailchimp: include:servers.mcsv.net
• SendGrid: include:sendgrid.net
• Zendesk: include:mail.zendesk.com
• Salesforce: include:_spf.salesforce.com
• HubSpot: include:_spf.hubspot.net

Issue 5: SPF Passing But DMARC Failing

SPF checks the Envelope Sender (Return-Path), not the visible sender (From:). If these don't align, SPF will pass but DMARC Alignment will fail. This is common with third-party senders that use their own Return-Path domain.