2 syntactically usable
All tools
SPF / RFC 7208 / ORDERED POLICY / DNSBuild the policy.
Build the policy.
Keep the evidence.
Compose one ordered SPF record, see every qualifier and lookup-bearing term, and leave with a deployment plan—not a mystery string.
- Exact term ledger
- Static lookup floor
- Local generation
GENERATED DNS RECORD
Coherent candidate—verify it against live DNS.
RFC 7208
LOGICAL VALUE53 characters · 53 UTF-8 bytes
v=spf1 include:_spf.google.com ip4:192.0.2.64/28 ~allZONE-FILE HANDOFF1 quoted character-string; DNS joins them without spaces
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ip4:192.0.2.64/28 ~all"Generated syntax is not authorization evidence.
Confirm the real SMTP MAIL FROM and HELO identities, verify every provider target in current documentation, publish one SPF record, then trace the live policy.
nested cost remains unknown
1 DNS string
operator attestations complete
ORDERED TERM LEDGER
Read the policy the way a receiver starts to.
include:_spf.google.comAuthorize a match. The plus sign is normally omitted.
+1 DNSGoogle Workspace
ip4:192.0.2.64/28Authorize a match. The plus sign is normally omitted.
STATICApplication relay
~allTerminal unmatched result
ALWAYS MATCHESAn unmatched client produces SPF softfail.
PRE-PUBLISH REVIEW
No blocking syntax issue found.
Nested lookup cost is unresolved
The visible policy contributes a floor of 1. Includes or redirect can consume additional terms during live evaluation.
Deployment evidence is incomplete
5 readiness attestations remain unchecked.
Candidate syntax is coherent
Publication safety still depends on current provider data, complete source inventory, one live SPF record, and representative message tests.
LOOKUP BUDGET
A floor, not a fabricated final count.
1/10 direct terms
RFC 7208 limits terms that cause DNS queries during one evaluation. Each include, a, mx, exists, and redirect shown here contributes at least one direct term. Includes and redirects can add nested terms, while void lookups and address-record limits need live DNS evidence.
Trace the candidate after publicationDEPLOYMENT EVIDENCE
0/5 checks recorded.
CHANGE HANDOFF
Export the exact inputs, ordered terms, assumptions, findings, and deployment evidence.
THE IDENTITY BOUNDARY
SPF authorizes an SMTP identity—not the visible From address.
SPF evaluates the client IP against a policy for the SMTP MAIL FROM domain, or the HELO identity in defined cases. DMARC can use an SPF pass only when that authenticated domain aligns with the visible From domain. Inventorying only what subscribers see is therefore incomplete.
Connecting IP
SPF policy domain
DMARC alignment
EVALUATION MODEL
Mechanisms are ordered instructions.
A receiver evaluates mechanisms left to right and stops at the first match. A qualifier controls the result of that match: pass, fail, softfail, or neutral. The terminal all mechanism always matches. Keeping broad or negative mechanisms ahead of specific authorizations can change policy meaning even when every term is syntactically valid.
+PassAuthorize a match. The plus sign is normally omitted.
-FailA match produces SPF fail.
~SoftfailA match produces SPF softfail.
?NeutralA match produces SPF neutral.
RESOURCE LIMITS
Count the path a receiver follows, not the number of visible includes.
The lookup-bearing terms are include, a, mx, ptr, exists, and redirect. RFC 7208 caps them at ten during an evaluation and separately constrains void lookups and address records. Nested include and redirect policies matter, so a generator can report a direct floor but cannot honestly promise a final total without resolving DNS.
ip4 / ip6Static address or rangeNo DNS term
includeEvaluate another SPF policyNested cost
a / mxResolve address-bearing DNS dataDNS term
existsResolve a constructed domainDNS term
CHANGE CONTROL
Treat SPF as a maintained dependency graph.
- 01Inventory
Map applications, providers, relays, return-path domains, HELO names, owners, and expected retirement dates.
- 02Verify
Confirm provider include targets in current provider documentation. Do not copy an unrelated customer’s record.
- 03Stage
Keep one SPF record, allow for DNS caching, and preserve old authorization while legitimate in-flight mail can still be evaluated.
- 04Trace
Resolve the published policy recursively, send representative mail, and inspect Authentication-Results and DMARC aggregate evidence.
- 05Own
Assign review dates and remove retired sources so authorization does not expand forever.
COMMON QUESTIONS
Can I publish more than one SPF record?+
No. Selection of multiple SPF records for the same owner name produces a permanent error. Merge authorized sources into one policy.
Is ~all automatically safer than -all?+
It is less definitive, but safety depends on source coverage and rollout evidence. A complete inventory and representative testing matter more than choosing a symbol by habit.
Why is the lookup number only a floor?+
The visible record does not reveal the nested policies behind include or redirect, nor the exact live DNS outcomes. Use the SPF checker after publication.
Should I flatten provider includes into IP addresses?+
Flattening trades live provider indirection for a snapshot you must keep synchronized. Use it only with an explicit refresh and monitoring system, not as a one-time copy operation.
Do subdomains inherit the parent SPF record?+
No. Publish policy at every MAIL FROM or HELO domain that needs one, or deliberately use a redirect architecture.
PRIMARY REFERENCE