SPF Records Explained: How They Protect Your Domain

What is SPF?

SPF (Sender Policy Framework) is a type of TXT record published in your domain's DNS settings. It acts as a whitelist, declaring which IP addresses and mail servers are authorized to send emails using your domain name.

Without SPF, anyone could send emails pretending to be from your domain. Spammers and phishers exploit this to impersonate legitimate organizations. SPF helps receiving mail servers verify that incoming mail from your domain actually comes from servers you've approved.

SPF is one of three key email authentication protocols, alongside DKIM and DMARC. Together, they form a robust defense against email spoofing and improve your domain's deliverability.

How SPF Works

When an email arrives at a receiving mail server, here's what happens:

1. The receiving server extracts the domain from the email's "envelope from" address (also called the Return-Path)
2. It performs a DNS lookup for the TXT record containing the SPF policy for that domain
3. The server compares the IP address of the sending server against the list of authorized IPs in the SPF record
4. Based on the SPF policy, the server marks the email as pass, fail, softfail, or neutral

If the sending IP matches an authorized source, SPF passes. If not, the result depends on your SPF policy's qualifier (more on that below).

SPF Syntax Explained

An SPF record starts with a version tag and contains one or more mechanisms that define authorized senders. Here's the basic structure:

v=spf1 [mechanisms] [qualifier]all

Common Mechanisms

Qualifiers

Qualifiers are prefixes that determine how a match (or non-match) should be handled:

Most SPF records end with -all (hard fail) or ~all (soft fail). We recommend -all for maximum protection once you've verified all legitimate sending sources.

Common SPF Examples

Google Workspace

If you use Google Workspace for email:

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

Microsoft 365

For Microsoft 365 (formerly Office 365):

v=spf1 include:spf.protection.outlook.com -all

Multiple Services

If you use Google Workspace plus a marketing platform like Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Custom Mail Server

For a custom mail server with a specific IP:

v=spf1 mx ip4:203.0.113.25 -all

Domain That Doesn't Send Email

For domains that should never send email (parked or redirect-only domains):

v=spf1 -all

This tells receivers to reject any email claiming to come from this domain.

SPF Limitations

The 10 DNS Lookup Limit

SPF has a critical limitation: a maximum of 10 DNS lookups per SPF check. This includes lookups from include, a, mx, redirect, and exists mechanisms.

Each include: counts as one lookup, but if that included record has its own includes, those count too. You can quickly exceed 10 lookups when using multiple third-party email services.

If your SPF record exceeds 10 lookups, it results in a "permerror" and SPF validation fails. Ways to mitigate this:

• Use ip4: and ip6: instead of include: where possible (IP mechanisms don't count as lookups)
• Remove unused or redundant include statements
• Consider SPF flattening services (though they require maintenance)
• Consolidate sending through fewer providers

Other Limitations

• Forwarding breaks SPF: When email is forwarded, the forwarding server's IP won't be in your SPF record, causing failures
• Only checks envelope sender: SPF validates the Return-Path, not the visible "From" header users see
• Requires DMARC for full protection: Without DMARC, failed SPF checks may not prevent delivery

Testing Your SPF Record

After publishing your SPF record, it's essential to verify it's working correctly. Common issues include:

• Syntax errors that invalidate the entire record
• Missing authorized senders (causing legitimate email to fail)
• Exceeding the 10 DNS lookup limit
• Multiple SPF records (only one is allowed per domain)
• Using ~all when -all would be more secure