A TXT record is a DNS record used to store text-based information for a domain or subdomain. At first sight, that can sound vague, but in practice TXT records are extremely important. They are commonly used for domain ownership verification, email authentication, service validation and other technical instructions that need to be published through DNS without pointing directly to a server or IP address.

Unlike an A record, which points to an IPv4 address, or an MX record, which tells the internet where incoming email should be delivered, a TXT record does not route traffic in the usual sense. Its role is different. It publishes text data that other systems can read and interpret.

That is exactly why TXT records appear in so many practical situations. You may see them when connecting a domain to Google Workspace or Microsoft 365, when setting up SPF or DMARC, when verifying domain ownership for an external service, or when publishing security-related information connected to email and domain control.

What a TXT record actually does in practice

A TXT record allows a domain owner to place text-based information into DNS in a way that other services can query and interpret. The value itself may look like plain text, but in many real-world cases it is not meant for humans to read casually. It is meant for systems and services that expect a specific format.

For example, an email service may look for a TXT record that defines which servers are allowed to send mail for your domain. A cloud service may ask you to place a verification code in a TXT record to prove that you control the domain. A security setup may use TXT records to publish policy information that receiving systems should check before trusting a message.

This is why TXT records are often described as very flexible. They can hold simple text, but in practice they are often used to carry structured technical information.

Why TXT records matter so much

TXT records matter because many modern internet services rely on them as a simple and standard way to publish small pieces of control or verification data.

They are useful because:

• they are widely supported – nearly every DNS provider supports TXT records,
• they are flexible – the value can hold many different types of information depending on the use case,
• they are easy to query – external systems can look them up through DNS without needing direct access to your hosting or email server,
• they work well for verification – adding a TXT record is one of the most common ways to prove control over a domain.

This is also why TXT records show up again and again when connecting domains to third-party tools. They are one of the simplest ways to confirm ownership and publish technical instructions without changing how the website itself loads.

What TXT records are used for most often

The most common use cases are much more practical than the name “text record” may suggest.

• Domain verification – many services ask you to add a TXT record with a specific verification string to prove that you control the domain.
• SPF – SPF is published as a TXT record and lists which servers are allowed to send email for the domain.
• DMARC – DMARC is also published as a TXT record and defines how receiving mail servers should treat messages that fail email authentication.
• Other service integrations – various SaaS tools, security platforms and cloud services use TXT records for domain linking and validation.

That is why TXT records are so common in email administration, but not limited to it. They sit at the point where DNS meets identity, trust and service configuration.

What a TXT record looks like

A TXT record usually contains a hostname or DNS name, the record type TXT, and a value written as one or more text strings.

A simple example could look like this:

example.com TXT "verification=abc123xyz"

Or in the case of SPF:

example.com TXT "v=spf1 include:_spf.google.com -all"

And for DMARC:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

To a non-technical user, these may just look like random strings. In practice, each one follows a specific format expected by the service that reads it.

TXT records do not point to a server

This is one of the most important distinctions. A TXT record does not normally point traffic anywhere. It does not say “go to this IP address” the way an A record does, and it does not say “deliver email to this mail server” the way an MX record does.

Instead, it publishes information. That is why TXT records are often misunderstood by people who expect every DNS record to route a service somewhere. TXT records are more about declaration than about routing.

Put simply, a TXT record says: here is a piece of information about this domain. Other systems can now read it and act accordingly.

Can a domain have more than one TXT record?

Yes. A domain can have multiple TXT records. In fact, this is very common.

For example, one domain may simultaneously publish:

• a verification TXT record for Microsoft 365,
• an SPF record for email sending,
• a DMARC record on the _dmarc subdomain,
• another verification token for an external marketing or analytics service.

This is one reason why TXT records need to be managed carefully. They are flexible, but they can also become messy if old values remain in DNS long after a service has been removed.

How TXT records relate to email

TXT records are especially important in email configuration. This is where many domain owners first meet them.

For example, SPF is published as a TXT record. DMARC is also published as a TXT record. And depending on the provider, some DKIM-related setups also involve TXT publication of the public key, although some providers instead use CNAME-based DKIM delegation.

This matters because email reliability is not only about where mail is delivered. It is also about who is allowed to send it, how the sender is authenticated and whether the domain publishes the expected trust signals for receiving systems.

That is why TXT records are so often involved in deliverability issues. A website can work perfectly while email authentication still fails because a TXT-based SPF or DMARC configuration is wrong or incomplete.

What can go wrong with TXT records

TXT records are simple in concept, but there are still several common mistakes:

• the value is pasted incorrectly,
• quotation marks or formatting are changed by mistake,
• an old TXT record remains in place and conflicts with the new setup,
• the record is published on the wrong hostname or subdomain,
• the administrator assumes the change is live immediately, even though DNS cache is still serving older data.

Another practical issue is size and structure. Some TXT values are long, especially in email-related use cases. DNS systems may split long TXT content into multiple quoted strings behind the scenes. That is normal, but it is one of the reasons why copying and editing TXT records manually should be done carefully.

Why TXT record changes do not show up immediately

Like other DNS records, TXT records are affected by caching and TTL. That means even after the authoritative record is changed correctly, part of the internet may still see the older value for some time.

This becomes very visible when verifying a domain with a service that keeps saying “record not found” even though the TXT record has already been added. In many cases, the problem is not that the record is wrong. It is simply that the new value has not yet become visible through the relevant DNS resolvers.

That is why TXT record changes should be checked with DNS lookup tools, not only inside the DNS provider’s control panel.

What are the limits of TXT records?

TXT records are very useful, but they are not meant for everything. They are good for relatively small pieces of text-based data, verification strings and technical policy information. They are not designed to replace proper routing records such as A, AAAA or MX, and they are not a place for large amounts of structured application data.

They are also highly context-dependent. A TXT value only makes sense if the system reading it knows how to interpret it. Without that context, it is just text sitting in DNS.

Why this term is worth understanding even outside technical roles

TXT records are one of the clearest examples of how DNS is used for much more than pointing a website to a server. They show that modern domains also carry proof, trust signals, service validation and policy information in the background.

If you understand what a TXT record does, it becomes much easier to understand why one service asks you to “add this DNS value”, why a domain verification process may fail for a few hours even after the record is added, or why email authentication depends so heavily on correctly published text-based DNS data.

That is why TXT records matter not only to DNS specialists, but also to website owners, marketers, founders and anyone connecting a domain to external services. They are quiet DNS records, but often some of the most operationally important ones.

Related terms

• DNS – TXT is one type of DNS record, and its role makes full sense only in the wider context of how DNS works.
• Nameservers – TXT records are stored on authoritative nameservers and served from there to the rest of the internet.
• Hostname – important because TXT records may be published on the root domain or on specific subdomains, depending on the use case.
• A record – useful for contrast, because A points directly to an IPv4 address, while TXT stores text-based data.
• AAAA record – similar to an A record, but for IPv6 rather than IPv4.
• MX record – another DNS record type, but with a very different function, since MX controls incoming email routing.
• SPF – one of the best-known examples of a policy published through a TXT record.
• DMARC – another major email policy record published through TXT.
• Domain verification – one of the most common reasons third-party tools ask domain owners to add a TXT record.