An SPF record (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email on behalf of your domain. When a message arrives, the receiving server looks up your SPF record and checks whether the sending IP is on the approved list. If it is not, the message may be rejected, flagged, or delivered with a warning — depending on your policy.
What Is an SPF Record?
SPF stands for Sender Policy Framework. It was standardised in RFC 7208 and is now a baseline requirement for trustworthy email delivery. The record lives in your domain's DNS as a single TXT record at the root of your domain (e.g., example.com). It contains a version tag (v=spf1) followed by one or more mechanisms that describe which sources are permitted to send mail.
Without an SPF record, any server on the internet can claim to send email from your domain. Spammers and phishers exploit this routinely. Adding an SPF record gives receiving mail servers a way to verify that a message genuinely originated from an authorised source.
What Does an SPF Record Look Like?
SPF records are published as DNS TXT records. Here is a typical example for a domain that sends through Google Workspace and Mailgun:
v=spf1 include:_spf.google.com include:mailgun.org ~allBreaking this down: v=spf1 declares the SPF version. The two include: directives delegate authority to Google's and Mailgun's own SPF records. The ~all at the end is a softfail catch-all, meaning mail from any other source should be treated with suspicion but not outright rejected.
How Receiving Servers Check SPF
When an email arrives at a receiving mail server, the server performs the following steps:
- It reads the envelope sender address (also called the MAIL FROM or Return-Path address).
- It extracts the domain from that address.
- It queries DNS for a TXT record at that domain containing
v=spf1. - It evaluates the mechanisms in the SPF record from left to right against the connecting IP address.
- It returns a result: Pass, Fail, Softfail, Neutral, None, TempError, or PermError.
SPF Result Codes Explained
Understanding what each SPF result means helps you configure your record and troubleshoot delivery issues.
| Result | Meaning | Typical Action |
|---|---|---|
| Pass | The sending IP is authorised. | Deliver normally. |
| Fail | The sending IP is explicitly not authorised (-all). | Reject or discard. |
| Softfail | The sending IP is probably not authorised (~all). | Accept but mark as suspicious. |
| Neutral | The domain makes no assertion about the IP (?all). | Treat as if no SPF record exists. |
| None | No SPF record found for the domain. | No authentication possible. |
| TempError | A transient DNS error occurred during lookup. | Retry later; do not reject. |
| PermError | The SPF record is malformed or exceeded the lookup limit. | Treat as failure; record needs fixing. |
The SPF Lookup Limit
SPF has a hard limit of 10 DNS lookups during evaluation. Each include:,a, mx, and exists mechanism counts toward this limit. If your record exceeds 10 lookups, receiving servers return a PermError, which means your SPF record effectively fails — even if every IP listed is legitimate.
include:directives from email service providers. Use an SPF flattening tool or consolidate your sending sources to stay within the limit. Exceeding it is one of the most common causes of SPF PermError.Why SPF Alone Is Not Enough
SPF is a critical first step, but it has two important limitations:
- It does not protect the From header. SPF checks the envelope sender, not the address your recipients actually see. An attacker can pass SPF on the envelope domain while spoofing a completely different From address.
- It breaks with email forwarding. When a message is forwarded, the envelope sender changes. The forwarding server's IP is not in the original domain's SPF record, so SPF fails even for legitimate messages.
This is why SPF should always be combined with DKIM (which signs the message itself) and DMARC (which enforces alignment and provides reporting). Together, all three protocols provide comprehensive email authentication.
How to Check Your SPF Record
You can verify your domain's SPF record using the TXT Record Lookup tool. Look for the TXT record starting with v=spf1. If you manage multiple sending services, also check the MX Lookup tool to confirm your mail routing is consistent with your SPF policy.
Frequently Asked Questions
Can a domain have more than one SPF record?
No. A domain must have exactly one SPF record. If you publish multiple TXT records starting withv=spf1, receiving servers will return a PermError, which causes SPF to fail. If you need to authorise multiple sending services, combine them into a single SPF record using multipleinclude: or ip4: mechanisms.
What is the difference between ~all and -all?
~all is a softfail, meaning mail from unlisted sources should be accepted but treated with suspicion. -all is a hardfail, instructing receiving servers to reject mail from unlisted sources outright. Most domains start with ~all while monitoring, then move to-all once they are confident all sending sources are listed and DMARC is enforcing policy.
Does SPF work for subdomains?
SPF records are not automatically inherited by subdomains. If you send email from marketing.example.com, you need a separate SPF TXT record at that subdomain. Alternatively, if you never send email from a subdomain, you can publish a record of v=spf1 -all at that subdomain to block all mail claiming to come from it.
Will adding an SPF record stop spam immediately?
SPF reduces the risk of your domain being spoofed, but it does not stop all spam. It only tells receiving servers whether the sending IP is authorised — it cannot prevent someone from setting up a new domain and sending spam from there. For stronger protection, combine SPF with DKIM and enforce a DMARC policy of p=quarantine or p=reject.
How long does it take for an SPF record to take effect?
SPF records propagate according to your DNS TTL (Time to Live). A typical TTL of 3600 seconds means changes are visible within an hour, though some resolvers may cache the old record longer. Set a shorter TTL (e.g., 300 seconds) before making changes, then restore it after the update is confirmed.