TXT Records and What Reads Them

A record type that means whatever reads it

A TXT record holds a string of text, and DNS assigns that string no meaning whatsoever. RFC 1035 says so directly: TXT records hold descriptive text, and the semantics of the text depends on the domain where it is found. The specification is stating that the meaning lives outside the record.

Everything interesting about TXT records follows from that. SPF, DKIM, DMARC and the verification tokens dozens of services ask you to publish are conventions rather than record types. Somebody decided a particular string at a particular name would carry a particular meaning, then wrote software that reads it. IANA lists the type as value 16, meaning text strings, and that is the whole definition.

The practical effect is that a TXT record cannot be wrong the way an address record can be wrong. A malformed IP address is rejected before it reaches the zone. A malformed SPF policy is a valid TXT record holding a string the SPF checker cannot parse, and DNS neither notices nor cares.

So the useful question is never whether a TXT record is valid. It is which system reads this name, and whether what is published there matches what that system expects.

SPF, and the rule that a domain gets exactly one

A domain must publish exactly one SPF record. Publishing two does not mean the second is ignored, and it does not mean the two are combined: it means SPF stops producing a result at all.

RFC 7208 requires SPF policies to be published as TXT records and no other type. A checker collects the TXT records at the name, discards every one that does not begin with exactly v=spf1, then applies the rule that matters. If the resulting set holds more than one record, the check produces a permerror — a permanent error, not a fail and not a softfail. Evaluation ends with no usable answer, and any DMARC policy resting on SPF loses that leg of its evidence.

How a domain ends up with two is always the same story. A second sending service is added, its setup page says to add a TXT record, and the record is added rather than merged. Both begin with v=spf1, nothing in the control panel objects, and the domain keeps sending mail, so the breakage goes unnoticed until somebody reads a DMARC report.

The correction is to merge into one v=spf1 record listing every authorized source, with a single all term at the end. Two ceilings limit how far that goes. RFC 7208 caps the mechanisms that trigger DNS queries — include, a, mx, ptr and exists, plus the redirect modifier — at ten lookups, and listing individual ip4 ranges instead runs into the character string limit covered below.

Notice how differently the failure gets described. Provider documentation tends to say mail might land in a spam folder; the RFC defines a permerror. One is the symptom, the other the cause.

DKIM, where several records are correct

DKIM inverts the SPF rule, which trips up people who learned the SPF rule first. A domain signing through four services correctly publishes four DKIM records, and they do not conflict, because each lives at a different name.

RFC 6376 puts DKIM public keys in a subdomain named _domainkey, addressed by a selector, a label the signer chooses. A signature carrying a domain of example.com and a selector of foo.bar sends the verifier to foo.bar._domainkey.example.com. The RFC explains the design in one line: the key namespace is subdivided using selectors in order to support multiple concurrent public keys per signing domain.

The record holds tagged values, of which two matter most. The v= tag, when present, must be set to DKIM1, and records carrying anything else are discarded. The p= tag holds the public key, and an empty p value is neither a mistake nor a truncation: RFC 6376 defines it as meaning the key has been revoked.

Selectors also make rotation safe, because nothing is replaced in place. Publish the new key at a new selector, switch the signing service to it, and remove the old selector only after mail signed with it has aged out of the world's queues. Deleting the old record first breaks verification for messages already in flight.

DMARC, and a second one-record rule with a quieter failure

DMARC is also a TXT record, published at a fixed name rather than at the domain itself. RFC 7489 stores domain owner preferences in a subdomain named _dmarc, so the policy for example.com lives at _dmarc.example.com and nowhere else.

The record starts with v=DMARC1. RFC 7489 required both the v tag and the p tag that states the policy, and that is the rule most published guidance still describes — but it changed in May 2026. RFC 9989, which obsoletes RFC 7489, says that if the p tag “is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included 'p=none.'” The permissive reading is now the explicit default rather than a discarded record, which matters mostly because it removes one silent way for a policy to stop applying. Discovery works much as it does for SPF: records that do not begin with v=DMARC1 are discarded, and then, as the RFC puts it, if the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied.

That failure is quieter than the SPF one. A duplicated DMARC record raises no error anybody sees; receivers behave as though the domain had never published a policy. Reports stop arriving, enforcement stops applying, and the zone still holds what looks like a working policy.

DMARC authenticates nothing on its own. It reads the results SPF and DKIM produced, requires the identifier one of them authenticated to align with the domain in the message's From header, and tells the receiver what to do when neither aligns. That dependency sets the order of work: one correct SPF record and verifiable DKIM signing come before a policy that acts on their output.

The 255 character limit is not the limit people think it is

The limit applies to a single string inside a TXT record, not to the record as a whole. That distinction separates a rule that explains what you are looking at from a rule that makes DKIM look impossible.

RFC 1035 defines a character-string as a single length octet followed by that number of characters, up to 256 in length including the length octet. Subtract the octet carrying the length and 255 characters of actual data remain. The same RFC defines the contents of a TXT record as one or more character-strings, so a record may hold several.

A value longer than 255 characters is therefore published as several strings inside one record, never as several records. Route 53's documentation gives the operator's version: break the value into strings of 255 characters or fewer, enclose each in double quotation marks, and list them on the same line.

Consumers reassemble the pieces with nothing between them. RFC 6376 requires strings in a DKIM TXT record to be concatenated with no intervening whitespace, and RFC 7208 says the same for SPF, describing the strings as concatenated together without adding spaces. Because concatenation inserts nothing, a split may fall anywhere in the value, including in the middle of a token, and the reassembled result is identical.

This is why the question arises for DKIM and rarely for anything else. A 2048 bit public key in base64 form is longer than one string can hold, so it has to be split, and the failures that follow almost always come from a control panel that inserted a space at the break or dropped a quotation mark. Hosts also impose their own ceilings on the total value, with Route 53 capping a TXT value at four thousand characters, which is a service limit rather than a rule of DNS.

Verification tokens and the archaeology of a zone

Domain verification is the other dominant use of TXT records. A service generates a unique string, you publish it, the service queries for it, and possession of the record stands as proof that you control the domain.

What differs is what happens afterward, and this is where administrators get burned. Google's guidance for its own token says the record must stay in place until ownership is verified, and may be removed once that has happened. Other services re-check continuously and withdraw verification if it disappears. There is no general rule, so check before deleting anything a service asked you to publish.

Because the cost of deleting the wrong token is invisible and arrives late, the safe-seeming habit is to delete none of them. A ten year old zone routinely carries verification strings for analytics platforms, help desks, security scanners and marketing tools the organization stopped paying for years ago.

Two things are wrong with that. Verification tokens are a public inventory of the vendors a company uses, useful to anybody assembling a convincing phishing pretext. And a record nobody recognizes is a record nobody will question, which is the condition every unwanted DNS entry depends on.

The fix is bookkeeping rather than technology. Note what each token is for and when it was added, and put removal of a service's DNS records on the same checklist as revoking its API keys.

Nothing in a TXT record is private

DNS has no access control. Any resolver on the internet can ask for the TXT records at any name and receive them, and nothing in RFC 1035 attaches confidentiality to what a TXT record holds. Publishing a TXT record is publishing.

The free-text field invites the opposite assumption, because it looks like a scratch pad. Zones turn up holding API keys, internal hostnames, license strings and notes between colleagues, left there by somebody treating DNS as configuration rather than publication.

Removal does not undo it. Anyone who queried the name while the record existed already holds the value. A secret that spent an afternoon in a TXT record has to be rotated, not quietly withdrawn.

The working rule is short. If it would matter that a stranger read it, it does not belong in DNS. Everything a TXT record is legitimately used for, from mail authentication policy to proof of domain control, is designed to be read by strangers.