Connecting a Vercel project to a third-party domain is the five-step flow: add the domain to the Vercel project, copy the DNS records Vercel gives you, paste them into the registrar’s DNS panel, wait for DNS propagation, and let Vercel verify. The flow is the same for Namecheap, Cloudflare, Google Domains, GoDaddy, Porkbun, Hover, and any other registrar — the registrar’s UI is the only thing that changes. The interesting part is the apex vs. www split, the DNS verification step, the three records Vercel asks for, and the four pitfalls (the wrong record type, the wrong target, the missing www, the propagation wait) that quietly break the connection.
The reason “connect Vercel domain to tech domain” is its own question is that the Vercel docs cover the happy path well, and the Vercel docs skip the “what if the domain is on a different registrar” path. The third-party registrar is where the developer is going to spend 80% of the time, and the third-party registrar is the part the developer has to know to make the connection work.
Table of contents
- The short version
- The five steps to connect a third-party domain to Vercel
- The three DNS records Vercel asks for
- The four pitfalls that quietly break the connection
- The way the apex vs. www split shapes the setup
- The five registrars a developer will see most often
- FAQ
The short version
The Vercel project has a Domains section in Settings. The developer adds the domain (e.g. example.com and www.example.com), Vercel shows the DNS records the developer needs to add at the registrar, the developer adds those records at the registrar’s DNS panel, the developer waits for the DNS to propagate, and Vercel automatically detects the records and issues a TLS certificate. The flow is the same for any registrar — the developer just has to know which DNS panel to log in to.
The five steps to connect a third-party domain to Vercel
The flow to connect a third-party domain to a Vercel project is the same five steps regardless of the registrar. The five steps are the ones the developer will follow, and the five steps are the ones the developer should know before they start.
Step 1: add the domain to the Vercel project. In the Vercel dashboard, open the project, click Settings → Domains, and add the domain. The developer should add both example.com (the apex) and www.example.com (the www subdomain) if they want both to work. Vercel will show the DNS records the developer needs to add at the registrar.
Step 2: copy the DNS records Vercel gives you. Vercel shows three records: an A record for the apex (example.com → 76.76.21.21), a CNAME record for the www subdomain (www.example.com → cname.vercel-dns.com), and a TXT record for verification (_vercel.example.com → a long verification string). The records are the lever the developer has, and the records are the part the developer has to copy exactly.
Step 3: paste the records into the registrar’s DNS panel. In the registrar’s dashboard, find the DNS panel, and add the three records. The panel is usually at a path like “Advanced DNS,” “DNS Records,” or “Manage DNS.” The developer has to add the records with the right host, the right value, and the right TTL (300–3600 seconds is typical).
Step 4: wait for DNS propagation. The records take seconds to minutes to propagate across the internet, depending on the TTL. The developer can check the propagation with dig example.com A or nslookup example.com. The command returns the IP address Vercel gave, and the IP is the signal that the records have propagated.
Step 5: let Vercel verify. Vercel polls the DNS records every minute or so. Once the records are detected, Vercel marks the domain as “Valid” and issues a TLS certificate. The TLS certificate takes a few minutes, and the green padlock appears in the browser once the certificate is active.
The five steps are the same for every registrar. The developer should know which DNS panel to log in to, and the developer should know the right path to the panel for the registrar they are using.
The three DNS records Vercel asks for
Vercel asks for three DNS records when the developer adds a custom domain. The three records serve different purposes, and the developer should know what each one is for.
The A record for the apex. The A record maps the apex domain (example.com) to Vercel’s load balancer IP (76.76.21.21 at the time of writing — the IP may have changed). The apex is the right answer for the bare domain (no www), and the apex is the canonical URL for most projects. The A record is required for the apex because CNAME records are not allowed at the apex by DNS spec.
The CNAME record for the www subdomain. The CNAME record maps the www subdomain (www.example.com) to Vercel’s load balancer domain (cname.vercel-dns.com). The www is the right answer for projects that want to redirect www to the apex, or vice versa. The CNAME is preferred over an A record for subdomains because the target is a domain, not an IP, and the IP can change without the developer having to update the record.
The TXT record for verification. The TXT record maps a special subdomain (_vercel.example.com) to a long verification string that Vercel generates. The TXT record is how Vercel verifies that the developer owns the domain. The TXT record is required, and Vercel will not issue the TLS certificate until the TXT record is detected.
The three records are the floor. Some projects also add a TXT record for SPF (email authentication), a MX record for email, and a CAA record to restrict which certificate authorities can issue a certificate for the domain. The three are the ones the developer needs to make the connection work.
The four pitfalls that quietly break the connection
A short, opinionated list of pitfalls that have actually broken real Vercel + third-party domain connections. None of them are dramatic. They are the boring ones.
The A record points at the wrong IP. A developer who copies the IP from an old tutorial, or who guesses the IP, is a developer whose domain is going to point at the wrong place. The fix is to copy the IP directly from Vercel’s Domains panel, and to verify with dig example.com A that the IP matches.
The CNAME target is misspelled. A developer who types cname.vercel-dns.com as cname.vercel.com is a developer whose www is not going to resolve. The fix is to copy the target exactly from Vercel’s panel, character by character, and to verify with dig www.example.com CNAME that the target matches.
The www is not added. A developer who adds the apex but forgets the www is a developer whose www.example.com is going to serve a parking page or a DNS error. The fix is to add both example.com and www.example.com to Vercel’s Domains panel, and to set up the redirect (apex → www or www → apex) in Vercel’s settings.
The DNS propagation is not waited for. A developer who adds the records and immediately clicks “Refresh” in Vercel is a developer who is going to see “Invalid Configuration” for the next few minutes. The fix is to wait for the TTL to expire (usually 5–60 minutes, depending on the registrar’s default), and to verify with dig that the records have propagated before asking Vercel to refresh.
The four pitfalls are the floor. There are also pitfalls from the registrar stripping the leading underscore in the TXT record, from the registrar’s UI hiding the TTL field, from the registrar’s nameservers not being the ones the developer thinks they are, and from the developer accidentally using the wrong domain (a typo, a co.uk vs. com). The four are the ones the developer will see most often.
The way the apex vs. www split shapes the setup
The apex (example.com) and the www subdomain (www.example.com) are two distinct DNS records, and the developer has to make a choice about which one is the canonical URL. The choice shapes the rest of the setup, and the choice is the part the developer has to know to avoid a 30-minute debugging session.
The “apex is canonical” pattern. The apex (example.com) is the primary URL, and www redirects to the apex. The pattern is the right answer for a project that wants a clean URL, and the pattern is the one most marketing sites use. The DNS setup is A record for the apex, CNAME for www, and a 301 redirect from www to the apex in Vercel’s settings.
The “www is canonical” pattern. The www subdomain is the primary URL, and the apex redirects to www. The pattern is the right answer for a project that has a www cookie, a www CORS policy, or a www CSP rule. The DNS setup is the same (A for apex, CNAME for www), but the 301 redirect is from the apex to www.
The “both work” pattern. Both the apex and the www serve the same content, and there is no redirect. The pattern is the right answer for a project that does not care about canonical URLs, and the pattern is the one that has the worst SEO implications (Google sees two URLs for the same content). The DNS setup is the same, and the redirect is not set in Vercel’s settings.
The three patterns are the floor. There is also the “apex is a parking page, www is the real site” pattern (common for projects that have not migrated the apex yet), and the “apex redirects to a different domain” pattern (common for projects that have been acquired). The three are the ones the developer should know first.
The five registrars a developer will see most often
A short, opinionated list of the registrars a developer will see most often. The five are the ones the developer should know the DNS panel path for, and the five are the ones the developer should know how to add records in.
Namecheap. The DNS panel is at “Advanced DNS” in the domain management. The panel shows the current records, has an “Add New Record” button, and supports A, AAAA, CNAME, MX, TXT, and other record types. The panel is one of the cleanest, and the panel is the one the developer will navigate fastest.
Cloudflare. The DNS panel is at “DNS” → “Records” in the domain management. The panel shows the current records, has an “Add Record” button, and supports all record types. Cloudflare also has “CNAME flattening” which allows a CNAME at the apex (a feature Vercel does not require but which can simplify the setup for some users).
Google Domains (now Squarespace Domains). The DNS panel is at “DNS” in the domain management. The panel is clean and straightforward, and the panel supports all record types. The migration to Squarespace has not changed the panel significantly.
GoDaddy. The DNS panel is at “DNS” → “Manage Zones” in the domain management. The panel is the most cluttered of the five, and the panel has a “Quick Add” button that adds multiple records at once (useful for Vercel’s three records). The panel is the one a developer will navigate slowest.
Porkbun. The DNS panel is at “Details” → “DNS Records” in the domain management. The panel is the simplest of the five, and the panel has an “Add Record” button that supports all record types. The panel is the one a developer will navigate second-fastest.
The five registrars are the floor. There is also Hover, OVH, Gandi, and many others. The five are the ones a developer will see most often in real projects.
How this fits the rest of the stack
A custom domain rarely lives in isolation. The custom domain usually points at a Vercel project that is part of a stack (a database, an API, a worker, a static site). The platform that handles the rest of the stack should make the developer feel like the pieces are in the same conversation.
The services layer is the part of the platform that runs the long-lived API the Vercel project calls. The database layer is the part that holds the data the Vercel project reads and writes. The static layer is the part that hosts the dashboard the developer uses to manage the project. The environment variables are the part that holds the secrets the Vercel project reads at build time.
A Vercel project on a platform where the service, the database, the storage, and the secrets are all in the same place is a project the team is going to be able to manage. A Vercel project on a platform where each piece is in a different console is a project the team is going to spend the first hour just opening the right tab.
For a team that wants to see the full cost of the project before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the static site, the domain, the TLS — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
FAQ
How do I connect a Vercel project to a third-party domain?
Add the domain to the Vercel project’s Domains panel, copy the three DNS records Vercel gives you (an A record for the apex, a CNAME for the www, and a TXT for verification), paste the records into the registrar’s DNS panel, wait for the DNS to propagate, and let Vercel verify. The flow is the same for Namecheap, Cloudflare, GoDaddy, Google Domains, and Porkbun — the registrar’s UI is the only thing that changes.
Why is my Vercel domain showing “Invalid Configuration”?
The most common causes are: the A record is pointing at the wrong IP, the CNAME target is misspelled, the TXT verification record is missing, the www is not added, or the DNS has not propagated yet. The fix is to verify each of the four with dig or nslookup before asking Vercel to refresh.
How long does it take for a Vercel domain to start working?
The DNS propagation is usually seconds to minutes for a low TTL, or up to 48 hours for a high TTL. Vercel’s verification usually takes a few minutes after the DNS has propagated. The TLS certificate is usually issued within minutes of verification, and the green padlock appears in the browser immediately. The full setup is usually done in under an hour.
Can I use a third-party domain on Vercel for free?
Yes. The free Vercel plan supports custom domains — there is no per-domain fee. The developer only pays for the registrar (Namecheap, Cloudflare, etc.) and for the Vercel plan (free, Pro, or Enterprise). The pattern is the right answer for a developer who wants a custom domain on a free Vercel plan.
Can I move my Vercel project to a different domain?
Yes. The developer adds the new domain to the Vercel project’s Domains panel, removes the old domain, and the new domain becomes the canonical URL. The DNS records at the registrar’s panel need to be updated to point at the new domain. The pattern is the right answer for a project that has rebranded or moved to a new domain.
What is the difference between an A record and a CNAME record?
An A record maps a domain to an IPv4 address. A CNAME record maps a domain to another domain name. The apex (example.com) requires an A record because CNAME records are not allowed at the apex by DNS spec. Subdomains (www.example.com, app.example.com) can use either an A record or a CNAME record, and a CNAME is preferred when the target is a load balancer that may have multiple IPs.
How do I redirect www to the apex (or vice versa) on Vercel?
In the Vercel project’s Domains panel, click the www domain, and select “Redirect to apex” or “Redirect to www.” Vercel will set up a 301 redirect that sends all traffic from the source domain to the target domain. The pattern is the right answer for a developer who wants one canonical URL for SEO purposes.