TXT records and domain verification

Module 4: Records for email · Reading time: 7 minutes

Learning objective: After this lesson, you'll be able to create a TXT record to verify your domain with a service, and you'll know when multiple TXT records can sit side by side and when they can't.

Key concepts: TXT record, verification code, name with underscore, quotation marks, text chunks of 255 characters, SPF/DMARC as special TXT records

A note in your DNS

A TXT record is the simplest record there is: a piece of text at a name. The DNS itself does nothing with it. It's meant for other programmes that come along to read that text.

That's why TXT is the favourite record of services that want to know whether a domain really belongs to you. Google Search Console, Microsoft 365, Google Workspace, Facebook, Apple, GitHub, newsletter services and webshop platforms all work the same way:

1. The service gives you a code, for example google-site-verification=Ab12Cd34... or MS=ms12345678.
2. You add that code as a TXT record in your domain's DNS.
3. The service looks up the TXT record for your domain. If the code is there, it knows: whoever could place this code manages this domain.

Only someone who can change a domain's DNS can place such a record. That's why it's a reliable check.

What does a TXT record look like?

example.com.   3600  IN  TXT  "google-site-verification=Ab12Cd34Ef56"
example.com.   3600  IN  TXT  "MS=ms12345678"
example.com.   3600  IN  TXT  "v=spf1 mx include:spf.service.example ~all"

A few things to know:

• Quotation marks. In a zone file, the text sits between quotation marks. In most panels you don't need to type these yourself: the panel adds them around the text for you. If you do type them, check after saving that there aren't any doubled-up quotation marks.
• Chunks of 255 characters. A single piece of text in a TXT record can be at most 255 characters long (RFC 1035). Longer texts, such as a DKIM key, get split into multiple chunks within the same record: "first part" "second part". Programmes that read TXT records stick these chunks back together. Good panels split this automatically; with some, you have to do it yourself.
• Capitals and spaces count. Copy the code exactly, preferably using copy and paste. A trailing space or a missing character is enough to make verification fail.

On which name?

The service always states which name the record should go on:

• On the domain itself. The service says "@", "root", "leave host empty", or simply names example.com. In most panels you then type @ or leave the field empty.
• On a dedicated name. Some services want a separate name starting with an underscore, such as _github-challenge-examplecompany or _acme-challenge. The underscore shows that this isn't a regular hostname (you can't open a website on it). In your panel, type only that first part; your domain name is already added after it.

A common mistake: filling in the full name in a panel that adds the domain name itself. This creates _github-challenge-examplecompany.example.com.example.com, and the service finds nothing. After saving, check which full name the panel displays.

Multiple TXT records: is that allowed?

Yes. You can have as many TXT records as you like on one name. A verification for Google and one for Microsoft don't get in each other's way. Each service searches through all TXT records for its own code.

There are two exceptions, and they matter:

• SPF (starts with v=spf1): a maximum of one per name. Two SPF records make your SPF invalid (lesson 4.3).
• DMARC (on _dmarc, starts with v=DMARC1): a maximum of one. With two records, a receiver behaves as if you have no DMARC at all (lesson 4.5).

If a service asks you to "add this SPF record", don't create a second SPF record, add to the existing one instead.

Can you remove the verification afterwards?

That depends on the service. Many services (such as Google Search Console and Microsoft 365) check again later. If you remove the record, your domain may be marked as "not verified" again after a while. So leave it in place, unless the service says it's fine to remove. You can clean up an old verification record from a service you no longer use.

It doesn't work right away

Have you just created the record and does the service say "not found"? That's usually down to the cache (module 6). If the service already queried your domain before the record existed, it remembers for a while that nothing was there. Wait a quarter of an hour and try again. In the meantime, check for yourself with an online DNS lookup tool whether the record is there (lessons 8.2 and 8.3).

In practice: what it looks like in a panel

In this example, we use My WebOké. Go to the domain, the DNS tab, and click Add Record. Choose type TXT, enter @ under Hostname (or the name the service gives you) and paste the code as the value. You don't need to type the quotation marks. In DirectAdmin it works the same way under DNS Administration; there, leave TXT Record Type set to Plain.

In other panels, the fields are sometimes called Host, Hostname or Name and Value, Content or Data, but the principle is the same.

Summary

• A TXT record is text at a name. Services use it to check whether a domain belongs to you.
• Copy the code exactly and place it on the name the service specifies (often @, sometimes a name with an underscore).
• Multiple TXT records on one name are allowed, except for SPF and DMARC: a maximum of one each.
• If verification doesn't succeed straight away, wait a while: the answer may still be sitting in a cache.

Quiz

Exercise

Exercise Z4.2: Looking up a verification code. Look up the TXT records for wikipedia.org. Among them is a Google verification code. Paste the full verification text that starts with google-site-verification=.

Exercise O4.2: Setting it up yourself in your practice zone. In the practice zone, you'll use a fake service; with your real domain you'd of course use the real code the service gives you. You'll receive a personal code <your code> for this exercise (it looks like oefen-<code>-<letters>). In your practice zone <code>.dnspractice.eu, create two TXT records:

1. on the name of the zone itself (@): dnscursus-verificatie=<your code>
2. on the name _cursus-challenge: just <your code>

Further reading

The steps in these articles apply to the WebOké panels; in other panels it works in a similar way.

• DirectAdmin guide 5.6: TXT records for verification (Google, Microsoft and others)
• Managing DNS records in My WebOké (with examples for CNAME, TXT, and external services)
• WebOké manual 5.4: Managing DNS: adding, editing and deleting records
• RFC 1035 section 3.3.14 (TXT), RFC 7208 section 3.3 (long SPF texts in multiple chunks)