10 TXT Record Checker Tools for Email Delivery

Do not index

Authentication can look correct in DNS while messages still land in spam, bounce, or lose visibility across Gmail, Outlook, and Yahoo. A TXT record checker confirms what DNS publishes, but it can't prove that SPF, DKIM, DMARC, and BIMI align with the visible From address, match the actual sending infrastructure, survive propagation differences, or support a healthy sender reputation. The right diagnostic depends on the question: is the record published, structurally valid, propagated consistently, interpreted correctly, or working in real mail flow?

The resources below are organized by diagnostic job rather than treated as interchangeable lookup pages. The practical sequence is simple: inspect the published records, query authoritative DNS, compare resolver results, review message headers and DMARC reports, then connect authentication results to bounces, complaints, reputation, and lost revenue.

Table of Contents

1. MXToolbox DNS Lookup and TXT Record Checker What MXToolbox can prove 2. Google Admin Toolbox Dig Where raw DNS output matters 3. DMARC Analyzer Why reporting beats a presence check 4. Zonemaster Use it after structural changes 5. Cloudflare DNS Lookup Read TTL as operational context 6. OnDMARC TXT Record Inspector Test the policy logic, not just syntax 7. MailAdept Deliverability Diagnostics with the mailX API Connect infrastructure to commercial risk 8. DNS Checker Use propagation checks with restraint 9. WhatsMyDNS TXT Record Lookup Diagnose resolver disagreement correctly 10. Reverse DNS Lookup with TXT Context Check the complete sending identity Top 10 TXT Record Checker Comparison Choose the Checker That Answers the Real Question Common mistakes that keep causing delivery failures A practical TXT record troubleshooting checklist Frequently asked questions What does a TXT record checker verify?Does a TXT checker check BIMI?Why can SPF pass while DMARC fails?How long do DNS changes take to appear?When is expert diagnosis warranted?

1. MXToolbox DNS Lookup and TXT Record Checker

MXToolbox is useful when a deliverability team needs a readable first pass across the authentication stack. It can expose the exact TXT values associated with SPF, DKIM, and DMARC, while syntax-oriented checks help identify records that are missing required structure. That matters because a typo in v=spf1, an incorrect DKIM selector, or a malformed DMARC policy can stop receiving systems from evaluating authentication as intended.

A practical lookup should check all three records together:

SPF at the sending domain: example.com TXT

DKIM at the selector host: selector1._domainkey.example.com TXT

DMARC at the policy host: _dmarc.example.com TXT

A valid-looking result still needs context. SPF authorizes the envelope sender, DKIM validates a signature, and DMARC evaluates alignment with the visible From domain. If one link fails, Gmail, Outlook, or Yahoo may place legitimate mail in spam or reject it, reducing conversions and weakening brand trust.

What MXToolbox can prove

The checker can show whether a record is visible through the queried DNS path and whether its value resembles the expected authentication syntax. It can also help identify inconsistent nameserver answers and expose TTL information when available.

A useful header excerpt looks like this:

Authentication-Results: mx.example.net; spf=pass; dkim=pass; dmarc=fail header.from=example.com

That message passed SPF and DKIM in isolation, yet DMARC failed because alignment or policy evaluation failed. A checker helps locate the record. The header explains what happened to the message.

View the comparison infographic

2. Google Admin Toolbox Dig

Google Admin Toolbox Dig is the right choice when a visual checker leaves uncertainty about DNS authority, delegation, or resolver behavior. It presents raw DNS output, including the response structure that a receiving mail system uses to find TXT data. That makes it less friendly for casual checks, but more valuable during an outage or nameserver migration.

A typical command-line equivalent is:

dig example.com TXT

For a DMARC policy, the query target must be exact:

dig _dmarc.example.com TXT

DMARC receivers query the _dmarc name for the policy record, as specified by RFC 7489. Checking example.com instead of _dmarc.example.com can create a false conclusion that DMARC is missing or broken.

Where raw DNS output matters

Dig can reveal which nameservers answer, whether the delegation chain points to the intended provider, and whether responses differ between authoritative servers. It can also expose DNSSEC-related response flags and delegation problems that a simplified TXT lookup may hide.

Use direct authoritative queries when possible:

dig @ns1.example-dns.com example.com TXT

Then compare the result with another authoritative server:

dig @ns2.example-dns.com example.com TXT

If one server publishes the new SPF value and another returns the old value, some receiving systems may authenticate messages differently. That creates inconsistent delivery, confusing incident reports, and potentially unnecessary campaign pauses.

The +trace option can follow delegation from the root through the authoritative zone:

dig +trace example.com TXT

Dig doesn't interpret whether a DMARC policy is strategically appropriate, and it doesn't inspect sender reputation. It proves DNS behavior, not business impact. A raw response can confirm publication while mail still fails because the wrong sending source is authorized or the DKIM signature uses another selector.

See the terminal-style DNS lookup illustration

3. DMARC Analyzer

DMARC analyzers from PowerDMARC, Valimail, and Dmarcian address the question that basic TXT lookup pages usually leave unanswered: does the published policy correspond to real mail flow? These platforms process aggregate reports and can map sending sources, authentication results, and policy outcomes to the domain's DMARC configuration.

A raw record such as:

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

shows that a policy exists and that aggregate reports have a destination. It doesn't show whether marketing platforms, transactional providers, support systems, and outbound tools pass alignment. That distinction matters because SPF may pass for the envelope domain while the visible From domain remains misaligned.

Why reporting beats a presence check

DMARC reports can identify an unrecognized sender using the brand's domain, a legitimate provider omitted from SPF, or a DKIM selector that no longer matches production headers. Those failures can send legitimate messages toward spam or enforcement, while unauthorized sources can damage domain reputation and create phishing risk.

Teams should review reports before changing p=none to p=quarantine or p=reject. A policy change made without source inventory can block invoices, password resets, or campaign mail. The resulting revenue risk is practical, not theoretical. Customers miss lifecycle messages, sales sequences lose visibility, and support teams inherit avoidable tickets.

A DMARC analyzer also doesn't replace message-level testing. Aggregate data is broad, while a failed message header can reveal the exact selector, envelope sender, and authentication result behind a single incident.

Organizations that need deeper context should also understand email authentication as a connected system rather than a collection of unrelated TXT values.

Review the DMARC report illustration

4. Zonemaster

Zonemaster is designed for DNS zone validation, not merely for displaying a TXT string. It checks delegation, nameserver behavior, DNS structure, and standards compliance. That makes it useful when several lookup tools return a record, yet mail servers still report intermittent authentication failures.

The distinction is important. A checker may display a TXT value that a resolver can retrieve, while a deeper zone test identifies a delegation defect, inconsistent authority, or DNSSEC problem. Those structural issues can cause receiving systems to time out, fail validation, or obtain different answers depending on the DNS path.

Use it after structural changes

Zonemaster is especially appropriate after:

Nameserver migrations: Delegation errors can affect every authentication record at once.

Registrar changes: A domain can point to an unintended DNS provider or incomplete zone.

DNSSEC changes: Invalid or expired signatures can make otherwise correct records unusable.

Complex zone edits: Duplicate or malformed entries may behave differently across tools.

A useful record-shape example is a split TXT value:

"v=DKIM1; k=rsa; p=first-part-of-key" "second-part-of-key"

Each individual character-string is limited to 255 characters, while a longer TXT value can use multiple strings that resolvers concatenate, according to ISC's DNS guidance. A checker that displays the fragments separately without reconstructing the value can mislead an operator reviewing a DKIM key.

Zonemaster can prove that DNS structure and delegation are behaving correctly. It can't determine whether the key matches the signature in a real message or whether the sender's reputation is causing spam placement. If the zone passes but delivery fails, policy logic, alignment, headers, or reputation deserve attention.

5. Cloudflare DNS Lookup

Cloudflare DNS Lookup is useful for a quick resolver-level view of how TXT records are being served. It can show the returned value, record type, and TTL, helping teams compare what a public DNS path sees with what the authoritative nameserver publishes.

That comparison matters after a DNS change. A local dashboard may show the new value immediately, while receiving mail systems continue to use a cached response. A campaign launched during that mismatch can produce mixed authentication results. Some recipients may accept the new DKIM selector, while others query an older value and fail signature verification.

Read TTL as operational context

TTL tells resolvers how long they may retain an answer. It doesn't measure inbox placement, sender reputation, or the quality of an SPF policy. A low TTL can create more frequent refreshes, while a longer TTL can make corrections slower to appear after a mistake. Neither setting makes a flawed authentication record correct.

A practical comparison looks like this:

Cloudflare resolver result: what a public resolver currently returns.

Authoritative Dig result: what the DNS host currently publishes.

Message header result: what the receiving server evaluated.

DMARC report result: how multiple receiving systems observed the policy in production.

Cloudflare's lookup is therefore a sanity check, not a final deliverability verdict. If the public result differs from authoritative DNS, the team should investigate caching, delegation, or zone publication. If both agree but dmarc=fail appears in headers, the next task is alignment and policy interpretation.

See the global DNS distribution illustration

6. OnDMARC TXT Record Inspector

OnDMARC's inspector is designed to translate raw SPF, DKIM, and DMARC values into policy meaning. That interpretation is valuable because operators often see a record that exists, assume protection is active, and miss the fact that the policy only monitors failures.

For example:

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

This record requests reporting but doesn't instruct receivers to quarantine or reject failing messages. That may be appropriate during inventory, but it shouldn't be mistaken for enforcement.

Test the policy logic, not just syntax

An SPF value ending in +all authorizes every sending source. It may be syntactically readable, yet it defeats the purpose of restricting senders. An SPF record should be reviewed against every legitimate platform, including transactional services, marketing systems, help desks, and sales infrastructure.

The inspector can help flag these policy decisions and draw attention to subdomain behavior. A domain may have a parent policy while a subdomain uses a separate record. If the sending address, Return-Path, or DKIM signing domain uses that subdomain, the team must inspect the exact host involved.

A useful DKIM example is:

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"

If the message header says d=example.net or s=selector2, the published selector1 record isn't relevant to that message. The checker can confirm that selector1 exists. Only the header can show which selector the sender used.

Teams can use MailAdept's SPF record checker for a focused publication and validation check, then compare the result with headers and reports before enabling stricter enforcement.

7. MailAdept Deliverability Diagnostics with the mailX API

A DNS-only lookup answers where a record points. MailAdept's mailX API is intended for the harder question, whether the record fits the sending system and the observed authentication results. It combines checks for SPF, DKIM, DMARC, and BIMI with header-level context and broader deliverability diagnostics.

That distinction changes the investigation. An SPF record may be published correctly but authorize an outdated or problematic upstream source. A DKIM public key may resolve successfully while the message uses a different selector. A DMARC policy may exist while the visible From domain fails alignment for a major mail stream.

Connect infrastructure to commercial risk

A practical diagnostic should associate each sending source with its domain, envelope sender, IP or provider, DKIM selector, and observed authentication result. Without that inventory, teams can fix the root domain while leaving a transactional subdomain or campaign platform broken.

The same diagnostic should also consider bounces, spam complaints, and reputation signals. Authentication is a prerequisite for trust, not a substitute for it. Mailbox providers can still filter messages when recipients disengage, complain, or see suspicious sending behavior.

MailAdept is a subscription-based email deliverability consulting service that combines AI agents with human experts. Its work can help teams turn isolated TXT results into an operational plan, but no diagnostic should promise or guarantee inbox placement. The sensible output is a prioritized list of verified failures, affected sending sources, controlled changes, and retest results.

email deliverability consulting earns its value. Tools reduce lookup time. Experienced review determines which change is safe, which source is causing the failure, and which messages carry the highest revenue risk.

8. DNS Checker

DNSChecker is designed for propagation analysis across multiple geographic lookup points. It helps answer whether a newly published TXT value is visible consistently, rather than relying on one resolver or a local DNS cache.

That job matters after changing SPF, DKIM, or DMARC. A sender can receive a successful result in one location while another resolver still returns the old value. During that window, delivery may vary by recipient provider or region, making campaign performance appear random.

Use propagation checks with restraint

DNSChecker can show that a record hasn't reached every queried location. It can't prove that all receiving mail systems have refreshed their caches, and it can't prove that the new value is logically correct. A globally visible mistake remains a mistake.

The correct sequence is:

Record the old value: Preserve the previous SPF, DKIM, or DMARC configuration.

Publish the controlled change: Edit the existing record rather than creating duplicates.

Check authoritative DNS: Confirm that the intended nameservers serve the new value.

Compare multiple locations: Look for stale or conflicting answers.

Send controlled tests: Inspect headers at Gmail, Outlook, and Yahoo accounts.

Review reports: Confirm production behavior after the change.

A DNS change can appear quickly or remain cached longer, depending on resolver behavior and TTL. Teams shouldn't schedule a high-risk enforcement change solely because one propagation page looks green. If propagation is consistent but DMARC still fails, the likely issue is alignment, selector choice, source authorization, or policy interpretation.

9. WhatsMyDNS TXT Record Lookup

WhatsMyDNS is useful when different recipients report different outcomes after a DNS edit. Its multi-resolver view can expose whether public resolvers return the same TXT value or whether caching and authority remain inconsistent.

Consider a split result. A Google Public DNS query returns the new SPF record, while another resolver returns the previous value. That doesn't establish that Gmail will accept every message or that another provider will reject every message. It does establish that DNS answers differ across paths, which is enough to delay production changes.

Diagnose resolver disagreement correctly

Resolver differences can result from cached responses, stale delegation, or inconsistent authoritative nameservers. The next step is not automatically to blame the public resolver. Query the authoritative servers directly with Dig and compare their answers.

A useful diagnostic chain is:

Authoritative servers disagree: investigate DNS provider publication or zone configuration.

Authoritative servers agree, public resolvers differ: allow caching to settle and verify TTL behavior.

Resolvers agree, headers fail: inspect the actual Return-Path, DKIM selector, signing domain, and DMARC alignment.

Headers pass, mail lands in spam: investigate reputation, engagement, content, complaint signals, and provider-specific filtering.

WhatsMyDNS can prove resolver consistency at the time of testing. It cannot prove inbox placement or determine whether an authenticated sender deserves trust. That boundary prevents a common and costly mistake, treating a clean propagation screen as permission to scale sending.

10. Reverse DNS Lookup with TXT Context

Reverse DNS isn't a TXT lookup, but it belongs in an infrastructure diagnosis because receiving systems evaluate more than visible authentication records. A reverse DNS checker queries the PTR hostname for a sending IP, then compares that identity with forward DNS and the domain's authentication configuration.

A sending IP that identifies as a generic infrastructure hostname can create a weak identity signal. A PTR hostname that doesn't resolve back to the sending IP creates a forward and reverse mismatch. An IP that sends mail but isn't authorized by SPF creates another gap. Each issue can contribute to rejection, spam placement, or reputation deterioration even when DKIM and DMARC records are present.

Check the complete sending identity

For every dedicated sending IP, confirm:

PTR hostname: It should identify the intended mail infrastructure.

Forward resolution: The PTR hostname should resolve to the sending IP.

SPF authorization: The sending IP or authorized provider path should appear in the relevant SPF policy.

DKIM identity: The message's signing domain and selector should match published DNS.

SMTP identity: The SMTP banner and TLS identity should be consistent with the configured hostname where applicable.

An infrastructure owner, not a regular DNS editor, usually controls PTR records. The sender should request a custom reverse DNS configuration from the email service provider and then validate the result independently. A generic PTR isn't an automatic rejection, but it removes useful identity consistency from the receiving server's assessment.

Teams troubleshooting an SMTP identity problem can also review guidance on how to fix a reverse DNS mismatch. The checker can prove forward and reverse relationships. It can't calculate reputation or guarantee that a mailbox provider will place a message in the inbox.

See the forward and reverse DNS illustration

Top 10 TXT Record Checker Comparison

Tool	Core features	UX & ease	Deliverability value	Best for / Audience	Price / Notes
MXToolbox DNS Lookup and TXT Record Checker	Real-time DNS/TXT queries; SPF/DKIM/DMARC syntax checks; blacklist lookup	Web UI; easy for quick checks; some UI clutter	Pinpoints malformed TXT records and alignment errors that block acceptance	Deliverability pros, admins, quick diagnostics	Free tier; no automated monitoring
Google Admin Toolbox Dig	Raw dig output; authoritative NS responses; DNSSEC, SOA/NS details	Command-style output; steep learning curve	Confirms authoritative publication; finds propagation gaps & DNSSEC failures	DNS engineers, mail server operators	Free
DMARC Analyzer (PowerDMARC / Valimail / Dmarcian)	DMARC aggregate/forensic parsing; source breakdown; enforcement tracking	Data-rich dashboard; requires DMARC reports (delay)	Shows real enforcement across providers and unauthorized senders	Security teams, domain owners, deliverability teams	Paid (subscription for full insights)
Zonemaster (ICANN DNS Validator)	Full zone validation vs. DNS specs; TXT syntax & delegation checks; DNSSEC	Very technical output; slower checks (1–2 min)	Catches DNS-spec violations and delegation errors that break mail lookups	Registrars, DNS administrators, infra teams	Free
Cloudflare DNS Lookup	Global resolver queries; TXT values, TTL, record age; response time diagnostics	User-friendly; global propagation view	Reveals slow or cached responses that cause mail server timeouts	Ops, site owners, deliverability teams monitoring performance	Free; historical data on paid plans
OnDMARC TXT Record Inspector	SPF/DKIM/DMARC three-record view; color-coded policy analysis; enforcement guidance	Email-focused UI; visual policy explanations	Translates TXT records into expected mail outcomes; guides safe policy progression	Email marketers, operations, teams enabling DMARC	Limited free tier; subscription for advanced features
MailAdept Deliverability Diagnostics (mailX API)	Real-time SPF/DKIM/DMARC/BIMI validation; header cross-reference; reputation scoring	Deliverability-native, contextual reports; requires API or consult	Prioritizes fixes by inbox impact; links records to sending behavior and warmup	SaaS, e‑commerce, transactional/high-volume senders, agencies	Part of MailAdept service; consult/API access required
DNS Checker (DNSChecker.org)	Multi-location propagation (20+ regions); TTL per location; visual status	Simple visual interface; fast for post-change checks	Identifies incomplete global propagation causing regional failures	Non-technical teams, quick verification after DNS updates	Free
WhatsMyDNS TXT Record Lookup	Multi-resolver queries (30+ public resolvers); resolver consistency; history	Lightweight; fast; clear consistency view	Detects resolver/caching inconsistencies that create split deliverability	Troubleshooting resolver-specific issues across providers	Free
Reverse DNS (rDNS) Lookup with TXT context	PTR retrieval; forward/reverse alignment; IP reputation context	Technical; may require ISP/hosting changes to fix	Validates IP ownership and rDNS alignment, critical trust signal for mail servers	Transactional/high-volume senders, infra engineers	Tool availability varies; fixes often require provider action

Choose the Checker That Answers the Real Question

A txt record checker is a publication tool first. It can show whether DNS returns a TXT value, whether the value is split into strings, and sometimes whether the syntax resembles SPF, DKIM, DMARC, or verification data. It cannot independently prove that the right sending system is authorized, that DKIM matches the message header, that DMARC alignment passes, or that Gmail, Outlook, and Yahoo will place the message in the inbox.

The diagnostic job determines the right resource:

Publication: Use a readable TXT lookup to confirm the expected host and value.

Authority: Use Dig to verify the authoritative nameservers and delegation chain.

Propagation: Compare resolver and geographic results after a controlled change.

Policy interpretation: Inspect SPF mechanisms, DKIM selectors, DMARC tags, and subdomain behavior.

Reporting: Review DMARC aggregate data to identify real sending sources and failures.

Infrastructure: Check PTR, forward DNS, SMTP identity, and IP authorization.

Deliverability context: Match DNS results with headers, bounces, complaints, engagement, and reputation signals.

Common mistakes that keep causing delivery failures

Checking only one record leaves gaps in the authentication chain. SPF can pass while DKIM fails, or DKIM can pass while DMARC fails because the authenticated domain doesn't align with the visible From address. The fix is to inspect SPF, DKIM, and DMARC for every real sending source.

Confusing DNS visibility with inbox placement leads teams to scale a broken or distrusted stream. A published record proves retrieval, not reputation, engagement, content quality, or provider filtering.

Changing DMARC enforcement without reviewing sources can block legitimate transactional and marketing mail. Review reports and headers before moving from monitoring to stricter enforcement.

Ignoring DKIM selectors and headers causes teams to validate the wrong DNS hostname. The selector in the DKIM-Signature header determines which TXT record matters.

Treating TTL or propagation as proof of success mistakes caching behavior for authentication quality. A record can propagate perfectly and still authorize the wrong provider or use an invalid policy.

A practical TXT record troubleshooting checklist

Identify every sending source, including marketing, transactional, support, and outbound systems.

Inspect SPF, DKIM, DMARC, and BIMI at the exact domains and selector hosts used in messages.

Query authoritative DNS with Dig and confirm nameserver consistency.

Compare public resolvers to separate propagation problems from zone publication errors.

Review message headers for spf, dkim, dmarc, header.from, header.d, and the active selector.

Review DMARC reports for unauthorized sources, alignment failures, and policy outcomes.

Make one controlled change, document the previous value, and retest.

Connect the result to delivery metrics, including bounces, spam complaints, opens, clicks, conversions, and revenue exposure.

Frequently asked questions

What does a TXT record checker verify?

It verifies what a DNS resolver can retrieve for a requested host. It may identify SPF, DKIM, DMARC, or verification records, but it doesn't prove real-message authentication or inbox placement.

Does a TXT checker check BIMI?

Some tools classify or inspect BIMI records, while basic lookup tools only return raw TXT values. A dedicated BIMI check is still needed to validate the correct host and configuration.

Why can SPF pass while DMARC fails?

SPF can pass for the envelope sender while failing alignment with the visible From domain. DMARC evaluates that relationship, along with DKIM alignment and the published policy.

How long do DNS changes take to appear?

The timing depends on authoritative publication, resolver caching, and TTL. A single successful lookup isn't enough, so teams should compare authoritative and public results before testing delivery.

When is expert diagnosis warranted?

Expert review is warranted when authentication appears correct but mail still reaches spam, bounces, produces inconsistent provider results, or affects revenue-critical messages. At that point, the problem usually spans DNS, headers, sending behavior, reputation, and recipient engagement.

The right checker confirms the right layer. Publication, propagation, policy, and deliverability diagnosis are different jobs, and confusing them costs conversions and brand trust. MailAdept combines technical authentication review with ongoing deliverability context, without promising guaranteed inbox placement.

Still facing deliverability issues? Get a free deliverability audit. MailAdept can connect TXT records, message headers, DMARC reports, sender reputation, and sending behavior into a prioritized remediation plan. Teams can visit Mailadept to discuss subscription-based support from AI agents and human deliverability experts.