CUSTOM DOMAIN
A customer connects their domain. The widget detects their provider, writes the records with one click, verifies ownership, issues HTTPS. Green check. Everyone moves on.
Three weeks later that same domain returns an error, and nobody on your team changed anything. The customer did not either, at least not on purpose. Somewhere between then and now, a record moved. This is the part of custom domains that rarely makes the demo: the connection is not a document you sign once. It is a live thing sitting in someone else's DNS zone, and that zone keeps changing after you leave.
The connection is only true until the next edit
DNS is shared space. The record your integration wrote lives in the same zone as everything else the customer does with their domain: their email, their marketing tools, whatever their agency set up last year. Any of those actors can edit, replace, or delete the record you depend on, and none of them know it belongs to you.
The connection can go dark in a handful of predictable ways. What they share is that your product did nothing wrong and your product still stops working. The customer experiences it as your outage.
| Failure mode | What causes it | How it is detected |
|---|---|---|
| Record removed as clutter | The customer edits their own zone, sees a record they do not recognize, and deletes it | The record we placed is gone from a zone we are still watching |
| Overwrite by a second service | Another integration writes to the same name and replaces the record the first one placed | The value at that name no longer matches what we wrote for the connection |
| Lost in a migration | The provider runs a migration, or the customer moves registrars, and not every record survives intact | The record stops resolving after the move, against a map that says it should be there |
| Cleaned up by a contractor | A well-meaning contractor tidies the zone and takes a live record with them | A record we know belongs to a connection disappears without a matching request from your platform |
Apex records fail loudest
Not all records break equally. The record at the apex, the bare domain with no subdomain in front of it, is the one that decides where the whole domain resolves. Replace it and existing content goes down the instant the change propagates. There is no partial degradation and no grace period. The site that was live is now pointing somewhere else.
What makes the apex worse is that it is the record people are most tempted to touch. It is the domain itself, so it draws attention. A customer setting up a new landing page, or a major email provider's setup wizard, may replace the apex to serve its own purpose, and the swap that helps one service quietly breaks yours. Later, another change can reverse it just as fast. The apex is a single seat, and whoever sat down last wins.
A connection you cannot observe after setup is a connection you will only hear about from an angry customer.
Collisions need memory to detect
Here is the part that is hard to solve by hoping. When a second service overwrites your record, the only way to know it happened is to know which record was yours to begin with. If you never tracked that a specific record belonged to a specific connection, a collision looks identical to a normal zone with a lot going on. You cannot tell the difference between "this was replaced" and "this was never here."
Keeping a precise map of which records belong to which connection is what turns a mystery into a diagnosis. When the apex changes, you can say what it used to be, what wrote it, and what it is now. That is the difference between guessing and answering a support ticket in one reply.
Delegated and hosted subdomains have their own version of this. When you point a whole subtree at your infrastructure, the pointing records are load-bearing for everything beneath them. Remove those records without cleaning up what depends on them, and queries across the entire subtree can start failing at once. Deprovisioning is not just deleting a row in your database. If the DNS side is not handled deliberately, tearing down one connection can take out names you did not mean to touch. Drift and deprovisioning are two faces of the same problem: records changing state without anyone watching.
Watching is the feature
So the honest version of custom domains is not "write the records and walk away." It is write the records, then keep looking. It is the same discipline that lets customers connect their domain in one click, extended past the green check and into the weeks that follow.
Monitoring, then a webhook when it drifts
We watch the connected domains after setup. When a record we placed gets changed, overwritten, or removed, we detect it, and when a connection degrades we fire a webhook to your platform. The failure becomes a signal you can act on instead of a surprise that shows up as churn.
That shift matters more than it sounds. A silent outage is the worst kind, because the clock starts the moment it breaks and stops only when a customer notices and complains. Everything in between is damage you did not know you were taking. An alert compresses that window to near zero. You can reach out before the customer does, or fix it before they ever see the error page.
Setup gets the attention because it is the visible moment. But the domains that stay connected are the ones someone keeps watching. When drift becomes an event you receive rather than a story you piece together after the fact, a connected domain stops being a thing you hope holds and starts being a thing you can stand behind.
Custom domains, on autopilot
Let your customers connect their own domain in one click. We detect their DNS provider, write the records, verify ownership, and issue HTTPS, then keep watching so drift reaches you as a webhook instead of a churned customer.
Get started