A client says their campaign emails are landing in spam. Another has invoices rejected by a recipient’s mail gateway. The website is up, SSL is valid, and nobody changed the email platform - at least, not intentionally. This is where knowing how to validate SPF records moves from a DNS housekeeping task to a service-protection workflow.
SPF, or Sender Policy Framework, tells receiving mail servers which systems are allowed to send email for a domain. A valid-looking record is not necessarily a working one. It may authorise the wrong platform, exceed DNS lookup limits, use an overly permissive policy, or pass SPF while still failing DMARC alignment.
For agencies and teams responsible for multiple domains, the goal is not simply to find an SPF TXT record. It is to confirm that every legitimate sender is authorised, the policy can be evaluated reliably, and the domain’s wider email authentication setup behaves as intended.
What SPF validation actually checks
An SPF record lives in DNS as a TXT record and usually begins with `v=spf1`. It contains mechanisms that identify permitted sending sources, followed by a policy such as `-all` or `~all`.
A basic example might look like this:
`v=spf1 include:spf.protection.outlook.com -all`
That record authorises Microsoft 365 to send mail using the domain in the SMTP envelope sender, often shown as the Return-Path. The `-all` at the end tells receiving servers that every other sender should fail SPF.
Validation has three separate parts. First, confirm that DNS returns one valid SPF policy. Next, trace the policy and every included service to make sure it stays within SPF processing limits. Finally, test actual mail flows and check whether SPF passes and aligns with the visible From domain for DMARC.
Skipping the last step is a common mistake. SPF can pass for a third-party bounce domain while DMARC fails because the message’s visible From address belongs to the client’s domain.
How to validate SPF records step by step
1. Query the domain that actually sends mail
Start with a DNS lookup for the domain used in the envelope sender, not automatically the domain in the visible From field. In many cases they are the same, but mailing platforms, CRMs, ecommerce tools and ticketing systems often use separate return-path domains.
Use a DNS command-line tool or DNS inspection service to retrieve TXT records. You are looking for one record beginning with `v=spf1`. Multiple TXT records are normal, but there must only be one SPF record for a given hostname. Two separate records beginning with `v=spf1` produce an SPF PermError, which means receivers cannot reliably evaluate the policy.
Also check the exact hostname. A record at `example.co.uk` does not automatically cover `news.example.co.uk` or `mail.example.co.uk`. If those subdomains appear in envelope sender addresses, they need their own valid policy or a deliberate DNS arrangement that routes mail through an authorised identity.
2. Read the record as a sending inventory
Treat each mechanism as a statement about a service that can send on the client’s behalf. Common mechanisms include `ip4`, `ip6`, `a`, `mx` and `include`. A record may contain an IP range for an office system, an include for Microsoft 365, and another include for an email marketing provider.
The question is not whether the syntax looks familiar. Ask whether each entry maps to a sender the client still uses. Old CRM providers, former transactional email services and inherited hosting-server IPs are frequent sources of unnecessary authorisation.
An overly broad record creates a security and deliverability problem. If a client’s SPF policy allows a retired provider or a whole shared hosting range, it expands the places from which mail can appear legitimate. Remove obsolete senders only after confirming they are not used for password resets, contact forms, order notifications, support platforms or finance workflows.
The final qualifier deserves equal care. `-all` is a hard fail and is usually the right end state once all genuine senders are accounted for. `~all` is a soft fail and may be used during a controlled transition. `?all` provides no meaningful policy. Do not change `~all` to `-all` merely to make a report look cleaner - first validate every real sending path.
3. Count DNS lookups before receivers do
SPF has a hard evaluation limit of ten DNS-triggering lookups. Includes are the usual cause of trouble, especially where one vendor includes another service behind the scenes. The `a`, `mx`, `exists`, `ptr`, `redirect` and `include` mechanisms can all contribute to the lookup count.
This failure can be invisible until a receiving server evaluates the record. The sender may see a message accepted by its own platform, while the recipient records SPF PermError and applies a stricter spam policy. It is particularly easy to miss on a domain with several marketing, support and ecommerce integrations added over time.
Trace each include recursively rather than counting only the visible terms in the top-level record. A specialist SPF checker can show the lookup tree, but the result still needs human judgement. A technically compliant record may authorise services that should no longer be there, and a short record may fail to cover an important sender.
SPF flattening can reduce lookup pressure by replacing included domains with current IP ranges. It can help in specific cases, but it transfers maintenance to your team. Providers change sending infrastructure, and a flattened record can become stale without continuous checking. For most agency portfolios, reducing unnecessary providers and using supported vendor records is safer than treating flattening as a one-time fix.
4. Test real messages and DMARC alignment
Publish the corrected record, allow for DNS propagation, then send test messages through every major channel: mailbox provider, marketing platform, transactional service, website forms, helpdesk and any billing or ecommerce system.
Inspect the received message headers. Look for an authentication result showing `spf=pass`, then identify the domain assessed by SPF. Compare it with the visible From domain and the domain named in the DMARC result. Under relaxed DMARC alignment, the domains can share the same organisational domain. Under strict alignment, they must match exactly.
This matters most with third-party sending tools. A message can pass SPF for the provider’s return-path domain but fail alignment with `clientdomain.co.uk`. In that situation, configure a custom return-path or bounce domain through the provider, or rely on correctly aligned DKIM where appropriate. SPF and DKIM are separate authentication methods; DMARC can pass when either one passes and aligns.
5. Check the policy after changes, not just before them
Every new platform can alter the domain’s sending estate. A marketing team launching a new newsletter tool, a developer changing an ecommerce integration, or a client moving from one Microsoft tenant to another can all make yesterday’s SPF record incomplete.
Build SPF validation into change control. When a new sender is approved, record its purpose, envelope domain, SPF requirement, DKIM configuration and owner. When a platform is retired, remove its authorisation after a defined observation period. This creates a defensible inventory instead of a TXT record that nobody wants to touch.
Common SPF failures across client portfolios
The most damaging issues are often operational rather than technical. One client may have two SPF records after a rushed migration. Another may have a valid record at the root domain but send invoices from an unprotected subdomain. A third may be within the lookup limit today but tip over it when a vendor updates its own SPF dependencies.
Website contact forms deserve particular attention. If a form sends messages with a visitor’s address in the From field, SPF and DMARC failures are likely because the website server is not authorised to send for that visitor’s domain. Configure the form to send from an address on the client’s own domain, then place the visitor’s address in Reply-To instead.
The same principle applies to forwarding. Traditional forwarding can break SPF because the forwarding server is not authorised by the original sender’s domain. Modern forwarding practices can mitigate this, but it is not a reason to assume every forwarded message will authenticate cleanly.
Turn SPF into a monitored control
A one-off check is useful after a migration. Ongoing monitoring is what prevents a small DNS edit from becoming a client-facing deliverability incident weeks later. Monitor for record changes, duplicate SPF policies, lookup-limit failures and changes to associated DMARC results. Pair that with alerts that identify the affected domain and explain what needs attention, rather than asking an account manager to interpret raw DNS output.
For an agency handling a broad client portfolio, this is exactly the kind of control that benefits from centralisation. TLDTrack can sit alongside DNS, availability, SSL, security and deliverability checks, giving the team one operational view instead of a collection of separate reminders and browser tabs.
The practical standard is simple: every approved sender is authorised, every retired sender is removed, SPF evaluates within limits, and real messages authenticate in the way the client expects. Keep that standard visible, and email deliverability becomes a managed service rather than an urgent ticket after the damage is done.
