A TXT record is a type of DNS record that stores a short piece of text against your domain name, which other services can look up and read. It does not send visitors anywhere; it exists to prove ownership of a domain and to publish rules about how email from it should be treated.
How a TXT record works
Your domain’s DNS zone holds several record types. An A record points to a web server, an MX record points to a mail server, and a TXT record simply holds text. Any service can query it, read the value and act on it. A domain can have many TXT records, at the root of the domain or on specific subdomains.
There are two main jobs. The first is domain verification. When you add a domain property in Google Search Console, or connect a domain to Microsoft 365, Meta Business or an email platform, the service gives you a unique code to add as a TXT record. It then checks your DNS; if the code is there, you have shown you control the domain.
The second is email authentication. An SPF record, published as TXT, lists the servers allowed to send email for your domain. DKIM publishes a public key as a TXT record on a selector subdomain (some providers, such as Microsoft 365, have you add a CNAME that points to it), so receiving servers can check a message’s digital signature. DMARC sits at _dmarc.yourdomain and tells receiving servers what to do with mail that fails those checks and where to send reports.
Why it matters
Domain verification in Search Console gives you data for every version of your site at once: http and https, www and non-www, and all subdomains. It is the property type I recommend, and it stays verified only while the TXT record stays in place.
Email authentication has moved from good practice to a requirement. Since 2024 Gmail and Yahoo have required bulk senders to publish SPF, DKIM and DMARC, and Microsoft has introduced similar rules for Outlook.com. Even a small firm of solicitors in Manchester sending quotes and invoices from Microsoft 365 benefits: a missing or broken SPF record is a common reason legitimate emails land in junk, and DMARC makes it harder for someone to send fake invoices in your name.
Common mistakes
- Two SPF records on one domain. A domain may have only one SPF record. Adding a second for a new newsletter tool makes both invalid. Merge them into one.
- Exceeding SPF’s lookup limit. SPF allows only ten DNS lookups. Each “include” for another sending service uses some, and going over causes failures.
- Deleting verification records during a tidy-up. A record that looks like random characters may be what keeps you verified in Search Console. Remove it and access is lost when the service rechecks.
- Losing records in a nameserver move. Switching DNS provider without copying every TXT record breaks verification and email authentication at the same moment.
- Typing the value into the wrong host field. Some providers add your domain automatically, so entering the full domain as the host creates a record for yourdomain.co.uk.yourdomain.co.uk.
How to act on it
Look up your domain’s TXT records using your DNS provider’s dashboard or a free public lookup tool, and list what each one does. Check there is exactly one record starting v=spf1, that it names every service that sends email for you, and that a DMARC record exists at _dmarc. If you are unsure what a record is for, ask before deleting it.
When you change DNS provider or host, export the full zone first and compare it after the move. Setting up a Search Console domain property and checking the DNS records behind it is a routine first step in my technical SEO work.