What Is TXT Record in DNS and Why It Matters for Email

Do not index

A DNS TXT record is a text-based DNS entry used to attach machine-readable instructions to a domain. In email, TXT records carry SPF, DKIM, and DMARC data, which helps determine whether messages reach the inbox or go to spam.

A sender can have clean lists, relevant content, and a strong offer, yet still watch replies disappear because authentication is broken. A missing SPF record, an incorrectly placed DKIM key, a malformed DMARC policy, a blacklist issue, or an SMTP failure can damage inbox placement and waste sales, marketing, and onboarding effort.

This guide answers what is TXT record in practical terms, then shows how to inspect, publish, and troubleshoot TXT-based email authentication without guessing.

Table of Contents

Why TXT Records Control Your Email Deliverability A fast way to interpret the problem How TXT Records Work in DNS One domain, multiple scopes Email Authentication Protocols Stored in TXT Records SPF authorizes sending infrastructure DKIM proves control of a signing key DMARC applies policy and alignment How to View and Add TXT Records Step 1, inspect the current zone Step 2, add the provider-issued value Step 3, verify the published result Common TXT Record Mistakes That Break Deliverability Multiple SPF records Too many SPF lookups DKIM selector or alignment failures DMARC enforcement arrives too early TXT Records Beyond Email Authentication Which records deserve attention first Your TXT Record Diagnostic Workflow

Why TXT Records Control Your Email Deliverability

A TXT record is a DNS entry that attaches text-based information to a domain. Originally, that text could be a human-readable note. Modern mail systems use it as a machine-readable control plane for authentication, verification, and security policies. TXT records were formally proposed for arbitrary string attributes in RFC 1464, published in May 1993, building on the TXT resource record defined in RFC 1035 in 1987. This history is documented in the history of DNS TXT records.

The deliverability impact is direct. SPF uses a TXT record to identify authorized sending infrastructure. DKIM uses a selector-based TXT record to publish a public key. DMARC uses a _dmarc TXT record to tell receivers how to handle messages that fail authentication. If one is missing, malformed, or published at the wrong hostname, receiving systems may be unable to evaluate the policy correctly.

Mailbox providers such as Gmail, Outlook, and Yahoo evaluate authentication alongside reputation, message behavior, infrastructure, and other signals. TXT records don't guarantee inbox placement, but they provide the evidence receivers need to distinguish authorized mail from spoofed or suspicious mail.

A fast way to interpret the problem

When emails go to spam, the following sequence helps isolate TXT-related causes:

Check SPF at the domain apex. Confirm that the record begins with v=spf1 and includes every legitimate sending service.

Check DKIM at the correct selector. A DKIM record usually lives at selector._domainkey, not at the root domain.

Check DMARC at _dmarc. Confirm that the policy can be found and that the visible From domain aligns with SPF or DKIM.

Review reputation and infrastructure. Authentication can be valid while blacklists, SMTP errors, or sending behavior still hurt placement.

A practical overview of DNS TXT records for domain investors can also help readers understand why one domain may contain several unrelated TXT entries. For a broader foundation, the DNS record types explained guide separates TXT from MX, CNAME, A, and other records.

How TXT Records Work in DNS

Every TXT record has a few operational parts:

Owner name: The hostname where the record is published, such as @, selector._domainkey, or _dmarc.

Record type: TXT.

Value: The text interpreted by a verification service or mail receiver.

TTL: The period resolvers cache the answer before requesting it again.

For example, an SPF record at the apex might use @ as the host and a value beginning with v=spf1. A DKIM key uses a selector, so a selector named mail2026 would be published at mail2026._domainkey. DMARC uses _dmarc, meaning a policy for example.com is queried at _dmarc.example.com.

One domain, multiple scopes

A single domain can have several TXT records because each owner name has a different scope and meaning:

Owner name	Typical use	What the receiver reads
`@`	SPF or verification	Sending authorization or ownership token
`selector._domainkey`	DKIM	Public key for a specific signing selector
`_dmarc`	DMARC	Policy, alignment, and reporting instructions
Service-specific hostname	SaaS verification	A token proving control of the domain

TXT records are publicly queryable through normal DNS lookups. That visibility is useful for debugging, but it also means an SPF policy, DKIM public key, DMARC policy, and verification token can be inspected by anyone who queries the domain. Public visibility isn't a defect. These protocols depend on receivers being able to retrieve the published information consistently.

The important distinction is between record content and record location. A perfectly written DMARC value at the apex won't work as a DMARC policy because receivers query _dmarc. Likewise, a DKIM public key placed at the wrong selector won't validate the signature generated by the sender.

Email Authentication Protocols Stored in TXT Records

SPF, DKIM, and DMARC solve different problems. Treating them as interchangeable creates confusing diagnostics and can leave a domain exposed even when one record appears valid.

SPF authorizes sending infrastructure

An SPF record tells receiving servers which systems are permitted to send mail for a domain. A common example is:

v=spf1 include:_spf.google.com ~all

The v=spf1 prefix identifies SPF. The include mechanism delegates authorization to another SPF policy, such as a provider's sending infrastructure. The ~all ending is a soft fail for sources not authorized by the preceding mechanisms.

SPF is evaluated against the sending infrastructure, not against the message body. A valid SPF result can still fail DMARC if the authenticated domain doesn't align with the visible From domain. SPF also has a hard limit of 10 DNS lookups per record evaluation, including nested include, redirect, and exists chains, as described in SPF record management guidance. Exceeding that limit can produce a permerror, which removes SPF from the reliable authentication path.

DKIM proves control of a signing key

DKIM adds a cryptographic signature to outgoing mail. The receiving system uses the selector in the message to find a public key in DNS. If the selector is mail2026, the lookup target follows this pattern:

mail2026._domainkey.example.com

The TXT value contains the key declaration and public key, commonly beginning with v=DKIM1; k=rsa; p=. The exact value comes from the email provider or signing system. A missing key, stale selector, malformed value, or mismatch between the selector used in the message and the selector published in DNS causes DKIM validation to fail.

DMARC applies policy and alignment

DMARC is also a TXT record. Its policy is published at _dmarc, and receivers query that hostname through ordinary DNS lookups. A basic monitoring policy can look like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The p value controls the requested treatment of failing mail:

p=none requests monitoring without asking receivers to quarantine or reject the message.

p=quarantine asks receivers to treat failing messages as suspicious, often by placing them in spam.

p=reject asks receivers to reject messages that fail DMARC evaluation.

DMARC requires at least one of SPF or DKIM to pass and align with the visible From domain. That relationship is why a team should verify the complete chain instead of checking only whether a TXT record exists. For a practical guide to how to verify email sending domains, the same principle applies: confirm the record, the sending service, and the domain alignment. Teams can also review SPF record examples before editing a production policy.

Protocol	Owner Name	Purpose	Example Value
SPF	`@`	Authorizes sending services	`v=spf1 include:_spf.google.com ~all`
DKIM	`selector._domainkey`	Publishes a public signing key	`v=DKIM1; k=rsa; p=PUBLIC_KEY`
DMARC	`_dmarc`	Defines failure handling and reporting	`v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com`

How to View and Add TXT Records

The safest workflow starts with observation. Before adding a record, identify the authoritative DNS provider and inspect the records already published. A lookup often reveals an existing SPF policy, several verification tokens, DKIM selectors, or a DMARC record that another administrator configured earlier.

Step 1, inspect the current zone

Use a TXT Lookup tool to query the domain and review every returned TXT value. The result should be interpreted by owner name and purpose, not just copied into a spreadsheet. An apex SPF record, a DKIM key, a DMARC policy, and a SaaS verification token are separate objects even though DNS labels them all as TXT.

Step 2, add the provider-issued value

In Cloudflare, GoDaddy, Namecheap, Google Domains, or another DNS manager, open the DNS zone editor and create a record with:

Type: TXT

Name or host: The exact hostname supplied by the email or verification provider

Value: The complete string, without accidental edits

TTL: The provider's default or a chosen cache duration

The host field varies by provider. Some expect @ for the apex, while others expect the domain to be omitted. Some dashboards append the domain automatically. Entering the full hostname where the interface expects only the relative label can create a record at the wrong location.

Step 3, verify the published result

After saving, query the record again from outside the DNS dashboard. DNS changes can take minutes to 48 hours to appear consistently worldwide, depending on caching and TTL behavior. A dashboard showing “saved” proves only that the provider accepted the change. It doesn't prove that every receiver can retrieve the expected value.

Trailing spaces, copied quotation marks, truncated DKIM keys, and an incorrect hostname can all break authentication without warning. If a team is also preparing outreach copy, a free email response generator can help with reply drafting, but message quality won't compensate for a TXT record that receivers can't validate.

Common TXT Record Mistakes That Break Deliverability

A TXT lookup can return data and still leave authentication broken. The critical question isn't “does a record exist?” It is “can the receiving system interpret the right record at the right owner name?”

Multiple SPF records

Symptom: SPF returns a permanent error, or different tools show conflicting policies.

Cause: A domain has multiple TXT records beginning with v=spf1. SPF policy must be consolidated into one record. Adding a second SPF entry when onboarding a new provider creates ambiguity instead of extending authorization.

Fix: Inventory every sending platform, merge the required mechanisms into one policy, and remove obsolete SPF records. The final policy should authorize only legitimate infrastructure, because an overly broad policy can make spoofing easier while an incomplete one can cause legitimate mail to fail.

Too many SPF lookups

Symptom: SPF produces permerror even though the syntax appears correct.

Cause: SPF evaluation exceeds the 10 DNS lookup limit established under RFC 7208, including nested include, redirect, and exists chains. Each new provider can add more DNS-dependent evaluation.

Fix: Remove unused providers, simplify nested policies, and ask vendors for optimized authorization methods. Don't add random mechanisms just to make a test pass. Excessive complexity makes future changes harder and can affect every message using that SPF path.

DKIM selector or alignment failures

Symptom: DKIM is missing, fails cryptographic validation, or passes for a domain that doesn't align with the visible From address.

Cause: The provider signs with one selector while DNS publishes another, the key was copied incorrectly, or the signing domain differs from the From domain in a way DMARC doesn't accept.

Fix: Compare the selector in the message headers with the owner name in DNS, republish the provider's exact public key, and confirm alignment. Rotating keys is useful operational hygiene, but removing an old key before all systems stop using it can break active senders.

DMARC enforcement arrives too early

Symptom: Legitimate transactional or campaign messages are rejected after a policy change.

Cause: p=reject was enabled before all sending services, subdomains, and alignment paths were identified.

Fix: Start with monitoring through p=none, review reports, repair SPF and DKIM alignment, then consider quarantine or reject when the organization understands its legitimate mail flows. Enforcement protects the domain, but premature enforcement can block the organization's own messages.

A live diagnostic tool should report the symptom, explain the cause, and show the remediation rather than returning raw DNS text alone. That distinction matters when a founder needs to restore replies quickly or a developer is debugging an automated sending workflow.

TXT Records Beyond Email Authentication

TXT records also verify domain ownership for services such as Google Workspace, Microsoft 365, analytics platforms, monitoring systems, and other SaaS products. These entries usually contain a provider-specific token. They prove control of DNS, but they don't authorize email and shouldn't be mistaken for SPF or DMARC.

TXT also supports newer email security and branding workflows. BIMI publishes brand-related data in DNS, while MTA-STS uses DNS TXT to advertise that a domain has an MTA-STS policy. A BIMI record can help a receiving ecosystem locate brand information, but it doesn't replace SPF, DKIM, or DMARC.

A lookup may therefore show a long list that appears unrelated to deliverability. Independent coverage describes TXT's evolution from human-readable notes to machine-readable data, and academic measurement work found non-email uses dominated one large TXT-query trace, including NFSv4 at 72.14%, anti-virus at 12.00%, DNS-based service discovery at 4.30%, and SPF/domainkey at 0.24%. Those figures come from the Cloudflare explanation of DNS TXT records, which is useful context for understanding TXT sprawl.

Which records deserve attention first

For inbox placement, prioritize:

SPF: Confirm the authorized sending infrastructure.

DKIM: Confirm the selector and public key used by each sender.

DMARC: Confirm the policy location, syntax, reporting, and alignment.

BIMI and MTA-STS: Review after core authentication and transport configuration are understood.

Verification tokens: Keep them separate from authentication troubleshooting unless a service setup depends on them.

AI agents face the same distinction. An agent that manages domains or sends campaigns needs live DNS context so it doesn't interpret a verification token as an authorization policy or publish a record under the wrong owner name.

Your TXT Record Diagnostic Workflow

A focused workflow reduces guesswork:

Check SPF with an SPF Checker. Confirm one policy exists and that its DNS evaluation stays within the permitted limit.

Verify DKIM selectors with a DKIM Checker. Test every sending provider, not only the primary mailbox platform.

Validate DMARC with a DMARC Checker. Confirm _dmarc, policy syntax, reporting, and alignment.

Review all TXT records with TXT Lookup. Separate authentication records from ownership tokens and unrelated service metadata.

Check blacklist status because valid authentication can't erase a domain or IP reputation problem.

Run SMTP and IMAP checks when delivery or mailbox access suggests an infrastructure failure.

Run a full mailX audit to connect DNS, authentication, blacklist, and infrastructure findings in one diagnostic view.

mailX is a free deliverability diagnostic layer that performs live checks across SPF, DKIM, DMARC, BIMI, MX, DNS, TXT, CNAME, PTR, SMTP, IMAP, blacklist status, and related configuration. It returns plain-English explanations and remediation steps, and its API and MCP interfaces let AI agents check authentication and infrastructure before they send.

That matters commercially. A broken TXT record can reduce replies, interrupt transactional onboarding, weaken trust, and waste campaign effort even when the copy is strong. Fixing the underlying signal gives legitimate messages a better chance of reaching the inbox and protects the sender reputation that future campaigns depend on.

Use mailX to review TXT-based authentication, blacklist status, DNS configuration, and mail infrastructure in a single free audit. The check requires no signup and returns clear explanations with specific next steps, so teams and AI agents can diagnose deliverability problems before sending the next campaign.