TXT Record Lookup – SPF, DKIM & DNS Text Records

TXT records are the Swiss Army knife of DNS text storage: they hold SPF policies, DKIM public keys, DMARC reports configuration, and one-line proofs that you control a domain for external services.

Unlike address records, TXT content is opaque to browsers but critical to mail receivers and verification bots that fetch DNS on a schedule.

This TXT record lookup on VSPIC surfaces every published string at the names you query, helping you close the gap between what you think you published and what the world actually sees.

A TXT record stores one or more character strings at a DNS name. There is no fixed schema — meaning comes from conventions like v=spf1 for mail or vendor-specific verification prefixes.

Authoritative servers return TXT as type 16 in DNS. Resolvers present the strings to clients that enforce policy (MTAs, crawlers, certificate authorities).

TXT coexists with other record types on different names, but standard zones forbid TXT on the same name as a CNAME alias.

Sender Policy Framework (SPF) publishes which hosts may send mail claiming your domain in the envelope From. It appears as TXT starting with v=spf1 followed by mechanisms like include, ip4, and all.

Receivers compare the sending IP against SPF mechanisms. A fail or softfail can affect placement in inbox versus spam folders depending on other signals.

SPF has a lookup limit — too many include chains break evaluation. Keep policies concise and test after every change.

DomainKeys Identified Mail (DKIM) signs messages cryptographically. The verifying side fetches a public key from a TXT record at selector._domainkey.domain.

Each sending platform chooses a selector string. Without knowing the selector, you may miss the DKIM TXT — check provider docs or send a signed test message and inspect headers.

Rotating DKIM keys means publishing new TXT at a new selector before retiring the old key.

DMARC tells receivers how to handle mail that fails SPF or DKIM alignment, and where to send aggregate reports. It lives in TXT at _dmarc.domain with v=DMARC1.

Policies range from none (monitor) through quarantine to reject. Tightening policy without aligned SPF and DKIM can block legitimate mail.

Report addresses (rua, ruf) in the DMARC TXT enable visibility into authentication failures.

Search consoles, certificate authorities, and SaaS onboarding often ask you to add a unique TXT string at the apex or a _verification subdomain.

Verification succeeds only when the exact token is visible publicly. Partial matches, wrong names, or trailing spaces cause frustrating false negatives.

After adding verification TXT, use this lookup to confirm propagation before clicking verify in the vendor UI.

• Enter the domain or precise hostname (_dmarc, selector._domainkey, etc.).
• Click Lookup TXT Records.
• Review every Value string — multiple TXT answers are common.
• Identify v=spf1, DKIM key material, v=DMARC1, or vendor tokens.
• Copy values for diffing against provider wizards.
• Re-query after TTL if verification still fails.

• Full TXT strings without truncation
• Host-level clarity for apex and underscore names
• TTL visible for propagation planning
• Foundation for email auth troubleshooting
• Pairs with dedicated SPF/DKIM/DMARC checker
• Free browser access for vendors and IT staff

• Document SPF includes whenever adding a new sender
• Stage DMARC at p=none before moving to quarantine or reject
• Rotate DKIM with overlapping selectors during key changes
• Remove obsolete verification TXT to keep zones tidy
• Audit TXT quarterly alongside MX changes
• Use both raw TXT lookup and parsed checker tools

• SPF DKIM DMARC Checker
• MX Record Lookup
• DNS Lookup
• Email Header Analyzer
• NS Lookup
• WHOIS Lookup

• RFC 7208 — Sender Policy Framework
• RFC 6376 — DomainKeys Identified Mail
• RFC 7489 — DMARC

TXT strings are informational. Mail receivers apply their own policies; correct DNS does not alone guarantee inbox placement.