Domain verification is the product

There are two things that could be meant by "this key is locked to example.com".

The weak one: somebody typed example.com into a field.

The strong one: somebody demonstrated control of example.com by placing a record only its owner could place.

Only the second is worth anything, and the difference between them is the difference between a licensing system and a decoration.

Why the weak version is worthless

If typing is enough, then anyone can claim any domain. I can bind my key to your domain. That alone is untidy rather than dangerous.

The dangerous version is the other direction: an attacker who lifts your public client key binds *their own* key to *your* domain, and now holds a legitimate credential for a site they do not own. Every check passes. Nothing looks wrong. You find out when the bill arrives, or when you do not.

What proof looks like

A TXT record at a name only the domain's operator can create, or a file at a path only they can write. Either demonstrates control at the level that matters, and neither can be faked from outside.

We accept both because organisations are different shapes. Some teams can edit DNS in a minute; some need a ticket and a week, but can deploy a file this afternoon.

And it has to be re-checked

A domain proved once is not proved forever. Domains are sold. Companies fold. Records get cleaned up by somebody tidying a zone file who does not know what _buildapi is for.

So we re-check periodically, allow a few failures — DNS is DNS, and a single lookup failure means nothing — and lapse the verification if it stays gone.

The subtlety is what "verified" means once re-checking exists. We treat it as *last time we could actually see the proof*, not *the first time we ever could*. A proof nobody has been able to see for a month is not a proof any more, whether or not the background job happened to run.

The part people find harsh

Removing the record does eventually stop the key working.

That is not a punishment. It is the feature. If losing control of the domain cost nothing, then proving control gained nothing, and the whole lock is theatre.

We make it as forgiving as we can: several checks before anything changes, a grace period, and clear warnings in the dashboard well before a key stops. But the end state, if the proof is gone and stays gone, has to be refusal.

Three states, not one

Worth naming, because conflating them causes most of the confusion:

• Bound — the key names a domain. A claim.
• Verified — control was demonstrated, recently enough that we still believe it. A fact.
• Enforced — refusal actually happens when the first two do not hold.

Enforcement used to be off by default, which was right when the feature shipped — turning it on would have cut off every existing customer who had never been asked to verify anything. It was wrong to leave standing, because with enforcement off, a verified domain and an unverified one mean exactly the same thing at request time.

It is on now, for everyone, and turning it off is a deliberate act with a warning attached.