# SPF record syntax explained: mechanisms and qualifiers > Every SPF mechanism and qualifier in evaluation order: what -all and ~all really do, include versus redirect, and the 10-lookup limit that voids a record. An SPF record is a DNS TXT value that starts with `v=spf1`, then lists space-separated mechanisms that authorize or reject sending IP addresses. A mechanism can have a qualifier, such as `-all`, that determines the SPF result when it matches. Start with [what SPF is and which identity it checks](/learning/what-is-spf) if you need the protocol context; under [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html), the record is evaluated for the SMTP MAIL FROM or HELO identity, not the visible From address. ## Quick takeaways - An SPF record begins with the version token `v=spf1`. - Mechanisms are evaluated left to right until one produces a match. - A missing qualifier means `+`, which produces an SPF Pass when the mechanism matches. - `include` evaluates another domain's SPF policy as part of the current record, while `redirect` delegates evaluation only when no mechanism matched. - SPF evaluation has a limit of ten DNS-querying terms, including relevant `include` and `redirect` terms. - SPF authorizes the SMTP MAIL FROM or HELO identity, which can differ from the address a recipient sees in the From header. ## Who is affected? This syntax applies to domain owners who publish SPF records and to receivers that evaluate SMTP senders under [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html), an IETF Standards Track RFC published in April 2014 that obsoletes RFC 4408. It matters whenever a domain appears in the SMTP `MAIL FROM` command or in the sending server's `HELO` or `EHLO` command. The relevant record is published at the exact SPF identity being evaluated. For most outbound mail, that is the domain in the SMTP MAIL FROM address. A receiver can also evaluate the HELO identity. RFC 7208 recommends checking HELO separately and requires a receiver to check MAIL FROM when the HELO check was not performed or did not reach a definitive policy result. The visible From address is a different identifier. SPF does not authenticate it directly. That distinction is central to [DMARC alignment](https://www.rfc-editor.org/rfc/rfc9989.html), which compares authenticated identifiers with the visible From domain. A domain that does not send mail may publish a restrictive policy, but do not add [`-all`](/learning/glossary/spf-all-qualifier) until every legitimate source that uses the applicable MAIL FROM or HELO domain is known. An omitted sender can cause SPF Fail for its mail. ## What are the requirements? ### The record starts with an SPF version and uses one TXT record RFC 7208 defines SPF version 1 records as DNS TXT records beginning with `v=spf1`. The rest of the record contains terms separated by spaces. A domain must not publish multiple SPF records that claim to be SPF version 1 records. A receiver that finds multiple records returns Permerror. ```text v=spf1 ip4:192.0.2.0/24 include:spf.sender.example -all ``` This is illustrative only. Replace the example IP range and included domain with values generated or documented for your own authorized senders. Do not copy another organization's SPF record. ![SPF record anatomy showing the version token, mechanisms, qualifier, include term, and all mechanism](/images/editorial/spf-record-syntax-explained-mechanisms-qualifiers/spf-record-syntax-explained-mechanisms-qualifiers-record-anatomy.webp "1200x600") *Source: Palisade.* This article focuses on the grammar and evaluation behavior of the record itself. ### Mechanisms test the connecting sender An SPF mechanism tests the SMTP client IP address or evaluates another SPF policy. RFC 7208 defines these mechanisms: - `all` matches every sender. It normally appears at the end because terms after `all` cannot be reached. - [`include:`](/learning/glossary/spf-include) evaluates the named domain's SPF record. - `a` tests addresses returned for a domain's A or AAAA records. - `mx` tests addresses associated with a domain's MX hosts. See [what the SPF MX mechanism does](/learning/glossary/spf-mx-mechanism) for its narrower behavior. - `ip4:` and `ip6:` test a literal IPv4 or IPv6 address range. - `exists:` performs a DNS lookup whose result determines whether the mechanism matches. - `ptr` uses reverse-DNS processing. RFC 7208 says it is not recommended and publishers should not use it. Mechanisms are evaluated in order. The first mechanism that matches determines the result through its qualifier. This makes order operationally significant: a broad `ip4` range placed before a narrow exception can match first. ### Qualifiers set the result of a match A qualifier is one character immediately before a mechanism. If no qualifier appears, the default is `+`. ```text +ip4:192.0.2.10 -ip4:198.51.100.10 ~all ?all ``` This is illustrative only. These addresses are documentation ranges, not sending infrastructure. RFC 7208 defines four qualifiers: - `+` produces Pass when the mechanism matches. - `-` produces Fail when the mechanism matches. - `~` produces Softfail when the mechanism matches. - `?` produces Neutral when the mechanism matches. The qualifier changes the SPF evaluation result. It does not independently instruct every receiver to reject, accept, or place a message in the inbox. RFC 7208 leaves handling of SPF results to receiver policy. The `all` mechanism is often used as the final term because it always matches. [The SPF `all` mechanism guide](/learning/spf-all-mechanism) explains why `-all`, `~all`, and `?all` communicate different policy results. ### Include and redirect have different jobs `include:` is a mechanism inside the current record. The included domain is evaluated using the original SMTP client IP address. If that evaluation returns Pass, the `include` mechanism matches and its qualifier controls the result. If the included policy returns Fail, Softfail, or Neutral, `include` does not match and evaluation continues. Temperror and Permerror are returned as errors. `redirect=` is a modifier, not a mechanism. It is used only when no mechanism matched. It delegates the final evaluation to the named domain's SPF record. A record cannot contain more than one `redirect` modifier, and a `redirect` is ignored when a mechanism already matched. ```text v=spf1 include:spf.sender.example -all v=spf1 ip4:192.0.2.10 redirect=spf.policy.example ``` These examples are illustrative only. An `include` lets the current record continue evaluating after a non-Pass result from the included policy. A `redirect` hands off only after the current record has no match. Do not replace one with the other without tracing the expected result for each authorized sender. The `exp` modifier is also defined by RFC 7208. It supplies an explanation string for an SPF Fail result. It does not authorize a sender and it does not change the result. ### DNS-querying terms have a ten-term limit RFC 7208 requires SPF evaluators to limit processing to ten DNS-querying terms during an SPF check. The applicable mechanisms are `include`, `a`, `mx`, `ptr`, and `exists`, plus the `redirect` modifier. Each time one of these terms causes DNS queries, it counts toward the evaluation budget. Literal `ip4`, `ip6`, and `all` terms do not perform DNS lookups. However, an apparently short record can still exceed the limit when an `include` expands into more DNS-querying terms. > Treat the ten-query limit as an evaluation limit, not a count of visible `include` tokens. Adding a sender's include can break SPF for every source that reaches that part of the record. ![SPF evaluation flow showing ordered mechanisms, include expansion, redirect fallback, and the ten-query limit](/images/editorial/spf-record-syntax-explained-mechanisms-qualifiers/spf-record-syntax-explained-mechanisms-qualifiers-evaluation-flow.webp "1200x676") *Source: Palisade.* ## When does the requirement take effect? RFC 7208 was published in April 2014 as the current Standards Track specification for SPF version 1 and obsoleted RFC 4408. It does not set a future enforcement date or require every domain to publish SPF. Its syntax and processing limits apply when a receiver chooses to perform an SPF version 1 evaluation. Receiver handling of Pass, Fail, Softfail, and other results remains local policy. A receiver can use SPF with other authentication signals, but SPF syntax alone does not determine delivery. RFC 8601, published in May 2019, defines the `Authentication-Results` header field used to record authentication outcomes. It supersedes RFC 7601. When present, an SPF result can identify the authenticated SMTP identity with properties such as `smtp.mailfrom` or `smtp.helo`. ## How do I implement the requirement? ### 1. Identify the SMTP identities your sources use Inventory each legitimate sending service and determine its actual MAIL FROM domain and HELO identity. Do not infer the SPF identity from the visible From address. If an ESP sends with a provider-owned MAIL FROM domain, its SPF result may apply to that provider domain rather than yours. Check the service's documented sending-domain configuration before adding an SPF term. ### 2. Publish one `v=spf1` TXT record at the right domain Publish one SPF version 1 TXT record at each domain that needs a policy. Confirm the record exists at the precise MAIL FROM or HELO domain used by the sender. Keep the record as one logical SPF policy even if DNS tooling displays long TXT data in multiple quoted strings. Multiple strings within one TXT record are permitted. Multiple SPF version 1 records are not. ### 3. Put specific authorization before the final policy Place literal IP ranges and service-provided include terms before `all`. Use only mechanisms that match a known sending path. Start with terms that authorize real sources. Then select the final `all` qualifier that reflects the policy you can support. `-all` makes a definitive authorization statement, so it requires a complete sender inventory. ### 4. Trace include and redirect paths Follow every include path and count DNS-querying terms across the possible evaluation path. Check the service's current documentation before changing an include value. Use `redirect` only when the intent is to use another domain's SPF policy as the fallback after no local mechanism matches. It is not a general replacement for an include. ### 5. Recheck changes before publishing a restrictive policy Compare the proposed record with the sending sources that use the domain. Send test messages through each production path after DNS propagation. A DNS syntax check is useful, but it cannot reveal a sender that was omitted from the inventory or prove how a specific receiver will apply its local policy. ## How do I validate compliance? First, inspect authoritative DNS and at least one public resolver for one SPF TXT record that begins with `v=spf1`. Confirm that it is published at the exact SMTP identity, not only at the organizational domain. Next, trace every applicable evaluation path and count DNS-querying terms. The [Palisade SPF checker](/tools/spf) can inspect a published SPF record and help identify syntax and lookup-budget issues. A public lookup cannot prove the production sending path, continuous DNS state, a receiver's private decision, or future message placement. Then send a real message from each authorized production source and inspect its delivered headers. RFC 8601 defines how a receiver can record SPF results in `Authentication-Results`, including `smtp.mailfrom` and `smtp.helo` properties. Confirm that the property identifies the expected SMTP domain and that the evaluated result matches the intended sender. Finally, review DMARC aggregate reports after data accumulates. SPF Pass alone does not establish DMARC alignment. Aggregate-report evidence can show whether the SPF-authenticated domain aligns with the visible From domain for real traffic. ## Check the SPF record before you change its policy Use the [SPF checker](/tools/spf) to inspect the record published for the domain that appears in the SMTP MAIL FROM or HELO identity. Compare its syntax and lookup path with a delivered message's `Authentication-Results` header before adding an include or changing the final `all` policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=spf-record-syntax-explained-mechanisms-qualifiers) For an IT team or MSP, [Palisade's DMARC Agent](https://docs.palisade.email/) can analyze DMARC aggregate-report evidence and prepare remediation work for human review after data accumulates. It does not change an SPF record automatically, discover every sender, prove every future message will authenticate, or guarantee a receiver delivery decision. ## Sources and further reading - [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) ## Frequently asked questions ### What is the correct first term in an SPF record? The correct first term is `v=spf1`. It identifies the TXT value as an SPF version 1 record under RFC 7208. ### Does SPF check the visible From address? No. SPF evaluates the SMTP MAIL FROM identity or the SMTP HELO identity. The visible From address is relevant to DMARC alignment, not the SPF identity by itself. ### What does `-all` mean in an SPF record? `-all` means every sender that reaches that final mechanism receives an SPF Fail result. It is appropriate only when every legitimate sender for the evaluated domain has already matched an earlier authorization term. ### Is `include` the same as `redirect` in SPF? No. `include` is a mechanism that matches only when the included policy returns Pass. `redirect` is a modifier that delegates evaluation only if no mechanism in the current record matched. ### How many DNS lookups can an SPF record use? RFC 7208 limits SPF evaluation to ten DNS-querying terms. The limit includes applicable `include`, `a`, `mx`, `ptr`, `exists`, and `redirect` terms across the evaluation path. ### Does a passing SPF result guarantee delivery? No. SPF Pass means the evaluated SMTP client was authorized for the checked SPF identity. Each receiver applies its own delivery policy and can consider other authentication, reputation, and message signals.