// DNS and email

The record is right. The answer is still wrong.

You published it. You checked it. It resolves correctly from where you are sitting, and somewhere out there something is still being handed the old answer. No tool that reads your zone can tell you which somewhere, or for how long, because reading is not the problem. So I change one record inside an agreed window and measure where it landed and where it did not.

// Free first

You probably got here from one of my own free checkers. It was right.

So this page opens where that report ends, rather than reading your zone back to you. Three concessions first, because the rest only means something if these are said out loud.

Every finding that routes to this page is free, and it stays free. Thirty finding ids across the mail records, the zone records and the registry delegation. No account, no email address, no signup, no locked row, no blurred verdict, no “three more issues found”. If you never contact me you still leave knowing everything that is wrong. This page does not discover those thirty things. It triages them.

The free tools on this site that already found it: DNS Health Check covers the zone half — the delegation, the SOA timers, the apex, dangling aliases, reserved addresses and oversized TXT answers. Email Domain Health Check covers the mail half, including every SPF and DMARC finding on this page. Website Health Check runs almost all of it in one report, and Domain Registration Lookup is where the registry half of the delegation fault comes from.
Zonemaster compares your authoritative servers better than my free tool does: This is worth being blunt about. My DNS checker asks a recursive resolver and reports what came back. It never speaks to your authoritative servers and never compares two of them. Zonemaster does exactly that — a whole Consistency test module covering the SOA serial, the SOA timers, the NS set, glue against authoritative data and the MNAME — and it is run by AFNIC and The Swedish Internet Foundation. Two country-code registries. It is free. Run it.
MXToolbox queries each of your nameservers, and reads your negative TTL: Its DNS Check says so plainly: Then we query each name server to make sure your DNS Servers all respond, measure their performance and audit the results against common best practices. It also carries a dedicated SOA NXDOMAIN value check, on the same twenty-four hour threshold my own checker uses. So the declared negative TTL is free to read too, and one dig gives it to you as well.
A language model will write your corrected SPF record: In seconds, inside the ten-lookup limit, with a sane SOA and a clear explanation of negative caching thrown in. That is genuinely true and pretending otherwise would be insulting. Ask one. Then come back to the next section, which is about the part it cannot do — not because it does not know how, but because the answer does not exist until somebody makes a change and watches.

One more, since five different tools lead here: tell me which report you are holding. That single question changes what my first reply says more than anything else in the form.

// The gap

Everything free reads the zone. Nothing free watches it change.

My checker asks a resolver. Zonemaster and MXToolbox ask your authoritative servers. Propagation checkers ask public resolvers in a range of locations. All of them read, and they all answer the same question: what does the zone say right now?

The fault that costs you money is not in the reading. It is in the change. A record can be correct in your zone, served by every nameserver you know about, and still be wrong for a share of the internet for hours — and a single query has no way of sampling the ones that are wrong.

Three reasons no amount of checking gets there

A change has to be caused. The state after the change does not exist until somebody edits the zone. Nothing can be measured about it in advance, and nothing can be measured about it afterwards either, because the moment has passed.
Convergence is per-server and per-resolver, and it is not uniform. One authoritative server that never took the update produces a fault that works whenever you check it — because whether you see the problem depends entirely on which server your query happened to reach.
The hard one: nothing that queries on demand can measure how long a missing record stays missing, because its own first query starts the clock. Ask whether a name exists before it does, and you have just created the cached “it does not exist”. Every checker destroys that measurement by taking it. To know how long a newly published record will appear absent, you have to have been watching before it was published.

That third one is not an opinion about a competitor. It is a property of the protocol, and it is why this is a booking rather than a scan.

The resolver operators say it themselves, and so does the standard

Quoted narrowly, and every one of these was opened again on the day this page was written.

Google, about their own resolver — Public DNS FAQ You can use the Flush Cache tool to refresh the Google Public DNS cache for common record types and most domain names.
The tool exists at all because their answer and your zone diverge. Note most, not all — and note that this is the resolver a large share of your users resolve through, and the one my own free checker falls back to. There is a flush tool, and it advises flushing the main domain name first if the registrar or DNS hosting changed recently.
Google, on the domains it cannot help with — Public DNS FAQ Domains using EDNS Client Subnet (ECS) for geolocation cannot be flushed – for any domains using ECS, set TTLs for ECS-enabled records short enough (15 minutes or less).
The alternative they give is to always wait for the record TTLs to expire, which are generally limited to six hours even if the actual TTL is longer. So there is a practical ceiling of roughly six hours at one major resolver, a class of domain that cannot be cleared at all, and a vendor-documented instruction to wait. None of those three is in any registrar’s help article.
Cloudflare, about the limits of its own control — TTL reference It may take longer than 5 minutes for you to actually experience record changes, as your local DNS cache may take longer to update.
And on what the field governs at all: Time to Live (TTL) is a field on DNS records that controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users. The TTL is the answer to “how long”. Not a fixed number somebody told you once.
RFC 2308, on the number that decides how long the damage lasts — rfc-editor.org When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA’s TTL.
And the threshold: Values of one to three hours have been found to work well and would make sensible a default. Values exceeding one day have been found to be problematic. That sentence is why my free checker flags a negative TTL over twenty-four hours, and why MXToolbox’s check uses the same number. The standard sets it. I did not.

Read min(SOA.MINIMUM, SOA’s TTL) off your zone with one dig and you know what your zone declares. What no free tool can give you is the interval that actually elapsed — at real resolvers, on the day you published — because that needs a query taken before the record existed.

// What you get

Two records, and both of them are events

Not descriptions of tables. These are the tables, filled in the shape yours would arrive in. Every row carries how it was established, because a page where everything says observed would be claiming a completeness the vantage points do not support.

First: the negative-cache clock, measured rather than calculated

One name, mail2.example.com, asked at 08:55 before it existed, published at 09:14. The record’s own TTL is 300 — five minutes. This is the one that cannot be bought back afterwards at any price, which is why it comes first and why it is tier one’s opening line rather than a footnote.

How long one newly published record stayed missing, by vantage point
Asked from	Asked before it existed	NXDOMAIN cleared	Elapsed, and how it was established
Google Public DNS	08:55	15:20, same day	6 h 06 m OBSERVED The zone declares `min(86400, 86400)`, so twenty-four hours. It cleared in six, and Google documents why: its cache TTLs are generally limited to six hours even if the actual TTL is longer.
A second public resolver	08:55	08:58, the next day	23 h 44 m OBSERVED This one held the negative answer for very nearly the interval the zone itself declared. Nothing was wrong with the record at any point. It was correct, published, and served by every nameserver within half an hour.
The client’s own office forwarder	08:55	Not seen to clear inside the window	Not measured REASONED The appliance was not mine to poll on a schedule. The zone’s declared number is the ceiling and nothing narrower can be claimed — a record correct in the zone can still be wrong at a resolver I cannot see.

One publish. One record, correct throughout. Absent for six hours at one resolver and very nearly a full day at another — and the number the zone declared predicted neither of them exactly. Six hours against a record TTL of three hundred seconds is seventy-three times over; the second row is two hundred and eighty-five times over.

Second: the convergence record, one server at a time

One canary label, canary-0817.example.com. It carries no traffic, nothing resolves it, and it was added rather than changed. Published at 09:14:14, then asked of every authoritative server by name.

What each authoritative server served before and after one canary change
Authoritative server	Served before	Served after	First seen	Converged, and how it was established
ns1.example.net	NXDOMAIN	203.0.113.10	09:14:22	8 s OBSERVED The primary. Took the edit immediately, as it should.
ns2.example.net	NXDOMAIN	203.0.113.10	09:14:31	17 s OBSERVED Notified and transferred. Nothing to do here.
ns3.example.net	NXDOMAIN	203.0.113.10	09:41:08	26 m 46 s OBSERVED Transfers on a timer rather than on a notify. Check this server at any point after the first half hour and it is correct, which is why no on-demand test has ever reported it.
ns4.example.org	NXDOMAIN	NXDOMAIN	—	Never took it OBSERVED Still in the delegation. Still answering queries. Has not received a zone transfer. A resolver that happened to ask this server got “does not exist” for as long as it stayed in rotation. Nobody on the client side remembered it was there.
The registry’s glue	ns1–ns4	ns1–ns4	—	Not sampled REASONED The delegation at the registry still names ns4, so removing it is a registrar change rather than a zone edit — somebody else’s schedule. Read once, not watched.

The fourth row is the product. It does not exist until somebody edits the zone and then asks every server individually. No reading tool returns it, because the answer is not in the zone as it stands — it is in the difference between two moments. The third row is the quieter one and often the more useful: a server that transfers on a timer instead of a notify is correct by the time anybody checks it, which is exactly why no on-demand test has ever reported it to you.

What these tables are not. They show the servers and resolvers that were asked, from the vantage points used, on one day. That is evidence, not a census, and nothing here claims to see every resolver on the internet. The row marked REASONED is where the measuring stopped and honest reasoning took over.

// The hard part

This asks for write access to your DNS. Read this before anything else.

Every other paid page on this site asks to restore a backup, force a renewal, or connect to a port. This one asks for the ability to change a live DNS zone, and a wrong change there takes your domain off the internet — mail included — for as long as the caches hold it. That is a worse blast radius than anything else I sell, so the limits are on the page rather than in the terms.

What the rehearsal is allowed to touch, in full:

One record, in a name that carries no traffic, chosen for the purpose. Never the apex. Never www. Never an MX. Never SPF, DKIM or DMARC. Never anything a service resolves.
The negative-cache measurement uses a name that has never existed, so nothing can break by its absence continuing.
Nothing is deleted. Additive changes only, for the whole rehearsal.
Every change is written down before it is made, with its exact rollback — and the rollback is tested on the canary first, before it is ever needed on something real.
Real records change only in the repair and rehearsal tiers, inside an agreed window, one at a time, with you present, and with the previous value recorded word for word before anything is touched.
If you would rather not grant access at all, you make each change while I watch and measure. That works. It is slower and it costs more of your time, and it is offered here rather than buried.

Passive tools, active engagement — and that is not a contradiction. Every free checker on this site is strictly passive: it reads public records and connects to nothing it was not pointed at. This engagement is different by agreement. It is authorised, scoped and reversible work on a zone you own, with the boundary above written into it.

One thing that is not a limitation but belongs here anyway: if the rehearsal finds your zone has already been changed by somebody you do not recognise — a record nobody can account for, or a delegation moved without your knowledge — you hear about it immediately, in the reply I notice it in. The engagement pauses at that point. Incident response is not this page.

// The faults

Twelve things that actually go wrong, worst first — by who notices

Not ordered by severity. Ordered by who finds out and how fast, because that is what decides what gets fixed first. Notice where the mail faults land. Seven of the nine most severe findings that route to this page are mail records rather than zone records — the label reads “DNS and email” and the severe half is email.

Fault 1 The zone does not answer at all zone.nxdomain, ns.absent, soa.absent · 2 CRIT, 1 HIGH · Everybody, instantly: No zone, no nameservers, or no SOA record. The domain is off the internet and mail is off with it. This is the only fault on the list nobody needs telling about.
Fault 2 Mail has nowhere to go mx.missing, mx.unresolved · HIGH, or WARN — see below · People sending to you. Nobody browsing notices: No MX records at all, or an MX host with no address behind it. mx.missing is the only finding on this site that carries two severities from one place in the code — HIGH on the email checker, where you arrived because mail is broken, and WARN on the DNS report, where the same absence is usually a web-only domain that never wanted mail. The finding does not change. Only how loudly it is ranked.
Fault 3 An SPF record no receiver will evaluate as written spf.lookup_limit, spf.lookup_near, spf.duplicate, spf.syntax, spf.chunk_join, spf.void_limit, spf.ptr · 4 CRIT, 1 HIGH, 2 WARN · Some of your recipients, silently: The record is there. It looks fine. RFC 7208 says an implementation MUST limit the total number of those terms to 10, and a record that exceeds it, or has two copies, or joins its strings wrongly, is a permanent error rather than a soft one. Three separate rows in my own service mapping collapse into this single fault, and calling them three findings would treble one repair.
Fault 4 A DMARC record that is not a readable policy dmarc.malformed, dmarc.duplicate, dmarc.no_policy · 3 CRIT · Nobody — until a receiver starts enforcing: Malformed, duplicated, or carrying no policy tag. A receiver that cannot read the record does not fall back to your intent; it falls back to its own. All three are CRIT because the failure is silent and the record looks present in every panel that lists it.
Fault 5 A record the protocol forbids in that position dns.cname_at_apex, mx.ip_literal, mx.target_is_cname · 2 HIGH, 1 WARN · Some resolvers, not others: A CNAME at the apex, an MX pointing at an IP address, or an MX pointing at an alias. These are the faults that work often enough to survive years of being noticed and then forgotten, because the thing that breaks depends on which implementation is reading.
Fault 6 A private or reserved address published in public DNS a.reserved_ip, mx.reserved_ip · 2 HIGH · Everyone outside your network: A name resolving to an address that only exists inside somebody’s LAN. It works perfectly from the office, which is where it gets tested, and from nowhere else.
Fault 7 A CNAME pointing at a name no zone answers for dns.cname_dangling · HIGH · Whoever visits that name: The alias resolves, the target does not exist. Usually a service that was cancelled and a record that was not. Occasionally it is worse than that, because a name nobody owns is a name somebody else can claim.
Fault 8 The delegation names a server that cannot be used, or the registry and the zone disagree about who is authoritative ns.unresolvable, domain.ns_mismatch, domain.ns_none · 2 HIGH, 1 WARN · Intermittently, by luck of which server answered: Half of this is not mine to fix and the page says so plainly: the registry half needs a registrar to act, on their own schedule. This is also the fault my own service mapping words as one row and which is really two — the delegation and the mail path are the same sentence and completely different repairs.
Fault 9 Every nameserver is in one place ns.single, ns.same_subnet · HIGH, WARN · Nobody — then everybody at once: RFC 2182 asks for three servers … with at least one which must be well removed from the others, and says servers should certainly not all be placed on the same LAN segment in the same room of the same building. The repair is a second nameserver somewhere else, and that somewhere else is a provider, not me.
Fault 10 A TXT answer larger than a UDP response txt.oversized · WARN · Nobody visibly: Enough TXT records on one name that the answer stops fitting, and some resolvers quietly return nothing rather than falling back. This is the one that makes an SPF fault look unfixable: the record is correct, you can read it, and the receiver never got it.
Fault 11 DMARC reports addressed to a domain that never authorised them dmarc.rua_unauthorised · HIGH · Nobody. The reports simply never arrive: Sending reports to an address at another domain needs that domain to publish permission. Without it, conforming receivers do not send. You are not collecting less data than you think — you are collecting none.
Fault 12 The zone’s cache timers are wrong soa.timers, soa.negative_ttl · 2 WARN · Nothing today: Both are WARN and both are the reason this page exists. They break nothing now. They set how long your next mistake lasts, and how long a newly published record appears missing. My free checker flags a negative TTL over twenty-four hours because RFC 2308 says values exceeding one day have been found to be problematic — and that is the last thing any free tool can tell you about it, because the number it reads is the number the zone declares.

Sixteen rows in my service mapping. Thirty finding ids. Twelve faults. None of those numbers is interchangeable and the mismatch runs both ways: three of the rows collapse into fault three above, and one row splits across two faults with completely unrelated repairs. That is why the list is twelve items and not sixteen, and it is why the triage is worth something even though the findings were free.

Where the boundary with my other two services sits, and it is drawn in code rather than in copy. A mail record that is missing or too weak is email deliverability — no SPF at all, one ending in +all, a DMARC policy of p=none, reputation, blocklists, warm-up, and the whole path to enforcement with a sender inventory behind it. A mail record that is present and that no receiver will evaluate is this page. Separately, a long TTL on your apex belongs to migration and site repair; the SOA’s own timers and the negative TTL belong here. Those splits are not marketing lines — they are how my own checkers have routed these findings since the first version.

// What it covers

Four ways in

Everyone starts with the measurement, because until a change has been watched nobody knows which of the free report’s findings are urgent and which are paperwork — including me.

DNS & Email Review

Everyone starts here. It also scopes everything else.

The negative-cache clock measured, not calculated — how long a newly published name actually stayed missing, at real resolvers, from a query taken before it existed
The convergence record for one canary change, read from every authoritative server by name, before and after
The free checkers’ thirty findings triaged into the twelve faults and ordered by what breaks for whom. Not rediscovered — triaged
The registry delegation compared against your live zone, so a disagreement is named rather than assumed
Nothing real is changed. One zone, one provider’s change path, up to 6 authoritative nameservers, up to 12 names tracked, one canary, one window
The window is longer than a day if your zone says it is, and I tell you its length from your own SOA before you commit to anything

Recommended

Review + Repair

Not a starting point. Follows the measurement.

The tier where the records start answering correctly everywhere.

SPF rebuilt as one record inside the ten-lookup limit, DMARC made readable, the apex alias and the MX targets corrected, reserved addresses taken out of public DNS
The SOA minimum lowered to something your next cutover can live with, then the negative interval measured again — so the fix arrives with a before-and-after number rather than an assurance
SOA timers set deliberately, with the reasoning written down for whoever edits the zone next
The drill re-run to prove each change reached every server, rather than asserting that it did
Everything staged, additive where possible, reversible, with a named rollback whose previous value was recorded word for word first

Review fee credited — you pay the difference, not both.

Cutover Rehearsal

If a real move is already scheduled, start this conversation here.

Everything in the repair
The real change, staged — TTLs and the SOA minimum lowered far enough in advance to matter, and the whole path walked once on canaries before anything real moves
The delegation and the registry brought into agreement, which means a registrar conversation on somebody else’s schedule
A second nameserver on separate infrastructure where the delegation fault applies
Reversible at every step with a named rollback, and somebody reachable throughout

Review fee credited — you pay the difference, not both.

Zone Watch

Because the next zone edit can undo any of it and nothing announces that.

The SOA serial and an agreed record set read from every authoritative server and compared, on a schedule
The watch is for a server that has stopped taking updates — caught in the month it happens rather than during your next cutover
New nameservers and new records added to the set as they appear
A one-page record each month you can hand to anyone who asks
Monthly in advance, cancel anytime, never auto-renewing

Five things about the packages, before you ask

The cap is one zone and one window, not a record count. Up to 6 authoritative nameservers and up to 12 names tracked in the convergence record. Names rather than records, deliberately: a zone with two hundred A records and one MX is a shorter day than a zone with twelve records split across two providers and a registry that disagrees with both. The tracked names are what actually scales the work, because each one is asked of each server at each of two moments. A second zone, a second provider or a second window is its own piece of work.
The review is not always a same-day deliverable, and that is a property of your zone rather than my calendar. The negative-cache measurement takes as long as your negative interval takes to expire, and min(SOA.MINIMUM, SOA’s TTL) can be a full day. One free lookup tells me which it is, so you get the window in writing before you commit. A one-hour minimum is a morning. And the length of the wait is itself the finding — if the review takes two days, that is the fault the free checker already reported, costing you two days.
The recommended tier is the repair, and that is deliberate. The measurement tells you a nameserver never took the change and that a record stayed missing for six hours. The repair means it stops happening. Only one of those changes your position — but you cannot start there, because until a change has been watched nobody knows which findings matter.
Lowering your SOA minimum sits in the repair tier, not the review, and the re-measurement is included rather than quoted. The SOA is a real record, and real records only move where the boundary above says they can. Charging extra to prove my own fix worked would be the exact failure this page is written against.
What moves the size of the job is who controls the zone. A registrar panel, a DNS provider with an API, a hosting company that edits records on a ticket, or a split setup nobody is sure about — that single answer decides whether a measured rehearsal is possible at all. After that: the negative TTL you already publish, how many authoritative servers there are and whether they belong to one provider, whether the registry and the zone already disagree, whether mail is in scope, and whether there is a real cutover coming.

Zone Watch is not uptime monitoring, and the difference is the whole point. Uptime monitoring watches whether your site answers, and it is free in places including the checkers on this site. If you want dashboards and somebody watching the stack, that is hosted monitoring and it is a different service that does not look at DNS at all. Monitoring watches whether your site answers. Zone Watch watches whether your nameservers still agree with each other. Neither does the other’s job.

And on Zone Watch specifically: the comparison itself is not the thing you are paying for — Zonemaster does that free, on demand, and this page said so at the top. What it cannot do is run unattended with last month’s answer sitting beside this month’s. Zonemaster tells you today. Zone Watch tells you the month a server stopped taking updates.

There are no figures on this page, and that is deliberate rather than coy. A fixed number printed here would be wrong for most situations in one direction or the other, and I would rather quote against what you actually have. Describe it in the form and you get a figure back before anything is committed to. If your situation does not fit any of the four packages, say so and I will tell you honestly whether it is worth doing at all.

// From you

What I need before anything starts

The first item is the one that makes the rest safe, and nothing begins without it in writing.

The list

Written permission to add and remove a named canary record in your zone — with the boundary above attached to it: one label, no traffic, additive only, rollback written before the change. This is the non-negotiable one.
Access to the zone, or a person who can make a change while I watch. Either works. Which one it is changes the shape and the length of the engagement, so it is worth answering honestly in the form.
The complete list of authoritative nameservers, including any you believe is decommissioned. A server nobody remembers is precisely the one that stopped taking updates.
Who your registrar is, and who can log in there. The registry half of the delegation fault cannot be closed without it.
Whether the zone is DNSSEC-signed, and who holds the keys.
Any cutover already planned, and its date. If there is one, the rehearsal should be scheduled against it, and it is a different and more valuable conversation.
The mail host, if the mail faults are in scope, and who can change records there.
A window that accounts for your negative TTL. The measurement is as long as your zone’s own minimum, and pretending otherwise would make the schedule a fiction.
Somebody reachable while changes are made. If anything is disturbed despite the precautions, the work stops and you are told inside the hour.

What protects both of us: written authorisation naming the canary label and the zone, written acknowledgement of the boundary above, and — for the repair and rehearsal tiers — that every change is staged, additive where possible, and reversible with a named rollback whose previous value was recorded word for word first.

// Limits

What this cannot promise

All of it, in one place, before you pay rather than after. Several of these are the reason to book at a particular moment rather than a reason not to book at all.

A convergence record shows the servers and resolvers that were asked, from the vantage points used, on one day. It is evidence, not a census, and nothing here claims to see every resolver on the internet.
The negative-cache measurement cannot be taken retroactively. If the record is already published, the interval is gone — at any price. That is the honest reason to book before a cutover rather than after one.
Google’s own documentation says some domains cannot be flushed at all. Where EDNS Client Subnet is in play, the answer clears when the TTL says so and not before. That is a limit on the work, quoted from the vendor rather than argued about.
Lowering a TTL does not shorten a cache that has already answered. The old value is held for the old TTL. This is the uncomfortable one, and it is exactly why the rehearsal has to happen before the change rather than during it.
A record correct in your zone can still be wrong at somebody’s own resolver. Corporate resolvers, appliances and forwarders are outside what this engagement can see or fix — and an oversized TXT answer is the case where one of them drops the answer entirely and silently.
The registry half of the delegation fault is not mine to fix. A registrar has to act, on their own schedule, and some take days.
It is a point in time. Your next zone edit can undo any of it and nothing will announce that. Zone Watch exists for that reason, and it is stated here as a limitation rather than dressed up as an upsell.
This is not deliverability work. Getting mail into the inbox — reputation, blocklists, content, warm-up, enforcement — is email deliverability, and that page is linked here rather than competed with.
If every record is already correct and the rehearsal converges cleanly, that is the finding. The fee is earned and the engagement ends with a cutover plan and nothing to repair. I would rather report that than manufacture a list.

// Not this

Things that are not this engagement

Five, named so nobody assumes coverage

Deliverability. Reputation, blocklists, content, warm-up, and the DMARC enforcement path from p=none to p=reject with a sender inventory behind it. That is email deliverability, it already exists, and I would rather link it than compete with it. If you need both, say so and I will tell you which order they go in.
DNSSEC. Signing a zone, rolling keys, or repairing a broken chain of trust is a different job with a different failure mode — an unsigned mistake is a wrong answer, a signing mistake is no answer at all. Quoted separately if at all. For reading the current state of a signed zone, DNSViz does it free.
Running DNS. Building, hosting or operating nameservers. The repair for a single-nameserver zone is a second nameserver somewhere else, and that somewhere else is a provider rather than me.
Incident response. If the rehearsal finds a record nobody on your side recognises, or a delegation moved without your knowledge, you hear about it immediately and the engagement pauses. What happens next is a different conversation.
A measured rehearsal on a schedule I do not control. If your hosting company edits your zone on a support ticket, the clock cannot be started at a moment somebody is watching. Say so up front and I will tell you which parts still apply, rather than letting it become silent scope inside the review.

// Billing

How payment works

Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.

You apply through the form

No payment at this point, and no commitment. Tell me which free report you are holding, who controls the zone, and what prompted this.
I review it and confirm the scope

If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope, the nameserver list, the canary label and the length of the window read off your own SOA in writing before any invoice exists.
An invoice arrives, payable within 48 hours

It carries an invoice number and a due date. Unpaid past that, the application lapses and the slot is released to somebody else.
Work begins once payment is received, and once the permission is signed

Not before, and the written permission is the second half of that sentence rather than a formality — it is what makes changing a live zone safe to do at all. For one-off work there is nothing to suspend after delivery, so payment comes first. That is the standard arrangement and it runs both ways.
Zone Watch, if you take it, is monthly in advance

Non-payment simply stops the work. Nothing is billed silently in the background and you can stop whenever you like.

// Not live yet?

If you are still building, or still planning the move

Everything above assumes a zone that grew over years and a change you are already nervous about. Before either of those, the same work is a fraction of it — and here the gap is unusually sharp, because two of these cannot be done later at all.

What that involves

Lowering the SOA minimum costs nothing today and cannot be done retroactively on cutover morning. This is the strongest argument on the page for acting early. A zone that publishes a sane negative interval now gives you a short window later. A zone that publishes a day of it gives you a day of a name appearing missing, on the morning you least want that, and lowering it at that point is itself a change that has to reach everybody first.
The negative-cache measurement has to start before the record exists. Booked in advance of a planned move, it is a real number. Booked after, it does not exist. There is no version of this that can be caught up on.
A second nameserver on separate infrastructure is a decision, not a migration, while there is one zone and nobody depending on the current delegation. RFC 2182 has asked for that since 1997.
The first canary run before there is a customer to notice it. Then you know which of your nameservers takes an edit and which does not, on a day nobody cares about, which is the cheapest that test will ever be.

Mention that you have a move coming, or that you are pre-launch, in the form and I will quote it as its own piece of work. A rehearsal before a planned mail or provider move is worth several times a rehearsal in the abstract, and it is the version of this engagement I would rather sell.

Run the free checkers first. Then tell me what you are about to change.

They cost nothing, need no signup and no email address, and they print the finding id next to the record it came from. If they come back clean, or you have already watched a change land on every one of your nameservers by name, you have saved a fee and I would rather tell you that than take it. If nobody has ever measured it, that is exactly what this is for.

Send me a message ↓

Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.

Your Name

Email Address

Message

I'm interested in the DNS and email troubleshooting review.

Which free checker the report came from — DNS health check, email domain health check, website health check, domain registration lookup, or the engagement builder:

The finding id, if you have one (for example soa.negative_ttl or spf.lookup_limit):

Who controls the zone — a registrar panel, a DNS provider with an API, a hosting company that edits records on a ticket, or not sure:

How many authoritative nameservers, and whether they are all with one provider:

Is the zone DNSSEC-signed, and do you know who holds the keys:

Is mail in scope, and who can change records at the mail host:

Is there a cutover or provider move already planned, and when:

Is there anyone who can make a zone change while I watch, if you would rather not grant access:

Please do NOT paste zone-file exports, the output of a zone transfer, or registrar or DNS provider logins here — none of that is needed to quote, and the zone comes later once we have agreed the scope and the permission is in writing.

// FAQ

Questions

Your own free checker already told me all of this. What am I paying for?

Nothing you already have. All thirty findings are free, ungated and uncapped, and they stay that way — there is no locked row, no blurred verdict and no email address to hand over. What is not in any of those reports is what happens when you change a record: which of your nameservers actually took it, which resolvers went on serving the old answer, and for how long. The free tools read your zone. This measures a change to it. Those are different questions and only one of them needs somebody present.

Isn’t Zonemaster better at this, and free?

At the thing it does, yes, and I would rather say so here than have you find out. Zonemaster queries the authoritative servers and compares them — SOA serial, timers, the NS set, glue, MNAME — and it is run by AFNIC and The Swedish Internet Foundation, two ccTLD registries. My free DNS checker asks a recursive resolver and reports what came back, which is a narrower view. Run Zonemaster. Then notice what it tells you: the state of the zone right now. Ask it again after you change something and it tells you the state right now again. What it cannot do is have been watching before you published.

Why can the review take more than a day?

Because the length of the measurement is set by your zone, not by my schedule. The interval a resolver holds a “does not exist” answer comes from min(SOA.MINIMUM, SOA’s TTL), and if that works out at twenty-four hours then watching a name appear takes twenty-four hours. I read that number off your zone with one free lookup and tell you the window before you commit to anything. A one-hour minimum is a morning. And the wait is not overhead — the length of it is the finding.

Do you need to change my DNS? What exactly do you touch?

One record, in a name that carries no traffic, chosen for the purpose. Never the apex, never www, never an MX, never SPF, DKIM or DMARC, never anything a service resolves. The negative-cache measurement uses a name that has never existed, so nothing can break by its absence continuing. Nothing is deleted. Every change is written down before it is made, with its exact rollback, and the rollback is tested on the canary first. Real records move only in the repair and rehearsal tiers, inside an agreed window, one at a time, with you present. And if you would rather not grant access at all, you make each change while I watch and measure. That works. It is slower and it costs more of your time.

Can you measure the negative cache after I have already published the record?

No, and no amount of money changes that. The measurement needs a query from before the name existed, because that query is what creates the cached “it does not exist” whose lifetime is being measured. Once the record is published, the interval is gone. It is the one thing on this page that cannot be recovered afterwards, and it is the honest reason to book before a cutover rather than after one.

How is this different from the email deliverability service?

The split is in my own code rather than in my sales copy, which is why I can state it precisely. A record that is missing or too weak is deliverability work. A record that is present and that no receiver will evaluate is this page. No SPF at all, or one ending in +all, or a DMARC policy of p=none — those route to email deliverability, along with reputation, blocklists, warm-up and the whole path to enforcement. An SPF record over the ten-lookup limit, or two of them, or a DMARC record a receiver cannot parse — those are here. If you need both, say so and I will tell you which order.

My hosting company edits my DNS on a support ticket. Does this still work?

Partly, and it is better to know that now than inside the engagement. A measured rehearsal needs the change to happen at a moment somebody is watching. If a third party makes your edits on their own queue, I cannot control when the clock starts, so the convergence record becomes best-effort and the negative-cache measurement may not be possible at all. Everything else still applies: the triage, the repairs written against your actual configuration, and the delegation work. Tell me who edits your zone in the form and I will say plainly which parts you would be paying for.

Does this cover DNSSEC?

No, and it is quoted separately if at all. Signing a zone, rolling keys or repairing a broken chain of trust is a different job with a different failure mode — an unsigned mistake is a wrong answer, a signing mistake is no answer at all. If your zone is signed, tell me, because every change then carries a signing step and a second set of caches. For reading the current state of a signed zone, DNSViz does it free and does it well.

What if everything turns out to be correct?

Then that is the finding, the fee is earned, and you get a cutover plan and nothing to repair. A rehearsal that converges cleanly across every nameserver, with a negative interval that matches what the zone declares, is worth knowing before you move a mail provider — and it is the result I would rather report than a list. If the free checkers already came back clean and you have already watched a change land on every one of your nameservers by name, you have saved a fee and I would rather tell you that than take it.