SPF Records Explained
How Sender Policy Framework records specify which servers are allowed to send email for a domain.
Core Concept
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of a domain.
Receiving mail servers check the sending server's IP against the domain's published SPF record to help determine whether a message is legitimate or spoofed.
How an SPF Record Is Structured
An SPF record is a single TXT record made up of mechanisms that define authorized senders.
- v=spf1 — declares the record as SPF version 1
- ip4 / ip6 — authorizes specific IP addresses or ranges
- include — authorizes another domain's SPF-listed senders
- ~all / -all — defines the policy for unlisted senders
Soft Fail vs Hard Fail
~all (soft fail) asks receivers to flag unauthorized mail as suspicious; -all (hard fail) asks them to reject it outright.
The 10-Lookup Limit
SPF enforces a hard limit of 10 DNS lookups during evaluation, a constraint that trips up domains using many third-party mail services.
- Each include mechanism counts toward the limit
- Nested includes from third-party services add up quickly
- Exceeding the limit causes SPF evaluation to fail entirely
Why SPF Alone Isn't Enough
SPF has a structural gap that limits its effectiveness on its own.
It validates the envelope sender address used during the SMTP transaction, which is often invisible to end users and can differ from the visible From header they actually see.
The Alignment Gap
An email can pass SPF while still displaying a spoofed From address, because SPF checks a different address than the one users actually see.
Maintaining SPF Records Over Time
SPF records need active maintenance as an organization's email infrastructure changes.
- Auditing which third-party services are actually still in use
- Flattening nested includes to stay under the lookup limit
- Monitoring for authentication failures indicating drift
Real-World Implementation
SPF is a baseline component of nearly every serious email authentication setup.
- Combined with DKIM and DMARC for full authentication coverage
- Monitored through DMARC aggregate reports for failures
- Audited whenever new email-sending services are adopted
SPF is necessary but not sufficient on its own — it's most effective as one layer of a combined SPF, DKIM, and DMARC authentication strategy.
Common Mistakes to Avoid
A few common mistakes cause SPF records to fail or provide weaker protection than intended.
- Exceeding the 10-lookup limit by including too many nested third-party services.
- Leaving stale entries in place for email services no longer in use.
- Using ~all (soft fail) when -all (hard fail) better matches the intended policy.
- Assuming SPF alone verifies the visible From address a user actually sees.
- Failing to audit which third-party services are genuinely still sending mail.
- Overlooking the exists mechanism, a less common but sometimes useful SPF option.
- Assuming SPF alone protects against a spoofed visible From address.
- Failing to test SPF changes in a monitored, non-enforcing mode first.
- Overlooking macro expansion, an advanced SPF feature rarely needed but easy to misuse.
- Assuming SPF checks apply to messages relayed through internal forwarding systems the same way.
- Failing to periodically audit for redundant or overlapping include mechanisms.
- Overlooking that some email marketing platforms require periodic re-verification of SPF inclusion.
Best Practices Checklist
These practices help keep SPF records accurate and within technical limits.
- Audit SPF includes regularly to remove entries for decommissioned services.
- Flatten nested includes where possible to stay comfortably under the 10-lookup limit.
- Pair SPF with DKIM and DMARC rather than relying on it as a standalone defense.
- Choose -all deliberately once confident all legitimate senders are properly included.
- Monitor DMARC aggregate reports to catch SPF failures from forgotten senders.
- Understand less common mechanisms like exists for specialized SPF use cases.
- Pair SPF with DKIM and DMARC rather than relying on it alone against spoofing.
- Test significant SPF changes in a monitored mode before full enforcement.
- Avoid macro expansion unless a specific advanced use case genuinely requires it.
- Understand how internal forwarding interacts with SPF checks, since it can complicate validation.
- Audit SPF records periodically for redundant or overlapping include mechanisms to simplify maintenance.
- Check whether a marketing platform requires periodic re-verification of its SPF include entry.
Frequently Asked Questions
Frequently asked questions about SPF records.
What does SPF actually verify?
It verifies the sending server's IP against the domain's published SPF record — it validates the server, not the message content or visible From address.
What's the 10-lookup limit and why does it matter?
SPF enforces a hard limit of 10 DNS lookups during evaluation, and exceeding it causes SPF evaluation to fail entirely, even with a well-formatted record.
What's the difference between ~all and -all?
~all (soft fail) asks receivers to flag unauthorized mail as suspicious, while -all (hard fail) asks them to reject it outright.
Why isn't SPF enough on its own to prevent spoofing?
It validates the envelope sender, which is often invisible to end users and can differ from the visible From address they actually see.
How often should SPF records be reviewed?
Regularly — as an organization's email infrastructure changes, stale entries and near-limit lookup counts both need periodic attention.
What does the exists mechanism do in SPF?
It checks for the existence of a DNS record matching a specified domain, a less common mechanism used in specialized configurations.
Does SPF alone stop From address spoofing?
No — it validates the envelope sender, which can differ from the visible From address; DMARC is needed to enforce that alignment.
Should SPF changes be tested before full enforcement?
Yes — monitoring the impact of a change before it affects mail delivery reduces the risk of inadvertently blocking legitimate senders.
What is SPF macro expansion?
An advanced feature allowing dynamic values within an SPF record, rarely necessary and prone to misconfiguration if used without a clear need.
Does internal email forwarding complicate SPF validation?
Yes — forwarding can change the effective sending IP, sometimes causing legitimate forwarded mail to fail SPF checks unexpectedly.
Do some platforms require periodic SPF re-verification?
Some do as part of their own security practices, making it worth confirming a platform's specific requirements beyond initial setup.
Check a Domain's SPF Record
Run an email security scan to see the SPF configuration and authorized senders for a domain.
Launch Tool →