What is SPF record syntax, and how does it affect application email?

An SPF record is an ordered policy expression

RFC 7208 defines an SPF record as a DNS TXT string whose first term is v=spf1. The remaining space-separated terms are mechanisms, which can match, and modifiers, which change processing. Evaluation proceeds from left to right and stops at the first matching mechanism, so order expresses policy. A typical record might authorize two fixed address ranges, include one provider policy, then end with -all. Do not paste that pattern unchanged: the correct record depends on the exact SMTP MAIL FROM or HELO identities and real sending sources. Inventory application providers, mail servers, support tools, identity platforms, marketing systems, forwarding paths, and disaster-recovery senders first. Publish the policy at the domain being evaluated, not automatically at the visible From domain. One syntactically valid record can still authorize the wrong sources, omit a production stream, or exceed DNS evaluation limits.

Qualifiers map a mechanism match to an SPF result

A mechanism can start with a qualifier: + for pass, - for fail, ~ for softfail, or ? for neutral. If no qualifier appears, + is implied. The qualifier applies only when that mechanism matches. It does not change whether later terms are evaluated when the mechanism does not match. Teams often focus on the final all term, but every earlier include, address, a, mx, or exists mechanism also has a qualifier and can terminate evaluation. Use explicit review rather than assuming ~all means test mode or -all proves every source is known. A fail result is receiver evidence about the evaluated SMTP identity and IP, not a universal command to delete mail. Receivers apply local policy. Neutral and softfail are not authorization passes. Record the intended result for authorized, unauthorized, and temporarily unresolved sources and verify it with controlled IP and identity fixtures.

Address mechanisms are direct but require ownership

The ip4 and ip6 mechanisms authorize matching network ranges expressed with their protocol-specific syntax and optional prefix length. They avoid additional address lookup during evaluation, but they can become stale as egress networks change. Use public sending addresses, never private runtime addresses, and keep ranges as narrow as operational failover permits. Every range should have an owner, source system, environment, change procedure, and review date. The a mechanism resolves an A or AAAA name, defaulting to the current SPF domain unless another domain-spec is supplied. The mx mechanism resolves MX hosts and their addresses. Those mechanisms add DNS work and can authorize infrastructure that changes outside the application's release. Do not use a or mx as a shortcut unless all resolved addresses are intentionally permitted to send with that exact SMTP identity. Monitor changes and test both IPv4 and IPv6 paths.

Include evaluates another policy, not a text fragment

The include mechanism evaluates the referenced domain's SPF policy and matches when that nested evaluation returns pass. It does not paste terms mechanically into the current string, and other nested outcomes have defined effects. Use include only when the referenced organization explicitly documents that domain for your sending relationship. A provider's website domain, MX domain, or visible From domain is not automatically its SPF include. Includes create operational dependencies: a provider record change can alter authorization, add nested DNS lookups, or produce temporary and permanent errors. Record the vendor, service, exact include domain, contract source, owner, and removal plan. Test the resulting policy from the provider's actual sending IP and your envelope domain. Never flatten provider includes into copied IP lists unless you also accept ownership for tracking every provider address change and preserving the original semantics.

All, redirect, and explanation serve different roles

The all mechanism always matches and is normally placed last; terms after it cannot affect evaluation. Its qualifier determines the result for sources not matched earlier. The redirect modifier tells SPF to use another domain's policy when no mechanism in the current record matched. Redirect is not the same as include: include is one ordered mechanism, while redirect replaces the final policy decision under its defined conditions. A record should not contain multiple redirect modifiers. The exp modifier can reference an explanation for a fail result, but it does not authorize mail and creates additional operational and privacy considerations. Keep explanations generic and avoid sender or recipient data. Choose redirect when domains intentionally share an entire policy and have coordinated ownership. Choose include when adding one provider's authorized sources inside a broader local policy. Test unmatched paths, not only expected passes.

Avoid ptr and treat exists and macros as advanced

RFC 7208 says the ptr mechanism should not be used because it is slow, unreliable, and burdensome. Do not add ptr to make an unfamiliar IP pass. The exists mechanism can perform a DNS existence test using a domain-spec, and SPF macros can expand identity and connection components inside supported fields. These tools can express delegated or per-customer authorization but increase complexity, DNS work, privacy exposure, and failure modes. Macro syntax is not arbitrary string templating; only defined letters, transformers, delimiters, and contexts are valid. Never place full recipient addresses, secrets, or unbounded tenant input into DNS queries. If a simple set of owned IP ranges and documented provider includes can express the policy, prefer it. For advanced policies, build deterministic fixtures for multiple domains, senders, IP families, null reverse paths, macro escaping, NXDOMAIN, timeouts, and unexpected DNS answers before production.

Respect the ten-term DNS lookup limit

RFC 7208 limits SPF implementations to ten terms that cause DNS queries during one check, including relevant include, a, mx, ptr, exists, and redirect processing. Nested includes count. The specification also recommends limiting void lookups, where DNS returns an empty answer or name error, to two. Exceeding processing limits can produce a permanent error rather than a pass. Count the expanded evaluation graph, not just terms visible in the top-level TXT string. A single provider include can bring multiple nested dependencies, and an mx mechanism can trigger address lookups for multiple hosts. Use a standards-aware evaluator with captured DNS fixtures, but also inspect the dependency tree yourself. Remove unused providers and redundant mechanisms. Avoid unsafe flattening that silently loses provider updates. Monitor policy changes and leave lookup headroom for provider evolution rather than deploying exactly at the maximum.

Publish exactly one SPF policy for a domain

RFC 7208 uses DNS TXT records for SPF and requires selection of the record beginning with v=spf1. Multiple SPF records for the same exact owner name cause a permanent error rather than combining authorization. Modify the existing policy under coordinated ownership; do not add a second TXT record because another application needs access. Other unrelated TXT records at the name can coexist, but only one selected SPF policy should exist. Confirm the DNS control plane's quoting and string-splitting behavior, query authoritative servers, then query independent recursive resolvers. Preserve the previous value and TTL for rollback. DNS propagation is not instantaneous, and negative caches can persist. A dashboard green check proves only its observed query and parser behavior. Verify the exact production envelope domain from raw received headers and provider logs, including subdomains and bounce addresses that may publish separate policies.

Connect SPF syntax to DMARC without conflating them

SPF normally evaluates the MAIL FROM domain or HELO identity under protocol rules. DMARC uses the visible RFC 5322 From domain and accepts SPF as one path only when the authenticated SPF domain aligns with that visible domain. A provider return-path can therefore pass SPF while remaining unaligned for DMARC. Conversely, an aligned DKIM pass can satisfy DMARC when SPF fails or is unaligned. Record SPF result, evaluated domain, connecting IP, visible From, DKIM results, alignment, and DMARC outcome separately. Forwarding commonly changes the connecting IP and can break SPF even when the original sender was authorized. Do not widen SPF to include arbitrary forwarders. Use DKIM and, where appropriate, authenticated-chain mechanisms and receiver evidence. An SPF pass does not prove message integrity, content safety, recipient consent, server acceptance, or inbox placement.

Validate changes with a deterministic workflow

Before editing DNS, export the current record and enumerate each mechanism or modifier with its owner and purpose. Parse the candidate under RFC 7208 grammar, expand DNS dependencies from controlled snapshots, count lookup-causing terms, and test authorized and unauthorized IPv4 and IPv6 fixtures. Check nested include pass, fail, neutral, softfail, temporary error, and permanent error behavior. Test null reverse-path handling through HELO, subdomains, provider return paths, and a source that should fall through to all. Publish through normal change controls, query authoritative and recursive DNS, then send controlled messages through every real stream. Preserve raw Authentication-Results from trusted receivers and compare them with expected identities. Roll back on missing production sources, multiple-record selection, lookup-limit errors, widespread temperror, or unintended authorization. Never test by sending unsolicited mail.

Set up SPF with SendHQ

SendHQ provisions an SPF TXT policy as part of sender-identity setup. It stops setup on conflicting SPF policies and reports a recommended merged SPF value rather than silently overwriting an unrelated policy. Keep exactly one selectable SPF policy; consult the Domains and DNS documentation for setup and repair details.

Frequently asked questions

Sources

• RFC 7208: Sender Policy Framework — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor