Skip to content
Email authentication

SPF syntax and lookup limits

Maintain one authorization policy for each envelope sender domain.

Which identity does SPF check?

SPF evaluates the connecting IP against the domain in SMTP MAIL FROM, with HELO used in defined circumstances such as a null reverse path. It does not authenticate the visible From header. DMARC separately evaluates alignment.

Keep the policy maintainable

  • Publish one SPF policy at the evaluated domain. Multiple TXT records beginning with v=spf1 produce an error; unrelated TXT records can coexist.
  • The limit is 10 evaluated DNS-querying terms across the policy and nested policies. include, a, mx, ptr, exists and redirect count; ip4, ip6 and all do not. DNS work has additional limits, including void lookups.
  • An include evaluates another policy. It is not an instruction to paste all of that provider’s records into yours.
  • Avoid hand-maintained flattening of vendor includes. Address changes can leave authorization stale; any managed flattening still needs ownership and ongoing maintenance.

Inspect your published record

Bash
read -r -p "Actual envelope sender domain: " mailfrom_domain
dig TXT "$mailfrom_domain" +noall +answer

This query displays DNS data. It does not evaluate the complete SPF policy or count all nested lookups. Compare the result with the sending provider’s current configuration and receiver authentication results.

Review before changing

  1. Inventory every system that uses this envelope sender domain, including infrequent transactional jobs.
  2. Remove authorization only after confirming the sender is retired. Preserve existing legitimate senders when adding a new one.
  3. Verify the authoritative record, then inspect a fresh message sent through each affected route.

For the Google-only policy and mixed-sender caveats, see SPF for Google Workspace.

Sources