What is a TXT record (and why SPF, DKIM, and DMARC all live in one)?

The one-sentence version

A TXT record stores free-form text against a name in DNS. It was invented for human-readable notes; today it is where almost every machine-readable policy that controls your email lives.

Why email authentication lives in TXT

SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI are all just published text that receiving mail servers look up. Rather than invent a new DNS record type for each, they reuse the TXT record, distinguished by where it sits and a version tag at the front:

• SPF lives in a TXT record at your domain itself (example.com), starting v=spf1.
• DKIM lives in a TXT record at <selector>._domainkey.example.com, starting v=DKIM1 and carrying the public key.
• DMARC lives in a TXT record at _dmarc.example.com, starting v=DMARC1.
• MTA-STS and TLS-RPT live in TXT records at _mta-sts.example.com and _smtp._tls.example.com.
• BIMI (your brand logo) lives in a TXT record at default._bimi.example.com.

The same record type also holds the domain-verification strings tools like Google and Microsoft ask you to add. So a single domain often has a dozen TXT records, each doing a completely different job.

The rules that actually bite

TXT looks trivial, but four quirks cause most of the real-world breakage we see in DMARC reports:

• The 255-character split. A single TXT string is capped at 255 characters. Longer values, most importantly a 2048-bit DKIM public key, must be split into several quoted strings that resolvers stitch back together. Paste a long key as one unbroken string and many DNS panels silently truncate or reject it, and your DKIM fails for no obvious reason.
• One SPF record, never two. A domain must publish exactly one v=spf1 TXT record. Publishing two is a permerror, and every sender then fails SPF. See merging multiple SPF records.
• Quoting. Some providers add the surrounding quotes for you and some want you to type them. Doubling them up, or pasting smart quotes from a doc, produces a record that looks right but parses wrong.
• Apex naming. To put SPF on your bare domain, providers disagree on what to type in the name field: @, a blank, or the full domain. Using the wrong one creates the record one label too deep, where no receiver looks.

How to add one, and verify it took

Adding a TXT record is the same three moves in every provider: choose the name (the host, such as _dmarc or @), set the type to TXT, and paste the value. The exact panel differs by host; our universal walkthrough covers the common ones.

The step people skip is verification. A TXT record gives no error when it is wrong, your mail just starts failing authentication days later. Confirm it before you move on:

• Run our DMARC audit or SPF tester to confirm the record resolves and parses as you intended.
• Or query it directly: dig TXT _dmarc.example.com +short on the command line returns exactly what receivers will see.
• Allow for propagation. A new or changed TXT record can take minutes to a few hours to be visible everywhere, depending on the record's TTL.

Why a wrong TXT record is dangerous

Most DNS records fail loudly: a bad MX bounces mail, a bad A record breaks a website. A bad email-authentication TXT record fails silently. Nothing alerts you. Your SPF, DKIM, or DMARC simply stops passing, and the first sign is often a wave of legitimate mail landing in spam or a 550 bounce. That is the whole reason to monitor: a TXT record you cannot see is a TXT record you cannot trust. trustyourinbox checks all of yours on a schedule and tells you, in plain English, when one drifts.