Quick TXT DNS Summary for Email
TXT records are DNS entries that store free‑form text, and modern email relies on them for core authentication and policy: SPF, DKIM, and DMARC.
| Item | Value |
|---|---|
| What TXT does | Stores text data at a DNS name (domain or subdomain). |
| Key email uses | SPF, DKIM, DMARC, and verification tokens for ESPs/CRMs/tools. |
| Where you edit it | At your DNS provider (registrar, hosting, or managed DNS). |
| Critical rule | One SPF TXT per name; multiple SPF TXT at the same host is invalid. |
| Risk of mistakes | Broken TXT → failed authentication → spam placement or rejection. |
Introduction: Why TXT DNS Records Power Modern Email Authentication
TXT DNS records are the foundation of modern email authentication. They carry the SPF policy that authorizes your outbound senders, the DKIM keys that sign your messages, and the DMARC policy that tells receivers how to treat failures.
Without correctly configured TXT records, your domain is easier to spoof, your legitimate messages are harder to trust, and your deliverability will suffer. This guide looks at TXT records through an email‑first lens so you can configure them safely, avoid common traps, and keep your DNS readable as your stack grows.
What Is a TXT Record in DNS? (Email‑Centric View)
TXT in One Minute for Email People
A TXT record attaches arbitrary text to a DNS name. Email standards define specific formats that live inside those TXT records, such as SPF policies, DKIM public keys, and DMARC policies.
In practice, almost every serious email‑sending domain will have multiple TXT records: some at the root, some at dedicated hosts like _dmarc.example.com or selector._domainkey.example.com, and some added by third‑party tools for verification.
Where TXT Fits in the DNS + Email Stack
TXT records sit alongside A/AAAA, MX, and PTR as part of your email DNS stack. A/AAAA map hostnames to IP addresses, MX handles inbound routing, PTR/rDNS gives outbound IPs an identity, and TXT holds the policies and keys that receivers use to authenticate mail.
That makes TXT the “policy and proof” layer: it does not route traffic, but it heavily influences whether receivers will trust your mail once it arrives.
Main Types of Email TXT Records
SPF TXT Records (Sender Policy Framework)
SPF is published as a TXT record at a domain or subdomain and starts with v=spf1. It lists which IPs or hosts are authorized to send mail for that name using mechanisms like ip4:, a, mx, and include:, and ends with a qualifier such as ~all or -all.
Receivers compare the connecting IP to this policy to decide whether the sending infrastructure is allowed to use that envelope domain. Because SPF is evaluated per name, you must not publish more than one SPF TXT record at the same host; doing so creates ambiguity and can cause SPF “permerror” results.
DKIM TXT Records (DomainKeys Identified Mail)
DKIM uses a key pair: the private key lives on your MTA or ESP, while the public key is published in a TXT record. That TXT record lives at a selector‑specific hostname, typically selector._domainkey.example.com, and starts with v=DKIM1; followed by a p= tag containing the base64‑encoded public key.
When your server signs a message, it includes the selector and signing domain in the DKIM‑Signature header. Receivers look up the corresponding TXT record, fetch the key, and verify that the message has not been tampered with and that it legitimately comes from that domain.
DMARC TXT Records (Domain‑Based Message Authentication, Reporting & Conformance)
DMARC is published as a TXT record at _dmarc.example.com (or a subdomain variant) and starts with v=DMARC1;. It defines policy tags like p= (none/quarantine/reject), rua= (aggregate reports), ruf= (forensic reports), and alignment controls.
DMARC ties SPF and DKIM together by requiring that at least one passes and aligns with the visible From domain, then instructs receivers how to handle failures. It also enables reporting, which is vital for ongoing monitoring and tuning of your DNS and sending sources.
Other Email‑Related TXT Uses
Beyond SPF, DKIM, and DMARC, TXT records often store verification tokens for ESPs, CRMs, analytics tools, or domain ownership checks. These records are usually one‑off strings containing an identifier or hash supplied by the tool.
Over time, zones can accumulate many verification TXT entries. If unmanaged, this clutter makes audits harder and increases the risk of accidentally editing or deleting a critical authentication record.
| TXT Type | Host / Name | Example Value | Main Purpose |
|---|---|---|---|
| SPF | @ (example.com) | v=spf1 ip4:203.0.113.0/24 include:esp.example.net ~all | Declare which IPs/hosts may send for the domain. |
| DKIM | selector._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqh... | Publish public key for verifying DKIM signatures. |
| DMARC | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@example.com | Set policy and reporting for SPF/DKIM alignment. |
| Verification | @ or custom host | google-site-verification=... | Prove domain ownership to a service. |
How TXT‑Based Mechanisms Work Together (SPF, DKIM, DMARC)
Layered Trust Model
SPF, DKIM, and DMARC are designed as layered defenses. SPF describes which infrastructure is allowed to send on behalf of a domain, DKIM signs individual messages so receivers can verify integrity, and DMARC defines how strictly to enforce those checks and how to report back.
TXT records are the on‑chain source of truth for these mechanisms: if you mis‑type a policy or publish it at the wrong host, the corresponding protection simply will not function, even if your MTAs are correctly configured.
Alignment and Real‑World Flows
DMARC alignment requires that the domain in SPF’s envelope From identity or DKIM’s d= value match (or be a subdomain of) the visible From domain. If SPF passes but is aligned to a different domain than the one users see, DMARC will not treat that as a full pass unless your alignment settings allow it.
This is why it is important to be precise about which domain you use in each TXT record and to avoid casually mixing different brands or domains in SPF includes and DKIM selectors without an alignment plan.
Configuring TXT Records for Email in Practice
General Rules for Editing TXT
You always edit TXT records in the authoritative DNS zone: the one whose nameservers are configured at the registrar. Before making changes, export or screenshot the current records so you can roll back if needed.
When adding SPF, DKIM, or DMARC, copy values directly from provider documentation or consoles to avoid quoting, spacing, and casing errors. Pay attention to how your DNS UI handles quotes; many interfaces expect you to paste the value without adding extra quote characters.
Provider‑Driven Workflows
Most mailbox and ESP platforms generate the exact TXT records you need. Typical patterns include:
- Mailbox provider SPF: add or extend SPF at the root domain to include their sending hosts.
- ESP SPF: add an
include:mechanism referencing their domain. - DKIM: publish one or more selector TXT records exactly as provided.
- DMARC: start with a monitoring policy before enforcing quarantine or reject.
| Scenario | TXT Type | Where to Publish | ⚠️ Pitfalls |
|---|---|---|---|
| Mailbox provider (e.g., Google/M365) | SPF, DKIM, DMARC | Root domain + _domainkey + _dmarc | Overwriting SPF instead of merging with existing senders. |
| Transactional ESP | SPF include, DKIM, optional DMARC | Root or subdomain used for mail | Publishing ESP SPF on wrong domain; missing DKIM selectors. |
| Verification for tools | Token TXT | Host specified by tool | Deleting tokens too early or leaving unnecessary clutter forever. |
Testing and Validating Email TXT Records
Tools and Techniques
You can inspect TXT records with both general DNS tools and email‑specific validators. On the command line, dig TXT example.com and dig TXT _dmarc.example.com show raw values, while web‑based SPF, DKIM, and DMARC tools parse and highlight syntax problems for you.
When troubleshooting, check both the raw TXT and the parsed interpretation from multiple tools. This helps catch edge cases like invisible control characters, broken quotes, or records that look fine to the eye but fail machine parsing.
TXT Health Checklist for Email
| ✅ Check | Why It Matters |
|---|---|
| Exactly one SPF TXT per host | Multiple SPF TXT at the same name result in undefined behavior and errors. |
| SPF uses includes, not duplicated policies | Prevents exceeding SPF’s 10‑lookup limit and keeps configs manageable. |
| All DKIM selectors resolve to valid keys | Missing or malformed keys cause DKIM failures. |
| DMARC policy is syntactically correct | Invalid tags or typos can cause receivers to ignore DMARC. |
| Old verification TXT records are documented | Avoids confusion and accidental deletion of active tokens. |
Common TXT Misconfigurations and How to Fix Them
Symptom → TXT Issue → Fix
| Symptom | Likely TXT Issue | What to Check | ✅ Fix |
|---|---|---|---|
| SPF “permerror” or “multiple SPF records” | More than one SPF TXT at the same name. | List all TXT at the host and count SPF policies. | Merge policies into a single SPF TXT record. |
| SPF “too many DNS lookups” | Excessive include:, a, mx, or ptr mechanisms. | Use an SPF checker to count lookups. | Consolidate includes, remove unused senders, simplify mechanisms. |
| DKIM fail “no key found” | Missing selector TXT or published at wrong host. | Look up selector._domainkey.domain in DNS. | Publish key at exact selector/host provided by your MTA/ESP. |
| DMARC reports show “no DMARC record” | No TXT at _dmarc.domain or syntax invalid. | Query TXT at _dmarc.domain and validate using a DMARC checker. | Add or correct DMARC TXT with valid tags. |
SPF Gotchas (Includes, Multiples, and Mechanism Order)
SPF includes count toward a hard limit of 10 DNS lookups; going beyond that causes “permerror” and makes SPF unreliable. Blindly stacking many third‑party includes will eventually hit this ceiling, especially in complex environments.
To keep SPF healthy, consolidate overlapping includes, remove legacy senders, and avoid mechanisms like ptr that are expensive and discouraged. Always keep SPF in a single TXT record per host and adjust the ~all or -all qualifier based on how confident you are that your policy covers all legitimate senders.
Example Email TXT Configurations
Small Business Using Mailbox Provider + One ESP
| Type | Name | Value | Purpose |
|---|---|---|---|
| TXT (SPF) | @ | v=spf1 include:mailbox.example.net include:esp.example.net ~all | Authorize mailbox provider and ESP to send for primary domain. |
| TXT (DKIM) | mbox._domainkey | v=DKIM1; k=rsa; p=... | Mailbox provider DKIM key. |
| TXT (DKIM) | esp1._domainkey | v=DKIM1; k=rsa; p=... | ESP DKIM key. |
| TXT (DMARC) | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@example.com | Monitor SPF/DKIM alignment without enforcing yet. |
Advanced Setup with Subdomains
| Type | Name | Value | Purpose |
|---|---|---|---|
| TXT (SPF) | transactional | v=spf1 include:tx-esp.example.net -all | Strict SPF for transactional subdomain. |
| TXT (SPF) | newsletter | v=spf1 include:mkt-esp.example.net ~all | More relaxed policy for marketing subdomain. |
| TXT (DMARC) | _dmarc.transactional | v=DMARC1; p=reject; rua=mailto:dmarc-tx@example.com | Strict rejection of unauthenticated transactional mail. |
| TXT (DMARC) | _dmarc.newsletter | v=DMARC1; p=quarantine; rua=mailto:dmarc-mkt@example.com | Quarantine failures for marketing subdomain. |
Best Practices for TXT Records in Email‑Heavy Environments
- Assign clear ownership for TXT changes; avoid letting every tool auto‑edit DNS without review.
- Maintain documentation for each TXT record: who owns it, what system uses it, when it was last validated.
- Audit SPF includes and DKIM selectors periodically to remove unused or legacy entries.
- Roll out DMARC gradually: start with
p=none, then move to quarantine/reject as you gain confidence. - Use staging or subdomains for experiments instead of constantly editing your primary SPF/DMARC.
| ✅ Task | Frequency | Owner |
|---|---|---|
| Review SPF, DKIM, DMARC TXT records | Quarterly | Deliverability / Infra |
| Audit TXT verification tokens | Twice per year | Infra / Security |
| Validate DMARC reports and adjust policies | Monthly | Deliverability |
FAQ TXT DNS Records for Email
Why do SPF, DKIM, and DMARC use TXT records instead of their own types?
TXT records were widely supported and flexible when these standards were developed, so they became the practical vehicle for carrying authentication data. Dedicated record types were proposed for some mechanisms, but TXT won because every DNS implementation already handled it reliably.
Can I have more than one SPF TXT record?
No. You must publish exactly one SPF TXT record per host. If you need to combine policies from multiple providers, merge them into a single record, using include: and other mechanisms rather than creating separate SPF TXT entries.
Where should I publish DMARC if I use subdomains heavily?
Start with a DMARC policy at _dmarc.example.com for the organizational domain. You can then override behavior for specific subdomains with TXT records at _dmarc.sub.example.com. This lets you apply stricter or more relaxed policies per stream while keeping a global view.
How dangerous is it to paste provider SPF includes blindly?
Copy‑pasting includes without understanding them can push you over the 10‑lookup limit or accidentally authorize systems you do not control. Always review what an include expands to and periodically prune providers you no longer use.
How often should I rotate DKIM keys?
Rotation cadence depends on your risk model, but many organizations rotate keys every 6-12 months or whenever a key’s confidentiality might be in doubt. When rotating, keep old selectors published until you are sure all in‑flight mail signed with them has been delivered.
Do verification TXT records affect deliverability if I leave them forever?
Verification TXT records by themselves do not usually affect deliverability, but unmanaged clutter increases the risk of human error when editing DNS. It is best to document them, remove those no longer needed, and keep your zone as clean and readable as possible.
Don’t forget to clean your list. Boost your inbox rate.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, and 9 more invalid types. Free tier renews every day, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
