What this RFC defines
RFC 7208 defines SPF (Sender Policy Framework), a DNS-based mechanism that specifies which IP addresses are authorised to send email on behalf of a domain. Domain owners publish a TXT record in DNS listing their authorised sending IPs; receiving MTAs check this record against the connecting IP and the MAIL FROM envelope address.
Where you see it in practice
The SPF record in your domain’s DNS (v=spf1 include:sendgrid.net ~all) is defined by this RFC. When a receiving MTA runs an SPF check and your IP is not in the record, it returns a “fail” or “softfail” result that SPF-aware filters use to score your message. SPF pass is one of the two alignment signals DMARC depends on (alongside DKIM).
How it connects to other RFCs
RFC 7208 obsoletes RFC 4408 (the original SPF specification from 2006). It works directly with RFC 7489 (DMARC), which uses SPF results as one of its alignment signals. RFC 8601 defines the Authentication-Results header where SPF outcomes are recorded for downstream processing.
Current status
RFC 7208 is the current SPF standard, published April 2014. SPF has been required for bulk senders to Gmail and Yahoo since February 2024. The standard is stable with no planned successor.
The current SPF standard
RFC 7208 is the current standards-track SPF specification, published in April 2014 and obsoleting RFC 4408. It defines how a domain publishes an authorized-sender policy in a DNS TXT record (v=spf1 followed by mechanisms and modifiers), and how receiving MTAs evaluate the policy against the SMTP envelope MAIL FROM address. A pass result signals that the sending IP is authorized; a fail result signals it is not; a softfail is a “probably not authorized” hint. Each result becomes an input to filtering and DMARC alignment.
SPF alignment for DMARC
SPF alone checks the SMTP envelope sender (MAIL FROM), which is often invisible to end users. DMARC (RFC 7489) requires SPF pass PLUS alignment between the MAIL FROM domain and the RFC 5322 From header domain. This is why setting up SPF for an ESP like SendGrid or Mailgun is not enough for DMARC; you also need to either use a subdomain of your primary domain for MAIL FROM (proper alignment) or use DKIM as the alignment mechanism instead. Most ESPs support both approaches.
The 10-lookup problem
RFC 7208 retains the DNS lookup limit of 10 (with some sub-limits). Complex include chains routinely exceed this limit, producing PermError. Flattening the SPF record (replacing includes with the actual IP ranges they resolve to) is a common workaround but requires maintenance: if the underlying ESP changes IPs, the flattened record must be updated. Services like Kitterman SPF query counts, dmarcian, and Valimail provide dynamic flattening. Any domain sending mail through multiple third-party services should audit its SPF for lookup count.
RFC 7208 (April 2014) defines Sender Policy Framework (SPF): a DNS-based mechanism where a domain publishes which IP addresses are authorized to send email on its behalf. Receiving MTAs check the envelope sender (MAIL FROM per RFC 5321) against the SPF record and produce a verdict (pass, fail, softfail, neutral, none, temperror, permerror). SPF has a hard limit of 10 DNS lookups per evaluation. Obsoletes RFC 4408. Combined with DKIM and DMARC, one of the three pillars of email authentication.
RFC 7208 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Authorize which IPs may send mail using a domain in MAIL FROM |
| Storage | DNS TXT record at the domain (e.g., example.com. IN TXT "v=spf1 ...") |
| Checked identity | MAIL FROM envelope address (Return-Path), not the From header |
| Verdicts | pass, fail, softfail, neutral, none, temperror, permerror |
| Hard limit | 10 DNS lookups maximum per evaluation (permerror if exceeded) |
| Result surfaced in | Authentication-Results header per RFC 8601 |
| Published | April 2014 (obsoletes RFC 4408) |
SPF record syntax
SPF mechanisms reference
| Mechanism | Meaning | DNS lookups |
|---|---|---|
all | Matches everything (used as terminator) | 0 |
ip4:1.2.3.4 / ip4:1.2.3.0/24 | Match single IP or CIDR block (IPv4) | 0 |
ip6:2001:db8::/32 | Match IPv6 range | 0 |
a / a:domain | Match A/AAAA records of domain | 1 |
mx / mx:domain | Match MX records of domain | 1 (+1 per MX) |
ptr / ptr:domain | Match reverse DNS (DEPRECATED, do not use) | Many, MUST NOT use |
exists:domain | DNS A query for domain; match if any A record exists | 1 |
include:domain | Include another domain’s SPF record (recursive) | 1 (+all lookups in included record) |
The 10-lookup limit
include, a, mx, exists, and redirect counts against the limit; ip4 and ip6 do not. Domains using many third-party services (Google Workspace, SendGrid, Mailchimp, Klaviyo, HubSpot, Zendesk) commonly hit the limit and effectively have no SPF protection until flattened.Common SPF configuration mistakes
v=spf1 TXT record per domain. Publishing two produces permerror. This is a frequent misconfiguration when a new service instructs the admin to “add this SPF record” without checking for existing ones. Fix: merge all mechanisms into a single record.ptr. The ptr mechanism is deprecated by RFC 7208 section 5.5 due to load on DNS and unreliability. Some evaluators refuse to process it; others always fail it. Remove any ptr from your SPF record.+all or omitting the terminator. +all means “any sender passes SPF”, which negates the entire purpose. Use -all (hard fail) for domains that know their complete sender list, or ~all (soft fail) while migrating. Never +all. Omitting all entirely results in an implicit neutral, which similarly provides no protection.include: for every new sending service eventually blows the limit. Fix: use an SPF flattening service (Kitterman, dmarcian, EasyDMARC, Valimail) that expands includes into raw IP lists at query time and republishes as a static SPF with only ip4/ip6. Static flattening breaks if the third-party changes IPs; dynamic flattening tracks changes.SPF verdicts and how receivers use them
| Verdict | Meaning | Typical receiver action |
|---|---|---|
pass | Sender IP explicitly authorized | Accept; positive reputation signal |
fail | Sender IP explicitly not authorized | Reject or mark spam (per receiver policy) |
softfail | SPF policy says “probably not authorized” | Accept but treat as suspicious; negative reputation input |
neutral | Domain makes no assertion about this IP | Accept; no reputation signal |
none | Domain has no SPF record | Accept; no reputation signal; DMARC treats as fail |
temperror | DNS lookup failure during evaluation | Defer for retry (4xx) |
permerror | SPF record syntax error or lookup limit exceeded | Treat as fail; investigate configuration |
Related standards and further reading
- RFC 4408: Legacy SPF (obsoleted by RFC 7208)
- RFC 6376: DKIM (paired authentication mechanism)
- RFC 7489: DMARC (policy layer over SPF and DKIM)
- RFC 8601: Authentication-Results header (surfaces SPF verdict)
- RFC 5321: SMTP (defines the MAIL FROM identity SPF checks)
- RFC 8617: ARC (preserves SPF verdict across forwarders)
- SPF Record Setup Guide: syntax, examples, common patterns
- Free SPF Record Checker: syntax validation and lookup count
- Authentication-Results Header: reading SPF=pass/fail verdicts
- DKIM Record Guide: paired authentication
- DMARC Record Guide: policy layer requiring SPF or DKIM alignment
Frequently asked questions
What identity does SPF authenticate?
SPF authenticates the MAIL FROM envelope sender (the Return-Path address per RFC 5321). It does not authenticate the From header the recipient sees. This distinction matters for spoofing: an attacker can pass SPF with their own domain in MAIL FROM while forging your brand in From. DMARC alignment closes this by requiring MAIL FROM to align (identical or subdomain-related) with the From domain.
Why does my SPF fail even though I added every sending service?
You likely exceeded the 10 DNS lookup limit. Every include:, a, mx, exists, and redirect counts against the limit. Google Workspace, SendGrid, Mailchimp, HubSpot, and Salesforce each cost 1 lookup; several of them combined breach the limit. Fix: use SPF flattening (Kitterman, dmarcian, EasyDMARC, Valimail) which expands includes to raw IP ranges and republishes as static.
Should I use -all or ~all at the end of my SPF?
-all (hard fail) tells receivers to reject mail from non-authorized IPs. Use this once your SPF is comprehensive and stable. ~all (soft fail) tells receivers to accept but mark suspicious; use this during migration when you might not have all senders identified. Never use +all: it means “any sender passes” and defeats the purpose. Never omit all: it results in neutral which provides no protection.
Why does SPF break after email forwarding?
Traditional forwarding replays the message from the forwarder’s IP, not the original sender’s IP. The SPF check at the final destination sees the forwarder’s IP checked against the original sender’s SPF record, which naturally fails. Solutions: sender rewriting scheme (SRS, changes MAIL FROM to the forwarder’s domain so SPF checks its record), or ARC (RFC 8617) which lets the forwarder attest to the pre-forwarding SPF verdict.
What is the difference between SPF fail and DMARC fail?
SPF fail means the sending IP is not authorized for the MAIL FROM domain. DMARC fail means the message did not achieve alignment (SPF pass with aligned MAIL FROM, or DKIM pass with aligned d=). A message can SPF-fail but DMARC-pass (if DKIM is aligned and passes) or SPF-pass but DMARC-fail (if the MAIL FROM domain does not align with the From domain). See DMARC guide for alignment rules.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
