Fix Vercel Domain “Invalid Configuration”
Vercel’s Invalid Configuration label means the public domain setup does not yet satisfy what the assigned project expects; it does not identify one universal DNS mistake.
Add the hostname to the correct Vercel project, open its domain details, and use the exact records returned there or by `vercel domains inspect`. Vercel’s current general examples use an apex A record of 76.76.21.21 and a subdomain CNAME to cname.vercel-dns-0.com, but project-specific recommendations can differ. Remove conflicting records only for the affected hostname, verify authoritative DNS, and then recheck redirects, CAA, and HTTPS.
This guide diagnoses Vercel Invalid Configuration in dependency order: project ownership, hostname type, dashboard-required DNS, duplicate or stale routes, nameserver authority, propagation, certificate policy, and final canonical redirects. It treats the project dashboard as authoritative and separates domain configuration from application deployment or SPA routing errors.
Quick Questions
It means Vercel cannot confirm that the hostname’s current DNS configuration matches the domain requirements of the assigned project.
Use the exact value shown for that domain in the Vercel project or by vercel domains inspect. General examples are not a substitute for project-specific output.
No. Propagation only distributes the value you published. Compare the authoritative record before waiting.
Read the symptom before changing DNS
| Observed symptom | Most useful next check |
|---|---|
| Invalid in project settings | Inspect the exact required record and project assignment |
| Record looks correct but public lookup differs | Confirm authoritative nameservers and DNS host |
| Apex works but www fails | Add and assign www separately |
| Vercel domain is valid but a deep route returns 404 | Diagnose application routing, not domain DNS |
| DNS is valid but HTTPS fails | Review CAA, proxy behavior, and certificate status |
See which AI crawlers actually reach your website.
Track visits from GPTBot, ClaudeBot, PerplexityBot, search bots, and other discovery agents-then see which public pages attract their attention.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
Main Explanation
Begin inside Vercel, not at the registrar. Confirm that the full hostname is attached to the intended project and team. The apex, www, app, and wildcard versions are different domain assignments. A deployment can work perfectly on its vercel.app address while the custom hostname remains invalid because it was added to another project, transferred between teams, or never added at all.
Open the domain details or run `vercel domains inspect` for the hostname. Vercel’s current setup guide provides 76.76.21.21 as a general apex A example and cname.vercel-dns-0.com as a general subdomain CNAME example, but it explicitly tells users to inspect the domain for its recommended records. Copy that output rather than relying on a screenshot, cached article, or a record from a different project.
Identify the authoritative DNS provider before editing. The registrar can sell the domain while another service hosts its DNS through nameservers. If you edit a zone that is not authoritative, the public internet will continue returning the old records and Vercel will remain invalid. Check the domain’s NS records, then make the change in the provider those nameservers identify.
Review only the affected hostname for conflicts. An apex can retain old A or AAAA records from a previous host. A subdomain can retain a CNAME, forwarding rule, or wildcard behavior that sends it elsewhere. Do not delete MX, DKIM, SPF, or unrelated verification records. The goal is one unambiguous website route for the hostname, not an empty DNS zone.
Apex and subdomain configuration are not interchangeable. A normal CNAME is commonly used for www or another subdomain, while an apex may need an A record, Vercel nameservers, or supported flattening behavior. Wildcard domains can have additional nameserver requirements. Follow the project’s displayed method and do not add both the DNS-record method and nameserver method without understanding which provider is authoritative.
Verify the public answer after saving. Query the apex and requested subdomain separately and compare the returned A, AAAA, or CNAME values with Vercel’s current requirement. A local cache can lag, but authoritative DNS shows whether the source zone is correct. If the authoritative answer is wrong, waiting is not the fix; if it is correct and recursive resolvers differ, propagation is the remaining stage.
When routing matches but HTTPS still fails, inspect certificate blockers separately. Restrictive CAA records can prevent a supported certificate authority from issuing, while stale DNS or an unintended proxy can prevent validation. Avoid turning off security controls blindly. Compare the domain status and Vercel troubleshooting output, then change only the policy that conflicts with the documented certificate path.
Finish by testing HTTP, HTTPS, apex, and www as separate requests. Choose one preferred hostname and redirect alternatives to it. Update canonical tags, sitemap entries, OAuth callbacks, analytics, and Search Console to the production domain. Then scan the live URL with TruboRankAI for crawlability, metadata, sitemap, AEO, GEO, and AI-discoverability gaps; a valid Vercel domain alone does not guarantee indexing or traffic.
Practical Steps
- Confirm the hostname belongs to the intended Vercel project and team.
- Inspect the exact domain requirement in Vercel.
- Identify the authoritative DNS provider.
- Remove conflicting website routes on the affected hostname.
- Publish the project-specific apex or subdomain value.
- Verify authoritative and recursive DNS separately.
- Check CAA and HTTPS only after routing matches.
- Set one canonical host and audit the production URL.
Stop guessing whether AI crawlers see your best pages.
Use crawler activity as an early discovery signal, identify pages that receive attention, and find important pages that may need a clearer path.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
Turn AI crawler visits into a repeatable visibility workflow.
Monitor discovery over time, compare activity across important pages, and use the evidence to decide what deserves attention next.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
FAQ
Why is Vercel still invalid after I changed DNS?
You may have edited a non-authoritative DNS zone, used a general value instead of the project requirement, left a conflicting route, or be seeing cached recursive DNS.
Should I remove every existing DNS record?
No. Remove only conflicting website records for the hostname. Preserve mail, DKIM, SPF, and unrelated verification records.
Is a Vercel 404 the same as Invalid Configuration?
No. Invalid Configuration concerns domain assignment or DNS. A 404 after the domain is valid can come from a missing deployment route or SPA rewrite.
Sources and methodology
The guide separates domain assignment, authoritative DNS, routing, certificate policy, and application behavior using Vercel’s official domain documentation reviewed on 2026-08-16. Exact project output overrides general examples. The process improves launch readiness but does not guarantee indexing, rankings, citations, or traffic.
These references support the changeable facts and study findings discussed above. Results depend on each source's sample, date, market, query set, and measurement method.