What this RFC defined
RFC 4408 defined the original Sender Policy Framework (SPF), specifying how domain owners publish authorised sending IPs in DNS TXT records and how receiving servers check them. It established the core check_host() algorithm and the v=spf1 record syntax that remains in use today under RFC 7208.
Where you would have seen it in practice
If you have SPF records published for your domains today (v=spf1 include:… ~all), they follow the syntax originally defined in RFC 4408 and refined in RFC 7208. The two are largely compatible in practice because RFC 7208 tightened ambiguous language rather than changing the record format.
How it connects to other RFCs
RFC 4408 was obsoleted by RFC 7208 in 2014. RFC 7208 resolved ambiguities around macro expansion, multiple SPF records, and error handling. The DMARC framework (RFC 7489) builds on SPF alignment regardless of which SPF RFC the record follows, since the v=spf1 syntax is identical in both.
Current status
RFC 4408 was obsoleted by RFC 7208 in April 2014. New SPF documentation and implementations should reference RFC 7208. Existing SPF records published under RFC 4408 syntax continue to evaluate correctly under RFC 7208, since the core record syntax was not changed by the update.
The first published SPF standard
RFC 4408 was the first standards-track publication of the Sender Policy Framework in April 2006. Before this document, SPF existed as an experimental idea championed by Meng Weng Wong and various early adopters, but there was no single authoritative reference. RFC 4408 codified the DNS TXT record syntax (v=spf1 include:_spf.google.com ~all), the “mechanisms” (a, mx, ip4, ip6, include, exists, all), the “qualifiers” (+, -, ~, ?), and the evaluation algorithm that receiving MTAs use to check whether a sender IP is authorized for a given domain.
Superseded by RFC 7208
RFC 4408 was declared “experimental” for its lifetime and was obsoleted by RFC 7208 in April 2014. The eight-year gap accumulated significant errata, clarifications, and operational experience. RFC 7208 also removed the SPF-specific DNS record type (which had been assigned but rarely used), leaving TXT records as the single canonical publication method. If your DNS still contains an SPF-type record, it can be safely removed; only the TXT record matters.
The 10-lookup limit and other pitfalls
RFC 4408 introduced the DNS lookup limit of 10 (excluding some cheap lookups), which was carried forward into RFC 7208. This limit exists to prevent SPF from acting as a DNS DoS amplifier. Domains that use nested “include” mechanisms often exceed 10 lookups without realizing it, producing “PermError” results that treat the SPF check as if it were absent. Tools like MXToolbox SPF Survey, dmarcian, and Kitterman SPF query counts help diagnose this. If SPF checks fail intermittently for legitimate senders, exceeding the 10-lookup limit is the most common cause.
RFC 4408 (April 2006) was the original SPF (Sender Policy Framework) specification. Introduced the v=spf1 DNS TXT record syntax, mechanisms (a, mx, ip4, ip6, include), qualifiers (+, -, ~, ?), and verdicts (pass, fail, softfail, neutral, none, temperror, permerror). Obsoleted by RFC 7208 in April 2014. Historical relevance only: for current SPF implementation, reference RFC 7208. The syntax is essentially identical between the two RFCs; RFC 7208 clarified ambiguities, removed the deprecated SPF DNS record type (in favor of TXT), and refined operational guidance.
RFC 4408 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Original SPF specification |
| Status | Obsolete (superseded by RFC 7208) |
| Record location | DNS TXT (or dedicated SPF type, later deprecated) |
| Core syntax | Identical to RFC 7208: v=spf1 + mechanisms + qualifier + all |
| Published | April 2006 |
| Superseded by | RFC 7208 (April 2014) |
Changes from RFC 4408 to RFC 7208
| Aspect | RFC 4408 (2006) | RFC 7208 (2014) |
|---|---|---|
| DNS record type | TXT and dedicated SPF record type (both permitted) | TXT only (dedicated SPF type removed) |
| Mechanisms | a, mx, ip4, ip6, ptr, exists, include | Identical (with ptr deprecated) |
| Qualifiers | +, -, ~, ? | Identical |
| Verdicts | pass, fail, softfail, neutral, none, temperror, permerror | Identical |
| DNS lookup limit | 10 lookups (SHOULD) | 10 lookups (MUST; permerror if exceeded) |
| ptr mechanism | Allowed but discouraged | Explicitly deprecated (SHOULD NOT use) |
| Header field | Received-SPF (recommended) | Received-SPF or Authentication-Results per RFC 8601 |
The dedicated SPF DNS record type (deprecated)
Upgrading from RFC 4408 to RFC 7208
| Action | Reason |
|---|---|
| Confirm SPF is in TXT record (not just SPF type) | RFC 7208 removes SPF type |
Remove any ptr mechanisms | Deprecated in RFC 7208 section 5.5 |
| Audit DNS lookup count | MUST be 10 or fewer per RFC 7208 |
| Consider Authentication-Results header | Standard way to report SPF verdict in modern deployments |
| Deploy with DMARC per RFC 7489 | SPF alone does not protect against From header spoofing |
Common mistakes when SPF configuration references RFC 4408
ptr mechanism. Legal in RFC 4408 but explicitly deprecated in RFC 7208. Some evaluators refuse to process it; others always fail it. Remove ptr from all SPF records.Related standards and further reading
- RFC 7208: Current SPF specification (obsoletes RFC 4408)
- RFC 6376: DKIM (paired authentication mechanism)
- RFC 7489: DMARC (policy layer over SPF and DKIM)
- RFC 8601: Authentication-Results header
- RFC 8617: ARC (preserves SPF verdict across forwarders)
- RFC 5321: SMTP (defines MAIL FROM identity SPF authenticates)
- SPF Record Setup Guide: current syntax and patterns
- Free SPF Record Checker: validate your record
- DKIM Record Guide: paired authentication
- DMARC Record Guide: policy layer
Frequently asked questions
Is RFC 4408 still relevant in 2026?
Only for historical reference. RFC 4408 was superseded by RFC 7208 in April 2014. Current SPF specifications, tools, and receivers reference RFC 7208. Deploy per RFC 7208; reference RFC 4408 only when discussing the historical evolution of SPF or clarifying differences between the two specifications.
Do I need to update my SPF record if it was published under RFC 4408?
Probably not the content; SPF records are typically compatible between RFC 4408 and RFC 7208 syntax. Check for: (1) any records published under the dedicated SPF record type (removed in RFC 7208; must be in TXT), (2) any ptr mechanism (deprecated in RFC 7208; remove), (3) DNS lookup count (was recommended limit under 4408, now hard limit under 7208; fix if exceeded).
What was the SPF DNS record type and why was it removed?
RR type 99, a dedicated DNS record type for SPF policies. RFC 4408 permitted it alongside TXT. In practice, TXT records dominated because they worked with every DNS server and management tool; the SPF type required infrastructure upgrades. Adoption was so unbalanced that RFC 7208 removed the dedicated type entirely; only TXT is now permitted. Any domains still publishing only the SPF type have effectively no SPF policy from the perspective of modern evaluators.
What was different about the ptr mechanism in RFC 4408?
RFC 4408 permitted ptr (reverse DNS check) but noted it was expensive and unreliable. RFC 7208 elevated this to explicit deprecation (SHOULD NOT use). The mechanism triggers many DNS queries and is vulnerable to fake reverse DNS. Most evaluators today either refuse ptr entirely or always fail it. Remove ptr from any SPF record still using it.
Was DKIM available at the time of RFC 4408?
Not standardized. RFC 4408 (April 2006) predates RFC 4871 DKIM (May 2007). Early SPF deployments frequently ran without DKIM. DMARC (RFC 7489) which unified SPF and DKIM as inputs to a common policy came later still (March 2015). The full stack (SPF, DKIM, DMARC) took nearly a decade to assemble; RFC 4408 is the earliest layer.
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.
