CUSTOM DOMAIN
A customer clicks connect. The confirmation appears. Then, thirty seconds later, they open their new domain in a browser, see nothing, and reach for your support form. The subject line is almost always the same: it is not working yet.
Nine times out of ten, it is working. It just is not finished spreading. That gap between configured and fully live is called propagation, and it is one of the most common reasons a smooth onboarding still generates a ticket. The good news is that it is easy to explain honestly, and once your customers understand it, the tickets mostly stop.
Two different moments
There are two moments when a customer connects a domain, and people tend to collapse them into one.
The first is the record change. When Custom Domain detects the provider and writes the exact records at the customer's own DNS, that change is instant. The record now exists. Nothing is pending on the writing side.
The second is when the rest of the world learns about that record. The internet does not read your customer's DNS zone directly every time someone visits. It reads from thousands of caching resolvers scattered across networks and regions, and each of those resolvers holds on to what it last saw. Until those caches refresh, some visitors get the new answer and some still get the old one. That spread is propagation, and it takes a little time by design.
Configured is not the same as live
The record is instant. Being live everywhere is not. Both statements are true at once, and saying so up front is the whole trick.
TTL is the clock
How long propagation takes is not random. It is governed by a value attached to every DNS record called the TTL, or time to live. The TTL tells resolvers how long they are allowed to cache an answer before they have to ask again.
If a record carries a short TTL, resolvers throw away their cached copy quickly and pick up the new value almost immediately. If a record carries a long TTL, a resolver that cached the old answer just before you made the change can keep serving it until that timer runs out. This is why the same click can look instant for one person and slow for another. They are hitting different resolvers with different amounts of time left on the cache.
| TTL on the record | How fast a change spreads | Good for |
|---|---|---|
| 60 seconds | Resolvers refresh after about a minute, so the new value takes effect almost immediately | Records that may change, like the one pointing a custom domain at your platform |
| A standard, longer TTL | A resolver holding the old answer can keep serving it until the timer runs out, up to about an hour | Records that rarely move, where constant refreshing would only add query load |
The record change is immediate. Propagation is just the world's caches catching up to a change that already happened.
Choosing TTLs well is a small decision with an outsized effect on this experience. Records that may change get a very low TTL so an update takes effect in about a minute. Records that rarely move get a standard TTL, because refreshing them constantly would add query load for no benefit. Setting these thoughtfully means that when something does need to change, it changes fast, and when nothing changes, the internet is not doing needless work on your customer's behalf.
Verify, do not assume
Because writing a record and that record being resolvable are two different events, a connection flow should never assume the second one just because it did the first. Writing the record and then declaring victory is exactly how a customer ends up staring at a blank page while your dashboard insists everything is fine.
So Custom Domain does not stop at writing. It follows the same short sequence every time, and only reports success once success is real:
- Write the records. The provider is detected and the exact records are applied at the customer's own DNS, instantly.
- Wait for them to resolve. The flow checks that the new answer is coming back reliably across the network, not just at the write.
- Confirm and secure. Only then does ownership get confirmed and HTTPS get issued, so a reported success is true everywhere.
That way the moment the flow reports success, it is reporting something that is true across the network, not a hopeful guess made a second after the write. It is the same honesty that lets a customer connect their domain in one click and trust the result.
This is also the right way to talk to the person clicking the button. The honest message is short and it is accurate:
- Your connection is configured immediately.
- It becomes fully live as the change propagates, which usually happens quickly.
- You do not need to do anything while that finishes.
The trap to avoid
Never declare a connection live the instant you write the record. If you skip the resolve check, the customer discovers the delay alone, in a browser, with no idea whether they did something wrong.
That framing does two things. It sets a correct expectation before the customer has time to worry, and it quietly retires a whole category of it-is-not-working-yet messages before they ever reach your queue. When the check finally confirms the record is live everywhere, you know it for certain, and so does your customer.
What changes when you say it plainly
Propagation is not a flaw to hide. It is just how a distributed system stays fast, and it has worked this way for decades. The failure is not the delay. The failure is letting someone discover the delay alone, in a browser, with no idea whether they did something wrong.
When the flow writes the record instantly, waits for it to actually resolve, and tells the customer in plain language what is happening in between, the anxious half-minute stops being a support ticket and becomes a normal, expected pause. The domain comes up. Nobody had to email you. That is what it looks like when the hard part is handled before anyone notices it was there. If you want that handled for you, you can see how a one-click connection works in a few minutes.
Custom domains, on autopilot
Let your customers connect their own domain in one click. We detect their DNS provider, write the records, wait until they actually resolve, verify ownership, and issue HTTPS, while they just approve one screen.
Get started