Verifying deliverability fixes from the outside

A deliverability fix is finished when the outside world can prove it, not when you click save. Between those two moments sit caches you don't control, a waiting period you can calculate in advance, and a dashboard that is perfectly happy to show you what you typed rather than what anyone else can see. The repair runbook ended every step with "verify from outside". This lesson is the how.

Saved is not seen

The instant you save a change, your domain's authoritative nameservers (the machines holding the master copy of your zone, from the DNS lesson) start answering with the new value. Everything else on the internet is cache. Recursive resolvers, the middlemen that answer DNS questions for mail servers and laptops, keep serving the old answer until the TTL they fetched it with runs out. Your zone usually lives on several nameservers, a primary and its secondaries, and on rare bad days a secondary lags behind the primary too.

So "I saved the record" and "the world sees the record" are different claims about different systems, separated by minutes or hours.

The dashboard makes this worse, not better. A DNS panel renders back what you entered; that is its job. It will display your record faithfully even when the domain's nameservers point at a different DNS host entirely and nothing you type there reaches the internet. And a sending tool's green verification tick often means "the value parsed" or "we saw it once, weeks ago". None of these screens answer the only question that matters: what does a stranger's query return right now?

The verification ladder

Four rungs, in order. Each one proves something the previous rung can't.

Rung 1: ask the authoritative nameserver directly. This is the cache-free truth. Find the nameservers, then aim your query at one of them with @:

dig NS yourdomain.com +short
dig TXT _dmarc.yourdomain.com @ns1.yourdnshost.com +noall +answer

(dig ships with macOS and Linux; on Windows, nslookup or any web-based dig tool does the same job.) The authoritative server has no cache to be stale; it answers from the zone itself. If the new value is here, you published it correctly and everything from now on is patience. If the old value is here, no amount of waiting will help: you edited the wrong dashboard, made a typo, or hit the appended-domain trap. Fix the edit.

Rung 2: ask public resolvers and watch the change spread. Query a couple of big public resolvers and compare:

dig TXT _dmarc.yourdomain.com @1.1.1.1 +noall +answer
dig TXT _dmarc.yourdomain.com @8.8.8.8 +noall +answer

Disagreement between them is normal mid-transition; each cache expires on its own clock. Here's the reading trick: an authoritative answer shows the record's full configured TTL, while a cached answer shows a number counting down toward zero. A TTL of 2740 on a record configured at 3600 tells you you're looking at a cache and roughly when it will expire.

Rung 3: send a real message and read Authentication-Results. DNS resolving correctly is necessary and not sufficient. Whether the tool actually signs with your domain, whether the signature validates, whether alignment holds: no DNS query shows any of that. Send a real message through the affected tool to a mailbox you control at a different provider, open the headers, and read the Authentication-Results line the way the headers lesson taught. dkim=pass with your d=, spf=pass, dmarc=pass. That header is the only artifact in existence proving that a receiver, not you, agrees the fix worked.

Rung 4: re-run the health check. The free health check reads everything at once and grades it, which catches the side effects single queries miss, like an SPF merge that quietly blew the lookup budget. It's also the fastest before/after comparison you can keep.

Read the TTL before you touch anything

The craft move is to check the TTL first, while the old record is still up. Whatever that number is, it's your worst-case wait: a resolver that fetched the old record one second before your edit gets to serve it for one full TTL. Old TTL 300, worst case five minutes. Old TTL 86400, someone can legitimately see the stale value until this time tomorrow. Knowing the number before you save turns "why isn't it working yet" into arithmetic. (The planned-change trick from the DNS lesson, lowering the TTL a day ahead so stale caches die fast, is this same arithmetic run in reverse.)

The other half of the craft is restraint: one change at a time, each verified before the next. Stack a second change on an unverified first one and you lose the thread. If things improve you don't know which edit did it, and if things break you don't know which edit to undo. The practitioner track turns this into a formal safe-change routine; for now, the habit is enough.

Three ways to fool yourself

The false failure. You check from a resolver still serving the old record and conclude the fix didn't work. This is the single most common sequence behind our record won't validate guide: a correct fix, declared dead by a cache, followed by a second edit that does real damage. The panic re-add of an SPF record is how domains end up with two v=spf1 records and a permerror. The authoritative query exists precisely to prevent this: it can't be stale.

Your own mailbox. Sending a test to yourself on your own domain, or between two accounts at the same provider, tells you almost nothing. Mail that never leaves the provider may skip the checks entirely, and your own server is disposed to like you. Verification mail goes to a mailbox at a different provider, and its headers get read.

The green tick. A dashboard checkmark means the dashboard is satisfied, and dashboards are satisfied by syntax. A CNAME that exists at the wrong name (the appended-domain classic) or a record on disconnected nameservers can wear a green tick indefinitely. Rungs 1 and 3 outrank every tick.

Verified is a snapshot

Verification is a one-time act; monitoring is its continuation. The Authentication-Results: dkim=pass you file away today proves the fix landed today. It says nothing about next quarter, when a key rotates, a migration drops a TXT record, or a colleague edits the zone. Treat today's verified answers as a new baseline: write down the records and their values, then make sure something re-checks them on a schedule, which is exactly the spec monitoring for decay laid out. Up next in the sequence: what to do when the records verify clean but a blocklist is the problem, and how a real delisting works.

The lab

Do this on a domain you own; the artifact is a before/after query log.

1. Create a harmless TXT record, something like decay-lab.yourdomain.com with the value verification-ladder-test-1, and let it sit until it resolves publicly.
2. Query it through 8.8.8.8 and save the output: value and TTL. That's your "before" log, and the TTL is your worst-case wait. Write the arithmetic down ("TTL 3600, so stale answers are legitimate until 15:40").
3. Change the value to verification-ladder-test-2 and save.
4. Rung 1: query the authoritative nameserver with @. You should see the new value immediately, at full TTL.
5. Rung 2: query 1.1.1.1 and 8.8.8.8 every few minutes. Note which shows the new value first and watch the cached TTL count down on the laggard. Save the "after" log once both agree.

No domain yet? Run the read-only version: pick any well-known domain, query one of its TXT records through a public resolver twice, a minute apart, and watch the TTL decrease between answers. That shrinking number is a cache aging in front of you, and once you've seen it, you'll never mistake a cached answer for a fresh one again.

Terms from this lesson

• authoritative query - asking a domain's own nameserver directly (dig @ns1...), bypassing every cache; the ground truth of what is published.
• recursive resolver - a DNS middleman (your ISP's, 1.1.1.1, 8.8.8.8) that answers from cache until the TTL expires.
• counting-down TTL - the shrinking TTL in a cached answer; a decreasing number is the signature of a cache, a full one of an authoritative answer.
• worst-case wait - the old record's TTL at the moment you changed it; the longest any resolver may keep serving the stale value.
• one change at a time - the safe-change rule: verify each edit before making the next, so effects stay attributable.
• false failure - a correct fix judged broken because it was checked through a cache still holding the old record.

Check yourself

1. Your DNS dashboard displays the new record exactly as you entered it. What does that prove?

That resolvers worldwide are now serving the new valueThat receivers will pass the record on the next real messageOnly that the panel stored what you typed; if the domain's nameservers live elsewhere, even the authoritative servers never saw itThat the record's TTL has expired everywhere

2. Twenty minutes after you changed your DMARC policy from p=none to p=quarantine, a query through a public resolver returns: _dmarc.example.com. 2740 IN TXT v=DMARC1; p=none. What is the correct reading?

The fix failed and the record should be re-editedThe DNS host silently rejected the changeThis is a cached answer with about 45 minutes left on it; query the authoritative nameserver to confirm the new value is publishedDMARC changes always take 48 hours to appear

3. Your new DKIM CNAME resolves correctly from every public resolver you try. Why send a real message anyway?

To confirm your mail server is onlineBecause only the receiver's Authentication-Results header proves the tool is actually signing with your domain and that the signature validates and alignsBecause DNS queries expire after 24 hoursTo warm up the domain before real sending resumes

Scenario

This morning you merged your domain's two SPF records into one, exactly as the repair runbook prescribes. Forty minutes later a teammate runs a lookup from the office network and still sees both old records. 'The fix didn't take,' they report, and suggest redoing it.

What do you do?

Delete the merged record and redo the merge from scratchPublish the merged record a second time so at least one copy is rightQuery the authoritative nameserver directly, and check what TTL the old records carriedWait 72 hours, since SPF changes propagate slowly