Melbear AI steckt jetzt in jedem ModulAnsehen
← Blog

Pointing your domain at a platform: DNS, propagation and SSL, explained

Guides

Connecting your own domain to a platform is one of those tasks that sounds technical, takes about ten minutes, and then makes you wait. Here is what is actually happening, so that the waiting does not feel like a failure.

What a domain is, in one paragraph

A domain name is a label. On its own it points nowhere. The internet resolves it through DNS — a distributed directory that maps names to servers. When you "connect a domain", you are editing that directory entry at your registrar so that it points at the platform hosting your site.

The records you will meet

  • A record — maps a name directly to an IP address. Usually used for the bare domain, for example example.com.
  • CNAME — maps a name to another name. Usually used for www, so that it follows wherever the platform moves.
  • TXT — plain text, used for verification. A platform asks you to add a specific string to prove you actually control the domain, so that nobody else can claim it.

Why it is not instant

DNS answers are cached, deliberately. Every resolver between your visitor and the directory keeps the previous answer for a period set by the record TTL — often an hour, sometimes much longer. Until those caches expire, some people see the new site and some still see the old one. That is propagation. It is not a queue you are waiting in, and no support ticket makes it faster.

Two practical consequences:

  • Lower the TTL before you migrate, ideally a day ahead. A 300 second TTL turns a day of uncertainty into five minutes.
  • Do not judge the switch from your own browser. It is the most heavily cached machine you own. Check from mobile data, or use a DNS lookup tool.

Then the certificate

Once DNS points at the platform, the site still needs HTTPS. Certificates are issued automatically these days, but the issuing authority has to see the domain resolving to the right place before it will sign anything. So the order is always: DNS first, certificate second, padlock third. If the padlock has not appeared, the usual cause is that the DNS change has not finished, not that the certificate failed.

A sane sequence

  1. Lower the TTL on the existing records, a day before.
  2. Add the verification TXT record and confirm the platform sees it.
  3. Build and preview the new site on the platform address, before switching.
  4. Point the A and CNAME records at the platform.
  5. Wait. Check from a device that has never visited the old site.
  6. Confirm the certificate, then set redirects so both the bare domain and www land in the same place.

Keep the registrar account details somewhere you can find them. The single most common reason a domain migration stalls is that nobody remembers who registered it.