Connect a domain walkthrough

1. Open your website host and find its custom-domain instructions. It will give you an IP address, a hostname, or nameservers.
2. Enter your domain and that value above, and pick your registrar.
3. Open the DNS screen at your registrar using the path the walkthrough gives you.
4. Remove conflicting records — usually a parked-page A record and a URL forward. Never touch MX, TXT or SRV.
5. Add the records exactly as generated. Copy rather than retype.
6. Wait, then verify from a phone on mobile data — not the browser you have been working in.
7. Confirm both the bare domain and www load over HTTPS with a padlock.

Before changing anything, screenshot the entire DNS record table. It costs ten seconds and it is the only reliable undo you have.

• An A record. Points the domain at a specific IP address. Simple and precise. Its weakness is that if your host changes infrastructure, the IP can change and your site goes down until you update it.
• A CNAME. Points the domain at another hostname, which the host controls. Better than an A record where offered, because the host can move servers without you doing anything. The complication is that a plain CNAME cannot exist at the root of a domain, which is why registrars offer ALIAS or ANAME records to work around it.
• Nameservers. Hands your entire DNS over to your host. Simplest afterwards, most dangerous during — every existing record, including your email, stops applying unless you recreate it at the new provider first.

If your host offers both a hostname and an IP, take the hostname. It survives infrastructure changes you will never hear about.

Your domain's DNS holds two unrelated things: the records that point at your website, and the records that route your email. They live in the same table and look similar, and people tidying up before adding new records delete both.

The email records are the ones of type MX, plus TXT records containing SPF or DKIM information, plus sometimes a CNAME used for mail. Delete any of those and your mail stops arriving — with no error, no bounce visible to you, and no notification. You find out days later when someone mentions you never replied.

The rule is simple: only ever touch A, CNAME, ALIAS or ANAME records for the web. Leave MX, TXT and SRV alone entirely, even when they look like leftovers from a service you no longer use.

The nameserver method is where this bites hardest, because switching nameservers invalidates every existing record at once. If you go that route, recreate the mail records at the new provider before you switch, not after.

DNS changes are not instant because the answers are cached at many points between you and the record — your browser, your operating system, your router, your internet provider. Each holds the old answer until its cache expires, and the TTL value on the record is the upper bound on that.

In practice most changes take effect within minutes and occasionally take several hours. Nameserver changes are slower, sometimes a day or two. The commonly quoted forty-eight hours is a worst case rather than an expectation.

The important practical point is that your own browser is the least reliable place to check. It caches aggressively, and you have probably been loading the old version repeatedly while you worked. Check from your phone on mobile data, which shares none of that cache, or use an online DNS checker.

If it works on your phone and not your laptop, nothing is broken. That is your laptop's cache, and it will clear. Restart it if you cannot wait.

Most hosts issue an SSL certificate automatically once DNS points at them, but issuance happens after propagation, not before — the certificate authority has to verify that you control the domain, and it can only do that once the domain resolves to your host.

So a certificate warning immediately after DNS goes live is usually just impatience. Give it another few minutes and reload.

If it persists past an hour, the two usual causes are that only one of the bare domain and www resolves — a certificate covering both cannot be issued if one is missing — or, on Cloudflare, that the proxy is on and interacting badly with your host's own certificate. Set the record to DNS-only first, confirm the site loads, then turn proxying back on if you want it.

Do not skip the padlock check. Browsers warn users on non-HTTPS pages, and a warning on a small business site loses visitors faster than almost anything else on that page.

People type both. Some people type neither and let the browser guess. If only one of them resolves, you are losing a share of your traffic to a browser error page, and you will not notice because you type it the way you set it up.

Both should resolve, and one should redirect to the other so you end up with a single canonical address. Which one is the canonical version genuinely does not matter — pick one and be consistent everywhere: your Google Business Profile, your email signature, your invoices, your directory listings.

Test both explicitly after propagation, with https:// in front, from a device that has never visited your site. That is a thirty-second check that catches the most common half-completed setup.