A Customer Bought Back Their Domain 12 Minutes After Our Notice

Eleven customer web addresses were dead, and every one of them failed to resolve. Visitors got nothing. We filed all eleven under DNS problem, and Claude was ready to turn that label into a batch notice.

The label was true as far as it went. The mistake was assuming a shared symptom was enough to decide what had happened and what to say next. We had grouped the customers under one operational description, then handed Claude an action: send their own notice. It looked like a clean handoff. It was an incomplete diagnosis.

The timing made the shortcut tempting. A prior campaign had already contacted 53 accounts whose sites were headed toward failure. These eleven had been deliberately left out, because that final notice would have been false for them. Their addresses had already stopped working entirely, and none of the customers had been contacted about it.

We had the right instinct about the copy and the wrong model for the investigation. A resolver gives you an external symptom. It doesn’t tell you whether every affected name has the same registry state behind it. We let the visible failure stand in for the mechanism. One send away, we would have told a customer whose nameservers had changed that their domain had lapsed, or told customers with lapsed domains something closer to a nameserver problem, depending on which explanation the merged letter happened to lean on. Either direction is wrong for someone, and it goes out under our name rather than as a generic system error.

What the “no DNS” label was hiding

Claude’s failure was specific to the task we gave it. It could organize a mailing job around the “no DNS” label, but it couldn’t recover the distinction that label had erased. Our request already said the copy had to be new rather than a variant of the earlier notice. What we hadn’t made explicit was the step before it: check every name against its actual registry before deciding who belongs in the same letter.

That check changed the shape of the work. Ten of the eleven had lapsed registrations. One had gone nameservers. A visitor saw the same empty result either way, but the customers did not have the same problem, and a message that collapses the two turns a support notice into a guess.

The batch stopped being one batch

We wrote and sent a new notice to all eleven customers, but the campaign no longer had a single explanation. The registry checks split it into two problems and two letters. The unit of work turned out to be eleven customer situations whose browser symptom happened to match.

Two customers also received handwritten notes instead of the batch copy. That came out of the same refusal to treat the list as uniform. The earlier work had identified at least one account that had already received two emails and would need explicit approval before a third. Even when the technical state is clear, contact history changes what responsible automation looks like.

We also kept the work inside a deliberate send path. The original instruction required each account to be shown with its detail page before sending. It’s a modest check, and it pushes against the exact temptation the first label created. Grouping is efficient only after the individual records have been looked at enough to justify it.

DNS resolution is a poor substitute for a registry check when the customer-facing decision depends on why a name is unavailable. It can say something is wrong. It can’t choose the explanation, the letter, or the next action.

What came back

All eleven notices went out with no failures. One customer bought the lapsed domain back 12 minutes after reading the message and later pointed it at us. That was a real result. It wasn’t proof that the process had become automatic, only that the notice carried an actionable explanation for at least one person.

“No DNS” sounded precise because it named a visible failure. The registry check showed it was a bucket holding two different causes, two letters, and a separate decision about handwritten contact. The resolver found the symptom, and the registry check made the message usable. The 12-minute renewal is the number we keep beside that result.

When a group of customers shares one visible symptom, check each record’s underlying state before writing to them as a group. Here the same empty result came from ten lapsed registrations and one nameserver change, and each needed a different letter. For any batch notice, find out what was checked per account and what contact history each account already has.

dxdev LESSON · paste into your AI coding agent
LESSON: A Shared Symptom Is Not a Shared Cause
SOURCE: dxdev.com/blog/dead-domains-registry-check-over-dns
WHAT HAPPENED: Eleven customer domains had all stopped resolving, and the plan was to send all eleven the same "no DNS" batch notice. A registry check before sending revealed two different causes: ten had lapsed registrations, one had changed nameservers. Sending the merged explanation would have been factually wrong for at least one customer. The batch was split into two letters plus two handwritten notes for accounts with prior contact-frequency concerns, and one customer bought their lapsed domain back 12 minutes after receiving the corrected, specific notice.
THE RULE: A visible technical symptom (a resolver failure, an error code, a blank page) tells you something is wrong; it does not tell you which of several possible mechanisms caused it, and grouping affected accounts into one communication based on the symptom alone risks sending a factually incorrect explanation to some fraction of them. Check the actual mechanism per account before merging accounts into one message.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any customer-facing batch communication (email, notice, alert) planned around a shared surface-level symptom without a per-account check of the underlying cause.
  2. Any incident response that treats "N accounts show the same error" as "N accounts have the same problem" without a verification step that could split the group.
  3. Any automated or semi-automated outbound message process with no check for prior contact history before adding an account to a new batch send.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.