TXT Record Lookup

TXT records hold arbitrary text data in DNS. Any domain can publish TXT records at the root name or any subdomain — the DNS protocol imposes no constraint on content — which is why TXT records became the universal substrate for domain ownership verification. Google Workspace, Microsoft Entra ID (Azure AD), Stripe, Atlassian, HubSpot, and dozens of other platforms ask you to add a specific string as a TXT record to prove you control a domain during onboarding. This tool returns every TXT record published at the hostname you enter, exactly as a live resolver sees them right now.

Email authentication records

Three of the most security-relevant settings for any domain live in TXT records:

• SPF (Sender Policy Framework) — published at the apex domain (e.g., example.com). Specifies which mail servers are authorized to send email using that domain in the From address. A typical SPF record starts with v=spf1 and lists IP ranges or includes references to third-party providers: v=spf1 include:_spf.google.com ~all. A domain should have exactly one SPF record; multiple SPF records cause receivers to fail SPF evaluation.
• DKIM (DomainKeys Identified Mail) — published at a selector subdomain like selector1._domainkey.example.com. Contains a public key (v=DKIM1; k=rsa; p=...) that receiving mail servers use to verify the cryptographic signature added to messages by the sending server. Different mail providers use different selectors; querying the exact selector subdomain named in a message's DKIM-Signature header returns the relevant key.
• DMARC — published at _dmarc.example.com. Defines what receiving servers should do with messages that fail both SPF and DKIM: p=none (monitor only, take no action), p=quarantine (send to spam), or p=reject (block the message). Checking whether DMARC is present and at which policy level is a first-line diagnostic for deliverability problems.

Misconfigured SPF, DKIM, and DMARC records are one of the most common causes of legitimate email ending up in spam or being rejected outright. Querying TXT records directly shows the exact published values — no guessing whether a change you made in your DNS provider's control panel actually propagated.

Platform verification tokens

SaaS platforms verify domain ownership by asking administrators to publish a platform-specific string as a TXT record. Google publishes tokens like google-site-verification=abc123.... Microsoft Entra uses MS=msXXXXXXXX. Stripe and Atlassian use their own prefixes. Once the platform detects the record, it marks the domain as verified and removes the requirement — but the record often stays in DNS long after the verification is complete. Querying TXT records at a domain shows all currently published tokens, which is also useful for auditing what third-party verifications are active on a domain you've taken over or are reviewing.

ACME challenge records

Let's Encrypt and other ACME certificate authorities can verify domain control using DNS. The ACME client publishes a specific token as a TXT record at _acme-challenge.yourdomain.com, the CA checks for it, then the client removes it. If a certificate renewal is failing with a DNS challenge error, querying _acme-challenge.yourdomain.com tells you immediately whether the record was published and whether the value matches what the ACME client logged.

Long TXT records and quoted segments

The DNS protocol limits each string segment in a TXT record to 255 bytes. Records longer than 255 characters — which is common for DKIM public keys (typically 256 or more characters for RSA-2048 keys) — are split into multiple quoted string segments at the protocol level. Resolvers and email servers concatenate the segments transparently. When this tool or any DNS query tool shows a value in multiple quoted parts, that is normal DNS behavior, not a misconfiguration.