TXT record lookup

In iterative trace mode, the resolver is ignored.
Query multiple public resolvers to compare answers.

How to use the DNS lookup engine options effectively

What is the iterative trace?

The trace performs resolution step by step. The resolver first queries the root servers, then the TLD (.com, .fr, .eu), and then the authoritative servers of the target zone. At each step, the page shows the queried server, the answer, the RCODE, and the latency.

  1. 1. Root

    Discovery of the TLD servers for the requested name.

  2. 2. TLD

    Reference to the zone's NS (delegation).

  3. 3. Authoritative

    Final answer (or error) with TTL and latency.

What is it for?

  • Compare answers across resolvers and regions
  • Detect a hot cache, an overly long TTL, or an incomplete delegation
  • Explain a latency difference or an unexpected RCODE

Tip: keep the trace disabled for quick checks; enable it when investigating or preparing a ticket/post‑mortem.

What is the classic trace?

The classic trace queries only the selected resolver (UDP or DoH) and displays the answer as it is perceived from that network vantage point. You get the RCODE, the response sections, and the latency for the client → resolver leg.

  1. 1. Chosen resolver

    Uses the preset or custom configuration to run the query exactly like your service would.

  2. 2. Protocol preserved

    Respects the selected transport (UDP, TCP, or DoH) so you reproduce the real behaviour.

  3. 3. Detailed answer

    Shows the question, answer, and authority/additional sections when present, together with TTL and useful metadata.

Why use it?

  • Check the view of a specific resolver before suspecting delegation issues
  • Confirm cached values and the impact of a TTL or a flush
  • Document a resolution exactly as a client or microservice sees it

Tip: keep the iterative trace option turned off when auditing a given resolver; enable it afterwards to compare with the root → TLD → authoritative path.

How does the propagation test work?

The test queries a set of public resolvers (Google, Cloudflare, Quad9, OpenDNS, ISPs…) in parallel and groups the answers by content and RCODE. You instantly see who already picked up the update.

  1. 1. Multi-point resolvers

    Enables the propagation presets to question several actors spread around the world.

  2. 2. Automatic comparison

    Groups identical answers and highlights divergences or resolver-specific errors.

  3. 3. Actionable summary

    Provides a clear recap, the resolver list, their latencies, and each group's status.

When to use it?

  • Track how a DNS change propagates worldwide
  • Spot stale caches and decide on a targeted flush
  • Share a propagation snapshot in a ticket or post-mortem

Tip: while the propagation test is active, the resolver selector is frozen. Disable the mode to return to single-resolver diagnostics.

Additional information about DNS TXT records

A TXT record publishes text associated with a domain name. Services use it to prove domain ownership, configure email settings like SPF DKIM DMARC, or expose technical information.
A TXT record contains a name, a type, a value, and a TTL. The TTL indicates how long the response remains cached in the local resolver.

Example TXT DNS record

NameTypeValueTTL in seconds
@TXT"v=spf1 ip4:203.0.113.0/24 ~all"3600

In this example, the name @ targets the root of the domain. The value contains an SPF rule in text format. A TTL of 3600 corresponds to one hour.

Common examples

NameTypeValueTTL in seconds
selector1._domainkeyTXT"v=DKIM1; k=rsa; p=MII...AB"3600
_dmarcTXT"v=DMARC1; p=quarantine; adkim=s; aspf=s"3600
@TXT"property=token12345"300

These lines show a DKIM selector, a DMARC policy, and a verification token. The targeted name depends on the service used.

Multiple TXT records on the same name

It is possible to publish multiple TXT records on the same label. Each value appears in the response. For SPF, keep only one entry per name and group the mechanisms in it. For DKIM, use a different selector for each key.

TTL explained simply

A short TTL makes a change visible faster. Useful during an SPF update or domain verification.
A medium or long TTL reduces queries to authoritative servers. Suitable for stable configuration.
Reduce the TTL a few hours before modification, then raise it back after validation.

Good to know
A TXT value can exceed 255 bytes. It is then split into multiple quoted strings in the zone. Resolvers concatenate these strings on the client side.

Where to use a TXT record

Publish the TXT on the name requested by the service. SPF is often placed at the apex. DKIM is published on selector._domainkey. DMARC is placed on _dmarc. Verification services provide a specific name. A TXT can coexist with A AAAA MX on the same name.

To avoid
Having two SPF entries on the same name. Merge into a single value.
Forgetting quotes or improperly escaping special characters.
Publishing DKIM to the wrong selector.

Online verification

An online DNS lookup allows entering a domain name. You get the list of TXT values as well as the TTL visible from the Internet. This is a useful first check. Then perform a local test from your machine.

Verification on Windows

Windows provides nslookup. You can use it in interactive mode.

Local resolver
nslookup
set q=txt
example.com
Specific resolver
nslookup
set q=txt
server 1.1.1.1
example.com

The first part queries, according to the machine's network configuration. The second forces the use of a third-party resolver, here Cloudflare's.

Verification on Linux and Mac

On these systems, the dig command is convenient and easy to use.

Local resolver
dig TXT www.example.com
Specific resolver
dig TXT www.example.com @1.1.1.1

Quick reading of responses

Multiple lines indicate multiple TXT values. Read the prefixes v=spf1 v=DKIM1 v=DMARC1 to identify the function of each entry.
A high remaining TTL may explain a delay after a change.
An empty or truncated value often indicates a missing quote or poorly handled splitting.

Simple migration procedure

  1. Note the current values and TTL.
  2. Reduce the TTL to 300 or even 60 seconds a few hours before modification.
  3. Prepare the new value. For SPF, merge mechanisms into a single line.
  4. Publish the new value then remove the old one if necessary.
  5. Verify with nslookup or dig command from multiple networks and raise the TTL when everything is stable.

Practical tip
For DKIM, publish a new key on a new selector. Leave the old one during the transition period. Then remove the old key when everything is validated.

Common cases

SPF for proper email reception

Publish an SPF rule at the apex with authorized addresses and domains. Test before production deployment.

DKIM for message signing

Publish the public key to the selector provided by the email service. Verify that the key is complete.

DMARC for domain policy

Publish a policy on _dmarc with the p directive and useful options. Monitor reports if enabled.

Property verification

Publish a temporary TXT token provided by a service. Remove it after validation if the service allows.

Quick troubleshooting

  1. If SPF is reported as invalid, verify that only one SPF entry exists at the same name.
  2. If DKIM fails, verify the selector and key. Look for breaks or extra spaces.
  3. If DMARC is not detected, verify the _dmarc name and the v=DMARC1 value.
  4. If the response remains old, wait for TTL expiration and purge the local resolver cache if possible.

In summary, a TXT record publishes text information for a domain name. It serves for verifications, email policies, and other technical uses. The TTL controls cache duration. Multiple TXT records can coexist on the same name, but only one SPF entry should exist. Verification goes through an online tool, then through nslookup and dig.
With these guidelines, management remains clear. Changes proceed without stress. Services work as expected.