How to Connect a Domain to Vercel Without DNS Errors

Overview

If your goal is to connect a domain to Vercel without DNS errors, the safest approach is to decide one thing first: where DNS is managed. Everything else depends on that answer.

In most cases, you will use one of these paths:

• Vercel manages DNS: you point your domain’s nameservers to Vercel and create records there.
• An external DNS provider manages DNS: you keep nameservers at Cloudflare, Route 53, your registrar, or another provider, and add the records Vercel requires.

Both paths can work well. Problems usually come from mixing them unintentionally. For example, you may add a record in Vercel while the live nameservers still point to Cloudflare, or remove an old A record at the registrar while the real DNS zone exists somewhere else.

Before you start, keep this mental model in mind:

• Nameservers decide which DNS zone is authoritative.
• DNS records inside that authoritative zone decide where traffic goes.
• Vercel then decides which project should answer for the hostname.

That means a working setup has three layers aligned:

1. The domain points to the correct authoritative DNS provider.
2. The hostname has the correct A, CNAME, or other required record.
3. The domain is assigned to the intended Vercel project and environment.

If one layer is wrong, the site may fail in ways that look misleading. You might see an SSL warning when the actual issue is a stale DNS record, or get a Vercel validation error when the real problem is that the hostname is attached to another project.

As a general rule:

• Use a CNAME for subdomains such as www.example.com, app.example.com, or staging.example.com.
• Use the record type Vercel recommends for the apex/root domain such as example.com. Many DNS providers do not allow a CNAME at the apex if other records exist there, so follow the provider-specific guidance instead of forcing a pattern that works only for subdomains.

If you need a refresher on record types and zone management, see the Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types.

Checklist by scenario

Use the checklist below based on your actual setup. The point is not to follow every scenario, but to choose the one that matches your DNS authority and your target hostname.

Scenario 1: Connect a subdomain like www or app to Vercel

This is the cleanest case and often the best place to start.

1. Add the domain in Vercel to the correct project first. This tells Vercel which app should answer for the hostname.
2. Confirm where DNS is hosted. Check the domain’s nameservers before editing any records.
3. Create or update a CNAME record for the subdomain at the authoritative DNS provider, using the target Vercel provides in the dashboard.
4. Remove conflicting records for the same hostname. A subdomain should not have both an A record and a CNAME for the same name.
5. Wait for propagation based on your provider’s TTL and cache behavior.
6. Test the exact hostname you configured, not just the apex domain. For example, test app.example.com directly.

This pattern is especially useful when moving gradually from another platform. You can point app.example.com to Vercel first without touching the rest of the zone.

Scenario 2: Connect the apex domain example.com to Vercel

The root domain is where more DNS mistakes happen because providers handle apex records differently.

1. Add the apex domain in Vercel to the intended project.
2. Read the exact record instructions shown by Vercel for your provider or hosting mode.
3. Check for existing A, AAAA, ALIAS, ANAME, or forwarding rules on the apex. Old records are a frequent source of partial outages.
4. Replace only the records that are relevant, leaving mail and verification records alone unless you mean to change them.
5. Verify redirect behavior between example.com and www.example.com. Decide which hostname should be canonical and configure the redirect intentionally.

A good practice is to choose one public primary hostname. If you want users to land on www.example.com, then make that the canonical hostname and redirect the apex to it, or do the inverse. Avoid serving the same app on both without a redirect plan.

Scenario 3: Keep DNS at Cloudflare or another external provider

This is common, especially if your team already uses provider-specific features, email routing, or DNS automation.

1. Leave nameservers where they are. Do not change them unless you want Vercel to host DNS for the entire domain.
2. Add the Vercel-required records only in the external provider. Changes inside Vercel DNS will not matter if Vercel is not authoritative.
3. Be careful with proxy features. If your DNS provider can proxy traffic, start with a plain DNS-only setup unless you specifically need the proxy layer.
4. Check SSL mode and proxy interactions if using a CDN or reverse proxy in front of Vercel.
5. Verify that the hostname resolves publicly before assuming the issue is inside Vercel.

If you use Cloudflare, keep your DNS records, redirects, and proxy settings easy to trace. The more layers you add, the harder it becomes to tell whether the problem is DNS resolution, proxying, or Vercel routing. For broader DNS record examples, see the Cloudflare DNS Setup Guide.

Scenario 4: Move a domain from another host to Vercel

Migrations fail when the new records are added but the old platform still holds traffic for some hostnames.

1. Inventory all active hostnames: apex, www, app, API, docs, staging, and any region-specific subdomains.
2. Map each hostname to its destination. Not everything has to move to Vercel at once.
3. Lower TTL in advance when practical, so changes roll out faster later.
4. Remove obsolete records only after replacement records are in place.
5. Check for hidden dependencies such as registrar forwarding, old CDN configurations, or origin allowlists.
6. Confirm that the domain is not still attached to an old project or account if Vercel flags a conflict.

For teams with multiple environments, documenting hostnames in a small table saves time during every migration.

Scenario 5: Use separate domains for production, preview, or staging

This is where Vercel custom domain setups become much easier to maintain.

1. Assign one hostname per environment, such as example.com for production and staging.example.com for staging.
2. Avoid reusing the same custom domain across multiple projects unless you have a clear handoff process.
3. Record ownership and expected target values in your deployment notes or infrastructure repo.
4. Validate redirects and cookies if auth or session behavior differs between environments.

Environment-specific hostnames reduce deployment troubleshooting because DNS becomes predictable. You can move a staging hostname without risking the production domain.

What to double-check

If the domain still does not work, run this verification pass before making more changes. Many DNS incidents get worse when people keep editing records without checking authority, caches, and record conflicts.

1. Are you editing the authoritative DNS zone?

This is the first question to answer. If your nameservers point to one provider, changes made in another provider will not help. Check the live nameservers for the domain, then log in only to that provider for record changes.

2. Is the hostname attached to the correct Vercel project?

A valid DNS record is not enough. Vercel also needs to know which project should serve that hostname. If the domain was previously used elsewhere, check whether it is still associated with another project, team, or account.

3. Is there a conflicting record for the same hostname?

Typical conflicts include:

• A CNAME and A record for the same subdomain
• Old AAAA records still sending IPv6 traffic elsewhere
• Registrar forwarding active at the same time as DNS-based routing
• Proxy or CDN rules intercepting requests before they reach Vercel

Look at the exact hostname, not just the domain in general. A problem on www may not affect the apex, and vice versa.

4. Did you test propagation from multiple networks?

DNS can appear inconsistent for a while because recursive resolvers cache old answers. If one device still reaches the old site, test from a different network or use a DNS propagation tool. The DNS Propagation Checker Guide is a useful companion when changes look correct in one place and wrong in another.

5. Are mail records still intact?

When editing DNS under time pressure, it is easy to remove MX, SPF, DKIM, or DMARC records accidentally. Those records do not affect web routing directly, but deleting them can break mail flow or email authentication. If you changed the zone broadly, verify your mail-related records afterward. See the SPF, DKIM, and DMARC Setup Guide if you need a checklist.

6. Are redirects configured intentionally?

Sometimes the domain resolves correctly, but users still land on the wrong URL because redirects exist at multiple layers: registrar forwarding, CDN rules, framework config, and Vercel project settings. Write down the expected redirect chain and remove any duplicate layer you do not need.

7. Is the issue DNS, SSL, or application routing?

These are different classes of problems:

• DNS issue: hostname does not resolve correctly.
• SSL issue: hostname resolves, but certificate issuance or trust is not complete.
• Application routing issue: hostname resolves and loads Vercel, but the app returns a 404, wrong project, or unexpected route.

Classifying the issue first makes troubleshooting faster. Do not edit DNS if DNS is already correct and the remaining problem is app configuration.

Common mistakes

These are the patterns that cause the most confusion when trying to fix a Vercel domain not working.

Changing records in the wrong place

The domain registrar, the DNS host, and Vercel may all show DNS-related screens, but only the authoritative provider controls live resolution. Always verify nameservers before making edits.

Using the wrong record type

A subdomain usually needs a CNAME, while the apex may need a different record pattern depending on provider capabilities. Forcing a CNAME everywhere creates avoidable errors.

Leaving old records behind

Teams often add the new Vercel record but forget to remove an old A or AAAA record that still points to a previous host. This can create inconsistent responses across networks.

Proxying too early

If your DNS provider offers an HTTP proxy, disable extra layers until the basic DNS path works. Once the hostname validates and serves the correct project, reintroduce the proxy only if needed.

Confusing project-level and domain-level ownership

A domain may be valid in DNS but unavailable in Vercel because it is already assigned to another project or account. This often happens during migrations, team changes, or environment cleanup.

Ignoring the www version

Many setups configure only the apex or only www, then assume the other will work by default. Treat them as separate hostnames and decide which should redirect.

Editing unrelated records during a web migration

Mail, verification, and service records should remain untouched unless they are part of the migration. DNS incidents often expand because a simple website cutover turns into a full zone rewrite.

Not documenting environment domains

If production, preview, and staging use similar hostnames, write them down with owner, purpose, and expected target. This reduces repeated deployment troubleshooting every time a project moves.

When to revisit

This setup is worth revisiting anytime the inputs change, not just when something breaks. A short review before a release or migration can prevent a longer outage later.

Revisit your Vercel DNS setup when:

• You move DNS providers or registrars
• You switch from a single project to separate production and staging projects
• You add a CDN, proxy, WAF, or reverse proxy in front of Vercel
• You migrate from another host and need to retire old records
• You change your canonical hostname strategy between apex and www
• You transfer project ownership between teams or accounts
• You prepare for a busy launch period and want lower-risk changes

For a practical maintenance routine, keep a simple domain checklist in your repo or ops notes:

1. List each hostname and its intended destination.
2. Record where authoritative DNS is hosted.
3. Note the expected record type and target value.
4. Document which Vercel project owns the hostname.
5. Define the canonical redirect path.
6. Verify mail-related DNS records were not changed accidentally.
7. Run a propagation check after updates.

If you do this, the next domain move becomes much easier. You will not have to rediscover where DNS lives, which records matter, or why one environment worked last time while another did not.

The simplest way to connect a domain to Vercel without DNS errors is to slow the process down: identify the authoritative DNS provider, add the domain to the right Vercel project, use the correct record type for the exact hostname, and remove conflicts before testing. That checklist is reusable whether you are adding a first custom domain, moving from another platform, or cleaning up environment sprawl.