What Is a TXT Record?
A TXT record is a flexible DNS entry that stores arbitrary text associated with a domain, most often used to verify domain ownership and to hold email authentication settings like SPF, DKIM, and DMARC. Because it can contain almost any text, services rely on TXT records to publish machine-readable information tied to a domain. For businesses, TXT records are essential for proving ownership to third-party tools and for keeping outgoing email trusted and out of spam folders.
- Purpose
- Stores arbitrary text data for a domain
- Most common uses
- Domain verification and email authentication
- Email standards held
- SPF, DKIM, DMARC
- Defined in
- DNS standards (IETF RFC 1035)
What is a TXT record? #
A TXT record is a DNS entry designed to hold free-form text tied to a domain. Where an A record stores an IP address and an MX record stores mail server names, a TXT record can store almost any string, which makes it a general-purpose tool for publishing information about your domain that other systems can read. In practice, TXT records are used for two dominant purposes: proving to a third-party service that you own a domain, and holding email authentication policies like SPF, DKIM, and DMARC that keep your outgoing mail trusted. Because they are so flexible, TXT records quietly underpin a lot of modern web and email functionality, from verifying your site in Google Search Console to stopping scammers from spoofing your address. They live on your domain's nameservers with your other records, see /wiki/what-is-a-nameserver, and though they are invisible to visitors, misconfiguring them can break verification or email. We manage TXT records for clients through /services/domains-dns-email as part of a complete domain setup.
What are TXT records used for? #
The two headline uses are verification and email authentication, but the list is broader. Domain verification is ubiquitous: services like Google, Microsoft, and countless SaaS tools ask you to add a specific TXT record to prove you control a domain before they enable features for it, this is how you verify a site in Search Console or connect a marketing platform. Email authentication is the other major use: SPF, DKIM, and DMARC are all published as TXT records and tell receiving servers which servers may send mail for your domain and how to handle suspicious messages, directly affecting whether your email lands in the inbox or spam. Beyond these, TXT records store various policy and configuration values that different services define. What unites them is that they publish machine-readable facts about your domain in a way any system can query. Because these records silently control trust and access, keeping them correct is part of the ongoing DNS care we provide.
TXT records and SPF (Sender Policy Framework) #
SPF, or Sender Policy Framework, is an email authentication method published as a TXT record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to see whether the sending server is on the approved list. If it is, the message passes an important trust check; if not, the message may be flagged or rejected as possible spoofing. For a business using several sending systems, your email provider, a newsletter tool, an invoicing service, the SPF record must include all of them, or legitimate mail can fail. A common mistake is having multiple SPF records (only one is allowed) or omitting a service, both of which hurt deliverability. Getting SPF right is a key step in ensuring customers actually receive your emails. We configure SPF alongside DKIM and DMARC and verify the result with /tools/email-deliverability-checker so nothing legitimate gets blocked.
TXT records and DKIM (DomainKeys Identified Mail) #
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to your outgoing email and publishes the matching public key as a TXT record in your DNS. When a receiving server gets one of your messages, it uses the published key to verify the signature, confirming that the email genuinely came from your domain and was not altered in transit. This provides stronger proof of authenticity than SPF alone. Your email provider generates the DKIM key and gives you a TXT record (often at a selector subdomain) to add to your DNS; once published, your mail is signed and verifiable. DKIM is especially important because DMARC relies on SPF and DKIM results to decide how to treat messages. Missing or broken DKIM weakens your email trust and can push messages to spam. As with SPF, we set up DKIM correctly for each sending service a client uses, and confirm signatures validate, so outgoing email carries full authentication, see /wiki/what-is-an-mx-record for how these records complement incoming mail routing.
TXT records and DMARC #
DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a policy published as a TXT record that ties SPF and DKIM together and tells receiving servers what to do with mail from your domain that fails authentication. You can instruct servers to take no action, quarantine suspicious messages to spam, or reject them outright, and DMARC can also send you reports about who is sending mail using your domain, revealing spoofing attempts. Setting a sensible DMARC policy protects your brand from being impersonated in phishing and improves the reputation of your legitimate mail. Many businesses start with a monitoring-only policy to gather reports, then tighten it as they confirm all their real senders pass. Because DMARC depends on correct SPF and DKIM, it is the capstone of email authentication rather than a standalone fix. We configure DMARC in coordination with the other records, choosing a policy that protects the domain without blocking legitimate mail, and monitor the results as part of /services/domains-dns-email.
TXT records for domain verification #
One of the most frequent things a business owner is asked to do is add a TXT record to verify domain ownership. When you connect a domain to Google Workspace, claim a site in Search Console, set up Microsoft 365, or link many marketing and analytics tools, the service gives you a unique TXT value to publish in your DNS. By checking that the record exists, the service confirms you actually control the domain before granting access or enabling features. These verification records are harmless to leave in place and often required to stay, since removing one can un-verify your domain and disable a connected service. The process is simple but easy to fumble: paste the exact value provided, add it at the authoritative DNS provider, and wait for propagation before clicking verify, see /wiki/what-is-dns-propagation and /wiki/what-is-a-nameserver. We handle these verifications routinely when connecting clients' domains to the tools they use, so setup completes smoothly the first time through /services/domains-dns-email.
Common TXT record mistakes #
TXT records are simple but easy to misconfigure. A classic error is publishing more than one SPF record, the standard allows only one, so a second breaks authentication; the fix is to merge all authorized senders into a single record. Typos or truncated values are common because TXT strings can be long, and even one wrong character invalidates a DKIM key or verification token. Adding a record at a non-authoritative provider means it never takes effect, see /wiki/what-is-a-nameserver. Forgetting propagation and clicking verify too soon leads to false failures, see /wiki/what-is-dns-propagation. Removing a verification TXT record that a service still needs can silently un-verify your domain and disable features. Finally, neglecting to update SPF and DKIM when adding a new sending tool causes that tool's mail to land in spam. Each of these is avoidable with careful, exact entry and verification, which is exactly the discipline we apply, confirming results with /tools/email-deliverability-checker.
How do you create a TXT record? #
You add TXT records wherever your domain's DNS is managed, at your registrar, host, or DNS provider, in the DNS or zone editor. You choose the name (often the bare domain for SPF and DMARC, or a specific selector subdomain for DKIM), select record type TXT, paste the exact text value the service provided, and set a TTL. Precision matters: copy the value character for character, because a single mistake can break authentication or verification. After saving, wait for propagation, then use the service's verify button or a checking tool to confirm the record is live and correct, see /wiki/what-is-dns-propagation. For email records, test by sending messages and reviewing whether they authenticate and land in the inbox. Because these records govern trust and access rather than anything visible, mistakes are easy to overlook until email or a connected tool fails. We set up and verify TXT records for clients as part of /services/domains-dns-email, and diagnose issues with /tools/email-deliverability-checker.
How TXT records affect email deliverability and trust #
TXT records are central to whether your emails reach customers and whether your domain can be trusted. Properly configured SPF, DKIM, and DMARC records tell the world that your mail is legitimate, which keeps messages out of spam folders and protects your domain from being spoofed in phishing attacks that could damage your reputation. Poorly configured or missing records do the opposite: legitimate replies to customers get filtered, appointment confirmations vanish into junk, and scammers can more easily impersonate your address. For a local business that relies on email to book jobs, confirm orders, and follow up with leads, this directly affects revenue and reputation. Deliverability is not only about writing good emails, it starts with correct DNS. That is why we treat email authentication as a core part of domain setup rather than an afterthought, configuring the full suite of TXT records and verifying them with /tools/email-deliverability-checker, so your messages are trusted and your brand is protected, through /services/domains-dns-email and /services/website-security.
FAQ
What is a TXT record used for?
A TXT record stores arbitrary text tied to a domain, most commonly to verify domain ownership with third-party services and to hold email authentication settings like SPF, DKIM, and DMARC. These uses keep your outgoing email trusted and prove to tools like Google that you control the domain before enabling features.
What is the difference between SPF, DKIM, and DMARC?
All three are email authentication policies published as TXT records. SPF lists which servers may send mail for your domain, DKIM cryptographically signs your messages, and DMARC ties the two together and tells receivers how to handle mail that fails. Together they keep your email out of spam and block spoofing.
Can I have more than one SPF record?
No. A domain should have only one SPF record; publishing two breaks authentication. If you use multiple sending services, you merge all of them into a single SPF record. Having duplicate or conflicting SPF records is a common cause of deliverability problems, which we check with /tools/email-deliverability-checker.
Why does a service ask me to add a TXT record?
Services like Google, Microsoft, and marketing tools ask you to add a unique TXT record to verify that you control the domain before enabling features. By confirming the record exists, they prove ownership. These verification records are harmless to keep and often must stay in place to remain verified.
Will a TXT record change break my website?
No. TXT records do not affect where your website loads, that is handled by A and CNAME records. TXT records govern verification and email authentication. However, misconfiguring email TXT records can send your outgoing mail to spam, so they still matter greatly for a business, see /wiki/what-is-an-mx-record.
How long do TXT record changes take?
TXT record changes take from a few minutes to 48 hours to take effect everywhere, depending on TTL and caching, a process called DNS propagation. Wait for propagation before clicking a service's verify button or testing email, or you may see a false failure, see /wiki/what-is-dns-propagation.
Was this helpful?