What is the difference between DNS SPF and TXT?

TXT is a general-purpose DNS record type; SPF is one specific kind of policy text published inside a TXT record. RFC 1035 defines a TXT record's data as one or more character-strings whose meaning depends on the domain where they're found, with no inherent tie to email. RFC 7208 narrows that container for email authentication: SPF data must be published only in a TXT (type 16) record, and only counts as SPF once its text begins with v=spf1. An earlier dedicated SPF record type existed under a separate DNS type code, but current implementations don't use it, so DNS TXT is now the only record type SPF uses.

Do I have SPF on my domain?

Not by default. A domain has no SPF policy unless someone has published a matching TXT record for it. To check, a lookup queries DNS for TXT records at the domain and looks for one whose text begins with v=spf1; if none matches, the standards-defined result is none. Palisade's SPF checker runs that same TXT lookup against a domain you enter, so you can see the result without querying DNS by hand.

How to enter SPF record in DNS?

The exact interface depends on which DNS provider hosts the domain, but the record's requirements don't change between providers. It must be added as a TXT record, its value must begin with v=spf1, and the domain must not end up with more than one TXT record matching that tag, since a second matching record causes the check to return permerror instead of a working policy. Check your DNS provider's own documentation for the specific steps to add or edit a TXT record in their interface.

What is SPF for SMTP?

RFC 7208 is formally titled "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1," and it defines how a domain's SPF policy is published in DNS and read by a receiving mail system. This article covers that publication step: SPF policy data lives in a DNS TXT record. The mechanisms that determine which sending sources a record actually authorizes are a separate topic covered on the SPF hub.

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

An SPF policy is published in DNS as a TXT record, not as its own DNS record type. RFC 7208 requires that SPF data appear only in a TXT (type 16) resource record whose text begins with the tag v=spf1. A dedicated SPF record type existed under an earlier RFC, but current implementations don't use it. To find out whether a domain has SPF, a receiver queries DNS for TXT records at that domain and looks for one that matches the tag.

At a glance

Quick takeaways

SPF policy content MUST be published in a DNS TXT (type 16) record; a separate SPF record type exists in DNS history but isn't used by current implementations.
Every valid SPF record starts with the version tag v=spf1, immediately followed by a space or the end of the record.
A domain must not have more than one TXT record matching that tag. If a receiver finds more than one, the check returns permerror instead of picking one.
If no TXT record at the domain begins with v=spf1, the standards-defined result is none, the formal meaning of "this domain has no SPF record."
A TXT record's value can span several internal strings of up to 255 octets each; SPF treats those strings as one record concatenated together.
SPF records should stay small enough that the full DNS answer fits inside a 512-octet response.

How an SPF policy lives inside a DNS TXT record

A TXT record is a general-purpose DNS record. RFC 1035 defines its RDATA as "one or more s," and its meaning depends entirely on which domain the record is attached to. Nothing about the TXT record type itself relates to email; a domain can carry TXT records for many unrelated purposes. For the general record shape, see what a TXT record is.

SPF narrows that general container to one specific use. RFC 7208 states that SPF records "MUST be published as a DNS TXT (type 16) Resource Record (RR) only," with the record's content encoded as US-ASCII. An earlier RFC had defined a dedicated DNS record type for SPF, code 99. RFC 7208 reports that this type "saw no substantial use, and interoperability issues in a common DNS server made its future application questionable at best," and current implementations are not to use it. That history is why every current SPF policy is a TXT record and nothing else.

SPF sits alongside other authentication mechanisms, including DKIM and DMARC, inside the broader email authentication picture. The full grammar an SPF record uses to authorize senders lives on the SPF hub.

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.

SPF DNS TXT lookup decision rule showing when a domain check returns none, proceeds, or permerror — Source: Palisade.

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:

Technical exampletext

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.

The specific mechanisms in the example, and how a domain chooses which senders to authorize, are covered in full on the SPF hub.

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.

Exact steps for adding or editing a TXT record differ by DNS host, and the interface itself sits outside the scope of the record format. After making a change, query the domain from more than one resolver, since DNS providers and public resolvers can serve a stale answer for a short period after an edit.

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.

Evidence