When a custom domain is not serving yet, juudd tells your assistant the one mistake that looks exactly like waiting, in the same reply that prints the record. A DNS record that is correct and slow and a DNS record that is wrong and silent produce the same status, so the warning goes where the record is, not in a document the reader may never open.
That is the decision. The rest of this post is the afternoon that earned it and what the sentence says.
The record that existed and did nothing
claim_domain hands your assistant one record to add at whoever runs your DNS: a CNAME from your hostname to the platform's fallback name. Then it asks you to call domain_status once and to be patient, because DNS takes time. Both halves of that were true, and together they hid a failure.
On 2026-09-03, on the platform's own demo domain, the record existed and named the right target. domain_status reported that the domain was pending and that the certificate was pending validation, and it kept reporting that for as long as anyone was willing to wait. The record had been created with the provider's proxy switched on.
Nothing in the reply said that could be wrong. The same reply said, twice, that waiting is normal.
Why the screen cannot tell them apart
Validation has to read a name. A proxied record answers with an address instead of the name it points at, so the validator never sees the CNAME it is looking for, and the domain sits pending. In your provider's dashboard the record looks perfectly correct, because it is. Only the proxy setting is off, and that setting is not part of the record you were asked to add.
So the platform's own wording pointed at the innocent explanation. The loud half of the reply was the one that was wrong. A slow record and a proxied record cost the same screen, and we had told the reader to expect the first.
The sentence, and where it goes
The fix is one sentence: the record has to be DNS-only, meaning the provider's proxy must be off. It is appended in four places, every place the record is printed:
- the plain claim, where you are handed the record to add
- the claim that also offers a one-click link, where the record is the fallback if the link does not work
- the claim whose registration did not complete, where the record is to be added while
domain_statusretries it - the pending branch of
domain_status, where someone who has already made the mistake is looking
Two tests hold it. It is not said once at the top of a setup page, because the person who needs it is not reading a setup page. They are reading a reply that says waiting is normal.
It also says who it applies to. The setting is one provider's concept. A customer whose DNS is anywhere else has nothing to switch off and should not go looking for it, so the sentence names the provider whose word it is and says that elsewhere there is nothing to turn off.
What it does not fix
- A wrong record still waits. The platform cannot see your provider's proxy setting, only that validation has not completed.
- A domain that never validates is dropped after seven days, and
domain_statusthen says the registration is gone and that you can release the domain and claim it again. - A bare apex such as example.com works only if your provider flattens CNAMEs or offers an alias record. Otherwise use www and redirect the apex at your provider.
The rule, once
A fact that lives in a decision record, in an email to a vendor and in a code comment, but not in the sentence a customer reads, has not been told to anyone. State the gotcha beside the thing it is about. The tools and their limits are listed in the docs.