How to Set Up TXT Records: Ownership, ACME DNS Validation, Email

This article is a localized edition of the Japanese original. Read the Japanese original

A TXT record is a DNS record for putting an arbitrary string on a domain, and it is used to prove that you own the domain, to authenticate email senders, to validate when issuing SSL certificates, and so on. The basic rule of setup is "register the value exactly as given, at the name the service specifies," but the name you use and whether you can delete the record afterward differ by purpose. After covering the key points of TXT record format, this article explains the setup steps and how to verify each use that comes up often when running a WordPress site: service ownership verification, DNS validation for Let's Encrypt and others, and email security settings.

Key points of TXT record format

Written in zone file form, a TXT record looks like this.

example.com.              3600 IN TXT "google-site-verification=your-verification-token"
_acme-challenge.example.com. 300 IN TXT "your-acme-token"

The rules common to every purpose are as follows.

• Name: Whether it goes on the root domain or on an underscore name such as _acme-challenge is decided by the purpose. Many control panels automatically append the domain name to the name field, so check the on-screen explanation to see whether you should enter just _acme-challenge or the full name.
• Value: In a zone file, it is enclosed in quotation marks. Some control panels add the quotation marks automatically and some do not, and if they are added twice, the value changes.
• Length: A single string can be up to 255 bytes. Long values such as a DKIM public key are split into multiple strings and registered as one record (many control panels split them automatically).
• You can put several on the same name: You can put any number of TXT records on the same name. It is normal for an ownership verification value and an SPF value to sit side by side on the root domain. However, there is a separate rule that SPF may have only one record per name.
• It cannot coexist with a CNAME: On a name that has a CNAME, you cannot put other records, including TXT.

What to check before you set it up

You register TXT records in the DNS that is actually in use as the domain's name servers. First identify that, and at the same time list the TXT records that exist now.

dig NS example.com +short
dig example.com TXT +noall +answer

Note down what purpose each existing TXT record serves. If you delete TXT records whose purpose you do not know in the name of tidying up, email authentication and service integrations can stop. Before deleting or changing anything, saving the current list to a file will help when you need to restore.

Use 1: Verify service ownership

Many services, such as the domain property in Google Search Console, verify that you own the domain with a TXT record. The steps are largely the same.

1. On the service's screen, display the value to register (a string like google-site-verification=...).
2. Register it as a TXT record at the specified name (in most cases the root domain). Do not delete the existing TXT records; add to them.
3. After confirming that the value is visible in public DNS, run the verification on the service side.

dig @8.8.8.8 example.com TXT +short

The names of the verification screens and buttons differ by service and may change (as of October 2026).

What to note is that the rule is to not delete it even after verification is done. Some services, such as Google Search Console, periodically check that the value exists, and deleting it removes the ownership verification. Conversely, there is no reason to keep the values for services you no longer use, so tidy them up using the method in a later section.

Use 2: DNS validation for SSL certificates (_acme-challenge)

Certificate authorities that support ACME, such as Let's Encrypt, have a way to show through DNS that you administer the domain (the DNS-01 challenge). You use it when you obtain a wildcard certificate (*.example.com) or when the server cannot be reached over HTTP from outside.

The validation value goes in a TXT record named _acme-challenge.example.com. The value changes with every issuance, so if you register it by hand, you have to do the work at every renewal. certbot has plugins (for Cloudflare, Route 53, and others) that use the DNS provider's API to register and delete this TXT automatically, and if you run this on an ongoing basis, that is the realistic choice.

# Method of registering the value by hand (renewals also become manual)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

With this method, you register the value that certbot displays as a TXT, confirm that it is visible in public DNS, and then continue. If you request example.com and *.example.com at the same time, you need to register two values side by side on the same _acme-challenge name. If you overwrite one of them, validation fails.

If you use the DNS provider's API, that API token becomes "a key that can rewrite the zone." Limit its permissions to editing DNS for the target zone only, and keep the credentials file readable by root only (chmod 600 or similar).

When the certificate authority validates the domain, it also refers to CAA records (which specify the certificate authorities allowed to issue certificates). If you have set CAA, also check that the authority you use is permitted.

Use 3: Email security settings

For email, there are several settings that use TXT records, and each has a fixed name where it goes.

SPF, DKIM, and DMARC authenticate the sender and affect how well email sent from WordPress gets delivered. There is a rule that SPF may have only one record on the root domain, so when you add a new sending service, append to the existing SPF record. If you create a second SPF record, both may be judged invalid.

MTA-STS is a mechanism for asking senders of mail to your domain to deliver it over encryption (TLS). It is not complete with the TXT record alone; you also need to place a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt.

_mta-sts.example.com.   3600 IN TXT "v=STSv1; id=20261018a"
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

id is an identifier that you change when you change the policy file, and senders watch for a change in this value to fetch the policy again. Before choosing the strict behavior in the policy, start with the trial behavior, and switch after checking the reports that arrive through TLS-RPT; that way you avoid stopping the receipt of email.

Checking after registration

After you register, check the value on both the authoritative DNS server and public DNS.

# Query the authoritative DNS server directly (the current setting)
dig @ns1.example-dns.net _acme-challenge.example.com TXT +norecurse +short

# Check how it looks from outside with public DNS
dig @1.1.1.1 _acme-challenge.example.com TXT +short

The points to look at are as follows.

• Is the value displayed without a single character missing? Are the quotation marks doubled, or are there spaces before or after?
• Is the name off? If it was registered twice over, as in _acme-challenge.example.com.example.com, nothing is returned for the name you want.
• If it is visible on the authoritative server but not on public DNS, the "does not exist" answer from a query made before you registered may be cached. Wait a while and check again.

Tidying up TXT records you no longer need

TXT records tend to only ever get added. Verification values for services you do not use, and _acme-challenge values left over from manual certificate issuance, are candidates for cleanup.

When you tidy up, first list and save the current TXT records, and delete them only after checking one by one "which service this value is for and why." For values whose purpose you do not know, check whether the service's control panel has a matching setting, and it is safer to leave anything you are not sure about. After deleting, watch for a few days that related services (Search Console, sending and receiving email, and so on) keep working.

Summary

• The name for a TXT record is fixed by purpose. Register the name and value the service specifies exactly, and watch out for doubled quotation marks and doubly registered names.
• As a rule, do not delete ownership verification values even after verification. Tidy up only the values for services you no longer use.
• DNS validation for certificates goes at _acme-challenge. For ongoing operation, automate it with a plugin that uses the DNS provider's API, and limit the API token's permissions.
• SPF is one record on the root domain, and additions are made by appending to the existing record. MTA-STS needs both the TXT and the policy file.
• After registering, check that the name and value look correct on both the authoritative DNS and public DNS.

• How to register WordPress with Google Search Console
• How to restrict which certificate authorities can issue SSL certificates with CAA records

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)