DNS TXT SPF record: what it is and how it works

When the record's exact content changes the result

A record only counts as SPF if its text begins with the exact tag v=spf1, immediately followed by a space or the end of the record. RFC 7208 states the version section "ends at the space character... or the end of the record," so a record starting with something like v=spf10 does not match and is discarded.

When a receiver checks a domain, it queries DNS for TXT records only. Two outcomes follow directly from what DNS returns:

• If no TXT record at the domain begins with v=spf1, the result is none. That is the standards-level meaning of "this domain has no SPF record."
• If more than one TXT record at the domain matches, the domain is out of compliance. RFC 7208 requires that a domain "MUST NOT have multiple records that would cause an authorization check to select more than one record." When a receiver still finds several matching records, the check returns permerror rather than guessing which one is authoritative.

Size matters too, though less strictly. A TXT record's RDATA can hold more than one internal character-string, each capped at 255 octets by the DNS wire format in RFC 1035. RFC 7208 says a record with multiple strings "MUST be treated as if those strings are concatenated together without adding spaces," which is how a policy longer than 255 octets fits inside one TXT record. RFC 7208 also recommends the record stay small enough that the full DNS answer fits inside a 512-octet response, using a combined name-and-record length under 450 octets as the practical guideline for UDP.

If a check keeps returning permerror for a different reason, specifically too many nested DNS lookups rather than duplicate records, that failure mode has its own fix; see how to fix SPF PermError: too many DNS lookups.

A worked SPF TXT record

RFC 7208 gives this as an example of a correctly formed SPF record:

v=spf1 +mx a:colo.example.com/28 -all

This is the standards body's own illustrative example, not a live production value, and it should not be copied onto a real domain. Two things about its shape apply to any SPF TXT record, regardless of which mechanisms it uses:

• The record starts with v=spf1, and nothing precedes it.
• Everything after the version tag is one continuous string, even when the underlying TXT record stores it as several concatenated character-strings on the wire.

What to check before you publish or troubleshoot a record

If a domain doesn't yet have a matching record, three requirements come directly from the RFCs above, independent of which DNS provider hosts the zone:

• Publish the value as a TXT (type 16) record, not any other record type.
• Make sure the record's text begins with v=spf1, with nothing before it.
• Confirm the domain ends up with exactly one TXT record matching that tag. A second matching record, even one added by a different team or a forgotten legacy entry, produces permerror rather than a working policy.

Check whether your domain publishes an SPF record

Run the domain through Palisade's SPF checker to see the same DNS TXT lookup described above applied to your own domain, instead of working it out by hand against a DNS provider's interface.

Check the SPF record

A DNS TXT lookup only confirms what's published. It doesn't confirm that a specific sending source is included in the record, that DKIM or DMARC are configured correctly alongside it, or that a receiving mail server will treat a given message as authenticated.