How to connect a custom domain to your website without breaking email

The rule: change the website records, not every record

A domain’s DNS is a list of records, and only two or three of them are about the website: the one at the bare domain and the one at www, plus sometimes a verification record the host asks for. Everything else in the list, including the records that make email work, belongs to something other than the website and should be left exactly as it is. Connecting a domain to a new host means editing those two or three records and nothing else.

Hosts make this harder than it should be. Their “add a domain” screens often offer to become your DNS provider, or ask you to change nameservers, or show a record that conflicts with one you already have. This guide is about reading those screens correctly. It assumes the site is already running on the new host’s own address; if it isn’t, the host move guide gets you there, and the deployment guides for Vercel, Netlify and Cloudflare cover each host’s domain screen specifically.

Step 1: Capture what exists

Before opening any host’s domain screen, sign in to wherever the domain’s DNS is managed and export or screenshot every record with its type, name, value and TTL. If you don’t know where that is, the diagnostic finds it from the nameservers. Then label each record: website, email, verification, subdomain, or unknown. The DNS guide walks through the labelling; this capture is what makes every later step safe, and it’s the one people skip.

Step 2: Test the new site on the host’s address first

Every host gives the site an address of its own, such as project.vercel.app, project.netlify.app or project.pages.dev. Use it to check the site works: pages, images, forms, sign-in, anything that reads data. Fix problems here, where no visitor can see them. Some things, such as a sign-in provider that only accepts callbacks from the real domain, can’t be fully tested until after the switch; note them for step 10.

Step 3: Which records a website needs

Two names matter: the bare domain, called the apex or root and written @ in most DNS panels, and www. Hosts want one of these for each:

Add both names to the host, so that either works, and choose which one is primary. Netlify redirects the other to it automatically; Vercel’s documentation says it attempts the redirect and recommends setting one explicitly. Both recommend www as the primary when your DNS stays elsewhere, because the CNAME can follow the host’s network while an A record at the apex can’t. If the site currently answers on one or the other, keep it that way, because links and search listings point there.

Edit the existing records rather than adding new ones next to them. Two A records at @, one old and one new, send half your visitors to the old host.

Step 4: Verification records

Some hosts ask for a TXT record to prove you control the domain. Vercel asks for one, shown on its domain card, only when the domain is already in use by another Vercel account; Netlify doesn’t use one at all and simply checks the website records; Cloudflare relies on the domain being a zone in your account; Lovable, Bolt for subdomains, Replit and others ask for their own. These are additions, not replacements: they sit at their own name and don’t interfere with anything. Add them when asked, and when you leave a host, its verification record can be deleted or left; Replit, for instance, wants its kept for as long as the domain is connected, and it’s harmless afterwards.

What a verification record is not: a reason to remove other TXT records. A domain commonly has several, for email authentication and for other services that verified ownership in the past. Leave them.

Step 5: Nameservers, and why you usually don’t change them

A nameserver change moves the whole DNS to a different provider. Every host offers it, because managing your DNS lets them add records for you. But connecting a website needs two records, and Vercel’s own documentation says it plainly: changing only the website’s A or CNAME record at your current DNS provider doesn’t require moving the rest of your records. Netlify and Cloudflare each tell you to copy every existing record, including MX, before pointing nameservers at them.

You genuinely need a nameserver change only when:

• The host requires it. Cloudflare Workers custom domains need the domain’s DNS at Cloudflare; Cloudflare Pages doesn’t.
• The new registrar requires it, as Cloudflare Registrar does.
• You want the DNS provider’s features, such as Cloudflare’s proxy, for their own sake.

If one of those applies, it’s a separate job with its own procedure in the DNS guide: recreate the complete zone at the new provider, compare it line by line with your capture, and only then switch. Never do it as a side effect of clicking through a domain wizard.

Step 6: The email records stay exactly as they are

Email at your domain depends on four kinds of record, none of which has anything to do with where the website is:

• MX records, which name the servers that receive your mail. Google Workspace’s is smtp.google.com; Microsoft 365’s ends in .mail.protection.outlook.com.
• SPF, a TXT record at @ starting v=spf1. There must be exactly one.
• DKIM, TXT or CNAME records at names ending ._domainkey.
• DMARC, a TXT record at _dmarc.

A website move should not touch any of them. Vercel’s documentation says it directly: adding a domain to a project does not, by itself, move your DNS records or change your email configuration, and it doesn’t host mailboxes. No hosting provider’s domain screen needs your MX records changed. The damage happens when a wizard replaces the zone, or when someone tidies up records they don’t recognise. Broken SPF or DKIM doesn’t bounce mail; it sends it to spam quietly, for weeks.

Step 7: If Cloudflare is in front of the domain

If your DNS is at Cloudflare, each website record has a proxy switch, shown as an orange cloud. Proxied means visitors reach Cloudflare, which fetches from your host; a public lookup shows Cloudflare’s addresses rather than the host’s. That affects two things when you connect a domain to a host elsewhere:

• Outside hosts generally want the proxy off for their records. Netlify says the proxying must be disabled before it can issue a certificate, because it needs to terminate TLS itself; Vercel says it doesn’t recommend a reverse proxy in front of Vercel at all. So set those website records to DNS only, the grey cloud, and leave them that way unless the host says otherwise.
• Cloudflare’s own guidance is that DNS-only is for records that don’t serve web traffic, such as email and third-party verification records, so those stay grey regardless.
• If you do proxy a record that points at an outside host, Cloudflare strongly recommends the Full or Full (strict) encryption mode, so the connection between Cloudflare and the host is encrypted too.

If the site is hosted on Cloudflare itself, the proxy is part of the arrangement and Cloudflare manages the records.

Step 8: When the host’s instructions conflict with your DNS

Common cases and what to do:

• The host asks for an A record at @ but you already have one. Edit the existing record’s value. Don’t add a second.
• The host asks for a CNAME at @. DNS rules forbid it alongside other records, and Vercel’s troubleshooting page says so and steers you to the A record. Use the A record, or an ALIAS record if your provider offers one.
• The host asks for a CNAME at www but you have an A record there. Delete the A record at www and add the CNAME; a name can’t have both.
• The wizard wants to “import” or “take over” DNS. Decline. Choose the manual or external-DNS option and add the records yourself.
• The host shows the domain as invalid or pending. Compare the record it wants with the one you added, character by character, and allow for caching before assuming it’s wrong.
• A CAA record exists. It restricts who may issue certificates. Add the host’s certificate authority (Let’s Encrypt for Vercel and Netlify) rather than deleting the record.

Step 9: Make the change

1. Add the domain and www to the host’s project and copy the exact records it shows.
2. If the current website records have a long TTL, lower it to a few minutes and wait out the old TTL.
3. Edit the record at @ to the host’s A value (or ALIAS), and the record at www to the host’s CNAME value. Add any verification TXT record.
4. Touch nothing else. Save.
5. Watch the host’s domain screen. It should go from pending to valid within minutes as caches expire, then request a certificate; Cloudflare quotes 15 minutes to 24 hours for its own, and the others don’t give a figure.

Step 10: Verify the website and email

If the site isn’t there after the change, or one name works and the other doesn’t, or the browser shows a certificate warning, there’s a troubleshooting guide for each: website not showing after a DNS change, www works but the bare domain doesn’t, and HTTPS not working.

Step 11: Rollback

If the site doesn’t work on the domain, set the two records back to the values in your capture. With the TTL still short, most visitors return to the old host within minutes, as long as it’s still serving the site. Leave the old host running until you’ve verified the new one for a few days. Email needs no rollback, because you never changed it.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Adding a custom domain · Vercel
• Deploying and redirecting domains · Vercel
• Managing DNS records · Vercel
• Domains troubleshooting · Vercel
• Configure external DNS for a custom domain · Netlify
• Set up Netlify DNS · Netlify
• Manage multiple domains · Netlify
• Domain troubleshooting tips · Netlify
• Using Cloudflare with Vercel · Vercel
• HTTPS (SSL) · Netlify
• Custom domains for Workers · Cloudflare
• Custom domains for Pages · Cloudflare
• Proxy status · Cloudflare
• Encryption modes · Cloudflare
• Enable Universal SSL · Cloudflare
• Full DNS setup: change your nameservers · Cloudflare
• DNS record types · Cloudflare
• Set up MX records for Google Workspace · Google Workspace Admin Help
• Create DNS records at any DNS hosting provider · Microsoft 365