MX and TXT Records Explained
mx record lookup · txt record dns · spf record check dns · dkim dmarc txt
Complete guide to MX and TXT DNS records: mail routing, SPF, DKIM, DMARC, verification tokens, and how to check them online with DN01.
By DN01 Network Team
MX and TXT records control email delivery and domain verification. MX (Mail Exchange) tells the internet which servers accept mail for your domain. TXT holds text policies — most importantly SPF, DKIM, and DMARC for deliverability, plus one-off verification strings from Google, Microsoft, and other providers.
This guide explains how each record works, shows real-world examples, walks through checking records with the DNS Checker, and covers the mistakes we see most often after migrations or registrar changes. For single-record debugging you can also use the DIG tool or review WHOIS nameserver delegation if nothing resolves.
Treat MX and TXT as a system: MX routes inbound mail, while TXT authorizes outbound senders and proves domain control to third parties. A change at your registrar, CDN, or mail host can break one layer while the others still look healthy — that is why a full lookup beats checking only the record you remember editing.
What are MX records?
An MX record maps a domain to one or more mail exchangers, each with a priority (preference) integer. Senders try the lowest number first; equal priorities can be load-balanced. Example: `10 mail.example.com` and `20 mail-backup.example.com`.
MX targets must be hostnames with A or AAAA records — not bare IP addresses. After changing MX, verify with the DNS Checker and allow TTL to expire on old caches. Pair MX checks with the Blacklist Checker if inbound mail suddenly lands in spam folders.
Production domains should publish at least two MX hosts on different networks. If the primary exchanger is unreachable, RFC 5321 requires sending sites to try the next lower-priority host. Document both priorities in change tickets and re-run the DNS Checker after every MX edit so support threads show live priorities, not panel screenshots.
What are TXT records?
TXT records store arbitrary text strings. Email operators publish SPF at the apex (or legacy subdomain) as `v=spf1 ...`, DKIM as selectors like `default._domainkey.example.com`, and DMARC at `_dmarc.example.com`. Site verification uses short tokens (`google-site-verification=...`, `MS=ms...`).
Multiple strings in one TXT answer are normal. Some panels split long DKIM keys across chunks. When troubleshooting, copy the exact concatenated value from the DNS Checker rather than retyping from a PDF.
TXT is also used for BIMI, MTA-STS, and TLS-RPT on advanced mail setups — still published as text at predictable names. If your provider rotates DKIM selectors, both old and new selectors may appear briefly; query TXT after each rotation and note TTL before removing retired keys.
SPF, DKIM, and DMARC in TXT
SPF lists which hosts may send mail for your domain (`v=spf1 include:... ~all`). Only one SPF TXT may exist per owner name — duplicate SPF strings invalidate the policy entirely. Merge includes instead of adding a second record at the apex.
DKIM publishes a public key at `selector._domainkey.example.com`. Alignment with the From header domain matters for DMARC pass/fail. After onboarding a relay, confirm the selector TXT in the DNS Checker matches the provider dashboard before sending bulk campaigns.
DMARC at `_dmarc.example.com` sets policy (`p=none`, `quarantine`, `reject`) and report addresses (`rua=`, `ruf=`). Start with `p=none` to collect aggregate reports, then tighten once SPF and DKIM align reliably. Re-check all three families with the DNS Checker after any mail migration — MX alone never proves SPF is correct.
How to check MX and TXT online
Step 1 — Open the DNS Checker and enter the domain (apex or subdomain). Step 2 — Run a full lookup or focus on MX and TXT sections. Step 3 — Compare priority, targets, and TXT strings with your mail provider's setup guide. Step 4 — If values are stale, note TTL and re-query after it elapses.
For a focused MX query only, open the DIG tool, choose type MX, and inspect the answer section. Use the same domain in WHOIS to confirm nameservers match the DNS panel you edited.
Archive checker output in tickets: priorities, exchanger hostnames, full SPF/DKIM/DMARC strings, and TTL values. When Authentication-Results still show failures after a fix, wait one full TTL window and run the DNS Checker again — recursive caches often outlive the moment you click Save in the panel.
Verification and third-party TXT tokens
Search Console, Microsoft 365, Stripe, and certificate vendors each ask for a unique TXT proof at the apex or `_dnsauth` labels. These tokens coexist with SPF if published as separate TXT records at the same name — unlike SPF, multiple unrelated TXT strings at one owner are valid.
Before deleting «old» TXT records during cleanup, confirm none are active verification or DKIM keys. The DNS Checker lists every TXT answer at a name so you can compare against provider docs instead of guessing from memory.
After adding a verification TXT, query immediately with the DNS Checker, then again after TTL if the vendor still reports failure. Some registrars batch zone publishes every few minutes — two identical checker runs five minutes apart build confidence faster than refreshing the vendor UI alone.
Common problems
Missing SPF is the fastest way to spam folders. Wrong MX priority sends mail to a decommissioned host. Typoed verification TXT breaks Search Console or Microsoft 365 setup. Stale cached answers after TTL not lowered before a cutover look like «DNS is broken» when propagation is still in flight.
Duplicate SPF records at the same name invalidate SPF entirely — merge into one TXT. DMARC without aligned DKIM/SPF reports failures but does not fix them; treat DMARC as policy layer on top of working auth records.
Pointing MX at a CNAME-only label breaks resolution on strict resolvers. Publishing MX to a hostname without working A/AAAA records creates silent mail loss — confirm exchanger targets in the DNS Checker after every MX target change.
MX and TXT during migrations
Mail migrations fail quietly when MX is updated before SPF/DKIM/DMARC are ready on the new provider, or when old MX records remain with lower priority numbers than intended. Publish a baseline with the DNS Checker before cutover, then diff MX and TXT sections hourly during the migration window.
Lower TTL on MX and critical TXT twenty-four to forty-eight hours before the switch if your DNS host allows it. Confirm the lower TTL is visible publicly with the DNS Checker — some panels show 300 seconds while the live zone still serves 3600 until the next publish cycle completes.
Keep the old provider's MX at higher priority (larger number) until you validate inbound delivery on the new stack, then remove retired exchangers. Outbound mail may still use old SPF includes until you update apex TXT — check both directions with the DNS Checker before closing the ticket.
Document who owns each TXT string (marketing verification, IT mail, finance DMARC reports) so future cleanups do not delete production authentication records by mistake.
| Record | Purpose | Example | Check with |
|---|---|---|---|
| MX | Mail routing and priority | 10 mail.example.com | DNS Checker or DIG (MX) |
| TXT (SPF) | Sender authorization | v=spf1 include:_spf.example.com ~all | DNS Checker (TXT filter) |
| TXT (DKIM) | Signed mail authentication | v=DKIM1; k=rsa; p=MIGf... | DNS Checker (TXT) |
| TXT (DMARC) | Policy for failed auth | v=DMARC1; p=quarantine; rua=mailto:[email protected] | DNS Checker (TXT) |
| TXT (verify) | Domain ownership proofs | google-site-verification=abc123 | DNS Checker (TXT) |
Frequently asked questions
- How long do DNS changes take to appear?
Most resolvers honor TTL (time to live). If TTL is 3600 seconds, expect up to an hour before cached answers expire. Lower TTL before migrations, make the change, then verify with the DNS Checker and wait for the new values.
- Can I check MX and TXT without installing dig?
Yes. Open the DNS Checker, enter your domain, and filter or scroll to MX and TXT sections. For a single record type you can also use the DIG tool with type MX or TXT.
- Why does mail work but SPF still fails?
SPF only authorizes sending IPs or include chains. A working MX record does not imply SPF is correct. Compare your outbound SMTP IPs with the SPF include chain and use TXT lookups to confirm the live string matches your mail provider documentation.
- Should I use multiple MX records?
Yes for production mail. Publish at least two MX hosts with different priorities (lower number = higher preference). If the primary is down, senders try the next priority per RFC 5321.
- What RFC covers SPF?
SPF is defined in RFC 7208 (formerly RFC 4408). DKIM is RFC 6376 and DMARC is RFC 7489. These are all published as TXT records at predictable names.
- Can I publish MX and SPF on the same hostname label?
MX and SPF usually live on different names — MX on the apex or mail subdomain, SPF as TXT at the apex. Never place CNAME at a label that also needs MX or SPF. Use the DNS Checker to confirm no conflicting types share one owner name.
- How often should I re-check MX and TXT in production?
After every DNS or mail provider change, plus quarterly audits for domains that send bulk mail. Automated monitoring via the DN01 API can alert when MX priorities or SPF strings drift from expected values.
- Does DNS Checker store my lookups?
Successful checks may appear in local recent history in your browser session for convenience. Use the documented API with your own token if you need repeatable monitoring without using the web UI.