TXT Record Lookup

Look up a domain's TXT records: every value read and named, who asked for it, whether it may go, and the set's size on the wire.

From the zone's own nameserver · RFC 1035, 7208

Live from the zone's own server

Every TXT value read and named. A domain, or a name such as _dmarc.example.com.

Try

How we look it up 4 steps · about 1 s

  1. Root13 root servers
  2. TLDthe registry's servers
  3. Nameserverthe domain's own servers
  4. Answerevery TXT record
  5. Google8.8.8.8
  6. Cloudflare1.1.1.1

Every lookup walks the path itself: from a root server to the TLD's registry, then to the domain's own nameservers for the TXT records as they are now, and asks Google and Cloudflare what they still cache.

TXT Record Lookup: github.com's path from the root, then its TXT records grouped by kind, the SPF record's two strings marked, beside the navy column of who asked for themTXT Record Lookup: github.com's path from the root, then its TXT records grouped by kind, the SPF record's two strings marked, beside the navy column of who asked for themThe path from the rootThe lookup's own walk: a root server, the registry, the zone's nameserver, then what Google and Cloudflare cache.Every value, namedEach record with its kind, the service that asked for it, its bytes and TTL, and every 255-byte string boundary as sent.Who asked for thisThe services behind the verification tokens, how many each holds, and what their own docs say about keeping them.Four viewsThe records by kind, the email names beside the domain, the size on the wire against the UDP limits, and the commands.
github.com on 2026-11-01: 24 TXT records, 2,140 bytes, over the 1,232 bytes UDP carries, so resolvers ask again over TCP.

What is a TXT record?

A TXT record holds text at a DNS name. Each record is one or more character-strings of up to 255 bytes each, and a name can hold many records: together they are the name's TXT set.

RFC 1035 defined TXT for free text. Today almost every value has a job: an SPF policy at the domain, a DMARC policy at _dmarc, a DKIM key at selector._domainkey, or a token a service asked you to publish to prove you control the domain.

The 255-byte limit is per string, not per record (RFC 1035 §3.3.14). A longer value goes out as several strings inside one record, and SPF and DKIM join them with nothing between (RFC 7208 §3.3, RFC 6376 §3.6.2.2). Most DNS hosts split a long value for you.

One TXT recordgithub.com. 300 IN TXT
  1. 255length byte
    String 1 · 255 bytesv=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2
  2. 65length byte
    String 2 · 65 bytes27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all
What receivers read: the strings joinedv=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all
  • 320 bytes of text in 2 strings
github.com's SPF record as its nameserver sent it on 2026-11-01: one record, two strings, each after its length byte.

How to look up TXT records

Type a domain above, or a name such as _dmarc.example.com. The lookup asks the domain's own nameserver, Google Public DNS and Cloudflare, and reads every value. From a terminal, dig TXT, nslookup -type=TXT and Resolve-DnsName -Type TXT ask the same question.

Answers can differ between those places. A resolver keeps its copy for the record's TTL, so after a change Google's or Cloudflare's copy may show the old set until that runs out. The domain's own nameserver always has the current set, which is why the lookup reads that one.

dig prints each string in its own quotes: "v=spf1 …" "… -all" is one record with two strings, not two records.

  • The zone's own serverns-421.awsdns-52.com242,140 B5 min
  • Google Public DNSdns.google241,917 B5 min
  • Cloudflare DNSone.one.one.one241,928 B226 s

The same lookup from a terminal

dig github.com TXT +short

+short prints only the values

The three copies of github.com's TXT set, asked on 2026-11-01: the same 24 records, each place's own answer size and the TTL left.

What TXT record values mean

A value says what it is in its first characters: v=spf1 is SPF, v=DMARC1 DMARC, v=DKIM1 a DKIM key, v=BIMI1 BIMI, v=STSv1 MTA-STS and v=TLSRPTv1 TLS reporting. Most of the rest are verification tokens such as google-site-verification=… or MS=….

The lookup names each value by that start, the way receivers and services read it. A value that starts any other way is free text or a token from a service we don't know, and the page says so instead of guessing.

A value that almost matches is a mistake worth fixing: a space before v=spf1, or quotes typed into the value, make receivers skip the record.

  • SPFexample.comv=spf1 include:_spf.example.net ~all
  • DMARC_dmarc.example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.com
  • DKIMs1._domainkey.example.comv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…
  • BIMIdefault._bimi.example.comv=BIMI1; l=https://example.com/brand/logo.svg
  • MTA-STS_mta-sts.example.comv=STSv1; id=20261101
  • TLS-RPT_smtp._tls.example.comv=TLSRPTv1; rua=mailto:tls-reports@example.com
  • Verificationexample.comgoogle-site-verification=Xk2wPq7Lm9Vb3Nc8Rt5Yh1Jd6Fs4Ga0Ze2Ur7Io3Qp
  • ACME_acme-challenge.example.comgfj9Xq5Rg85nM2bT7wLk0pYc3Vs8Hd1Ju6Ne4Ao9Ci
  • Sender IDexample.comspf2.0/pra include:_spf.example.net ~all
  • Textexample.comkept by the ops team, ask before removing
Made-up example.com values, each named by the lookup's own reader, with the name it lives at.

Which TXT records can I delete?

Verification tokens prove to a service that you control the domain. Whether one must stay depends on the service: some check again later and drop the verification when the token is gone, others read it once.

The table lists the services the lookup knows, the start of each one's token and what its own documentation says about keeping it. Where the documentation doesn't say, keep the token unless you know you no longer use the service: removing one a service still checks can cut off its sign-in, mail or admin features.

Several tokens from one service are normal, since each account or property gets its own, so the lookup counts them and never calls one stale. A value nobody documents may belong to an old project: ask your team before removing it.

94 services: 25 say keep it, 16 say it may go once verified, 53 don't sayKeepMay goUnclear

  • Ahrefs Webmaster Tools / Site Auditahrefs-site-verification_Keep
  • Airtableairtable-verification=Keep
  • Amazon SESamazonses:Keep
  • Apple Business (Apple Business Manager) domain verificationapple-domain-verification=Keep
  • Atlassian Cloudatlassian-domain-verification=Keep
  • Atlassian custom email domainatlassian-sending-domain-verification=Keep
  • Brevo (ex-Sendinblue) domain authenticationbrevo-code:Keep
  • Cloudflareat cloudflare-verify.…Keep
  • Detectifydetectify-verification=Keep
  • Firebase Hostinghosting-site=Keep
  • GitHub Pagesat _github-pages-challenge-…Keep
  • GitLab Pagesgitlab-pages-verification-code=Keep
  • Google Search Consolegoogle-site-verification=Keep
  • HubSpothubspot-developer-verification=Keep
  • Jamf Accountjamf-site-verification=Keep
  • Loader.ioloaderio=Keep
  • Miromiro-verification=Keep
  • Mixpanelmixpanel-domain-verify=Keep
  • Oracle Health (Cerner) Millennium Platform app registrationcerner-client-id=Keep
  • Postmanpostman-domain-verification=Keep
  • Shopifyshopify-verification-code=Keep
  • Stripestripe-verification=Keep
  • Tailscaleat _tailscale-challenge.…Keep
  • Twilio Organizations domain verificationtwilio-domain-verification=Keep
  • Yandex Webmasteryandex-verification:Keep
  • Azure Front Doorat _dnsauth.…May go
  • Cisco Duo Single Sign-Onduo_sso_verification=May go
  • Cisco Webex Control Hubcisco-ci-domain-verification=May go
  • Cloudflare for SaaSat _cf-custom-hostname.…May go
  • Dockerdocker-verification=May go
  • Docusigndocusign=May go
  • DynatraceDynatrace-site-verification=May go
  • GitHubat _github-challenge-…May go
  • Google Workspace domain verificationgoogle-site-verification=May go
  • Have I Been Pwnedhibp-verify=dweb_May go
  • Microsoft 365 custom domainMS=ms…May go
  • Pinterestpinterest-site-verification=May go
  • Salesforce custom domain00D…May go
  • Sitecore Cloud Portalsitecore-domain-verification=May go
  • Zoho Mail domain verificationzoho-verification=May go
  • ZoomZOOM_verify_May go
  • 1Password1password-site-verification=Unclear
  • Adobe Admin Consoleadobe-idp-site-verification=Unclear
  • Anthropicanthropic-domain-verification-Unclear
  • Atlassian Statuspagestatus-page-domain-verification=Unclear
  • Azure App Service custom domainat asuid.…Unclear
  • Azure Communication Services Emailms-domain-verification=Unclear
  • Boxbox-domain-verification=Unclear
  • Calendlycalendly-site-verification=Unclear
  • Canvacanva-site-verification=Unclear
  • Citrixcitrix-verification-code=Unclear
  • Cursorcursor-domain-verification-…=Unclear
  • Dropboxdropbox-domain-verification=Unclear
  • Dynamics 365 Customer Insights - Journeys (formerly Dynamics 365 Marketing) domain authenticationd365mktkey=Unclear
  • GlobalSignglobalsign-domain-verification=Unclear
  • Google Workspace admin account recoverygoogle-gws-recovery-domain-verification=Unclear
  • GoTo (LogMeIn) Organization Centerlogmein-verification-code=Unclear
  • HackerOneh1-domain-verification=Unclear
  • HashiCorp Cloud Platformhcp-domain-verification=Unclear
  • HPE GreenLake cloudhpe-greenlake-domain-verification=Unclear
  • HubSpothubspot-domain-verification=Unclear
  • Infoblox SSO Portalinfoblox-domain-mastery=Unclear
  • Keybasekeybase-site-verification=Unclear
  • KnowBe4knowbe4-site-verification=Unclear
  • Krispkrisp-domain-verification=Unclear
  • Linearlinear-domain-verification=Unclear
  • LiveRampliveramp-site-verification=Unclear
  • Loomloom-site-verification=Unclear
  • LucidLinklucidlink-verification=Unclear
  • Mail.ru: VK WorkSpace (Mail.ru for business) domain verificationmailru-domain:Unclear
  • Mailchimp Transactional (Mandrill) sending-domain verificationmandrill_verify.Unclear
  • Meta (Facebook) Business domain verificationfacebook-domain-verification=Unclear
  • Microsoft Entra External ID SAML/WS-Fed IdP federationDirectFedAuthUrl=Unclear
  • MongoDB Atlasmongodb-site-verification=Unclear
  • Netlifyat netlify-challenge.…Unclear
  • Notionnotion-domain-verification=Unclear
  • Official MCP Registry (Model Context Protocol): DNS publisher authenticationv=MCPv1;Unclear
  • OneTrustonetrust-domain-verification=Unclear
  • OpenAIopenai-domain-verification=Unclear
  • Parallels My Accountparallels-domain-verification=Unclear
  • Pendopendo-domain-verification=Unclear
  • Proton Mailprotonmail-verification=Unclear
  • Salesforce Marketing Cloud Account Engagement (Pardot) domain validationpardot…Unclear
  • Salesforce Marketing Cloud EngagementSFMC-Unclear
  • Segmentsegment-site-verification=Unclear
  • Shopifyat shopify_verification.…Unclear
  • Slackslack-domain-verification=Unclear
  • Smartsheetsmartsheet-site-validation=Unclear
  • TeamViewerteamviewer-sso-verification=Unclear
  • TikTok for Developerstiktok-developers-site-verification=Unclear
  • Vercelvc-domain-verify=Unclear
  • Webflowone-time-verification=Unclear
  • WorkOS domain verification…-domain-verification-…=Unclear
  • Zapierzapier-domain-verification-challenge=Unclear
Every verification token the lookup names, with the start of its value (or the name it lives at) and what its service's own documentation says, read on 2026-11-01.

Long TXT records and the 255-character limit

One string holds at most 255 bytes. A long SPF policy or a 2048-bit DKIM key must be split into several strings inside one record, never into several records.

Receivers join the strings of one record with nothing between them. So a split must fall where the joined text still reads right: inside a name is fine (include:_spf.goo + gle.com), but ending one string with include:a.example and starting the next with include:b.example glues them into include:a.exampleinclude:b.example, which no receiver can read.

Split records are worse. Two v=spf1 records are a permanent error (RFC 7208 §4.5), the second half of an SPF record published as a record of its own is ignored, and a DKIM key split into two records can't verify anything.

Joins cleanly

  1. String 1 · 240 Bv=spf1 ip4:192.0.2.0/24 … include:_spf.example.net+ space
  2. String 2 · 29 Binclude:_spf.example.org -all

Joined

… include:_spf.example.net include:_spf.example.org -all

Glued at the boundary

  1. String 1 · 239 Bv=spf1 ip4:192.0.2.0/24 … include:_spf.example.net
  2. String 2 · 29 Binclude:_spf.example.org -all

Receivers read this term

include:_spf.example.netinclude:_spf.example.org -all

Split into two records: the tail is ignored

  1. v=spf1 ip4:192.0.2.0/24 … include:_spf.example.net
  2. include:_spf.example.org -all
A made-up SPF record split into two strings, read by the lookup's own engine: once with a space kept at the boundary, once glued, and once split into two records.

How many TXT records is too many?

DNS sets no limit on the number, but a name's whole TXT set goes out in one answer. Over 1,232 bytes, the size DNS Flag Day 2020 settled on for UDP, resolvers get a truncated answer and ask again over TCP (RFC 7766).

That costs a round trip, and a network that blocks DNS over TCP gets no answer at all. Without EDNS (RFC 6891), UDP carries only 512 bytes (RFC 1035 §4.2.1).

Big companies' sets are well over: measured on 2026-11-01, 7 of these 8 apex TXT sets need TCP. Removing the tokens of services you no longer use is the way down.

  1. google.com1,187 B17 records
  2. github.com1,928 B24 records
  3. apple.com2,149 B23 records
  4. cloudflare.com2,539 B29 records
  5. stripe.com2,971 B39 records
  6. dropbox.com4,482 B49 records
  7. microsoft.com4,660 B60 records
  8. atlassian.com8,233 B98 records
Apex TXT sets measured over TCP at 8.8.8.8 on November 1, 2026, with the 512-byte and 1,232-byte limits.

TXT records for email

Six email standards live in TXT records, each at its own name. A record at the wrong name does nothing: receivers look only where its standard says.

SPF sits at the domain and lists who may send its mail; DMARC at _dmarc says what receivers do with mail that fails; DKIM keys at selector._domainkey; BIMI at default._bimi; MTA-STS at _mta-sts, with its policy file on mta-sts. over HTTPS; TLS-RPT at _smtp._tls.

The lookup asks every one of those names beside the domain (the Names view). For a full check of one, open its checker.

  • SPFexample.comv=spf1 include:_spf.example.net -allSPF Checker
  • DMARC_dmarc.example.comv=DMARC1; p=quarantine; rua=mailto:dmarc@example.comDMARC Checker
  • DKIMs1._domainkey.example.comv=DKIM1; k=rsa; p=MIIBIjANBgkq…DKIM Checker
  • BIMIdefault._bimi.example.comv=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pemBIMI Checker
  • MTA-STS_mta-sts.example.comv=STSv1; id=20261101MTA-STS Checker
  • TLS-RPT_smtp._tls.example.comv=TLSRPTv1; rua=mailto:tls-reports@example.comMTA-STS Checker
The six email records on a made-up example.com, each at its own name, read by the lookup's own engine.

TXT record questions

How do I check a domain's TXT records?

Enter the domain in the TXT Record Lookup above: it reads the records from the domain's own nameserver and names every value. From a terminal, run dig example.com TXT, nslookup -type=TXT example.com or, in PowerShell, Resolve-DnsName example.com -Type TXT.

Can I remove Google's site verification TXT record?

It depends on which Google service asked, and the google-site-verification= value is the same form for both, so a lookup can't tell. Google Search Console says: "Important: To stay verified, don't remove the DNS record from your provider, even after verification succeeds." Removing it ends that verification at Google's next check. Google Workspace says of its sign-up verification: "Once verified, the TXT record can be safely removed." If you use Search Console for the domain, keep it.

How many TXT records can a domain have?

DNS sets no limit on the number. The whole set must fit one answer, at most 65,535 bytes even over TCP (RFC 1035 §4.2.2), and over 1,232 bytes resolvers have to ask again over TCP. DNS hosts may set their own limits.

What is the 255-character limit on TXT records?

Each character-string in a TXT record holds at most 255 bytes (RFC 1035 §3.3.14), but a record can hold several strings. A longer SPF value or DKIM key is split into strings inside one record, which receivers join with nothing between them.

Why do two SPF records break email?

A receiver that finds more than one v=spf1 record at a name stops with a permanent error (RFC 7208 §4.5), so SPF fails for all of the domain's mail. Merge every sender into one record.

How long do TXT record changes take to show?

The domain's own nameservers serve a change at once. Resolvers that cached the old set keep it until its TTL runs out, so a change can take up to the old record's TTL to reach everyone. The lookup shows each cached copy's countdown.

Is an SPF record a TXT record?

Yes. SPF records must be published as TXT records only (RFC 7208 §3.1). A separate SPF record type existed during SPF's experimental phase and was discontinued.

Do TXT records affect my website?

No. Browsers don't read TXT records to load a page; they hold text for mail servers and other services. Changing or removing one can affect those services, such as mail delivery or a service's verification, but not how the site loads.

Missing something?Suggest a feature or a new tool