An SPF record is a program evaluated through DNS, not a list that can grow without consequence. Each mechanism is considered in order until one matches, and several mechanisms can trigger additional DNS queries. The complete evaluation, including nested `include` records and a `redirect`, must stay within the protocol's limit. A record that looks short can exceed that limit because one vendor include expands into several more. When evaluation exceeds the limit, receivers return a permanent error instead of a useful authorization result.
RFC 7208 limits the number of terms that cause DNS queries to ten during one SPF check. The counted terms include `include`, `a`, `mx`, `ptr`, `exists`, and the `redirect` modifier, with recursive evaluation included in the total. Direct `ip4` and `ip6` mechanisms do not consume DNS-query terms. The deprecated `ptr` mechanism should not be added to new records. Separate safeguards also apply while expanding MX or PTR data, and receivers may limit repeated empty DNS results.
The only dependable way to keep SPF small is to control who may send with each envelope domain. Inventory every mail platform, server, device, and relay first. Record whether it uses the organizational domain, a subdomain, or a provider-managed bounce domain in MAIL FROM. If a service never uses your domain for the SMTP envelope, adding its include to your apex SPF record may provide no alignment benefit. If it signs with aligned DKIM, SPF can remain a secondary path rather than absorbing every provider IP.
Quick path: Use SPF Builder to draft the top-level record and review its direct lookup-causing terms. Then resolve every `include` and `redirect` recursively with an SPF evaluator before publishing. Use DMARC Builder to check how the envelope identity will align with the visible From domain.
Why SPF record design matters in practice
SPF authenticates the SMTP envelope identity, usually the domain found in Return-Path after delivery. It does not authenticate the visible From address by itself. DMARC supplies that connection by requiring the SPF-authenticated domain to align with the visible From domain. This is why a vendor can show `spf=pass` while DMARC still reports SPF misalignment: the vendor authorized its own bounce domain, not yours. Configure a branded return path when available, or rely on an aligned DKIM signature as the DMARC path.
Forwarding is another boundary. A forwarder connects from its own IP while preserving the original envelope domain in many common flows, so SPF can fail even though the original submission was authorized. Sender Rewriting Scheme can change that envelope identity, but the rewritten domain then belongs to the forwarder. An aligned DKIM signature that survives the forwarding modifications often provides the remaining DMARC pass. SPF policy should describe direct sending paths accurately rather than trying to authorize every intermediary on the internet.
- Visible record length is not the same thing as evaluation cost.
- Nested includes can create failures that the top-level record does not make obvious.
- Subdomains are often the cleanest way to keep authorization bounded.
- Documentation is part of SPF quality because the record must survive staff and vendor change.
How SPF record design works
Evaluation begins after `v=spf1` and proceeds left to right. A mechanism can have a qualifier: `+` for pass, `-` for fail, `~` for softfail, or `?` for neutral. The plus qualifier is the default. The `all` mechanism matches every remaining address and normally appears last. A typical policy authorizes known sources first, then ends with `-all` or `~all` according to the owner's rollout decision. Text after a matching mechanism does not change that result, so ordering matters.
`include` asks whether another domain's SPF policy would pass for the same IP. If it passes, the include matches; other outcomes have different handling, and evaluation may continue. `redirect` replaces the policy only when no earlier mechanism matched. `a` and `mx` derive authorized addresses from DNS, while `exists` performs a constructed existence check. These features are useful, but each adds dependencies and failure modes. Direct address mechanisms are cheaper to evaluate, though they create maintenance work when provider ranges change.
Macros can construct query names from the sender, domain, IP, or other evaluation values. They support advanced policies but make records difficult to reason about and can generate many distinct cache entries. Use them only when the mail architecture genuinely requires per-sender or per-tenant decisions and the operator understands the privacy and DNS-load effects. A plain include or dedicated subdomain is easier to audit in most deployments.
Where teams usually get it wrong
Publishing two SPF records at the same name is not a way to split a long policy. It produces a permanent error because the receiver cannot choose between them. Concatenate one policy across DNS character strings if the DNS provider requires it, but make sure resolvers return one logical TXT record beginning with `v=spf1`. General TXT verification records may coexist at the same name; the error is having more than one SPF policy, not having more than one TXT record of any kind.
Blind SPF flattening trades one problem for another. Replacing provider includes with copied IP ranges reduces query use, but the copy becomes stale when the provider changes its network. A managed flattener adds an external dependency and still needs monitoring. Use direct IP mechanisms when the addresses are contractually assigned and someone owns updates. For dynamic shared providers, a maintained include is often safer. Reduce the number of senders or separate them onto subdomains before copying data you cannot keep current.
A more reliable operating model
Give each include an owner, business purpose, source documentation link, date added, and retirement condition. Review the expanded lookup tree rather than just the visible top level. A provider can change its nested record without touching yours and push evaluation over the limit. Put marketing, transactional, support, and device mail on separate subdomains when different teams own them or when one stream needs an unusually complex provider chain. Segmentation reduces shared failure and makes DMARC reporting easier to classify.
A practical workflow
Collect delivered-message headers from every legitimate stream. The Return-Path and Authentication-Results fields show which domain SPF actually evaluated and whether it aligned for DMARC. Compare that evidence with the proposed authorization list. Remove providers that never use the domain in the envelope, and confirm whether devices or on-premises relays send directly or through a smarthost. Do not infer sending architecture from invoices or vendor names when a message trace can show the real path.
Build the smallest policy that covers those paths. Prefer exact `ip4` or `ip6` ranges for addresses the organization owns and maintains. Use provider includes only for services that send with the relevant envelope domain. Avoid `a` or `mx` as shortcuts unless the hosts named there genuinely send outbound mail and that coupling is intentional. The fact that a server receives mail or hosts a website does not mean it should be authorized to send.
Evaluate the full recursive tree against the ten-term limit and test representative authorized and unauthorized IPs. Check for DNS errors, loops, duplicate SPF policies, and unexpected macros. Then validate DMARC alignment with real messages. Move from `~all` to `-all` only when the inventory and tests support that choice. DMARC enforcement is a separate decision; `-all` does not by itself tell a receiver to reject visible-From spoofing when the SPF domain is unrelated.
Test failure behaviour as well as successful matches. A nonexistent include target, DNS timeout, or recursive loop can produce an error rather than simply falling through to the next mechanism. Check the policy from more than one recursive resolver and preserve the expanded tree with the change record. That snapshot makes it possible to explain a later failure caused by a provider dependency that changed outside your zone.
What good monitoring looks like
Re-evaluate SPF whenever a sender is added, removed, or changes its envelope setup. A scheduled check should expand nested dependencies and report total query-causing terms, permanent or temporary DNS errors, newly added networks, and records that no longer resolve. Keep the previous expansion for comparison. Because provider-managed includes can change without your TXT record changing, monitoring only the top-level string misses an important source of drift.
DMARC aggregate reports provide another signal. An expected sender showing SPF failure or misalignment may have changed its source range or bounce domain. An unknown source passing SPF deserves attention because the published policy may authorize more infrastructure than intended. Review DKIM at the same time before editing SPF; a stream with stable aligned DKIM may not need broader envelope authorization. Record the remediation against the sender owner so the same source is not rediscovered every week.
Where DomScan helps
DomScan's SPF Builder creates a record from selected mechanisms and reports the direct lookup-causing terms it added. That number is not a recursive SPF evaluation: a single provider include can expand into several more queries. Use the builder to avoid syntax mistakes and make the top-level policy readable, then validate the published record and every dependency with a full evaluator. DMARC and DKIM tools can show whether the sender has another aligned authentication path.
Independent references: Review RFC 7208 and Google Email Sender Guidelines for baseline details and neutral operational guidance.
A maintainable SPF policy is one record whose expanded dependencies stay within the limit, whose mechanisms map to active envelope senders, and whose owner can explain every authorization. If the only reason an include remains is that nobody knows what will break, the inventory is the problem to solve before the next provider is added.