Log in
CaptainDNS

Propagation & diagnostics

Compare resolvers worldwide and inspect returned answers.

Email authentication

Tools to verify and validate your email authentication setup.

SPF syntax validator

Review include chains and DNS query limits before publishing changes.

SPF record inspector

Resolve the published TXT record, flag lookup limits and decode each mechanism.

DKIM syntax validator

Quickly check the syntax of your DKIM records.

DKIM record check

Resolve a selector and analyse the published DKIM TXT record.

DMARC syntax validator

Check rua/ruf destinations, alignment modes and the active policy before publishing.

DMARC record inspector

Resolve the published policy, surface diagnostics and confirm enforcement before switching to reject.

BIMI syntax validator

Validate BIMI tags, the logo fetch and the VMC certificate before publishing.

BIMI record inspector

Resolve the published BIMI record, inspect logo and VMC diagnostics in one place.

Email deliverability audit

Audit MX, SPF, DKIM and DMARC to confirm a domain is ready to send.

Mail header analyzer

Decode participants, authentication results and routing from raw headers.

DMARC record generator

Create compliant DMARC records with all policy and reporting options.

Text

Transform, encode and measure your content in seconds.

Text case converter

Convert any block of text to upper or lower case instantly.

Base64 encoder / decoder

Encode or decode any content in Base64 without leaving the browser.

Slug generator

Transform any sentence into an SEO-friendly slug in seconds.

Word & character counter

Measure the length of any text, with instant word and character counts.

Images

Preview and validate your BIMI logos before publishing.

BIMI logo lookup

Inspect a BIMI logo URL—format, metadata and live rendering—before rollout.

Certificates

Inspect CSRs, BIMI logos and VMC certificates before you deploy.

CSR parser

Inspect a CSR, extract subject details, fingerprints and requested SANs.

VMC inspector

Inspect a Verified Mark Certificate—issuer, validity and SAN coverage—before you publish BIMI.

IP

Look up addresses, owners, reverse records and ranges.

Reverse lookup

Resolve a PTR record and validate DNS consistency.

IP WhoIs

Identify the owner of an IP range and its contacts.

IPv4 netmask

Calculate network, broadcast and usable hosts for any IPv4 block.

My IP address

Detect your IPv4/IPv6 addresses and their geolocation.

Audit DNS Health of a Domain

Why perform a complete audit?

A well-configured domain responds quickly and predictably. When parent delegation is accurate, each server is reachable via IPv4 and IPv6, the SOA is synchronized, and basic settings are clean, failures almost always disappear. This audit checks all of this by tracing the actual resolution chain. It first compares the parent's view with your zone's view, then queries each server to see if it responds authoritatively, accepts UDP and TCP, and whether its responses are consistent with its peers. You get an accurate reading of the domain's state at the moment you launch the check.

How does the audit work?

The check starts at the parent level. It reads the NS list published in the registry, as well as glue addresses at the parent when necessary. These helper addresses are called glue records. They are only needed if the server name belongs to the domain you're auditing. The audit then retrieves the NS list from the zone itself and compares both views. If there's a discrepancy, resolution becomes random. One resolver may follow the parent's path, another may follow the zone. The diagnostic then reports a parent-zone mismatch and tells you what to fix.

Once delegation is validated, the tool queries each server. It tests resolution via IPv4 and IPv6 when possible. It measures latency and verifies that the server responds authoritatively for the domain. It also checks that recursion is disabled on an authoritative server and that zone transfers aren't open to anyone. If a response is truncated over UDP, it verifies that TCP takes over. These points prevent subtle errors that only appear under load or with large responses.

Delegation, glue and lame delegation

Parent delegation must point to servers that know how to respond authoritatively for your zone. When the parent points to a host that isn't authoritative, it's called lame delegation. Resolvers waste time, sometimes give up, and you see SERVFAIL. The audit detects this case and clearly indicates which server is causing the problem. It also checks the freshness of glue records. Stale glue occurs when an NS address has changed but the parent's record hasn't been updated. Simple result: some resolvers have the correct address via the zone, others keep trying the old address via the parent. The report guides you to update glue records at the registrar.

Network accessibility and transport

An authoritative server must respond via UDP. It must also accept TCP when a response exceeds the expected size. Overly strict firewalls break this fallback. The audit tries both modes and tells you if TCP is blocked. It verifies IPv4 presence. It flags the absence of IPv6 as a possible improvement rather than a blocking error. Finally, it reminds you that an authoritative server shouldn't perform recursion and that zone transfers shouldn't be open to the public. These points concern security and stability.

Response consistency and SOA

All servers in the same zone must publish the same NS set, the same SOA serial, and the same data at time T. When a server hasn't received the latest version, you see different responses depending on which server is queried. The diagnostic reads the SOA on each host and verifies that the serial advances monotonically. It also examines SOA timers. A reasonable refresh allows secondaries to follow the primary. A short retry speeds up recovery after a failure. A sufficient expire prevents a secondary from abandoning the zone too quickly. The minimum TTL serves for negative caching and should remain measured. The report comments on these values practically, without dogma, to match your change rhythm.

IPv4 and IPv6

IPv6 presence isn't mandatory but it's becoming a standard. Enabling IPv6 on your NS removes a source of errors for visitors and bots that prefer this stack when it exists. The audit tests both stacks when published. It flags the absence of AAAA as an improvement opportunity and not as a failure.

DNSSEC if you use it

If your domain is signed, the audit verifies that the parent publishes a DS that matches the zone's keys. It reads DNSKEY records and checks whether signatures are valid at the apex. A mismatch between DS and keys breaks the chain of trust. The report explains what to update first and reminds you of the operation order during a key change.

Reading the result and taking action

The top of the report summarizes the overall state. Points classified as errors block or significantly degrade resolution. Fix parent-zone mismatches, missing glue, closed TCP, lame delegation, or divergent serial as priority. Points classified as warnings improve quality without being blocking. An absent IPv6, weak NS distribution, unrealistic SOA timers fall into this category. Each point comes with a concrete action statement. You know what to do and where to do it, in the zone or at the registrar.

Concrete scenarios

Before switching DNS providers, run the audit then reduce TTLs for critical records. Add new NS, update delegation at the registry, declare glue if your NS are in your domain, wait for caches to expire, then run the audit again. You validate that parent and zone tell the same story and that all servers respond authoritatively with the same SOA.

After changing an NS address, immediately check glue at the parent. As long as the old address remains published, part of the traffic continues going to the wrong place. The audit puts this point in front of you with the exact address to correct.

If users see random errors, check the consistency section. A frozen serial or an NS that hasn't received the latest zone often explains intermittent behavior. The check shows you which server is behind and gives you the order for bringing it back online.

Simple best practices

  • Keep at least two NS on distinct networks.
  • Update delegation and glue with each change.
  • Keep TCP open on authoritatives.
  • Disable recursion and lock down zone transfers.
  • Choose SOA timers adapted to your update cadence.
  • Enable IPv6 when you can.
  • Document each modification with date and reason.

These are short actions that prevent long incidents.

What you gain

A domain that passes the audit resolves the same way everywhere. Changes propagate according to the chosen TTL and not randomly. You reduce tickets related to endless "propagation" that's actually just poorly anticipated caching. You also detect weaknesses that don't show during a simple lookup, like lame delegation or closed TCP. The result is a clear action plan. You fix, you verify, you move on.

Privacy and scope

The check only queries public information. It contacts your zone and the parent as a resolver would. No private data is required. The tool doesn't store your configuration. Only anonymous technical metrics are kept to monitor service availability.

With this audit, you start from facts. Parent and zone are aligned or they're not. Servers respond authoritatively or they don't. The SOA is synchronized or lags behind. You gain a clear view of your domain and a simple path to fix what needs fixing.