TXT records hold text in a domain’s DNS. Nobody reads them directly, but email providers, search engines and software services check them constantly: to see which servers may send your email, how to handle fakes, and whether you really own the domain you signed up with. The lookup above lists every TXT record on a domain, explains what each one is for, and also checks the standard email names such as _dmarc, so you see the whole picture in one place.

What TXT Records Are For

A TXT record can hold any text, which is why so many different systems use them. Most TXT records you’ll find fall into a few groups:

• Email sending rules: SPF lists the servers allowed to send email for the domain
• Email policy: DMARC, published at _dmarc, tells receivers what to do with email that fails checks
• Email signing keys: DKIM public keys, published under a selector name such as google._domainkey
• Ownership checks: codes from Google, Microsoft, Facebook, Apple, Stripe and many others that prove you control the domain
• Newer email standards: MTA-STS and TLS reporting for encrypted delivery, and BIMI for showing your logo beside your email

How to Read Your Result

Each record is shown exactly as published, with its TTL and a line saying what it’s for. We recognize SPF, DMARC, DKIM, BIMI and MTA-STS records, and verification codes from more than 60 services. A record we can’t identify is labeled as a plain text record, which usually means a less common service or a custom note.

For a root domain, the lookup also checks _dmarc, _mta-sts, _smtp._tls and default._bimi, the standard names where email records live. Anything published there appears in its own section below the main records.

Verification Records

When you connect a domain to a service, such as Google Search Console, Microsoft 365, a payment provider or a design tool, the service often asks you to add a TXT record with a unique code. It then looks the code up to confirm you control the domain.

Most services only check once, at setup, though some check again from time to time and will unlink the domain if the code disappears. Before deleting a verification record, make sure the service is no longer in use. Old codes for services you’ve cancelled are harmless, but removing them keeps your records easier to read.

The Rules for TXT Records

A domain can have as many TXT records as it needs, but a few types have strict rules. There must be only one SPF record on a domain. Two SPF records make SPF fail for all of the domain’s email, so new services must be added to the existing record rather than as a second one.

Likewise, there must be only one DMARC record, and it must be at _dmarc, not on the domain itself. A DMARC record on the root domain is ignored. The lookup flags these mistakes and links to our SPF and DMARC checkers for a closer look.

Long TXT Records

A single piece of text in a TXT record can be at most 255 characters. Longer values, such as DKIM keys and long SPF records, are split into several pieces that are joined back together when read. Most DNS providers do this automatically when you paste a long value.

If yours doesn’t, you may need to split the value yourself into quoted pieces of 255 characters or fewer. The lookup shows the joined value and notes when a record is long enough to have been split, which helps when a long key isn’t working and you suspect it was cut short.

TXT Records on Subdomains

TXT records aren’t limited to the root domain. Email standards use fixed names under the domain, such as _dmarc for DMARC and a selector followed by _domainkey for each DKIM key. Some services also ask for a record on a subdomain, such as _github-challenge or a name they generate, so their check doesn’t clutter the root.

If a service asks for a TXT record on a specific name, enter that name in the lookup, such as _dmarc.example.com, to see exactly what is published there. Subdomains used for sending email, like mail.example.com or news.example.com, can also have their own SPF and DMARC records.

How Long TXT Changes Take

A new TXT record usually appears within a few minutes. A changed or deleted record can take longer, up to its TTL, because resolvers keep the old answer until it expires. If a service still sees an old verification code or an old SPF record, check the TTL shown in the lookup: that’s the longest you’ll need to wait. Lowering the TTL a day before a planned change makes future updates spread faster.

How to Add a TXT Record

In your DNS provider’s dashboard, add a new record, choose TXT as the type, and paste the value exactly as the service gave it, without adding extra quotation marks unless your provider asks for them. For the host or name, use @ or leave it blank for the root domain, or enter the name the service specifies, such as _dmarc.

After saving, run the lookup. If the new record doesn’t appear yet, wait a few minutes and try again. Most services will tell you if they can’t find the record, and a quick lookup shows whether it was published on the right name.

Common TXT Record Problems

When a service says it can’t find your TXT record, the cause is usually one of these:

• The record was added to the wrong name, often with the domain repeated, such as _dmarc.example.com.example.com
• Extra quotation marks or spaces were pasted in with the value
• A second SPF record was created instead of editing the existing one
• The DNS change hasn’t spread yet, because the old answer is still cached
• The record was added at the registrar while the domain’s name servers point to a different DNS provider

The last one catches many people. Your records live wherever your name servers point, which isn’t always where you bought the domain. Our DNS Lookup shows your name servers and who runs them. Nothing you look up here is saved or linked to you.