TXT Record Lookup

A TXT record is a DNS record that holds text attached to a name. It was meant for notes to humans, but today it mostly carries instructions for machines: which servers may send your email (SPF), what receivers should do with mail that fails authentication (DMARC), the public key that signs your mail (DKIM), and one-off tokens that prove to a service such as Google Workspace or Microsoft 365 that you control the domain.

This tool asks a recursive DNS resolver for all TXT records at the exact name you enter and shows each record as it is published, with its TTL. Records we recognize get a label. The raw answer, the resolver that gave it and the timing are in the Raw evidence panel under the result, so you can check our reading yourself.

The name matters. TXT records are not all stored at your domain itself. A lookup of example.com shows the SPF record and verification tokens, but not DMARC or DKIM, which live at their own names:

The DKIM selector is chosen by whoever signs your mail (for example google for Google Workspace, or selector1 and selector2 for Microsoft 365). You find it in the s= tag of the DKIM-Signature header of a message you sent.

A lookup shows what is published. It does not judge whether your SPF or DMARC policy is well built: a record can exist and still be wrong. The labels only tell you what a record is and whether receivers will even read it.

The panel at the top of the result is the verdict: a colored icon and a short label. A TXT lookup has three possible verdicts: Pass, Warning and Could not check. It never shows Fail, because finding records, finding none or getting no answer are the only things a lookup can observe.

Pass: TXT records found

The name has at least one TXT record, and each one is listed with its label and TTL. Pass means the records exist, not that they are correct. Read the labels:

• SPF record, DMARC policy, DKIM public key and similar labels mean receivers will read the record as that kind of record.
• “Looks like …, but receivers ignore it” means the record is close to a real one but has no effect. Typical causes: a space before v=spf1, no space after it as in v=spf1include:_spf.google.com ~all, or the DMARC version written in lower case, such as v=dmarc1; p=none (receivers require v=DMARC1).
• “… receivers look for it only at …” means the record is at the wrong name, for example a DMARC policy published at example.com instead of _dmarc.example.com. Move it to the name shown in the label.
• Verification token marks records that prove domain ownership to a service. They do nothing for email delivery.
• Records marked “Other text” use a format we do not know. That is normal; many services use their own formats.

Warning: no TXT records found

The resolver answered, and the answer was that there are no TXT records at this name (shown as NODATA: NOERROR with an empty answer), or that the name does not exist at all (NXDOMAIN). The most common reasons:

• a typo in the name, or a missing prefix (_dmarc., selector._domainkey.);
• the record was added at a different name than intended. If you type _dmarc.example.com into a Host field that already adds your domain, the record ends up at _dmarc.example.com.example.com;
• the record was added at a DNS provider that is not the one your domain actually uses (see below);
• the record is new and resolvers still remember the earlier “no record” answer. That memory is called negative caching. The result shows how much longer the resolver we asked may keep it; other resolvers count their own time, usually minutes to an hour.

A missing TXT record is not always a problem. A domain that never sends email does not need SPF, but it is still good practice to publish v=spf1 -all on it so nobody can send mail in its name.

Warning: the name is an alias to a name that does not exist

The name you entered has a CNAME record, so DNS follows it to another name, and that other name does not exist. Receivers get nothing back. This usually happens after a service is canceled: for example, a DKIM record published as a CNAME to an email provider that no longer hosts your key. Point the CNAME to the value your provider gives you now, or delete it if the service is no longer used.

Warning: CNAME at the top of the zone

The name you entered is the top of its DNS zone (for example example.com itself) and it has a CNAME record. The top of a zone must also hold SOA and NS records, and a name with a CNAME may hold nothing else, so many DNS servers will hide or refuse the other records, TXT and MX included. Replace the CNAME with A and AAAA records, or use your provider's flattening feature (Cloudflare calls it CNAME flattening), which answers with addresses instead of a CNAME.

Warning: CNAME next to other records

The name has a CNAME record and other records at the same time. A CNAME turns a name into an alias, and an alias may not have records of its own (RFC 1034 §3.6.2, RFC 2181 §10.1). Different DNS servers then give different answers. Keep either the CNAME or the other records.

Could not check

The resolver did not give a usable answer: it timed out, returned a server failure (SERVFAIL), refused the query, or sent something we could not decode safely. This says nothing about whether the records exist. We never turn a missing answer into a pass or a fail. Try again in a minute. If the failure stays, the usual causes are that your domain's DNS servers are unreachable, or that DNSSEC is broken (for example, the DS record at your registrar no longer matches the keys at your DNS provider).

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to [email protected] with the address of the result page, and we will fix it.

TTL: how long resolvers keep the answer

Each record comes with a TTL in seconds. Resolvers may reuse the answer for that long, so after you change a record, some people may see the old value until the TTL runs out. The TTL we show is the remaining time in the resolver's cache, so it can be lower than the value set at your DNS provider.

Long records split into several strings

One text string inside a TXT record can be at most 255 characters long (RFC 1035 §3.3). Longer values, such as 2048-bit DKIM keys, are published as several quoted strings inside one record, and we show them exactly like that: "v=DKIM1; k=rsa; p=MIIBIjANBg…" "…IDAQAB". SPF and DKIM join the strings without adding spaces (RFC 7208 §3.3, RFC 6376 §3.6.2.2). Many DNS dashboards split long values for you. Two separate TXT records are not the same as one record with two strings: SPF allows only one record.

These rules apply at every DNS provider:

1. Add the record where your DNS is hosted. That is the provider your domain's NS records point to, which is not always the company you bought the domain from. Records added anywhere else have no effect.
2. Enter only the part of the name before your domain. Use @ for the domain itself and _dmarc for _dmarc.example.com. Most dashboards add your domain to whatever you type.
3. Paste the value without surrounding quotes unless your provider asks for them. The quotes are only how records are written in zone files; they are not part of the text.
4. Keep one SPF record per name. To authorize a new sender, add its include: to your existing SPF record instead of creating a second one. With two SPF records, SPF returns an error for every message (permerror, RFC 7208 §4.5), so your mail no longer passes SPF. The same goes for DMARC: when there is more than one record at _dmarc, receivers ignore all of them (RFC 9989 §4.10).
5. Check the result by looking up the name here. A new record is usually visible within minutes, but resolvers that already cached the old answer can keep it until its TTL runs out.

Cloudflare

1. In the Cloudflare dashboard, open your domain and go to the DNS Records page.
2. Select Add record and choose TXT as the Type.
3. In Name, enter @ for the domain itself, or the prefix, for example _dmarc.
4. In Content, paste the value. If you leave out the quotes, Cloudflare adds them for you.
5. Leave TTL on Auto unless you have a reason to change it, and select Save. TXT records have no proxy setting: only A, AAAA and CNAME records can be proxied.

GoDaddy

1. Sign in to your GoDaddy Domain Portfolio and select the domain to open its Domain Settings.
2. Select DNS, then Add New Record, and choose TXT in the Type menu.
3. In Name, enter @ for the root domain, or the prefix, for example _dmarc.
4. In Value, paste the text. The default TTL of 1 hour is fine.
5. Select Save. If Domain Protection is on, GoDaddy asks you to confirm your identity first.

Namecheap

1. Sign in, open Domain List, and select Manage next to your domain.
2. Open the Advanced DNS tab and select Add New Record.
3. Choose TXT Record. In Host, enter @ for the domain itself or only the prefix, for example _dmarc or selector1._domainkey. Do not include the domain name.
4. Paste the text into Value and select Save all changes. Namecheap says new records normally take effect within 30 minutes.

Google Workspace

Google Workspace gives you the records; you add them at your DNS provider using the steps above.

• Domain verification: in the Google Admin console go to Menu > Account > Domains > Manage domains, select Verify domain and copy the value, including google-site-verification=. Add it as a TXT record at @. Google says it can take up to 72 hours to be detected, and that the record can be removed once the domain is verified.
• SPF: Google's recommended record, at @:

v=spf1 include:_spf.google.com ~all

If you already have an SPF record, add include:_spf.google.com to it instead of adding this one.

Microsoft 365

• Domain verification: in the Microsoft 365 admin center go to Settings > Domains, select + Add domain, and choose to verify with a TXT record. The wizard shows a value in the form MS=ms12345678; add it as a TXT record at @. Microsoft says verification can take up to 10 minutes, and up to 48 hours at some registrars.
• SPF: Microsoft's record for Microsoft 365, at @ with TTL 3600:

v=spf1 include:spf.protection.outlook.com -all

If an SPF record already exists, Microsoft asks you to add the Microsoft 365 value to it, so that there is a single SPF record. A domain that sends through both Google Workspace and Microsoft 365 publishes one record with both includes:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

~all asks receivers to treat mail from other servers as suspicious, -all asks them to reject it. Both are valid; use one of them, at the end of the record.

You can run the same lookup on your own computer. On macOS and Linux, dig is the usual tool; +short prints only the records:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig @1.1.1.1 TXT example.com +short

The last line asks a specific public resolver (here Cloudflare's 1.1.1.1) instead of the one your network uses, which helps when you suspect an old cached answer. On 22 September 2026 the first command returned:

"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
"v=spf1 -all"

nslookup works on Windows, macOS and Linux. Add a resolver address at the end to ask a specific server:

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com 1.1.1.1

In Windows PowerShell:

Resolve-DnsName -Name example.com -Type TXT
Resolve-DnsName -Name _dmarc.example.com -Type TXT -Server 1.1.1.1

Command-line tools print each string of a long record separately, in quotes. Join them without spaces to get the value that SPF and DKIM read.