SPF failures are usually not fixed by adding another TXT record. Start with the published DNS answer, identify every service that sends mail for the domain, then publish one completev=spf1 policy. Finally, check the DNS lookup budget before changing a hard-fail policy. This order avoids the two common outages: authorizing nobody, and authorizing only one of several real senders.

Short answer: query the exact domain for TXT, retain exactly one SPF version record, enumerate all sending systems, and keep SPF's evaluation budget at ten DNS-causing lookups or fewer. A record such as v=spf1 ip4:192.0.2.44 include:_spf.example-mail.test -allis a policy; it is not a generic deliverability setting to copy unchanged.

Separate DNS symptoms from SPF symptoms

DNS answers explain what is published; SPF evaluation explains whether an SMTP client is authorized. An empty TXT response can be a wrong hostname, an unpublished change, or a resolver cache. An SPF permerror can instead result from multiple SPF records or too many lookups even when DNS itself works normally. Record the exact queried name, record type, response status, TTL, and answer before editing anything.

Inspect a TXT recordBuild an SPF policy

Worked example: one domain, two valid senders

Example Corp uses a documentation-only application host at 192.0.2.44 and a newsletter provider whose published authorization is include:_spf.example-mail.test. Its intended policy is:

v=spf1 ip4:192.0.2.44 include:_spf.example-mail.test -all

This permits the application host directly and delegates the provider's addresses to its own SPF record. The final -all is appropriate only after both senders are tested. It does not make SPF an instruction to reject mail by itself: receivers combine SPF with their local policy and often with DKIM and DMARC results.

Publish one SPF record, not one per sender

The following pair is invalid for SPF evaluation because the same domain has more than one record beginning with v=spf1:

v=spf1 ip4:192.0.2.44 -all
v=spf1 include:_spf.example-mail.test -all

Combine the mechanisms in a single record instead. Other TXT records, such as domain verification or DMARC records at _dmarc.example.com, are not SPF records merely because they use TXT. Keep each protocol at its required owner name.

Count the DNS lookup budget before publishing

SPF limits an evaluation to ten DNS-querying mechanisms or modifiers. include,a, mx, ptr (discouraged), exists,redirect, and some nested policies can consume the budget; ip4 andip6 do not. A provider's include may itself include more providers, so count the expanded evaluation path rather than only the mechanisms visible in the top-level string.

  1. List every application, help desk, relay, and marketing platform that sends as the domain.
  2. Prefer a provider's documented single include over manually copied IP ranges.
  3. Remove retired senders and duplicate includes.
  4. Test representative mail after publishing and inspect the receiver's authentication results.

DNS troubleshooting checklist

  • Query TXT at the envelope sender's domain, not automatically at the visible From domain.
  • Confirm the answer is authoritative or wait for the recorded TTL before treating a cached answer as a failed deployment.
  • Check that DNS-provider quoting and record splitting produce one logical TXT value.
  • Use one SPF version record and one final all mechanism.
  • Roll out -all only when every legitimate sender has evidence of passing SPF.

Primary sources

  • RFC 7208 defines SPF record selection, evaluation, and limits.
  • RFC 1035 defines DNS resource-record concepts.
  • RFC 7489 explains how DMARC uses SPF alignment.