This guide provides a technical and standards-based walkthrough of SPF (Sender Policy Framework), covering its DNS-based record format, authentication mechanics, evaluation logic, common misconfigurations, lookup limits, real-world implementation examples, and best practices for domain owners and mail administrators. It is structured to aid systems engineers, email platform integrators, and security professionals in understanding and validating SPF policies using both manual techniques and automated tools.

The information herein is based on RFC 7208 and includes reference implementations for IPv4/IPv6 sources, macro expansion handling, DMARC alignment implications, interaction with DNS propagation, TTL behavior, and diagnostic scenarios using the SPF Checker.

Proper SPF policy configuration is critical to secure mail delivery, enforceable trust chains, and alignment with domain-based reputation systems. This document is intended to support rigorous configuration auditing and verification workflows in production environments.

1. Overview of Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email validation protocol designed to detect and prevent spoofing by allowing domain owners to publish a list of authorized mail servers in the Domain Name System (DNS). The mechanism is implemented by adding a specially formatted TXT record to the domain’s DNS zone file.

SPF is evaluated during the SMTP envelope phase (MAIL FROM) and plays a critical role in verifying the legitimacy of the sending infrastructure. SPF does not validate the “From:” header in the message body, and for that reason is often paired with DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance).

2. Specification Background and History

SPF was originally proposed by Meng Weng Wong in 2003 as part of the “RMX” proposal, which evolved into the “Sender Policy Framework.” The IETF took up SPF under the MARID working group, which was later dissolved due to technical and political disagreements. Despite that, SPF continued to see adoption and was formalized as RFC 4408 (Experimental) in 2006 and later updated to RFC 7208 (Standards Track) in 2014.

RFC 7208 defines the mechanisms, qualifiers, evaluation semantics, and error handling behavior for SPF and clarifies ambiguities in previous drafts. It also officially deprecates the use of the SPF-type DNS RR in favor of standard TXT records for compatibility reasons.

3. SPF Record Syntax

An SPF policy is expressed as a single line of text with the prefix v=spf1 followed by one or more mechanisms and an optional default qualifier. The evaluation process parses the mechanisms in sequence until a match is found or the list is exhausted. Each mechanism can optionally be prefixed by a qualifier.

v=spf1 ip4:203.0.113.0/24 include:_spf.example.com -all

This record indicates that mail is permitted from any IP address in the range 203.0.113.0/24 and from any host authorized in the SPF record for _spf.example.com. All other sources are explicitly not authorized (-all).

3.1 SPF Mechanisms

• all: Matches all IPs
• ip4: Matches specified IPv4 networks
• ip6: Matches specified IPv6 networks
• a: Matches the A or AAAA record for the domain
• mx: Matches the MX record target hosts
• ptr: Deprecated; resolves PTR then checks domain match
• include: Imports policy from another domain
• exists: Tests for existence of a domain

3.2 Qualifiers

• +: Pass (default)
• -: Fail
• ~: Softfail
• ?: Neutral

The order of mechanisms matters. SPF processes them sequentially. Only the first matching mechanism is used to determine the outcome.