Why SPF, DKIM, and DMARC All Use TXT Records (And What It Costs You)

The Short Answer

When you set up SPF, DKIM, or DMARC, you create a TXT record. Not an SPF record, not a DKIM record, not a DMARC record. A TXT record. This is not because TXT is the right tool for the job. It is because of timing and deployment economics in the early 2000s.

What TXT Records Were Actually Designed For

The TXT record type was added to DNS in 1983 as a way to attach arbitrary text to a DNS name. It was never intended to store structured data or serve as a home for authentication mechanisms. Its only purpose was descriptive: human-readable notes attached to a domain name.

When SPF arrived in the early 2000s, the IETF actually tried to give it its own dedicated record type. SPF was assigned RR type 99. For a brief period, type 99 meant SPF. Mail servers could look up the SPF record directly.

This did not last.

SPF and the Failed Attempt at a Dedicated Record Type

RR type 99 was officially deprecated in 2014 by RFC 7208. The reasoning was pragmatic: too many DNS resolvers and name servers had been deployed without support for type 99. Mail servers that could not look up type 99 would silently skip SPF checks, creating a situation where domains with type 99 records would appear to pass no SPF check at all.

The fix was to publish SPF data as a TXT record instead. The SPF mechanism was designed so that TXT record parsers would recognize SPF data and ignore anything that was not a valid SPF record. The "v=spf1" prefix made this possible.

This worked. But it meant that SPF was now living in a record type designed for human-readable text, storing machine-generated authorization rules. The ambiguity was baked in from day one.

DKIM Followed the Same Path

DKIM was designed from the start to use TXT records, not because TXT was the right fit, but because getting a new DNS record type approved and widely deployed takes years. The IETF explored assigning DKIM its own RR type (type 58 was discussed), but the deployment timeline made it impractical.

So DKIM selectors live in TXT records. A DKIM signature in an email header tells receiving servers to look up "selector._domainkey.example.com" as a TXT record. The selector prefix lets a domain publish multiple DKIM keys without touching the main domain zone.

The selector mechanism works, but it also creates a failure point: if your selector is misconfigured or unreachable, mail receivers cannot validate your DKIM signature. The TXT record format gives you no built-in validation or schema enforcement.

DMARC Inherited the Convention

DMARC was born in 2012, built on top of SPF and DKIM. Its policy records always lived in TXT records because that is where SPF and DKIM already lived.

A DMARC record looks like this:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:reports@example.com"

There is no DMARC record type. There is no specialized parser for this data in most DNS systems. A mail server that receives a DMARC failure report has to parse that TXT record string and interpret its semicolon-delimited key-value pairs manually. The parsing ambiguity that SPF introduced by accident, DMARC inherited by design.

What Dedicated Record Types Would Have Enabled

If SPF, DKIM, and DMARC had been assigned their own record types from the start, a few things would be different today.

First, record type enforcement. With a dedicated SPF record type, a DNS resolver would know unambiguously whether an SPF record exists and what it contains. There would be no risk of a TXT record accidentally publishing SPF data in the wrong format, or SPF data appearing alongside other TXT content on the same domain.

Second, security. A dedicated record type could have included built-in signature validation or key size constraints. TXT records are limited to 255 characters per string, which is why DKIM keys published in TXT records must be encoded across multiple strings and base64-wrapped. This encoding layer adds complexity and potential points of failure.

Third, parsing reliability. Mail receivers processing DMARC reports today must parse a free-text string that looks structured but has no formal schema. A dedicated DMARC record type could have enforced the policy format at the DNS layer, eliminating entire classes of misconfiguration.

OPENPGPKEY and SMIMEA face the same challenge. Both protocols use DNS as a key distribution mechanism but neither has a dedicated record type. OPENPGPKEY records at openpgpkey._domain.example.com and SMIMEA records at smimecert._domain.example.com are all TXT records, which means they carry the same legacy baggage. Any protocol that wants to use DNS for structured data faces the same chicken-and-egg problem: you need the ecosystem to support your record type before it is useful, but the ecosystem will not prioritize your record type until it is already useful.

The Real Costs of TXT Record Flexibility

Here is what the TXT record convention costs you in practice.

SPF character limits. TXT records are limited to 255 characters per string, with multiple strings allowed per record. SPF records that exceed this must be split across multiple strings. Most SPF implementations handle this automatically, but overly long SPF records can cause timeouts during DNS resolution, which mail receivers then treat as soft fail.

DKIM key parsing. DKIM keys in TXT records are base64-encoded. If the encoding is corrupted during zone transfers or if a DNS provider truncates whitespace, validation fails silently. There is no schema that would catch the error before it reaches a mail receiver.

DMARC report parsing. Aggregate DMARC reports arrive as XML attachments in email, and their accuracy depends entirely on participating mail receivers correctly interpreting your DMARC TXT record. If a receiver misparses your record, your aggregate data is wrong before the report is even generated.

This is where structured parsing tools matter. DMARCFlow reads DMARC aggregate and failure reports and converts the XML into human-readable formats. When your TXT record configuration is producing unexpected results, the difference between staring at raw XML and seeing a clean breakdown of authentication failures by domain is significant. Understanding what your records are actually doing is the first step toward fixing what they are not doing.

Ambiguity at scale. When multiple TXT record types share the same domain namespace, accidental collisions become possible. A domain that publishes both an SPF TXT record and a legacy SPF type 99 record creates unpredictable behavior depending on which records a resolver returns.

Where Email Authentication Goes From Here

The DNS ecosystem has improved since the early 2000s, but the inertia of existing SPF, DKIM, and DMARC deployments makes any move to dedicated record types extremely difficult. Deprecating TXT record usage for email authentication would require every mail receiver and DNS resolver in the world to support the new record type simultaneously, or risk silent authentication failures.

Some incremental improvements are already underway. RFC 8463 proposed a DKIM key publication format using a new DKIM RR type, but it remains experimental. The IETF has shown no urgency to assign dedicated record types for SPF or DMARC.

For now, TXT records are the permanent foundation of email authentication. Managing them well means knowing their limits: character boundaries in SPF, encoding requirements in DKIM, and parsing ambiguity in DMARC.