What Are TXT Records?
TXT records are a DNS record type that stores arbitrary text strings associated with a domain. Defined in RFC 1035 and extended by later specifications, TXT records were originally designed for descriptive text. Today they serve as the backbone of domain ownership verification, email authentication, and several other internet protocols.
Unlike A records (which map to IP addresses) or CNAME records (which alias to other hostnames), TXT records carry no routing or resolution information. They exist purely as data that services query and validate. A single domain can have multiple TXT records, and DNS resolvers return all matching records for a given name. The querying application processes only the ones it recognizes by matching the exact string content.
Why Services Use TXT Records for Verification
When a service asks you to add a TXT record to verify domain ownership, it is asking you to prove administrative access to the DNS zone. The service generates a unique token, you publish it as a TXT record at a specific hostname, and the service queries DNS to confirm the token exists. If it matches, ownership is proven.
TXT records are ideal because they do not affect website traffic, email delivery, or SSL certificates. Adding a TXT record is non-invasive — it cannot break your site or redirect your mail. Once verified, you can often delete the record without losing ownership, though some services require ongoing presence for periodic re-validation. This makes TXT-based verification the safest and most universal approach across the industry.
Google Search Console Verification
Google Search Console uses TXT records to verify domain ownership before granting access to search data and indexing controls. When you add a property, Google provides a verification string:
google-site-verification=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567
Publish this as a TXT record on your subdomain. For an is-pro.dev subdomain:
myproject.is-pro.dev. TXT "google-site-verification=aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567"
After propagation, click "Verify" in Search Console. Google queries the hostname, finds the token, and grants ownership.
GitHub Pages Domain Verification
GitHub uses DNS-based TXT records for domain verification at the account and organization level. The record uses a challenge prefix:
_github-challenge-myorg.is-pro.dev. TXT "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Once added, GitHub queries that hostname and marks the domain as verified, enabling organization-level domain association and preventing other GitHub users from claiming the same domain. This verification is required before you can enable certain security features like SAML SSO for enterprise organizations.
Let's Encrypt DNS-01 Challenge
The ACME protocol's DNS-01 challenge is the only method that supports wildcard certificates. Your ACME client creates a TXT record at a challenge hostname:
_acme-challenge.myproject.is-pro.dev. TXT "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Let's Encrypt queries DNS for this record. If the token matches, the certificate is issued. For automated renewal, your client must update this record through your DNS provider's API. The is-pro.dev dashboard supports API-based record management for this use case.
Tip: DNS-01 is required for wildcard
certificates like
*.yourproject.is-pro.dev. HTTP-01 validation
uses a file served over port 80 instead.
Cloudflare SSL/TLS Verification
Cloudflare may request a TXT record when you enable SSL/TLS for a domain proxied through their network. When adding a new domain, the platform provides several DNS records to configure, including a TXT verification record for certain features. The verification ensures Cloudflare can issue and renew SSL certificates without interruption. The record is typically one-time, but should remain until the certificate is active and confirmed in the Cloudflare dashboard.
SPF, DKIM, and DMARC as TXT Records
Beyond ownership verification, TXT records power email authentication. SPF publishes authorized sending IPs:
mail.myproject.is-pro.dev. TXT "v=spf1 include:sendgrid.net ~all"
DKIM publishes a public key at a selector
subdomain for cryptographic email signing.
DMARC publishes a policy at
_dmarc telling receivers how to handle
authentication failures. For a full walkthrough, see our
MX, SPF, and DKIM Basics
guide.
Adding TXT Records via is-pro.dev Dashboard
Adding a TXT record through the is-pro.dev dashboard:
- Log in at dash.is-pro.dev.
- Navigate to DNS management for your subdomain.
- Click "Add Record" and select type TXT.
-
Enter the hostname (e.g.,
@for the subdomain root, or_acme-challengefor Let's Encrypt). - Paste the TXT value and save. Changes propagate within seconds on the is-cool-me DNS infrastructure.
Verifying TXT Record Propagation with dig
After adding a TXT record, confirm it is visible:
dig myproject.is-pro.dev TXT +short
This returns all TXT records for the hostname. You should see the verification token you just added. If multiple TXT records exist, dig returns all of them. To query a specific nameserver:
dig @ns1.is-pro.dev myproject.is-pro.dev TXT +short
If dig returns the expected value but verification still fails, the service may be querying a different nameserver with cached results. Wait a few minutes and retry.
Common Issues and Troubleshooting
Verification Fails After Adding the Record
Even on platforms with fast propagation, verification services may cache previous results. Wait five minutes and retry. Most services allow multiple attempts without penalty.
Wrong Hostname or Missing Prefix
The most common mistake is adding the TXT record at the
wrong hostname. If Google asks for
myproject.is-pro.dev and you add it at the
root, verification fails. Always copy the exact hostname
from the verification instructions.
Extra Quotes or Whitespace
Do not add extra spaces, newlines, or additional quotes beyond what the DNS provider requires. Most dashboards handle quoting automatically — paste the raw value.
TTL Causing Stale Cache
If you recently changed a TXT record, resolvers may still
serve the old value until the TTL expires. Use
dig +trace to identify stale data, or wait
for the TTL to elapse.
Frequently Asked Questions
Can I verify without a TXT record?
Some services support HTML file uploads or meta tags, but TXT record verification is the most universal method. It does not require changes to your website's content and is the only option for bare domains without a web server.
Should I keep the TXT record after verification?
It varies. Google Search Console allows deletion but requires re-verification if you lose access. Let's Encrypt challenge records are temporary. Cloudflare may require the record for ongoing SSL management.
How fast do TXT records propagate on is-pro.dev?
TXT records added through the is-pro.dev dashboard propagate almost instantly. External resolvers pick up changes within one to five minutes.
Can I verify a subdomain I do not own?
No. Domain verification requires administrative access to the DNS zone. You must have an active is-pro.dev subdomain allocated to your account.
Need help? See Guides for step-by-step tutorials or join the Discord community for real-time support.