How to Set Up a Custom Domain

Every site you have ever visited at a clean address relies on the same four things: a registered name, a handful of DNS records, an ownership check, and a TLS certificate. Setting up a custom domain means putting those four things in place, roughly in that order. None of it is hard, but the order matters and the error messages are famously unhelpful.

This guide is vendor neutral. It applies whether you are pointing a domain at a website builder, an online store, a documentation platform, a link in bio tool, or a server you run yourself. Registrar dashboards differ, but the mechanics underneath are identical everywhere. If you already own a domain and just need to connect it to a service, skip ahead to step 4.

How to set up a custom domain in eight steps

1. Choose the domain name. Shorter beats clever. A good domain passes the radio test: someone hears it once and can type it correctly. Avoid hyphens and unusual spellings, since both invite typos. On extensions, .com remains the default that nobody questions, but .io, .dev, .app, and .ai are all normal for technical products, and a country extension is fine if your audience is local. Two practical checks before you fall in love with a name: search for existing trademarks in your industry, and confirm the matching social handles are at least tolerable. Remember that this name will probably also become your email address, so say it out loud a few times.

2. Register it. Any accredited registrar can sell you the same domain, so compare on the things that actually differ: the renewal price rather than the first year promotion, whether WHOIS privacy is included at no charge, whether the DNS editor is usable, and whether transferring out later is free and unobstructed. Expect roughly 10 to 20 USD per year for a .com, with other extensions ranging widely.

   After purchase, turn on auto renewal and the registrar transfer lock, and enable two factor authentication on the account. A domain is a lease, not a purchase: miss a renewal and the name eventually goes to auction, often to someone who will happily sell it back to you at a markup.

3. Learn the three records that matter. DNS has dozens of record types, but connecting a domain uses three. An A record maps a name to an IPv4 address (its sibling AAAA does the same for IPv6). A CNAME record declares one name an alias for another, and it is the workhorse of custom domain setups because the target can change its IP addresses without you touching anything. A TXT record holds arbitrary text and is used for ownership verification and for email policies like SPF and DKIM.

   One structural rule trips almost everyone: a CNAME cannot coexist with other records at the same name, which is why the bare domain (the apex, as in example.com with no prefix) usually cannot take a CNAME and gets an A record instead. Some DNS hosts work around this with ALIAS records or CNAME flattening. The full story is in our glossary entry on apex domains vs CNAMEs.

4. Pick a pointing method: nameservers or individual records. There are exactly two ways to point a domain at a service, and knowing which one you are being asked for prevents most confusion.

   Nameserver delegation changes who answers DNS queries for your entire domain. You replace the nameservers listed at your registrar with the ones your platform or DNS host provides, and from then on that provider controls every record. It is the right choice when a platform wants to manage everything on your behalf, or when you want a better DNS host than your registrar. The cost: every existing record, including the MX records that route your email, must be recreated at the new host before you switch, and the change can take a day or two to fully settle.

   Record pointing leaves your nameservers alone and adds only the specific records a service asks for. It is surgical, it is fast, and it cannot break your email because it never touches it. Unless a platform explicitly requires its own nameservers, record pointing is the better default for connecting one service to one domain.

5. Add the records the service asks for. A typical setup is one or both of these: a CNAME on a subdomain such as www or app pointing at a target hostname the platform gives you, and an A record on the apex pointing at an IP address. In your registrar's DNS editor, each record has a type, a name (sometimes labeled host), a value (sometimes labeled target or points to), and a TTL.

   Three conventions worth knowing: @ in the name field means the apex; most editors append your domain automatically, so enter www, not www.example.com; and TTL controls how long resolvers may cache the answer, so set it to something short like 300 seconds while you are setting things up. Copy the values exactly. A single trailing space has ruined many an afternoon.

6. Verify ownership. Before serving anything on your domain, a responsible platform makes you prove you control it, usually by asking you to publish a TXT record containing a unique token, sometimes by checking the CNAME you already created. This step exists to stop a stranger from attaching your domain to their account, so treat any platform that skips it with suspicion. Platforms often call this whole flow bring your own domain. Verification checks tend to run automatically every minute or so; if yours has not confirmed within ten minutes, the token is almost certainly published at the wrong name, which is covered in troubleshooting below.

7. Turn on HTTPS. Once DNS points at the platform, a modern service requests a certificate for your domain from a public certificate authority such as Let's Encrypt, installs it, and renews it indefinitely, all automatically and at no cost. You should not need to buy, generate, or upload a certificate for a standard setup, and a platform that asks you to is showing its age. Some platforms issue the certificate the moment the first request arrives, an approach called on-demand TLS. One quiet failure mode to know about: if your domain has a CAA record restricting which authorities may issue certificates, issuance fails silently until you add the platform's certificate authority to the list.

8. Test it properly. Check the domain in a private browsing window, because your normal browser has cached the old answers. Test both the apex and the www version, since it is common for one to work while the other was forgotten. If you are comfortable in a terminal, dig +short yourdomain.com shows exactly what the world sees; if not, any online DNS lookup tool does the same job. Confirm the padlock appears and that http redirects to https. Then set your TTLs back to something sensible like 3600.

How long propagation really takes

"Allow up to 48 hours" is the most repeated line in DNS, and it is mostly liability boilerplate. Here is what actually happens: resolvers around the world cache your records for the duration of the TTL, so a change becomes visible as old caches expire, not on some global schedule. This is what to honestly expect.

Change	Typically visible in	Worst case	What controls it
New record on an existing domain	1 to 5 minutes	About an hour	Negative caching of the earlier "no such record" answer
Editing an existing record	Minutes	The old record's TTL, often 1 to 24 hours	Whatever TTL was set before you made the change
Nameserver change	15 minutes to a few hours	24 to 48 hours	Registry TTLs at the extension level, which you cannot lower
Brand new registration	5 to 30 minutes	A few hours	How often the registry publishes updates
TLS certificate issuance	Seconds to minutes after DNS resolves	About an hour	CA validation checks, CAA records, rate limits

The practical takeaway: record changes land in minutes, nameserver changes are the slow ones, and if something is still wrong after an hour, the cause is almost certainly a mistake rather than propagation. Waiting longer will not fix a typo.

Troubleshooting: the three failures you will actually hit

The domain does not load at all

Look up what the world sees with dig +short or an online checker. If nothing comes back, the record was saved at the wrong name (the classic: entering www.example.com in a field that appends the domain automatically, creating www.example.com.example.com) or the domain is still sitting on the registrar's parking nameservers. If an IP comes back but the wrong one, you probably edited records at a DNS host that your nameservers no longer point to; records only count at the host your nameservers actually name.

The site loads with a certificate or SSL error

Almost always one of three things. The certificate has not been issued yet, so give it a few minutes after DNS starts resolving and retry. The certificate covers one name but not the one you typed, commonly www works while the apex does not, which means the second name was never added on the platform side. Or a CAA record on your domain is blocking the platform's certificate authority, which you can check with dig CAA yourdomain.com.

Verification keeps failing

Nine times out of ten the TXT token is published at the wrong name: the instructions wanted it at _verify.example.com and it landed at example.com, or the reverse. Check for stale tokens from earlier attempts sitting alongside the new one, paste the value without surrounding quotes unless your DNS editor asks for them, and confirm with a lookup tool that the record is actually visible before hitting retry again. If the platform verifies through the CNAME itself, that CNAME must resolve before verification can pass.

If you run a SaaS: your customers should never read this guide

Everything above is a reasonable ask for someone connecting one domain, once. It becomes unreasonable when it is multiplied across every customer who wants their own domain on your platform, because their confusion about TXT records turns into your support queue.

That is the product we build. Custom Domain gives your users a "connect your domain" flow that takes about 30 seconds: an embeddable widget walks them through it, one-click provider authorization covers 63 DNS and registrar providers, and ownership verification, DNS configuration, and multi-tenant TLS issuance and renewal all happen automatically. There is a full REST API, and an MCP server if your product or your users' AI agents need to drive it programmatically.

If that sounds like your roadmap, start with our guides to adding custom domains to your SaaS and automating TLS for customer domains, see the architecture on how it works, or try it on the free tier. Pricing starts at $0 and the docs cover the rest.