Email authentication

Fix SPF errors without authorizing the wrong senders

Diagnose duplicate SPF policies, lookup limits, envelope mismatches and forwarding using real message evidence.

Prepared with AI assistance. Read our editorial and corrections policy.

SPF failures are not all the same. A syntax error needs a different fix from an unauthorized sending IP, and a passing policy for the wrong identity will not repair DMARC alignment. Begin with a received test message and the recipient's authentication result rather than changing the record until an online checker turns green.

Find the domain actually evaluated

Inspect the trusted receiver's Authentication-Results and Return-Path information. SPF usually evaluates the SMTP envelope sender domain. A provider may use its own bounce domain even when your address appears in the visible From header. Publishing extra authorization at your From domain has no effect on an SPF check of a different envelope domain.

For a custom return-path service, use the provider's documented setup. It may require a dedicated subdomain and particular DNS records. Do not assume that an arbitrary CNAME or a broad authorization at the apex enables a custom bounce identity.

Eliminate duplicate policies carefully

Query TXT records at the evaluated domain and identify those starting with v=spf1. More than one SPF policy at the same name produces a policy error. Merge the approved mechanisms into one policy after inventorying all legitimate senders. Do not delete unrelated TXT records such as ownership-verification tokens.

dig example.com TXT
dig bounce.example.com TXT

A long TXT record can be represented as multiple quoted strings within one DNS resource record; the strings are concatenated for SPF evaluation. Multiple strings inside one record are different from two separate SPF records. Check how your provider's editor stores the data instead of judging only the appearance of quotation marks.

Count evaluated DNS lookups

SPF limits the number of DNS-querying terms evaluated during a check to ten. Mechanisms such as include, a, mx, exists and redirect can consume this budget; nested included policies matter too. The count is not simply the number of visible includes in your top-level record. Terms that are never reached on a particular evaluation path do not behave like evaluated terms.

When a legitimate sending path exceeds the limit, inventory unused services and remove authorization only when it is no longer needed. Ask the sending provider for a supported efficient policy. Consider separate envelope subdomains for distinct sending systems where they support that setup. Avoid manually flattening a provider's addresses unless you can maintain updates reliably; stale flattened addresses can stop legitimate mail or authorize former infrastructure.

Treat each result differently

SPF results and next checks
ResultNext action
passCheck DMARC alignment separately.
fail / softfailVerify the connecting IP and legitimate sending service.
permerrorInspect syntax, duplicate policies and lookup limits.
temperrorInvestigate transient DNS failures; avoid blind policy edits.
noneCheck the evaluated identity and whether a policy exists there.

Do not add +all as a troubleshooting shortcut. It authorizes every source and removes the intended restriction. Likewise, moving immediately to -all before inventorying senders can expose legitimate streams to policy failures. Choose the final qualifier deliberately with evidence and the sending service's guidance.

Recognize forwarding and delivery boundaries

A forwarder usually connects from a different IP than the original sender, so SPF can fail after forwarding. Some forwarders rewrite the envelope sender; others do not. An aligned surviving DKIM signature can allow DMARC to pass even when SPF fails. Evaluate the complete authentication picture before authorizing an unknown forwarder.

SPF also does not prove a subscriber requested mail or that the content is safe. Complaint rates, reputation, recipient engagement and local filtering remain separate. After a repair, send controlled tests from each authorized system, retain redacted headers and monitor the next normal sending cycle.

Read the authentication identity guide for alignment, and delivery troubleshooting when authentication passes but delivery still fails.

Sources and further reading

Examples use reserved documentation names and addresses. Confirm current provider requirements before changing production systems.