What is a TXT record used for?

A TXT record holds arbitrary text at a DNS name, and email standards use it for almost everything: SPF policies, DKIM public keys and DMARC policies are all TXT records. Services also use them for domain verification, publishing a token you add to prove you control the name before they will send mail as it.

Can a domain have more than one TXT record?

Yes, and a busy domain usually has several. A resolver returns all of them together and each reader recognises its own by the prefix. The one exception that matters is SPF: RFC 7208 permits exactly one v=spf1 record per name, and publishing a second makes the evaluation a permanent error.

Why does my DKIM key have a quotation mark in the middle of it?

Because each character-string inside a TXT record is limited to 255 bytes, and a 2048-bit key is longer than that. The record is published as two strings, which resolvers concatenate with nothing in between. It is correct as it stands, and joining the halves into one oversized string is what would break the record.

Is it safe to delete an old verification TXT record?

Usually, but check first. Many services re-verify domain ownership periodically rather than only at setup, so removing a token can quietly unverify a domain in a service that somebody still depends on. Identify which service issued the token, confirm nobody is using it, then remove it.

TXT record lookup: read a domain's TXT records

What a TXT record holds

A TXT record carries free text, which is why so many protocols were built on top of it. On a mail-sending domain the apex usually holds an SPF policy and a queue of ownership tokens issued by services that needed to prove you control the name.

A single name may carry many TXT records, and a resolver returns all of them in one answer. Nothing orders them and nothing distinguishes them except their content, so anything reading them has to recognise its own record by its prefix.

Three TXT records at the apex of example.com: one SPF policy and two ownership tokens.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.example.net -all"
example.com.  3600  IN  TXT  "google-site-verification=8xJq2vN4tR1sD0kZ"
example.com.  3600  IN  TXT  "MS=ms12345678"

Exactly one SPF record, no more

This is the fault a DNS TXT record lookup finds most often. RFC 7208 permits one v=spf1 record per name, and adding a second — usually by pasting in what a new sending platform asked for, beside the record that was already there — makes the evaluation a permanent error. Receivers that follow the specification then treat the domain as having no SPF policy at all.

The fix is to merge the mechanisms into one record rather than to choose between them. The SPF record checker walks the merged result and counts the lookups it costs.

Verification tokens and when to remove them

An ownership token proves to a service that you control the domain. Most are checked once at setup and then re-checked periodically, so removing one can silently unverify a domain in a service somebody else in the organisation depends on.

Remove them anyway, but deliberately: a token for a service nobody uses any more is a permanent record of a supplier relationship, and an unusually long list of them is a small piece of reconnaissance you are publishing for free. SenderProbe names the service behind each token it recognises, which is what makes the audit possible in the first place.

The 255-byte limit and long keys

RFC 1035 limits each character-string inside a TXT record to 255 bytes. A record longer than that is published as several strings, and a resolver concatenates them with nothing in between before handing the result to whatever asked.

This is why a 2048-bit DKIM key appears in a zone file with a quotation mark in the middle of the base64. It is correct. Splitting at a different point changes nothing, and removing the split is what breaks it.

One TXT record published as two character-strings. Resolvers join them without a separator, so the reader sees a single unbroken key.

selector1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; "
                                           "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

The mail records that are not at the apex

Not every TXT record a mail setup needs lives at the domain itself. A DMARC policy is published at _dmarc under the domain, a DKIM key at the selector followed by _domainkey, and an MTA-STS policy is announced at _mta-sts. Looking at the apex alone will not show you any of them.

Each has a tool of its own here, because each is parsed rather than merely listed: a DMARC record has a policy to evaluate and a DKIM record has a key to measure.

Run this check on your own domain. A workspace takes a minute to create and runs every one of the eleven checks against the domain you name.

Check my domain

Common questions

What is a TXT record used for?: A TXT record holds arbitrary text at a DNS name, and email standards use it for almost everything: SPF policies, DKIM public keys and DMARC policies are all TXT records. Services also use them for domain verification, publishing a token you add to prove you control the name before they will send mail as it.
Can a domain have more than one TXT record?: Yes, and a busy domain usually has several. A resolver returns all of them together and each reader recognises its own by the prefix. The one exception that matters is SPF: RFC 7208 permits exactly one v=spf1 record per name, and publishing a second makes the evaluation a permanent error.
Why does my DKIM key have a quotation mark in the middle of it?: Because each character-string inside a TXT record is limited to 255 bytes, and a 2048-bit key is longer than that. The record is published as two strings, which resolvers concatenate with nothing in between. It is correct as it stands, and joining the halves into one oversized string is what would break the record.
Is it safe to delete an old verification TXT record?: Usually, but check first. Many services re-verify domain ownership periodically rather than only at setup, so removing a token can quietly unverify a domain in a service that somebody still depends on. Identify which service issued the token, confirm nobody is using it, then remove it.

Keep reading

Related checks, definitions and guides.

See every TXT record a domain publishes, annotated