Vercel Custom Domain Not Working: DNS, SSL, Redirect Checklist

The deployment works on its vercel.app URL, but your own domain shows "Invalid Configuration", times out, throws a certificate error, or bounces between redirects. "Custom domain not working" covers at least five different failures, and the fix for one makes another worse. This post puts them in the order I would check them.

Everything about Vercel below comes from its domain documentation as read in November 2026 (the troubleshooting page was last updated in September 2026). I'm not describing incidents of my own; this is a checklist built from the docs, and DNS details change, so confirm against the dashboard.

Step 0: separate the domain from the deployment

Open the generated vercel.app URL of the same deployment. If it works, the build is fine and the problem is the domain: DNS, certificate, or assignment. If it doesn't, you have a deployment problem, not a domain problem (the 404 case is covered in my post on NOT_FOUND after deployment).

Vercel's own first list is short: is the domain added to the project, does it point at the CNAME or A record Vercel provided (check with dig), and is the problem only local to you (clear the browser cache, flush DNS caches).

Step 1: use the records your project shows, not a copied value

Vercel expects either an A record or a CNAME record. The documentation is explicit that the exact values are in the project under Settings > Domains, tailored to the project and plan.

• Apex domain (example.com): an A record. A CNAME at the apex would conflict with other records that must live there, such as NS and usually MX; the docs cite RFC 1034 for this.
• Subdomain (www.example.com): a CNAME record. Each project has its own target value.

Vercel assigns anycast addresses per project, so the A value can differ between projects. The docs warn that an address copied from another project or an old tutorial can leave the domain on DNS Change Recommended, DNS Change Required or Invalid Configuration. This is the single most common reason I'd expect a copy-pasted guide to fail: use what your dashboard shows today.

Also remove outdated records. For an apex, the docs say to delete other A or AAAA records before adding the new one. A leftover record for the same hostname is a classic cause of intermittent behavior.

Syntax mistakes the docs call out

• Name field: it should hold the prefix (www), not the full hostname. Vercel's own DNS form strips the domain if you paste the full name; other providers may not behave the same way.
• Trailing period on a CNAME value: the target Vercel gives you ends with a period, which marks a fully qualified name. Copy the value exactly, period included.

Verify from the terminal

dig A example.com +short
dig CNAME www.example.com +short
curl -IL https://example.com

The dig answers should match the values in Settings > Domains, and curl should finish over HTTPS at your primary domain. Vercel also lists dig ns example.com for checking nameservers.

Step 2: wait the right amount of time

The docs say changes to ordinary records (A, CNAME, TXT) typically propagate quickly, depending on the previous TTL, while a nameserver change can take up to 24 to 48 hours. During that window different visitors can see different things. If the site works on your phone's mobile data but not at home, a stale cache is plausible.

A tip from the same page: before switching, lower the existing record's TTL (they suggest something like 60 seconds), wait out the old TTL, then change the record. That makes rolling back fast. Raise the TTL again afterwards.

Vercel also states it does not support IPv6 yet, so you can't point an AAAA record at it for a third-party domain.

Step 3: "domain is in use by another account"

A domain can only be associated with one personal account or team at a time. If adding it fails with "Another Vercel account is using this domain", the docs give two paths:

• You can access the other account: transfer the domain to your current one from the Domains dashboard.
• You own the domain but not the other account: use Connect External and add the TXT record you're given to verify ownership.

For ordinary verification when the domain is in use elsewhere, Vercel asks for a TXT record, always at _vercel on the apex domain. This doesn't move the domain into your account. Remove the domain from a project and add it again and Vercel generates a new value, so update the record.

Step 4: certificate problems

If DNS is right but HTTPS isn't, the certificate is the next suspect. For non-wildcard domains Vercel uses the HTTP-01 challenge by default, and it handles it automatically as long as the domain actually points to Vercel. So bad DNS and a missing certificate are often the same problem.

Things the docs list:

• CAA records. Having no CAA records doesn't block issuance. If your policy restricts issuers, authorize Let's Encrypt with 0 issue "letsencrypt.org". Lookups climb to the parent name if the hostname has none, and the closest policy wins; they aren't combined. Check with dig CAA example.com +noall +answer.
• A CNAME can't coexist with a CAA record at the same hostname. If you need your own CA policy, the docs suggest replacing the CNAME with an A record.
• Wildcards need DNS-01 validation, so use Vercel's nameservers, or delegate the _acme-challenge subdomain by NS records if you can't switch.
• Reserved path: /.well-known can't be redirected or rewritten.

For ERR_SSL_PROTOCOL_ERROR, compare the failing hostname with the vercel.app URL in the same browser, then try another device and network. The docs note that a corporate or school network can fail on TLS inspection or filtering, which no setting on your side fixes.

Step 5: a proxy in front of Vercel

If you proxy through Cloudflare or similar, you've added a layer that can break both issuance and routing. Vercel says it does not recommend a reverse proxy in front of a project. If you do use one, route /.well-known/acme-challenge/* to Vercel on port 80 without caching, authentication, rewrites or redirects, or simply use DNS only.

The redirect loop (ERR_TOO_MANY_REDIRECTS) has a documented common cause: Cloudflare's Flexible SSL/TLS mode. The browser reaches Cloudflare over HTTPS, Cloudflare reaches Vercel over HTTP, Vercel redirects HTTP to HTTPS, and the loop begins. Vercel's HTTP-to-HTTPS redirect can't be disabled; the docs say to use Full (strict) with a valid origin certificate. If the loop continues, check your app's own redirects and domain redirects for conflicting targets.

Step 6: www, apex and redirects

If the apex works and www doesn't (or the reverse), you likely added only one. Add both to the project and set a redirect from one to the other under Settings > Domains > Edit > Redirect to. Vercel suggests www as the primary and the bare domain redirecting to it, because a CNAME gives its CDN more control than a fixed A record. Redirecting the other direction works too.

Once a domain is configured it applies automatically to the latest production deployment. A domain assigned to a different branch needs a new deployment on that branch before it resolves.

Order of checks

1. Does the vercel.app URL work? If not, it's not a domain problem.
2. Is the domain added to the project, with the records from Settings > Domains?
3. dig the records; remove stale ones; check name field and trailing period.
4. Allow for propagation, longer for nameserver changes.
5. Domain in use elsewhere? TXT at _vercel or Connect External.
6. Certificate: CAA, challenge path, wildcard method.
7. Proxy: DNS only, or Full (strict).
8. Add both apex and www, then set the redirect.

Summary

A domain that doesn't work on Vercel is almost always one of: wrong or stale DNS records, an ownership conflict, a certificate that couldn't be issued, or a proxy in between. The fastest way to stop guessing is to test the generated vercel.app URL first, then compare dig output with the values your own dashboard shows. Don't reuse records from another project or an old guide.