# SPF Record Syntax
Sender Policy Framework (SPF) record syntax defines the structured format of DNS TXT records that domain owners publish to declare which mail servers are authorized to send email on their behalf. The syntax follows a precise grammar governed by RFC 7208, and any deviation from that grammar produces records that receiving servers either reject outright or misinterpret. SPF exists because Simple Mail Transfer Protocol (SMTP) has no native sender authentication: any server on the internet can claim to send mail from any domain. SPF gives domain owners a mechanism to publish an explicit allowlist in DNS, allowing receiving mail servers to compare the connecting server's IP address against that list and make a policy decision before accepting the message.
---
SPF is an email authentication protocol defined in RFC 7208 (obsoleting RFC 4408). It operates at the DNS layer, published as a TXT record under the domain used in the SMTP envelope sender address (the MAIL FROM command, also called the Return-Path). The record consists of a version tag, one or more mechanisms, optional modifiers, and qualifiers that define the policy outcome for each mechanism match.
SPF is not the same as DKIM (DomainKeys Identified Mail), which authenticates message content via cryptographic signatures. SPF is also not DMARC, which is a policy layer built on top of both SPF and DKIM. SPF alone cannot prevent display-name spoofing or header From spoofing because it checks only the envelope sender, not the header visible to end users.
SPF does not encrypt email. It does not validate message content, attachments, or routing paths beyond the initial sending server. It is also not a reputation system: a domain with a valid SPF record that passes can still send spam or phishing.
The "v=spf1" version tag is the only currently deployed version; the experimental "v=spf2.0" (Sender ID) is deprecated and should not be used. Some legacy configurations still reference "spf2.0/pra" records, which modern mail systems ignore.
SPF records must be unique per domain. Publishing two TXT records beginning with "v=spf1" on the same domain creates a permerror condition per RFC 7208 Section 3.2, causing immediate SPF failure. This is a common misconfiguration when teams add SPF records without checking whether one already exists.
---
An SPF record is evaluated by the receiving mail server (the verifier) during the SMTP transaction, after the MAIL FROM command is issued. The verifier extracts the domain from the envelope sender address, queries that domain's DNS TXT records, and evaluates the SPF record against the connecting server's IP address.
Record Structure
A well-formed SPF record follows this pattern:
v=spf1 [mechanisms] [modifiers] [all]The version tag "v=spf1" must appear first. Mechanisms are evaluated left to right. The first mechanism that matches the connecting IP produces a result and evaluation stops.
Mechanisms
The "ip4" and "ip6" mechanisms authorize specific IPv4 or IPv6 addresses or CIDR ranges. Example: "ip4:203.0.113.0/24" authorizes all addresses in that subnet. This is the most precise and performant mechanism because it requires no additional DNS lookup.
The "a" mechanism authorizes IPs returned by the domain's A or AAAA record. If no domain is specified, the current domain is used. Example: "a:mail.example.com" resolves mail.example.com and authorizes those IPs.
The "mx" mechanism authorizes the IP addresses of the domain's MX records. Useful when the same servers both receive and send mail.
The "include" mechanism delegates to another domain's SPF record. Example: "include:_spf.google.com" instructs the verifier to evaluate Google's SPF record and use the result. If the included record returns "pass," the overall mechanism matches. Critically, each "include" triggers at least one additional DNS lookup.
The "exists" mechanism tests whether a constructed domain name resolves, enabling dynamic or macro-based policies. Rarely used in standard configurations.
The "all" mechanism is a wildcard that matches any IP. Typically placed last. It defines the catch-all policy for addresses that did not match any earlier mechanism.
Qualifiers
Each mechanism can be prefixed with a qualifier:
A record ending in "-all" is a hard-fail policy. A record ending in "~all" is a softfail policy, often used during initial deployment before moving to hard-fail.
DNS Lookup Limit
RFC 7208 Section 4.6.4 imposes a limit of 10 DNS lookups during SPF evaluation. Mechanisms that count toward this limit include: "include," "a," "mx," "exists," and "redirect." The "ip4" and "ip6" mechanisms do not require DNS lookups and do not count. Each "include" may itself reference additional "include" chains, and all nested lookups count toward the same 10-lookup budget.
Exceeding 10 lookups produces a "permerror" result, which DMARC treats as an SPF failure. This is not a theoretical edge case. An organization sending email through three cloud platforms (a marketing automation tool, a customer support platform, and a CRM) may easily exhaust the lookup budget before every authorized sender is covered.
Practical Example
Consider a company, "example.com," that sends transactional email through Amazon SES, marketing email through Mailchimp, and support email through Zendesk. A naive SPF record might look like:
v=spf1 include:amazonses.com include:servers.mcsv.net include:mail.zendesk.com ~allThis appears reasonable, but each include chain may itself contain nested includes. Amazon SES's SPF record contains multiple additional includes. Mailchimp's record similarly nests references. In practice, this single record may already approach or exceed the 10-lookup limit. The solution is to flatten the record: resolve all nested IP ranges statically and replace include chains with direct "ip4" and "ip6" mechanisms, then monitor for IP range changes from those providers.
The "redirect" Modifier
The "redirect" modifier replaces the current domain's SPF policy entirely with another domain's record. Unlike "include," which returns a pass/fail result for one mechanism, "redirect" delegates the entire policy. It is useful for organizations managing multiple domains that share one authoritative SPF configuration.
Processing Sequence
When a receiving mail server processes an SPF record, it evaluates mechanisms in order until one matches. If "include:third-party.com" appears before "ip4:10.0.0.1," the include mechanism is evaluated first. If the third-party's SPF record passes, processing stops with a pass result, even if the sending IP is 10.0.0.1. Order matters significantly when multiple mechanisms could match the same sending IP.
Modifiers are processed after all mechanisms. The "exp" modifier provides explanatory text for humans when SPF fails, while "redirect" delegates policy when no mechanism matches. Multiple redirect modifiers in the same record create a permerror.
Macros expand variables within mechanism arguments, enabling dynamic behavior. The "%{i}" macro expands to the sending IP, "%{s}" to the envelope sender, and "%{d}" to the sender domain. Example: "exists:%{i}._spf.%{d}" constructs a domain name incorporating the sending IP and checks whether that domain resolves. Macros are powerful but significantly increase complexity and debugging difficulty.
---
SPF is a foundational control against email spoofing, but its operational significance is frequently misunderstood in both directions: some teams treat SPF as sufficient protection, and others dismiss it as too limited to bother maintaining carefully. Both positions are wrong.
Without a published SPF record, or with a permissive "v=spf1 +all" record (which authorizes every IP on the internet), any server can pass SPF checks for that domain. This makes the domain trivially spoofable at the envelope layer. Phishing campaigns routinely target domains with no SPF record or weak SPF policy because these domains offer no friction to attackers constructing fraudulent email.
When SPF fails due to a permerror caused by exceeding the lookup limit, legitimate email from authorized platforms fails authentication. This produces two immediate business consequences: messages are rejected or marked as spam, reducing deliverability; and DMARC policies set to "reject" or "quarantine" will act on the SPF failure, causing operational disruptions that are often misattributed to other causes.
A concrete example of SPF-related delivery failure occurred when a mid-sized technology company onboarded a new HR platform for automated offer letters. The HR platform's sending domain was added via an "include" mechanism, pushing the total lookup count past 10. Candidates began reporting that offer letters were landing in spam or were not being received at all. The root cause took three days to identify because the failure appeared as a generic spam filtering issue, not a DNS configuration problem. Restoring deliverability required auditing the full lookup chain and flattening the record.
Common Misconceptions
First: SPF passing does not mean the email is legitimate. A legitimate SPF record for a domain used exclusively for phishing will pass SPF checks perfectly.
Second: SPF protects against spoofing the header From address visible to users. It does not. SPF checks the envelope sender, which is invisible to most email users. Without DMARC alignment requiring the envelope sender domain to match the header From domain, SPF provides no protection against the visible address that users actually read.
Third: once SPF is configured, it requires no maintenance. SPF records require active maintenance because third-party senders change their IP ranges, new sending services are onboarded, and old services are decommissioned. A record that was accurate at deployment may become inaccurate or exceed the lookup limit within months.
The most dangerous misconception is that SPF syntax errors are obvious. A record with 11 DNS lookups looks identical to one with 9 lookups when viewed in DNS. The permerror only manifests during mail flow, often silently degrading deliverability rather than creating obvious breakage. Organizations discover SPF syntax problems through DMARC reports, spam complaints, or customer reports of missing email, by which time business impact has already occurred.
---
The Cyber Defense Assurance (CDA) framework addresses SPF record syntax within the Secure Posture Hygiene (SPH) domain, treating it as a continuously maintained configuration artifact rather than a one-time deployment task. The Autonomous Posture Command (APC) methodology captures this precisely: "Your posture adapts. Your hygiene never sleeps."
SPF record management under APC is not a deployment event. It is an ongoing monitoring and enforcement function. CDA's approach applies three operational disciplines to SPF specifically:
Continuous DNS Monitoring: CDA positions automated DNS record monitoring as a baseline SPH control. Any change to an organization's SPF record, whether authorized or unauthorized, generates a posture event requiring acknowledgment. DNS hijacking and unauthorized record modification are documented attack vectors; SPF record integrity is therefore treated as a security control, not purely an email operations task.
Lookup Budget Governance: CDA establishes a lookup budget threshold, typically maintaining active lookups at seven or fewer, with automated alerts when the count approaches nine. This buffer accommodates temporary increases during platform transitions without triggering permerror conditions. When a new sending platform is onboarded, the APC process requires a lookup count audit before the include mechanism is added to production DNS.
Alignment Validation: CDA does not evaluate SPF in isolation. SPH controls require SPF to be evaluated in the context of DMARC alignment. A passing SPF result that does not align with the header From domain under a DMARC policy provides limited protective value. CDA's posture assessments score SPF implementation based on both technical validity (no syntax errors, no permerror conditions) and DMARC alignment status.
What CDA does differently: Most organizations treat email authentication as an IT operations function with a ticket-driven change process. CDA treats SPF record accuracy as a security posture indicator with the same operational cadence as patch status or certificate expiration monitoring. The practical difference is that SPF degradation (lookup count drift, unauthorized record changes, inclusion of deprecated mechanisms) is detected in hours, not discovered during an incident investigation.
---
---
---