TXT Record Lookup

Find all Text (TXT) records for a domain, typically used for domain verification, SPF, and DMARC.

About TXT Records

TXT (text) records allow administrators to insert arbitrary text into DNS records. Over time, this record type has been co-opted to serve multiple security and verification purposes.

Common uses include Domain Verification (proving to services like Google Workspace or Microsoft 365 that you own the domain), SPF (Sender Policy Framework to prevent email spoofing), and DMARC policies.

Our TXT Record Lookup returns every DNS text record published on a domain — SPF, DMARC, DKIM, domain verification strings and any custom values. Use it to inspect the exact raw text a resolver sees, which is essential when debugging email authentication.

What is a TXT Record?

A TXT record is a DNS record that holds arbitrary text. It was originally created for human-readable notes, but in practice it has become the universal carrier for machine-readable policy data.

Almost every modern domain-based verification and email security mechanism rides on TXT records: SPF declares which servers may send mail, DMARC declares what to do when authentication fails, DKIM publishes public keys, and services from Google to Microsoft to AWS ask you to publish a token to prove you own a domain.

A single TXT record is limited to 255 characters per string, but a record may contain several strings that resolvers concatenate. A domain may publish many TXT records at the same name.

Stores arbitrary text data at any DNS name
Carries SPF, DMARC, DKIM, BIMI and MTA-STS policies
Used by most providers for domain ownership verification
Each string is limited to 255 characters; multiple strings are joined
A name can hold several TXT records at once

Why TXT Records Matter

Because TXT records carry email authentication policy, a mistake in one directly causes mail to be rejected, spoofed, or silently dropped. A malformed SPF record can break delivery for an entire company in minutes.

They are also the most cluttered part of a typical DNS zone. Verification tokens accumulate for years after the service that needed them is gone, and duplicate SPF records — which are invalid — are one of the most common email misconfigurations on the internet.

A broken SPF or DMARC TXT record breaks email for the whole domain
Two SPF records at the same name is a permanent error, not a warning
Stale verification tokens leak which vendors an organisation uses
TXT records are publicly readable by anyone, including attackers
Correct TXT records are required by Google and Yahoo bulk sender rules

How This TXT Record Lookup Works

The tool queries DNS for every TXT record published at the name you supply and returns the raw text exactly as resolvers receive it.

Validates the domain input against format and SSRF safety checks
Queries authoritative DNS for all records of type TXT
Joins multi-string records the way a resolver would
Classifies recognised records such as SPF, DKIM and DMARC
Returns the exact raw value so you can spot stray quotes and whitespace

How to Use the TXT Record Lookup

Enter a domain name such as example.com in the input field
For DMARC records, query the _dmarc subdomain directly
For DKIM records, query selector._domainkey under your domain
Run the lookup and review every TXT record returned
Compare the raw value against what you intended to publish

Understanding Your TXT Record Results

TXT records fall into several recognisable categories. Here is how to read the common ones:

Field / Value	Meaning
`v=spf1 ...`	An SPF record listing which servers may send email for the domain. Only one SPF record is permitted per name — a second one invalidates both.
`v=DMARC1 ...`	A DMARC policy, published at _dmarc.yourdomain.com. It defines what receivers should do with mail that fails authentication.
`v=DKIM1 ...`	A DKIM public key, published at selector._domainkey.yourdomain.com. Receivers use it to verify the signature on your outgoing mail.
`Verification token`	A random string such as google-site-verification=... proving domain ownership to a third party. Safe to remove once the service no longer needs it.
`TTL`	How long resolvers cache the record. Lower it to 300 seconds before editing SPF or DMARC so mistakes can be corrected quickly.

Common Problems & How to Fix Them

The SPF specification allows exactly one record per name. When a second one exists, receivers return a permerror and treat SPF as failed entirely — which can also cause DMARC to fail.

Merge every mechanism into a single record. Two records like "v=spf1 include:_spf.google.com ~all" and "v=spf1 include:sendgrid.net ~all" become one: "v=spf1 include:_spf.google.com include:sendgrid.net ~all".

Some DNS control panels add quotation marks automatically while others expect you to supply them. Doubling up produces a value like ""v=spf1 ~all"" which no parser recognises.

Look at the raw output from this tool. If you see stray quotes inside the value, remove the quotes from what you type into the control panel.

DMARC records must be published at _dmarc.yourdomain.com, not at the root. Querying the root will not return it.

Add the record with the name _dmarc and re-run the lookup against _dmarc.yourdomain.com to confirm.

Each TXT string is capped at 255 characters. Longer values — commonly 2048-bit DKIM keys — must be split into multiple quoted strings within one record, which resolvers then concatenate.

Most DNS providers handle this automatically. If yours does not, split the value manually into 255-character chunks, each in its own pair of quotes, with no separator between them.

Verification strings from services you no longer use tell attackers which vendors you work with and make the zone harder to audit.

Review every TXT record, identify which service each token belongs to, and remove the ones for services you have stopped using.

Best Practices

Keep exactly one SPF record per domain — merge all senders into it
Publish DMARC at _dmarc.yourdomain.com, never at the root
Lower the TTL to 300 seconds before editing email authentication records
Remove verification tokens once the service that required them is gone
Check the raw value after every edit to catch stray quotes and whitespace
Document which team or vendor owns each TXT record in your zone
Use 2048-bit DKIM keys and let your provider handle the string splitting

Security Recommendations

Remember every TXT record is world-readable — never store secrets, internal hostnames or credentials in one
Audit verification tokens regularly; stale ones reveal your vendor stack to attackers preparing targeted phishing
Keep SPF within the 10 DNS lookup limit, since exceeding it silently disables SPF entirely
Rotate DKIM keys periodically and remove the old selector once the rotation is complete
Watch for unexpected TXT records appearing in your zone, which can indicate a compromised DNS account
Publish DMARC with enforcement, not just monitoring, once your legitimate senders are aligned

Frequently Asked Questions

A TXT record stores arbitrary text in DNS. In practice it carries email authentication policies such as SPF, DMARC and DKIM, as well as domain ownership verification tokens for services like Google Workspace, Microsoft 365 and AWS.

Yes, and most domains have several. The important exception is SPF: only one record beginning with v=spf1 is permitted per name. Multiple SPF records cause a permanent error and break email authentication entirely.

Each individual string is limited to 255 characters, but a single record may contain multiple strings which resolvers concatenate. This is how 2048-bit DKIM public keys fit into DNS. Most providers split long values automatically.

DMARC records live at _dmarc.yourdomain.com, not at the domain root. Query that exact name. If it still returns nothing, the record may not have propagated yet or may have been published with the wrong name.

Verification tokens for services you no longer use are safe to remove and should be, since they reveal your vendor stack. Never remove SPF, DMARC or DKIM records without understanding what depends on them — deleting an SPF record can immediately break outbound mail delivery.

Changes propagate according to the previous record TTL, typically 5 minutes to an hour, with full worldwide propagation taking up to 48 hours. Lower the TTL to 300 seconds before making email authentication changes.

No. DNS is a public system and anyone can query your TXT records. Never place API keys, passwords, internal hostnames or any confidential information in a TXT record.