DNS TXT Record: The Email Authentication Record Explained

A DNS TXT record is a DNS record that stores text information for a domain. In email sending, it commonly publishes SPF, DKIM, and DMARC data so receiving mail servers can verify authorized senders, validate message signatures, apply anti-spoofing policies, and decide whether to trust, deliver, quarantine, or reject an email.

What is a DNS TXT record?

DNS, short for Domain Name System, is the distributed directory that helps internet services find information associated with a domain name. An A record maps a hostname to an IPv4 address. An MX record identifies the servers that receive mail for a domain. A DNS TXT record, by contrast, holds text data whose meaning depends on the protocol reading it.

That flexibility made TXT records a foundational part of modern email authentication. Your domain's DNS zone can publish statements such as:

• which services and IP addresses are permitted to send mail using an envelope-sender domain;
• the public key needed to verify a DKIM signature attached to an email;
• the DMARC policy receivers should use when a message claiming to be from your domain fails authentication;
• destinations for DMARC aggregate reports;
• ownership-verification tokens for email platforms and other services.

The DNS record type is simply TXT. The name and value determine what it does. For example, an SPF policy normally appears at the domain root, a DKIM key appears beneath a selector and _domainkey, and a DMARC policy appears beneath _dmarc.

example.com                 TXT  v=spf1 include:spf.email-service.example -all
mail2026._domainkey.example.com TXT  v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY
_dmarc.example.com          TXT  v=DMARC1; p=none; rua=mailto:dmarc@example.com

These examples are intentionally illustrative. Do not copy the provider hostname or the DKIM key: your email provider supplies the exact records for your sending configuration.

Why DNS TXT records matter for email deliverability

A DNS TXT record is not a deliverability score or a campaign metric. It does not have a percentage, a numerator, or a formula. Its importance is operational: it provides the public DNS data that mail receivers use during authentication checks.

When a recipient server receives a message, it evaluates more than the email's visible content. It can inspect the SMTP connection, sending IP reputation, reverse DNS, message headers, body structure, recipient engagement signals, complaint history, and authentication. SPF, DKIM, and DMARC are separate technologies, but all commonly depend on correctly published DNS TXT records.

A missing or malformed record can cause one or more of those checks to fail. That may affect inbox placement, lead to spam-folder placement, trigger a rejection under a recipient's security policy, or make it harder to investigate spoofing and unauthorized use of your domain. Authentication alone does not guarantee inbox placement, but reliable authentication removes a major source of uncertainty for receivers.

This matters especially for shared or changing email infrastructure. A company might send transactional receipts through one provider, product notifications through another, and newsletters through a campaign platform. Each legitimate source needs to be accounted for in the domain's authentication design. If DNS does not match the actual sending architecture, messages may fail despite being legitimate.

Major mailbox providers also expect authentication. Google's sender guidance requires all senders to use SPF or DKIM, while bulk senders sending more than 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC. That turns correct TXT publishing from a nice-to-have configuration detail into baseline sending hygiene.

The three email DNS TXT records you will see most often

SPF: authorization for the envelope sender

Sender Policy Framework, or SPF, lets a domain publish the hosts authorized to send mail on its behalf. It is evaluated against the SMTP envelope sender domain, commonly called the MAIL FROM, Return-Path, or bounce domain, rather than the friendly name a recipient sees in the From header.

An SPF record begins with v=spf1 and contains space-separated mechanisms and, sometimes, modifiers. A simple record might look like this:

example.com TXT v=spf1 ip4:198.51.100.24 -all

In plain language, that policy says that 198.51.100.24 is authorized to send mail for example.com; other sources should fail SPF. In a multi-service setup, an include mechanism is common:

example.com TXT v=spf1 include:spf.transactional-provider.example include:spf.marketing-provider.example -all

The include mechanism causes the evaluator to inspect the referenced domain's SPF policy. It is a delegation mechanism, not a comment or a simple text insertion. Its lookup behavior matters because SPF evaluation has a limit of 10 DNS-query-causing terms. A sprawling network of nested includes, redirects, a, mx, and other lookup-producing mechanisms can exceed that limit and yield an SPF permerror.

There must not be multiple SPF records at the same domain name. Publishing two TXT values that both start with v=spf1 is not a way to add authorization. Receivers can treat it as a permanent SPF error. Combine authorized sending sources into one valid SPF policy instead.

DKIM: a public key for signature verification

DomainKeys Identified Mail, or DKIM, signs a message with a private key held by the sender. The recipient retrieves the matching public key from DNS and uses it to validate the signature. A DKIM pass indicates that the relevant signed portions of the message match the signature and that the signer had access to the corresponding private key.

A DKIM lookup name combines a selector chosen by the signer, the fixed label _domainkey, and the signing domain from the d= tag in the message's DKIM-Signature header. If an email has:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

the receiving server queries:

mail2026._domainkey.example.com

A typical public-key record resembles this:

mail2026._domainkey.example.com TXT v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY

The p= value is the public key, not a secret. The private key must stay within the signing service or your own controlled sending infrastructure. Never publish a private key in DNS, in application code, or in a support ticket.

Selectors allow a domain to use more than one DKIM key at once. That is useful when different systems send mail, when a provider manages a key for a delegated subdomain, or when you rotate keys. Rather than replacing an active key in place, publish a new selector, configure signing with the new selector, confirm it passes, and only then retire the old selector after old messages no longer need verification.

DMARC: alignment, policy, and reporting

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM by checking whether at least one passing authentication method is aligned with the domain visible in the message's From header. It also lets the domain owner publish a requested disposition for failures and request feedback reports.

DMARC is published at _dmarc beneath the domain:

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

The p= tag is the requested policy for mail that fails DMARC:

• p=none asks receivers to take no specific enforcement action while reports are collected.
• p=quarantine asks receivers to treat failing mail suspiciously, often by placing it in spam or quarantine.
• p=reject asks receivers to reject failing mail during delivery.

The current DMARC core specification is RFC 9989, which supersedes the earlier RFC 7489. The practical DNS location remains the familiar _dmarc.example.com pattern, and a record begins with v=DMARC1.

DMARC alignment is the detail that catches many otherwise confusing setups. An email may pass SPF for a provider-owned return-path domain yet fail DMARC if that domain is not aligned with the visible From domain. Alternatively, a message can pass DMARC through aligned DKIM even when SPF fails, which is one reason robust senders configure both mechanisms.

DNS TXT record syntax: names, values, quotes, and length

The actual DNS record contains a record name, record type, TTL, and one or more text strings. DNS provider control panels present these fields differently, so do not assume that every dashboard uses the same labels. You may see Host, Name, Record name, or a blank/root indicator for the record location; the value might be labeled Content, Value, Data, or Text.

The concepts are the same:

Root-domain names versus full hostnames

This is a common source of errors. If your DNS zone is already example.com, a provider interface may expect only _dmarc for the record name. If you enter _dmarc.example.com into an interface that automatically appends the domain, it may create _dmarc.example.com.example.com instead.

Conversely, an API or advanced DNS editor may expect the full name. Always inspect the resulting fully qualified record after publishing. The right answer is not a universal dashboard label; it is the DNS name that a receiver will query.

Quotation marks and split strings

DNS presentation formats often show TXT values inside quotation marks. In many DNS interfaces, those quotes are display syntax and should not be manually included unless the provider explicitly says to include them. The key requirement is that a DNS lookup returns the intended concatenated text value.

A DNS TXT character-string is limited to 255 octets, but a TXT record may contain multiple character-strings. This is especially relevant for long RSA DKIM public keys. DNS tools and provider interfaces may display a long DKIM value as adjacent quoted strings, for example:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
"...remaining-base64-key-material..."

Resolvers concatenate those adjacent strings for the application. Do not insert an extra space, semicolon, quote character, or line break into the key material unless the DNS provider's instructions specifically require a particular entry format. Base64 key data is sensitive to accidental characters.

CNAME delegation and provider-provided DNS records

Some email services ask you to publish a CNAME record for a DKIM selector rather than directly creating a TXT record. In that arrangement, the selector name points to a hostname managed by the service, which then serves the DKIM TXT record. The authentication check still ultimately relies on a DKIM public key published through DNS, but the record type you add in your zone is CNAME.

Follow the provider's exact record type and target. Replacing a requested CNAME with a manually invented TXT record can break verification. Likewise, do not create a CNAME at a name that already has another DNS record type; DNS rules do not permit CNAME coexisting with other data at the same owner name.

How receivers use these records during delivery

A sender's application does not normally query its own SPF, DKIM, and DMARC records for every email. The receiving infrastructure performs the relevant DNS lookups while evaluating an incoming message.

A simplified sequence looks like this:

1. Your application submits an email through SMTP or an email API.
2. The sending infrastructure establishes an SMTP connection to the recipient's mail server.
3. The recipient evaluates the connecting IP and the envelope sender against the envelope domain's SPF TXT record.
4. The recipient reads one or more DKIM-Signature headers, derives each selector lookup name, retrieves the DKIM public key, and verifies the signature.
5. The recipient identifies the visible From-domain, retrieves the DMARC record at _dmarc, and evaluates whether SPF or DKIM passed with the required alignment.
6. The recipient combines authentication outcomes with local policy, content and reputation signals, then accepts, filters, quarantines, or rejects the message.

This process explains why a record can exist in DNS yet still not solve a delivery problem. The record must be located at the queried hostname, syntactically valid, propagated to authoritative nameservers, and consistent with the message that is actually being sent. An SPF policy cannot authorize a system that uses a different envelope domain. A DKIM public key cannot validate a message signed with an unconfigured selector. A DMARC record cannot pass a message whose authenticated domains do not align with the From domain.

Common DNS TXT record problems and what causes them

The record is published at the wrong hostname

A DMARC record placed at example.com instead of _dmarc.example.com will not be found by a DMARC lookup. A DKIM key published at _domainkey.example.com without the selector will not match a message signed as s=mail2026. An extra domain suffix introduced by a DNS dashboard is another variation of the same problem.

Fix it by starting with the query name, not the dashboard form. For DKIM, inspect a delivered message's DKIM-Signature header for s= and d=, then construct selector._domainkey.domain. For DMARC, begin with _dmarc. plus the From domain. For SPF, identify the SMTP envelope-from domain, not merely the brand domain in the From header.

Multiple SPF records exist

This often occurs after a team adds a second provider without editing the original policy. They publish another v=spf1 TXT value, assuming SPF works like multiple MX records. It does not.

Fix it by merging legitimate sending mechanisms into a single record at the same hostname. Remove the extra SPF-version record and test the final policy for syntax and lookup count. Do not preserve stale vendor includes merely because they once existed; every authorization in SPF expands the surface that can send with that envelope domain.

SPF has too many DNS lookups

A record can look short while still exceeding SPF's DNS lookup limit because include, redirect, a, mx, exists, and some nested policies cause more queries. A company that layers several platforms, resellers, and legacy services can hit the limit without realizing it.

Fix it by inventorying actual outbound mail sources, removing obsolete providers, flattening only when you can safely maintain it, or using dedicated subdomains with simpler independent SPF records. Treat flattening as an operational process, not a one-time copy-and-paste task: a provider's authorized IP ranges can change.

The DKIM key is malformed, truncated, or copied incorrectly

Long keys are easy to damage. Common mistakes include including quotation marks as literal value characters, inserting spaces into p=, omitting a segment of a split string, pasting a private key instead of a public key, or publishing at the wrong selector.

Fix it by re-copying the exact public record from the signing system, then querying the published selector directly. Confirm that the message's d= and s= values match the DNS record. Send a test email and inspect the recipient's authentication results for dkim=pass rather than relying only on a platform status screen.

The message is not actually signed

A published DKIM record does nothing if the sending service is not signing mail with the matching domain and selector. This can happen when domain verification is incomplete, a new sending stream is not configured, a sandbox environment uses a default signing identity, or an SMTP credential belongs to another account configuration.

Fix it at the sending layer. Confirm the sender identity, authenticated domain, DKIM selector, and active signing status with the platform. If you use an email API, make domain authentication part of deployment readiness rather than an afterthought. The email API setup guides should be treated as implementation requirements, not optional documentation.

DMARC is present but alignment fails

A domain may have a valid-looking DMARC record and still show dmarc=fail. The usual reason is that SPF passes for one domain while DKIM passes for another, but neither aligns with the visible From domain according to the applicable alignment mode.

Fix it by using a custom, aligned return-path domain for SPF and signing with your own From domain or an aligned subdomain for DKIM. In most modern sending architectures, aligned DKIM is the durable foundation because SPF frequently breaks during forwarding while DKIM can survive if the signed message content remains intact.

DNS propagation and stale caches create confusing tests

Changing a DNS record does not instantly update every recursive resolver. TTL values permit resolvers to cache prior answers, and some operational paths may have their own refresh timing. A validation tool can therefore show an old record shortly after a change.

Fix it by verifying the authoritative nameservers first, then allowing time for caches to expire. Avoid repeatedly changing a record in response to inconsistent early tests; that can create a moving target. Record the previous value, the new value, the change time, and the TTL so your team can diagnose what it is seeing.

How to publish and verify a DNS TXT record safely

Publishing an authentication record should be a controlled change, particularly for a domain that already sends production email. The goal is not just to make a DNS checker show green; it is to preserve every authorized mail flow while reducing unauthorized ones.

A practical publishing workflow

1. Inventory every sender. List transactional applications, marketing tools, help desks, billing systems, CRM workflows, Google Workspace or Microsoft 365 mailboxes, and any vendors that send with your domain.
2. Identify the domains each flow uses. Record the visible From domain, envelope-from domain, DKIM signing domain, selector, and destination mailbox types.
3. Collect provider-issued DNS instructions. Use exact values from each provider. Do not infer an SPF include hostname or manually generate a DKIM public key unless you operate the signer.
4. Inspect existing DNS first. Find the current SPF record, all DKIM selectors, and the DMARC record. Preserve valid authorizations during migration.
5. Publish one change at a time. For example, publish and validate DKIM before changing DMARC enforcement.
6. Query the public DNS result. Verify the record name, type, and returned value from outside your DNS provider's editor.
7. Send real test messages. Check the raw message or authentication summary at recipient mailboxes for SPF, DKIM, and DMARC outcomes.
8. Monitor before enforcing. Start DMARC reporting with p=none, identify legitimate systems that fail alignment, then increase enforcement only after the data supports it.

Command-line examples

On systems with dig, you can query records directly:

dig TXT example.com +short
dig TXT mail2026._domainkey.example.com +short
dig TXT _dmarc.example.com +short

On Windows PowerShell, an equivalent approach is:

Resolve-DnsName -Name example.com -Type TXT
Resolve-DnsName -Name mail2026._domainkey.example.com -Type TXT
Resolve-DnsName -Name _dmarc.example.com -Type TXT

These commands show what DNS is serving. They do not prove that an email stream uses the records correctly. Pair DNS inspection with an actual message test, because message headers reveal the envelope domain, signing selector, signing domain, and final authentication result.

DNS TXT records and domain separation

Using separate subdomains for different sending purposes can reduce risk and operational complexity. For example, a business might reserve notify.example.com for application notices, mail.example.com for marketing, and support.example.com for support-platform messages, while keeping employee mail on example.com.

Each subdomain can have its own SPF and DMARC policy, and each can use distinct DKIM selectors. That separation makes it easier to add or remove a vendor without editing one giant root-domain SPF record. It also limits the consequences of a configuration error or sender-reputation issue in one traffic class.

Domain separation is not an excuse to make authentication inconsistent. The From address, return-path, DKIM signing domain, and DMARC policy must still be deliberately aligned for each stream. A marketing platform using news.example.com should have records that reflect the domain it really places in the visible From header and the identities it really uses while sending.

There is also a human side to this design. Recipients should recognize the sender identity, and reply handling should be intentional. A technically valid authentication structure will not compensate for confusing branding, unexpected messages, stale lists, or a difficult unsubscribe process.

DMARC reporting turns DNS into an observability tool

The rua tag in a DMARC record can ask receivers to send aggregate reports to a specified mailbox or reporting service. Those reports summarize how receivers observed mail claiming to use your domain: source IPs, counts, authentication results, and policy dispositions.

A basic record might be:

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

The address should be capable of receiving report volume, and the reports are XML files that generally need parsing or a reporting service to become operationally useful. The objective is discovery: determine which systems are legitimately sending as your domain, which pass SPF and DKIM, and which may be unauthorized.

A sensible DMARC rollout has three stages:

• Observe: publish p=none with reporting and investigate all sending sources.
• Correct: configure aligned SPF and DKIM for legitimate systems, eliminate stale senders, and resolve forwarding or mailing-list edge cases where possible.
• Enforce: move to p=quarantine or p=reject when reports show that valid traffic reliably passes.

This is why DMARC should not be deployed as a blind security checkbox. A strict policy before you understand all legitimate mail can disrupt receipts, password resets, support tickets, invoice notifications, and third-party workflows. DNS publishes the policy, but the policy has real business consequences.

What a DNS TXT record cannot fix

Correct TXT records are necessary for strong email authentication, but they do not cure every delivery problem. They cannot repair a damaged sending reputation, persuade recipients to engage with unwanted mail, validate a poorly maintained list, or make deceptive content trustworthy.

For example, an authenticated campaign can still underperform if it has high complaint rates, sends to inactive recipients, uses misleading subject lines, lacks a clear unsubscribe method, or abruptly increases volume from a new IP or domain. Authentication establishes identity and policy; reputation and recipient behavior determine much of what happens next.

Likewise, a DNS TXT record is not a replacement for address quality. If a campaign repeatedly targets invalid, abandoned, or mistyped addresses, it can create bounces and harm operational performance even when SPF, DKIM, and DMARC all pass. Validate addresses before high-value sends, suppress hard bounces promptly, and keep consent records for marketing audiences. A free email verification tool can help check addresses before they enter a campaign workflow.

A practical checklist for email senders

Before treating email authentication as complete, verify all of the following:

• Your domain has exactly one valid SPF policy per hostname that uses SPF.
• The SPF policy authorizes every current, legitimate envelope sender and no retired services.
• SPF evaluation stays within the DNS lookup limit.
• Every sending platform signs with DKIM using a published selector and a domain you control or intentionally delegate.
• DKIM public keys are published at the selector hostnames shown in real DKIM-Signature headers.
• Your visible From domain has a DMARC record at the correct _dmarc hostname.
• At least SPF or DKIM passes with DMARC alignment for each production mail stream.
• DMARC reports are monitored before you move to a stronger enforcement policy.
• DNS changes are verified publicly and confirmed with actual delivered test messages.
• Retired providers, old selectors, and unused authorizations are regularly removed.

This checklist is intentionally broader than entering a single DNS value. Email authentication is a relationship between DNS records, the sending service's behavior, message headers, and the receiver's evaluation. All four need to agree.

Conclusion

A DNS TXT record is the publication mechanism behind much of email authentication. SPF uses it to identify authorized senders for an envelope domain, DKIM uses it to publish a signature-verification key, and DMARC uses it to publish alignment, policy, and reporting instructions for the domain shown in a message's From header.

The best way to manage TXT records is to treat them as production email infrastructure. Publish exact provider-issued values, verify the real hostname and resulting public DNS answer, test live messages, monitor DMARC data, and remove stale authorizations as your sending stack changes. When DNS accurately describes your mail ecosystem, receivers have a much clearer basis for trusting your messages.

FAQ

Is a DNS TXT record the same as SPF?

No. A DNS TXT record is a general DNS record type that can store many kinds of text data. SPF is one email-authentication protocol that is typically published in a TXT record. DKIM and DMARC also commonly use TXT records, but their names, syntax, and purposes differ.

Where do I add a DMARC DNS TXT record?

Add it at _dmarc beneath the domain used in the visible From address. For hello@example.com, the full record name is _dmarc.example.com. Whether your DNS provider wants _dmarc or the full hostname depends on how its zone editor handles domain suffixes.

Can I have more than one SPF TXT record?

You can have many TXT records at a domain for unrelated purposes, but you should publish only one SPF policy beginning with v=spf1 at a given hostname. Multiple SPF-version records can cause a permanent SPF error.

Why does DKIM fail when the TXT record exists?

The public key may be at the wrong selector hostname, malformed, incomplete, or inconsistent with the d= and s= values in the sent message. It can also fail because the message was not signed with that key, or because a signed part of the message was modified after signing.

How long does a DNS TXT record take to update?

The authoritative DNS provider may show the update quickly, but recursive DNS resolvers can continue returning cached data until the prior TTL expires. Verify the authoritative result, note the TTL, and allow cache time before drawing conclusions from mixed test results.