What is a TXT record? DNS Text Records Explained

A TXT record is a DNS entry that stores arbitrary text tied to a domain, which other systems can read and act on. Originally meant for human-readable notes, TXT records now quietly carry most of the machine-readable policies that secure email — SPF, DKIM, DMARC, and BIMI all live in TXT records — plus the verification strings services use to prove you own a domain.

What is a TXT record?

A TXT record holds a string of text associated with a domain name. It acts like a digital note: the domain owner publishes information, and any system that queries DNS can read and interpret it. The record has three parts — a name (the host it sits on, such as _dmarc.yourdomain.com), a type (TXT), and a value (the text itself).

That flexibility is why TXT records became the default home for email authentication and domain-verification data. The same record type carries very different payloads depending on the host it's published on:

One record type, several jobs — the host name tells receivers which policy it is.

For instance, an SPF TXT record at your root domain might read v=spf1 include:_spf.google.com ~all, telling servers which sources may send for you, while a DMARC record at _dmarc.yourdomain.com tells receivers what to do with mail that fails authentication.

How does a TXT record work?

TXT records are part of the DNS infrastructure, serving instructions or metadata to any system that asks. When a domain owner adds one, it's stored in the domain's DNS zone at a specific host name. A querying system — a receiving mail transfer agent (MTA), a verification service, or a security scanner — looks up that host name and reads the value.

The lifecycle of a TXT record, from creation to email authentication.

When you send a message, the recipient's server checks your SPF TXT record to confirm the source is authorized, reads your DKIM public key from a TXT record to verify the signature, and consults your DMARC TXT record to decide how to handle anything that fails. Each of those lookups happens in milliseconds during mail delivery, which is why a small text entry has an outsized effect on whether your mail reaches the inbox or gets flagged as phishing.

The 255-character limit (and why long DKIM keys look odd)

A single TXT string is capped at 255 characters. Values longer than that — most commonly a 2048-bit DKIM public key — are split into several quoted strings inside one record, which DNS concatenates back together on lookup. That's why a DKIM record often appears in your DNS editor as "v=DKIM1; k=rsa; p=MIGf..." "...restofkey..." with the value broken across quotes. It's normal; the strings are joined with no separator when the record is read. If you paste a long key as one unbroken line, some DNS providers reject it or silently truncate it — split it, or let your provider's interface handle the chunking.

Why TXT records matter

TXT records are small but they underpin core email and domain functions:

• Email authentication. They host SPF, DKIM, and DMARC data, so receivers can confirm your mail is genuine and reject spoofed messages that would otherwise reach your customers as spam or phishing.
• Domain verification. Services like Google Workspace and Microsoft 365 ask you to publish a unique TXT string to prove you control the domain before granting access.
• Security policy. MTA-STS and TLS reporting both rely on TXT records to advertise and monitor encrypted delivery.
• Brand and deliverability. BIMI logos are referenced from a TXT record, and correctly configured records signal trustworthiness to receivers, supporting deliverability over time.

Things to keep in mind

Managing TXT records takes precision — a single typo can block legitimate mail.

Key practices for keeping TXT records accurate and secure.

• Format carefully. A stray space or missing tag in an SPF record can fail authentication for every message. Validate syntax with a DNS lookup tool before you rely on it.
• Allow for propagation. Changes can take up to 48 hours to reach every resolver, though a low TTL speeds this up. Re-check after you edit.
• Respect the one-SPF-record rule. A domain may have many TXT records, but only one may be an SPF (v=spf1) record — a second one breaks SPF entirely.
• Monitor for tampering. Review your records periodically; an unauthorized change to SPF or DKIM can quietly enable spoofing. Confirm authentication results in your email headers.
• Align the rest of your DNS. Pair TXT records with correct MX records and PTR records so routing and authentication agree.

You can check all of your domain's authentication TXT records at once with the Email Security Score.

Related reading

• What are DMARC, DKIM, and SPF?
• What is DKIM?
• What is a DNS?