A TXT record is a free-text, publicly readable "public notice" field attached to your domain's listing in the internet's phone book. It does two common jobs: domain verification (proving a domain really belongs to you) and holding your email-security rules (SPF, DKIM, and DMARC). So when Google or Microsoft 365 asks you to "add a TXT record to verify your domain," this article tells you what that is, whether it is safe, whether it leaks any company information, and who should handle it, so you are not left staring at a string of characters that means nothing.
Who should read this? ❓
If your business has its own domain and runs email on it, this one is for you, especially if Google, Microsoft, or a third-party service has asked you to "add a TXT record to verify domain ownership," or if you have heard of SPF, DKIM, and DMARC but are not sure where they live or why they relate to your domain. If you have no domain and do not plan to run business email, you can skip this one.
First, why TXT records exist at all
Start with DNS. The Domain Name System is the internet's phone book: you give it a memorable domain name, and it looks up the real numeric address of the server so a visitor can connect. If you want the wider picture of this phone book and its other common entries, our companion guide on DNS records covers the main types.
In that phone book, an A record registers which server your website sits on, and an MX record registers which mailroom your email goes to. But people also wanted to attach a plain note to their listing, something that is neither an address nor a number, just text any system can read. Early DNS had no field for that, so the TXT record was created to fill the gap. It began as a "write whatever you like" field. Then, because a spot that is public yet editable only by the domain's owner turned out to be unusually handy, two important uses moved in: domain verification, and storing email-security rules.
What a TXT record actually looks like
In a domain control panel, a TXT record is usually made up of three parts. Once you recognise these three columns, your own control panel stops looking cryptic:
- Host / Name: where on the domain this record sits. For the root domain it is usually "@"; some uses (DKIM, mentioned below, is one) ask for a specific prefix, called a "selector," or a subdomain.
- Value: a free-form quoted text string. This is the actual content of the record: the verification string or the email rule is written here.
- TTL: how long servers around the world may cache this record. After a change, the old value lingers until the cache expires, then the new value takes over region by region.
One caveat: providers do not all label these columns the same way. "Host" may appear as "Name" or "Host," the root domain may be "@" or simply left blank, and "Value" may be called "Value," "Content," or "TXT Value." Different labels, same thing to fill in.
The TXT record Google or Microsoft asked you to add
The most common example, and the one closest to this question, is verifying a domain with Google Search Console. When you add a domain property, Google gives you a value like google-site-verification=AbC123… and asks you to publish it in a TXT record at your root domain. Google then queries your DNS, and once it sees that value, it confirms you control the domain and verification passes. It is much like a provider posting you a one-off receipt, which you pin to the notice board outside your own front door, so they can come back and confirm it is really you. Microsoft 365 and many other services use the very same TXT-verification pattern.
Is it safe? Does it expose anything?
This is the part most worth spelling out, and the most reassuring: the value is just a public text string. Publishing it grants no access and leaks nothing sensitive. In detail:
- TXT records are designed to be publicly readable. Anyone can look up the TXT records for any domain, and that is how they are meant to work, not a flaw.
- The verification string means nothing to an outsider and holds none of your company's confidential information. Reading it does not let anyone log in to your email, website, or admin panel. It only proves the domain is yours.
- The real security gate is who can change your DNS, meaning who holds the login to your domain account, not whether others can read this public notice.
So adding a verification TXT record at a provider's instruction is safe and routine. The thing to be careful about is whether the email asking you to add it genuinely came from the provider, which is exactly the problem the TXT record's other job sets out to solve.
Roughly how you add one at GoDaddy
Control panels differ between providers, but taking the common case of GoDaddy, adding a verification TXT record goes about like this: open the domain's DNS management page, choose Add record, set Type to TXT, set Name to "@", paste the supplied string into Value, and Save. The process changes no other record and does not disturb your website or email.
The other big job: email-security rules live in TXT records
Besides domain verification, TXT records are where three sets of email-security rules are stored. Together those rules act like a tamper-proof stamp of authenticity on the messages your company sends, so the receiving mail system can confirm a message really came from your domain and is not a scammer impersonating you. None is a separate field in DNS; each is text written into a TXT record in a particular format:
- SPF lists, in a TXT record, which servers may send email using your domain, like an authorised-sender list. How it is written and how it affects delivery is covered in more detail in our article on SPF.
- DKIM adds an encrypted signature to each message, checked against a public key also published in a TXT record, confirming the message was not altered in transit and really came from your domain. For the background to this, read our article on DKIM.
- DMARC sets a policy, again in a TXT record, telling receivers what to do when a message claims to be from your domain but fails the checks above. To understand how that policy is set, see our article on DMARC.
Together they reduce the chance of someone using your domain to send spam or phishing, and they affect whether your own legitimate email reaches the inbox. None is set in your email software; all are written into your domain's TXT records, which is why "setting up email security" sounds like an email task but in practice means changing DNS.
An easy detail to trip over
One more thing that often wastes an afternoon: a TXT record only takes effect when it is set at the DNS provider your Name Servers actually point to. Plenty of domains are bought through one registrar but have their DNS hosted elsewhere, at Cloudflare for instance. Edit the TXT record in the registrar's panel in that situation and the record looks added, yet the outside world cannot see it and verification never passes. In short, to change it in the right place you first have to know who actually manages this domain's records, which is one reason it is less hassle to leave this to whoever knows your domain setup.
So what should you do about it
You do not need to work out how to place a string into DNS yourself. When a provider asks you to "add a TXT record to verify your domain," forward that email or those instructions, as they are, to whoever looks after your website and domain. And if you are not sure the request is genuine, have someone verify it first rather than following links in an unexpected email, since impersonation is exactly what email security is meant to prevent.
What 5U Website does
Domain verification and email security are the kind of settings nobody notices when they are right, but that send your email to spam, or stop it sending, when they are wrong. Over close to two decades of building and hosting websites, we have handled many business-email setups on Google Workspace and Microsoft 365, and many SPF, DKIM, and DMARC configurations. We confirm a request is genuine before touching anything, check which provider actually hosts the domain's DNS, then enter the values to the provider's specification and double-check the result.
Let us handle it
There is no need to puzzle over a TXT record you cannot read. Our website design, development, and hosting service includes setting up and maintaining domain verification and email security (SPF, DKIM, and DMARC). If you have received a notice asking you to add a TXT record, or your business email is failing to send, failing to arrive, or landing in spam, send us an email and we usually reply within one to two business days.
Last updated:
