TXT Record Lookup

Q: What does a DMARC TXT record look like and where does it live?

A DMARC record lives at the subdomain _dmarc.yourdomain.com (note the leading underscore), not at the apex domain. The record value follows this structure: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100 . Key tags: p= sets the policy (none = monitor only, quarantine = send to spam, reject = block entirely); rua= is the email address to receive aggregate reports (sent daily); ruf= is the address for forensic/failure reports; pct= sets the percentage of failing emails the policy applies to (default 100%). To look up DMARC, enter _dmarc.yourdomain.com as the hostname in the TXT lookup tool. A missing DMARC record means no policy enforcement and no abuse visibility.

Look up TXT records for any domain to verify SPF, DKIM, and DMARC email authentication — or check domain ownership tokens for Google Search Console, Microsoft, and SSL providers. Free online TXT record checker.

What Are TXT Records Used For?

SPF (Sender Policy Framework) — prevent email spoofing: An SPF TXT record lists the mail servers authorized to send email on behalf of your domain. It looks like v=spf1 include:_spf.google.com ~all. If your SPF is missing or doesn't include your sending server's IP, emails land in spam or fail delivery. A TXT lookup reveals your current SPF policy and whether it covers all your sending services.
DKIM (DomainKeys Identified Mail) — email signature verification: DKIM TXT records store the public key used to verify email signatures. They live on a selector subdomain: selector._domainkey.example.com. Each sending service (Google Workspace, Mailchimp, SendGrid) uses its own selector — a TXT lookup on the specific selector confirms whether the public key is published and matches what your email provider expects.
DMARC — email authentication policy and reporting: A DMARC TXT record at _dmarc.yourdomain.com defines what happens when email fails SPF and DKIM checks: p=none (monitor), p=quarantine (spam), or p=reject (block). It also specifies reporting email addresses (rua=, ruf=) to receive aggregate and forensic reports of authentication failures.
Domain ownership verification tokens: Google Search Console uses google-site-verification=xxxxx, Microsoft uses ms=msxxxxxxxx, and many SSL/CA providers require TXT-based domain validation before issuing certificates. A TXT lookup confirms these verification tokens are correctly published and will be found during automated validation checks.
Multiple TXT records coexisting at once: A production domain typically publishes many TXT records simultaneously — SPF, one DKIM record per sending service, DMARC, and one or more ownership verification tokens — all at the same apex domain (or subdomains for DKIM and DMARC). A TXT lookup returns all of them, letting you audit the complete set in one query.

Look Up TXT Records

How to Look Up TXT Records

For SPF, DMARC, or verification tokens — use the root domain: Enter example.com (not www.example.com). SPF and most verification tokens live at the apex domain. DMARC lives at _dmarc.example.com — enter that subdomain explicitly for DMARC lookups.
For DKIM — use the selector subdomain: DKIM records require a selector prefix. The format is selector._domainkey.example.com. For Google Workspace, the default selector is google — so enter google._domainkey.example.com. For Mailchimp, the selector is typically k1 or k2. Check your provider's setup instructions for the exact selector name.
Select TXT as the record type: Choose TXT from the record type dropdown to return all TXT records published for that name. All records of the same type at the same hostname are returned together.
Parse the results: Each TXT record value appears as a quoted string. v=spf1 at the start identifies SPF; v=DKIM1 identifies DKIM public keys; v=DMARC1 identifies DMARC policies. Verification tokens typically start with the provider name (google-site-verification=, ms=, etc.).
Validate the content: Copy your SPF record value and compare it against your email provider's documentation to verify all required include: mechanisms are present. For DMARC, confirm the p= policy matches your intended enforcement level.

Real-World Use Case

A startup's marketing emails are landing in recipients' spam folders. The email deliverability consultant runs a TXT record lookup on the root domain and finds three problems at once: (1) the SPF record includes their old Mailchimp account (include:servers.mcsv.net) but not the new SendGrid account they migrated to 3 months ago — so all SendGrid emails fail SPF; (2) there is no DMARC record at _dmarc.domain.com, meaning there's no policy enforcement or reporting to detect abuse; (3) a stale Google site verification token is present that matches a Search Console property that was deleted. A single TXT lookup reveals the complete picture — the consultant adds the SendGrid SPF include, publishes a DMARC monitoring record, and removes the stale verification token, resolving all three issues before starting any actual email sending changes.

Best Practices for TXT Record Management

Keep SPF to a single record with one v=spf1 tag: DNS standards allow only one SPF record per hostname. Multiple SPF records cause immediate SPF failure regardless of content. If you need to authorize multiple senders, combine them into a single record using include: mechanisms or ip4:/ip6: blocks.
Limit SPF to 10 DNS lookups: Each include:, a:, and mx: mechanism in an SPF record triggers a DNS lookup during verification. The SPF spec caps this at 10 — exceeding it causes PermError and SPF failure. Use TXT lookup to count your current mechanisms; consider SPF flattening tools if you're near the limit.
Publish DMARC in monitoring mode first: Start with p=none; rua=mailto:reports@yourdomain.com to receive aggregate reports without blocking any email. Analyze the reports for 4-8 weeks to identify all legitimate sending sources before escalating to p=quarantine or p=reject.
Verify DKIM for every sending service separately: Each email service (Google Workspace, Mailchimp, SendGrid, HubSpot) uses its own DKIM selector and public key — look up each one independently using its specific selector subdomain. A missing DKIM record for one service doesn't affect others.
Remove stale verification tokens: Old Google Search Console, Microsoft, and SSL verification tokens left in DNS are harmless but add clutter and can confuse audits. Periodically review and remove TXT records for platforms you no longer use.

Performance & Limits

Returns all TXT records at once: Multiple TXT records at the same hostname (e.g., SPF + verification tokens at the apex domain) are all returned in a single query — no need to query individually.
Supports any subdomain depth: Look up DKIM selectors (selector._domainkey.example.com), DMARC (_dmarc.example.com), BIMI (default._bimi.example.com), or any other TXT-based subdomain record.
Live authoritative results: Queries use DNS-over-HTTPS to public resolvers, returning the currently-published authoritative values — not locally-cached stale data from your own resolver.
No character limit on output: TXT records can be up to 255 characters per string, with multiple strings chained — DKIM public keys are often 300+ characters. The tool displays the complete value regardless of length.
No software required: Works in any browser without dig, nslookup, or command-line access — accessible to non-technical administrators and support teams.

Common TXT Record Mistakes to Avoid

Publishing two SPF records instead of one: Adding a new SPF record without removing the old one creates two v=spf1 records at the same hostname — this immediately fails SPF evaluation for all email from your domain. Always edit the existing SPF record rather than adding a new one.
Looking up DKIM at the apex domain instead of the selector subdomain: DKIM records don't live at example.com — they live at selector._domainkey.example.com. Querying the apex for DKIM will return nothing or unrelated TXT records. Always include the selector prefix and ._domainkey. in the query name.
Confusing DMARC p=none with "no DMARC": A DMARC record with p=none is published and active — it monitors authentication results and sends reports, but doesn't block failing email. "No DMARC" means no _dmarc TXT record exists at all, which is different and leaves your domain with no reporting or policy enforcement.
Not verifying after adding a TXT record: DNS providers sometimes silently fail to save TXT records with special characters (semicolons, equals signs in DKIM keys) — always run a TXT lookup immediately after adding or modifying a TXT record to confirm it's actually being served.

Privacy & Security

DNS-over-HTTPS queries: All TXT lookups use DoH, preventing network-level observation of which domains you query.
Public record data only: TXT records are publicly accessible by design — anyone on the internet can query them. This tool retrieves the same data as any resolver.
No query logging: Domains queried are not stored or retained beyond your current browser session.
No account required: Check TXT records for any domain without registration or personal information.

Frequently Asked Questions

How do I look up a DKIM record for my domain?

DKIM records don't live at your apex domain — they require a selector subdomain in the format selector._domainkey.yourdomain.com. The selector name is assigned by your email provider: Google Workspace uses google (so query google._domainkey.yourdomain.com), Mailchimp typically uses k1 or k2, and SendGrid uses a custom selector visible in your SendGrid dashboard under Sender Authentication. Enter the full selector subdomain in the lookup tool and select TXT as the record type. The result should start with v=DKIM1; k=rsa; p= followed by a long base64-encoded public key. If you receive no result, the DKIM record hasn't been published yet or you're using the wrong selector name.

What is an SPF record and how do I verify it's correct?

An SPF (Sender Policy Framework) record is a TXT record at your apex domain that lists which mail servers are authorized to send email as your domain. It starts with v=spf1 and includes mechanisms like include:_spf.google.com (authorize Google Workspace), ip4:203.0.113.0/24 (authorize a specific IP range), and ends with a qualifier like ~all (softfail) or -all (hard fail). To verify it's correct: (1) run a TXT lookup on your apex domain; (2) find the record starting with v=spf1; (3) compare the include: mechanisms against every email sending service you use; (4) confirm there's only one SPF record (two records = immediate SPF failure). If you're missing a sending service, add its SPF include to the existing record — do not add a second SPF record.

What does a DMARC TXT record look like and where does it live?

A DMARC record lives at the subdomain _dmarc.yourdomain.com (note the leading underscore), not at the apex domain. The record value follows this structure: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100. Key tags: p= sets the policy (none = monitor only, quarantine = send to spam, reject = block entirely); rua= is the email address to receive aggregate reports (sent daily); ruf= is the address for forensic/failure reports; pct= sets the percentage of failing emails the policy applies to (default 100%). To look up DMARC, enter _dmarc.yourdomain.com as the hostname in the TXT lookup tool. A missing DMARC record means no policy enforcement and no abuse visibility.

Can a domain have more than one TXT record?

Yes — a domain can and typically does have multiple TXT records at the same hostname. At the apex domain, you commonly see an SPF record, one or more domain ownership verification tokens (Google Search Console, Microsoft, Atlassian, etc.), and sometimes BIMI pilot records coexisting at the same name. DNS delivers all of them together when queried. The important exception is SPF: while technically multiple TXT records at the same name are allowed, the SPF specification states that only one record starting with v=spf1 should exist — two SPF records cause PermError and SPF authentication failure. DKIM and DMARC avoid this issue by living on separate subdomains (selector._domainkey and _dmarc respectively), giving each service its own isolated namespace.