SPF records

SPF uses a TXT record to publish which systems may use a domain in the SMTP envelope sender.

That envelope domain can differ from the human-visible From: address. DMARC adds alignment rules for the visible domain, so an SPF pass alone does not prove that the displayed sender is authorized.

A policy might contain IP mechanisms and an included provider policy:

v=spf1 ip4:192.0.2.0/24 include:_spf.mail-provider.test -all

Read it from left to right. The mechanisms describe allowed senders, and -all says unmatched senders should fail. Copy the provider’s current value and understand its rollout guidance before using a strict ending on a production domain.

Keep exactly one SPF policy per owner name. When adding a sender, merge its mechanism into the existing v=spf1 record instead of publishing a second one. Multiple selected SPF records produce a permanent error rather than combining their permissions.

SPF limits evaluation to ten DNS-causing mechanisms and modifiers. Nested include, a, mx, redirect, and related lookups count toward that budget. A convenient chain of providers can exceed the limit even when the TXT text looks short. Direct ip4 and ip6 mechanisms do not require DNS lookups during evaluation.

SPF also has operational limits. Forwarding can change the connecting server and break SPF unless the forwarding system rewrites the envelope sender. SPF does not sign message content; DKIM performs that separate job.

Inspect the published policy:

dig TXT example.com +short

Look for one string beginning with v=spf1, then expand every include while counting DNS-causing terms. Remove services you no longer authorize. If a service uses a subdomain as its envelope sender, query that exact subdomain too.

Your action is to audit one domain’s SPF policy. List each authorized sender, count the DNS-causing terms including nested includes, confirm there is one policy, and identify the final all qualifier.