A TXT record is a type of DNS record that stores arbitrary text a domain can hand to other services. It is most often used to prove domain ownership and to configure email authentication: SPF, DKIM, and DMARC. The value is written inside quotation marks and added through your DNS host control panel.
This guide covers what a TXT record is and how it is structured, what it is actually used for, its technical limits, how to write a value with quotes correctly, how to add it at your registrar or DNS host, how to verify the result, and how to avoid common traps such as two SPF records or stray spaces.
What a TXT record is
A TXT record is one of the base DNS resource record types defined back in RFC 1035. It was originally meant as a way to attach a free-form text note to a domain name. Over time the format proved so convenient that it became the standard container for machine-readable data: email security policies, signing keys, and verification tokens.
Technically a TXT record consists of a name (the host), the type TXT, a TTL value, and one or more strings of text. Each string is wrapped in double quotes. A single domain name can hold several TXT records at once — they do not conflict, except in special cases like SPF, where only one record is allowed.
It is important to grasp the difference between an address record (A or AAAA), which tells the browser which IP to connect to, and a TXT record, which routes nothing anywhere. TXT is data to be read by specific services, not for directing traffic. If you are just getting to know the Domain Name System, start with an overview of DNS record types.
What a TXT record is for
TXT records have many practical uses, but nearly all of them boil down to two jobs: proving the domain belongs to you, and protecting your outbound mail from spoofing. Below is a summary table of the main scenarios with an example value.
| Use case | Host | Example value |
|---|---|---|
| Google verification | @ | google-site-verification=rXep9x...KJ2 |
| Yandex verification | @ | yandex-verification: a1b2c3d4e5f6 |
| SPF (which servers send mail) | @ | v=spf1 include:_spf.google.com ~all |
| DKIM (signing key) | selector._domainkey | v=DKIM1; k=rsa; p=MIGfMA0... |
| DMARC (handling policy) | _dmarc | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com |
| BIMI (logo in email) | default._bimi | v=BIMI1; l=SSL/TLS проверку://example.com/logo.svg |
Domain verification
Google Search Console, Yandex Webmaster, Microsoft 365, and dozens of other services ask you to add a TXT record with a unique token when you connect a domain. The logic is simple: if you were able to edit the domain DNS, then you control it. After the check passes you can leave the token in place — it is harmless and does not affect mail or the website.
Email authentication: SPF, DKIM, DMARC
This is the key role of TXT records today. SPF lists the servers allowed to send mail on behalf of your domain (the standard is described in RFC 7208). DKIM holds the public key the receiving side uses to verify a message signature. DMARC ties SPF and DKIM into a single policy and tells receivers what to do with messages that fail. A detailed breakdown of all three lives in a dedicated guide to SPF, DKIM, and DMARC.
BIMI and other scenarios
BIMI lets your brand logo appear next to a message in mail clients that support it. Beyond that, TXT is frequently used to publish _mta-sts policies, keys for external integrations, and service labels. The format stays the same — only the meaning of the text inside the quotes changes.
Limits and TXT record syntax
The main technical limit is set by the protocol: a single TXT string cannot exceed 255 characters. If the value is longer (typical for RSA 2048 DKIM keys), it is split into several quoted substrings, and the DNS server concatenates them back into one text with no separators when it answers. It looks like this:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7""nOq2hK4rE9pW3vLxYz1aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789abcdef"Note that both substrings are wrapped in double quotes, with no comma between them — just a line break. The domain itself has no hard limit on total TXT length, but the DNS answer should fit within a reasonable UDP packet size, otherwise the resolver falls back to TCP.
Quotes are the second common point of failure. In most control panels the quotes around a value are added automatically, so you do not type them by hand. But if the panel accepts raw zone syntax, quotes are required, and any internal quotes are escaped with a backslash. Always follow the hints from your DNS provider.
How to add a TXT record
The steps are the same across most registrars and DNS hosts; only the button labels differ:
- Log in to the DNS control panel for your domain (at the registrar, or at the host or CDN if your NS records are delegated there).
- Find the section named "DNS Records", "Zone Management", or similar and click "Add record".
- Choose the type
TXT. - In the "Host" or "Name" field enter the node:
@for the root domain,_dmarcfor DMARC,selector._domainkeyfor DKIM. - In the "Value" field paste the text without outer quotes (if the panel adds them itself).
- Leave the TTL at the default (usually 3600 seconds) and save.
Here is an example of a correct SPF value and a verification token as they are usually entered:
; SPF — one record for the whole domain
@ IN TXT "v=spf1 include:_spf.google.com include:mailgun.org ~all"
; Verification
@ IN TXT "google-site-verification=rXep9xKJ2fQ8vN0"Changes do not take effect instantly: they need time to propagate through resolver caches, usually from a few minutes up to the TTL of the old record.
How to verify a TXT record
After saving, always confirm the record is publicly visible. The fastest way from the command line is the dig utility:
dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=rXep9xKJ2fQ8vN0"
# Check DMARC on the subdomain
dig TXT _dmarc.example.com +shortThe +short flag keeps only the values in the output. On Windows the equivalent is nslookup -type=TXT example.com. If you prefer a browser, open our DNS lookup tool: it shows every TXT record on the domain without installing anything. For a focused check of email policies, the SPF, DKIM, and DMARC analyzer is handy — it does not just print the records, it validates them.
Common mistakes
Most TXT record problems come down to a handful of recurring situations:
- Two SPF records. The standard allows a domain only one TXT record starting with
v=spf1. If there are two, SPF verification breaks entirely. Merge allincludestatements into a single string. - Stray spaces and line breaks. A space before
v=spf1or inside a verification token makes the value invalid. Copy the text carefully, with no trailing spaces. - Wrong host. DMARC must live at
_dmarc, DKIM atselector._domainkey. A record placed at the root@will not work. - Manual quotes where the panel adds its own. The value ends up double-quoted —
""v=spf1...""— and fails to parse. - A very short TTL during frequent edits. While experimenting, use a small TTL, but for a production record return to 3600 to reduce DNS load.
After each change it helps to cross-check against the DNS reference on MDN and re-verify the record publicly, not just in the panel.
Frequently Asked Questions
How many TXT records can I add to one domain?
As many as you need: verification tokens, DKIM keys for different selectors, and service labels all coexist freely. The exception is SPF: a record starting with v=spf1 must be exactly one per domain, otherwise email authentication stops working correctly.
Why is the TXT record not visible right after I add it?
DNS caches answers. A new record becomes visible as the TTL of the old data expires in resolver caches — usually from a few minutes to an hour. Verify it publicly with dig or an online tool, not just inside your provider panel.
Do I need to add quotes to a TXT record manually?
It depends on the panel. Most web interfaces add the double quotes automatically — in that case type only the text itself. If you edit a zone file directly, quotes are required, and strings longer than 255 characters are split into several quoted substrings.
Can I store arbitrary text in a TXT record?
Yes, TXT formally allows any printable text. But you should not publish private data in it: TXT records are public and easily read by any resolver. Use them only for information you are comfortable disclosing publicly.
What is the difference between a TXT record and an SPF record?
There has been no separate SPF type in DNS for years — SPF is published precisely as a TXT record whose content is v=spf1 .... In other words, SPF is a special case of TXT with a specific syntax. Details are in the article on the SPF record.
How can I quickly check SPF, DKIM, and DMARC at once?
Run the domain through the email records analyzer: it pulls all three TXT policies, shows their values, and flags issues — duplicate SPF, missing DMARC, or invalid DKIM syntax — in a single report.