SPF answers a specific question: is the connecting host authorised to use the SMTP identity being evaluated? It does not directly authenticate the friendly From address shown in a mail client. That is why a message can pass SPF and still fail DMARC alignment.
A useful SPF review starts with a real message and the domain evaluated by the receiver. Then it follows the policy's mechanisms, dependent DNS lookups and matching path. Counting provider names in a control panel is not enough to predict the result.
Find the domain SPF actually evaluated
For ordinary messages, SPF commonly evaluates the envelope sender domain supplied in SMTP MAIL FROM. For a null reverse path, the HELO identity has a defined role. The visible From header belongs to a different message layer and must not be substituted casually.
The SPF policy analyzer reviews a supplied record's syntax and mechanisms. It does not reproduce every live DNS lookup for a particular delivery. Pair it with the receiver's Authentication-Results and the DNS explorer when investigating a real failure.
Record the connecting IP and evaluated domain from trusted receiving evidence. A provider can use its own bounce domain even when the visible From uses your brand. Editing your brand domain's SPF policy will not necessarily affect a check performed against that provider domain.
Read mechanisms in evaluation order
An SPF policy begins with v=spf1 and contains mechanisms and modifiers. Mechanisms can authorise explicit IP ranges, address records, mail exchanger hosts or another policy through include. Their order matters because evaluation can stop at the first matching mechanism.
Qualifiers describe the result of a match. The familiar all mechanism matches everything that reaches it, so placing authorising mechanisms after all does not make them useful. Review policy order as logic, not merely as a list of approved services.
v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -allThis documentation example checks the explicit IPv4 range, then the included policy, and reaches a fail result if neither authorises the sender. The example domains and addresses are reserved illustrations. Replace them only with sources established by your actual sending architecture.
| Term | Purpose | Review question |
|---|---|---|
| ip4 or ip6 | Match an explicit address range | Is the range necessary and correctly bounded? |
| include | Use another policy's passing result | What dependent lookups can it trigger? |
| a | Use address records for a name | Should website hosts also send mail? |
| mx | Use addresses of mail exchanger hosts | Are inbound servers also outbound senders? |
| redirect | Use another policy when applicable | Is it reachable under the current mechanisms? |
| all | Match any remaining sender | Does its qualifier express the intended result? |
Count DNS-causing evaluation, including dependencies
SPF limits DNS-causing terms during evaluation. The commonly cited ten-term limit applies to mechanisms and modifiers such as include, a, mx, ptr, exists and redirect as specified by the protocol. Nested includes count toward the evaluation, not just the terms visible in the top-level record.
An explicit ip4 or ip6 mechanism does not itself require that kind of DNS lookup. But replacing all provider includes with copied address ranges is not automatically a good solution. Provider infrastructure changes, and a stale flattened policy can reject legitimate senders or retain obsolete ones.
The number of actual DNS packets is not identical to the protocol's term accounting. Caches, MX expansion and additional limits complicate the relationship. Label a text-only parser's count as a preliminary estimate and investigate the live dependency path before declaring the policy within budget.
Void lookups and MX-related expansion have additional rules. A policy can be problematic even when a superficial count appears below ten. Use a standards-aware evaluator with the relevant sender input when you need to reproduce an exact result.
Understand what include means
An include mechanism matches when evaluation of the referenced policy produces the required passing result. It is not a simple text insertion, and error outcomes matter. A missing or broken included policy can therefore affect your domain even when your own record has not changed.
Inventory every include and its owner. If a provider is retired, remove its authorisation after confirming that no active stream still relies on it. Keeping unused includes increases both the trust surface and the chance that a provider-side change affects your policy.
A provider may offer a more specific include for the product you use. Follow its current instructions rather than adding several broad includes from unrelated services. Document the reason for each term so the next administrator can distinguish necessary authorisation from historical residue.
Review a policy that fails only for one provider
Suppose a policy contains several includes, and messages from the first provider pass while a later provider receives permerror. Evaluation can stop early for the first provider, but the later path may traverse more DNS-causing terms and exceed a limit. A successful sample does not prove every path is valid.
Collect one passing and one failing message, including connecting IP and evaluated identity. Trace the mechanisms in order for each. Record which dependencies are visited and where the outcome changes. This gives a concrete reason to simplify the policy rather than randomly moving terms around.
Remove obsolete senders, split legitimately separate mail streams onto appropriate subdomains if the architecture supports it, and use provider-supported configurations. Then test every stream again. Moving a mechanism earlier can hide one failure while leaving the overall policy fragile.
Check DMARC alignment separately
After SPF passes, compare its authenticated domain with the visible From domain under the applicable DMARC alignment mode. Relaxed alignment uses the organisational-domain relationship defined by DMARC processing; strict alignment requires the relevant exact domain match.
Do not attempt to fix alignment by adding the visible From domain as an arbitrary include. Includes authorise sending hosts through SPF policy evaluation; they do not change the message's envelope identity. Configure the provider's supported custom return path or use aligned DKIM where appropriate.
Forwarding can change the connecting host and break SPF even for an originally legitimate message. That is one reason to audit aligned DKIM as another authentication path. A broad SPF authorisation for every possible forwarder is neither practical nor an appropriate response.
Publish one coherent policy and verify it
Multiple TXT records can exist at a domain, but multiple competing SPF policies at the same owner name cause a problem. Combine the intended policy correctly rather than adding a second v=spf1 record for each new provider. DNS providers may split one long TXT value into character strings; that is different from publishing multiple policies.
After editing, query the authoritative record and a representative recursive resolver. Check quotes and string concatenation as returned by DNS tooling. A control panel's visual line wrapping is not necessarily part of the value, while an accidental extra policy is a real configuration change.
Keep the previous record and a list of tested message streams. Monitor after deployment because some caches retain the old policy until its TTL expires. Confirm that scheduled and low-volume senders still work, not only the high-volume stream used during the change window.
Frequently asked questions
Does SPF protect the visible From address?
SPF authenticates an SMTP identity against the connecting host. DMARC connects an aligned passing result to the visible From domain. Read both the SPF result and the evaluated domain before concluding that a message's displayed sender was authenticated.
Is ten includes always safe?
No. Includes can trigger nested DNS-causing terms, and other mechanisms contribute to the budget. Evaluation paths and additional protocol limits also matter. Count the live dependency path for representative senders rather than treating the top-level number of include strings as the complete calculation.
Should I replace includes with IP addresses?
Only with a maintained, justified design. Copying current provider addresses can become stale when infrastructure changes. Prefer provider-supported policy forms, remove unused dependencies and monitor the result. Any flattening process needs ownership, refresh logic and tests for missing or obsolete ranges.
What is the difference between softfail and fail?
They express different SPF outcomes through mechanism qualifiers. Receiving systems decide how to use those outcomes alongside other evidence. Neither outcome by itself guarantees a particular delivery action. Choose policy deliberately and verify DMARC behaviour for the actual message streams.
Can I publish a separate SPF record for each vendor?
Not as multiple competing policies at the same domain name. Build one valid policy for that identity, or use separate envelope subdomains where the sending architecture supports them. Confirm the provider actually uses the domain whose policy you are changing.
Why does mail still pass after I remove a sender?
A resolver may retain the earlier policy, another mechanism may still authorise the IP, or the observed pass may belong to DKIM or another identity. Inspect the exact result and current evaluation path. Removing one include does not prove every possible authorisation was removed.
What should a final SPF audit record contain?
Keep the policy, dependency owners, evaluated identities, representative sender IPs and observed receiver results. Include the change time and known cache window. This makes the audit repeatable when a provider changes infrastructure or a forgotten application starts failing months later.