Custom domains explained: DNS records, and connecting one to your app

The registrar

The company you paid for the name: Namecheap, GoDaddy, Porkbun, Cloudflare Registrar, Squarespace Domains and many others. The registrar records that you own the name and which nameservers are in charge of it. You renew here each year.

When comparing registrars, look at the renewal price, not the first-year price. Some sell the first year cheaply and renew at a much higher rate. Cloudflare, for example, says its registrar charges only what the registry and ICANN charge, with no markup on registration or renewal.

The DNS provider

The servers that answer “what is the address for example.com?” They are named in the domain’s NS (nameserver) records. By default this is your registrar, but you can point the nameservers somewhere else, such as Cloudflare or your host, and manage records there instead.

This is where you will do almost all of the work. When a guide says “add a CNAME record”, it means here.

The host

The platform that runs your app and serves its pages. It needs two things from you: records that send traffic its way, and sometimes a TXT record proving you control the domain. In return, it issues an HTTPS certificate for the name once it sees traffic arriving correctly.

Names: @, www and subdomains

In most DNS dashboards the name field is relative to your domain. @ means the domain itself (example.com, also called the apex or root). www means www.example.com. app means app.example.com. Some providers want the full name instead; if a record doesn’t work, check which style the form expects.

The IP addresses in the example are placeholders

Always copy the exact values your host shows you for your project. Hosts change their addresses over time and some give each project its own CNAME target, so values copied from an old blog post or another project are a common cause of failure.

The CNAME rule

RFC 1912, a long-standing guide to running DNS, states that a CNAME record is not allowed to coexist with any other data at the same name. The apex of every domain always has other records, at minimum NS and SOA records, and usually MX and TXT for email. So a plain CNAME at example.com breaks the rules, and on some DNS software it can make the whole domain unreachable.

The three workarounds

Use an A record. The host gives you one or more IP addresses for the apex. This is the most common instruction and works with every DNS provider.

Use a flattened CNAME, sometimes called ALIAS or ANAME. Some DNS providers let you enter a hostname at the apex and then answer lookups with the IP address behind it. Cloudflare calls this CNAME flattening, and it is what allows a bare domain to point at a Cloudflare Pages site.

Make www the main address. Point www.example.com at the host with a CNAME and redirect example.com to it. Vercel’s documentation recommends adding the www version when you add an apex domain for this reason.

Pick one main address and redirect the other

Whichever you choose, add both example.com and www.example.com to your host and set one to redirect to the other. Otherwise half your visitors get an error, depending on whether they typed www.

1. Add the domain on the host first

In the host’s domain settings, Maya adds book.mayastudio.com. The host responds with the record it wants: a CNAME named book pointing at a hostname unique to her project. If the domain had been used on another account at the same host, it would also ask for a TXT record to prove ownership.

2. Lower the TTL if you are changing an existing record

Her subdomain is new, so there is nothing to lower. If she were moving the main website, she would first edit the existing record’s TTL down to something like 300 seconds and wait out the old TTL, so that any correction later spreads in five minutes.

3. Add the record at the DNS provider

In the registrar’s DNS screen she adds: type CNAME, name book, value the hostname the host gave her, TTL automatic or 300. She does not touch the MX records for Google Workspace or the A record for her existing site.

4. Check what DNS says, then wait for the certificate

From a terminal she runs dig book.mayastudio.com CNAME +short and sees the host’s hostname come back. (On Windows, nslookup -type=CNAME book.mayastudio.com does the same.) The host’s dashboard then shows the domain as verified and issues an HTTPS certificate, which usually takes from a few minutes to an hour.

5. Test the real thing

She opens https://book.mayastudio.com in a private window, on her phone over mobile data rather than Wi-Fi, and checks that sign-in still works. Login cookies and redirect URLs (for Google sign-in, for example) are often tied to the old address, so a working home page doesn’t prove a working app.

Lower it before a change, raise it after

RFC 1912 gives the classic advice: keep TTLs reasonably long for stable records, lower them before a planned major change, and wait for the old TTL to expire before relying on the new value. In practice: a day before you move a live site, set the record’s TTL to 300 seconds. Make the change. Once everything works, raise it again to an hour or more.

New records are usually fast

A brand-new subdomain has nothing cached, so it often works within minutes. The slow cases are changing a record that already had a long TTL, and changing nameservers, which are cached at the registry level and often have TTLs of a day or more.

How to see the truth

Use dig example.com A +short to see the current answer, and dig @8.8.8.8 example.com A +short to ask a specific public resolver. If the authoritative answer is right but your browser still shows the old site, the problem is a cache on your machine, not your records.

Changing nameservers moves everything

Some hosts offer to manage your DNS for you by switching the domain’s nameservers. That moves every record to the new provider. Vercel’s documentation warns to copy your existing records first, including MX records for email and verification TXT records, and notes that changing only the website’s A or CNAME record doesn’t require moving anything else. If you only need the website connected, the record-by-record method is safer.

The email authentication records

Email providers depend on TXT records. SPF lists which servers may send mail for your domain, DKIM publishes a key used to sign messages, and DMARC tells receivers what to do when checks fail. Google’s sender guidelines require all senders to Gmail accounts to set up SPF or DKIM, and anyone sending more than 5,000 messages a day to use SPF, DKIM and DMARC.

If your app sends email (password resets, receipts), the email service will give you its own SPF and DKIM records to add. Note that a domain can only have one SPF record; add the new service to the existing one rather than creating a second.

Conflicting records for the same name

An old A record for www left in place next to a new CNAME for www. Delete or replace the old record; don’t add a second one beside it. Many registrars create default “parking” records that must be removed.

Typing the full name in a relative field

Entering book.mayastudio.com in a field that appends the domain produces book.mayastudio.com.mayastudio.com. If a lookup returns nothing, check how the record was saved.

Editing DNS at the wrong company

If your nameservers point at Cloudflare, records added at the registrar do nothing. Look up the NS records first (dig example.com NS +short) to see who is really in charge.

A CAA record that blocks your host’s certificate

If a CAA record allows only one certificate authority and your host uses another, the certificate never issues and the site shows a security warning. Either add the host’s authority to the CAA record or remove the restriction.

Proxying in front of the host without reading its docs

Turning on a DNS provider’s proxy (Cloudflare’s orange cloud, for example) puts another service between visitors and your host. Some hosts support this and some recommend DNS-only mode for verification and certificates. Start with DNS-only, confirm everything works, then add a proxy deliberately.

How long does it take for a custom domain to work?

A new subdomain record often works within minutes. Changing an existing record can take as long as its old TTL, and changing nameservers can take a day or more because those answers are cached for longer. HTTPS certificates are usually issued within minutes to an hour after the records are correct.

Should I use www or the bare domain for my app?

Either works if you add both to your host and redirect one to the other. Using www as the main address lets you use a CNAME, which some hosts prefer because they can change their servers without you updating records.

Can I put my app on a subdomain and keep my existing website?

Yes. Add a CNAME for a name like app or book pointing at your app’s host, and leave the records for the main domain alone. This is the lowest-risk way to connect a domain.

Do I need to move my domain to my hosting company?

No. You can keep the domain at any registrar and only add the records your host asks for. Transferring the registration or switching nameservers is optional.

Why does my domain work on my computer but not my phone, or the reverse?

Different devices and networks cache DNS answers for different lengths of time. Check the authoritative answer with dig or an online DNS lookup tool. If it’s correct, wait out the TTL rather than changing records again.

Will connecting a domain to my app break my email?

Not if you only add or change the A or CNAME record for the website. Email depends on MX and TXT records, which break only if you delete them or switch nameservers without copying them over.