SPF (Sender Policy Framework) is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of your domain. It helps prevent email spoofing and improves deliverability by allowing receiving mail servers to verify that incoming messages originate from authorized sources. Without a valid SPF record, your emails are more likely to land in spam folders or be rejected entirely.

Per RFC 7208 Section 4.6.4, SPF evaluation must not exceed 10 DNS lookups. This includes queries triggered by include, a, mx, ptr, exists, and redirect mechanisms. Exceeding this limit causes a permerror, meaning the SPF check fails and the email may be treated as if no SPF record exists. This safeguard prevents abuse and excessive resource consumption during email authentication.

-all (Fail) — Most secure. Only authorized servers listed in your SPF record can send; all others are rejected. Recommended for production domains.
~all (SoftFail) — Moderate. Unauthorized servers are flagged but not strictly rejected. Useful during SPF rollout or when you're unsure about all sending sources.
+all (Pass) — Not recommended. Allows any server to send email claiming your domain — effectively disables SPF protection.
?all (Neutral) — No policy. Equivalent to not having an SPF record for the "all" match.

The ptr mechanism was deprecated in RFC 7208 because it is slow, unreliable, and places an unnecessary burden on DNS infrastructure. PTR lookups require reverse DNS queries that often time out or return inconsistent results. Modern SPF best practices strongly discourage using ptr — replace it with explicit ip4 or ip6 mechanisms whenever possible.

1. Flatten includes — Replace nested include chains with direct IP ranges when feasible.
2. Use ip4/ip6 — Explicit IP mechanisms don't count toward the DNS limit.
3. Avoid mx and ptr — Both trigger extra DNS queries.
4. Consolidate vendors — If multiple services send email, see if they share a single include.
5. Use subdomains — Split SPF responsibilities across subdomains to isolate query counts.

No. RFC 7208 explicitly states that a domain must not have more than one SPF record. Multiple SPF TXT records will result in a permerror during evaluation. If you need to authorize multiple services, combine them into a single SPF record using multiple include mechanisms or IP ranges.

include — Incorporates the SPF record of another domain. If the included domain passes, the include mechanism matches. Processing continues with subsequent mechanisms.
redirect — Completely replaces the current SPF record with the SPF record of the target domain. All mechanisms before redirect are ignored. Only one redirect is allowed and it must be the last mechanism (before all).

A single DNS TXT record is limited to 255 characters per string. However, TXT records can span multiple strings (chunks) that are concatenated. The total SPF record should ideally stay under 512 bytes to avoid UDP DNS truncation issues. Overly long SPF records may require TCP fallback or cause delivery delays.