A TXT record holds arbitrary text at a DNS name. That sounds useless and is quietly one of the most important record types you have, because three separate systems rely on it: email authentication, domain ownership verification, and various service configurations.
Nothing reads a TXT record by accident. Something specific goes looking for a specific name, and finds a specific string, which is why exactness matters more here than anywhere else in DNS.
What they are used for
SPF lists the servers permitted to send mail for your domain. Lives on the domain itself.
DKIM publishes the public key that verifies your outgoing mail's signature. Lives on a selector name such as default._domainkey.
DMARC tells receiving servers what to do when SPF and DKIM fail. Lives at _dmarc.
Verification. A service asks you to publish a string to prove you control the domain. Usually on the domain itself, sometimes on a name they specify.
The first three are covered properly in understanding SPF, DKIM and DMARC. This page is about the record type itself and the ways it goes wrong.
Adding one
In the Zone Editor, add a record of type TXT with three fields: the name, the TTL, and the value.
The name is where people get caught. cPanel usually appends your domain, so entering _dmarc produces _dmarc.example.com. Entering the full name when it also appends gives you _dmarc.example.com.example.com, which nothing will ever find.
Look at what the field displays after you type, and use @ or leave it blank for the domain itself.
The value is pasted exactly as given. These strings are compared character for character, and a trimmed space or a missing character means the check simply fails.
One SPF record, always
This is the rule that catches people who add a service.
A domain may have only one SPF record. Two is a configuration error, and receiving servers are permitted to ignore both, which means adding a second one to authorise a new sender can break authentication for everything.
If you use several senders, they go into one record:
v=spf1 +mx +a include:_spf.google.com include:sendgrid.net ~all
There is also a limit of ten DNS lookups when the record is evaluated, and each include counts toward it. Long chains silently exceed the limit, at which point SPF fails for everyone: a failure that is invisible until you check.
Other TXT records are fine alongside it. The one-record rule applies to SPF specifically, not to TXT in general.
Long values and quoting
A single string inside a TXT record is limited to 255 characters. Longer values, DKIM keys routinely exceed this, are split into several quoted strings that are joined back together:
"v=DKIM1; k=rsa; p=MIIBIjANBgkq..." "...rest of the key"
Most control panels handle the splitting for you. If one rejects a long value, quoting it yourself usually resolves it.
What matters is that nothing is lost. A truncated DKIM key produces a signature that fails to verify, and that is worse than publishing no DKIM at all, because the receiving server now has an active reason to distrust the message rather than simply no information.
Verification records
When a service asks you to prove domain control, publish the string exactly as given, at the name they specify.
Two things go wrong. The name is often the domain itself instead of a subdomain, and putting it in the wrong place means verification never succeeds while the record looks present. And some services want the record to stay in place permanently: removing it after verification revokes the connection, sometimes weeks later.
Leave verification records alone unless you are certain they are obsolete. They cost nothing and removing one has caused more outages than keeping one ever has.
Verify what you published
dig TXT example.com dig TXT _dmarc.example.com dig TXT default._domainkey.example.com
Query the exact name the record is meant to live at. A record present on the domain when the service is looking at a subdomain is invisible to it, and the panel will show it as saved correctly.
If the query returns nothing, wait for propagation before assuming a mistake: TXT records are cached like anything else.
Common problems
Verification fails but the record looks right. The name is doubled, or it is on the domain when the service wants a subdomain. Query the exact name.
Mail authentication broke after adding a service. A second SPF record was added instead of extending the first.
DKIM fails after a migration. The published key no longer matches the signing key on the new server. Regenerate it there.
The panel rejects a long value. Split it into quoted 255-character strings, or use the panel's own DKIM tool which handles this.
A record disappeared. Nameservers were changed and the zone was rebuilt from defaults, TXT records are among the first casualties. Changing nameservers deals with recording them beforehand.
Most of the TXT records on a real domain are verification strings nobody can identify. How to Use TXT Records for Domain Verification explains which are safe to remove.
Read the record back after every change
Text records are edited by hand more than any other type, and they are the ones most often saved with a character missing or a quote in the wrong place. Query the record after saving rather than trusting the panel, and compare it against what the service asking for it specified. A value that is almost correct fails exactly like one that is absent, and it costs more time because everybody assumes the record is present and therefore fine.