A CNAME record conflict subdomain troubleshooting process helps explain why a subdomain will not point to the service you selected. The cause is often simple: a CNAME cannot share the same hostname with most other record types.
However, DNS control panels can hide details behind friendly labels. A provider may also require an exact target, a verification record, or a special setup for the root domain. This guide explains the rules, the common errors, and a safe way to confirm the final result.
What a CNAME record does
CNAME means canonical name. It creates an alias from one DNS name to another name. For example, portal.example.com might point to customer.hosting-provider.example.
When a resolver asks for the alias, DNS follows the CNAME and continues looking up the target name. The target may then return an address record, such as an A or AAAA record. Your browser eventually connects to the address returned for that target.
A CNAME points to a name, not directly to an IPv4 or IPv6 address. Therefore, enter the provider’s hostname in the target field. Do not replace it with an IP address unless the provider specifically instructs you to use an A or AAAA record.
For background on nameservers, resolution, and DNS record behavior, see Cloudflare’s DNS overview. The exact interface varies, but the underlying model remains the same.
Why a CNAME conflicts with another record
The central rule is straightforward: a hostname with a CNAME should not also have other data records. That includes A, AAAA, MX, TXT, NS, and many provider-specific records.
Suppose app.example.com already has an A record. Adding a CNAME for app.example.com creates two different instructions for the same name. A compliant DNS service should reject the combination or require you to remove the earlier record.
This rule differs from having several A records for one hostname. Multiple A records can support address rotation or redundancy. A CNAME, by contrast, delegates the name to another name and therefore cannot coexist with those records at that label.
A control panel may describe the problem as a duplicate record, invalid configuration, conflicting record, or existing resource record. These messages describe the same basic issue. The next step is to inspect every record at the exact hostname, not just the record you intended to add. This is the core of CNAME record conflict subdomain troubleshooting.
Common CNAME errors on subdomains
Leaving an old A or AAAA record in place
This is the most common mistake. A previous website, application, or proxy setup may have created an A record. Adding a CNAME without removing that record causes a conflict.
Check both IPv4 and IPv6 entries. An AAAA record can remain unnoticed because some dashboards group it under advanced settings. Remove it only after confirming that the subdomain no longer needs the old destination.
Using the wrong provider target
Hosting and SaaS providers often assign a specific hostname for each customer or service. The target may include a required region, account identifier, or trailing dot in the provider’s documentation.
Copy the target exactly. Do not guess from a general help article, and do not use the provider’s main website address unless its instructions say to do so. A syntactically valid target can still lead to the wrong service.
Adding a CNAME to the wrong label
The record name must match the requested subdomain. If the provider asks for www, create the record at www.example.com. If it asks for status, do not place the record at the root domain.
Many DNS dashboards automatically append the domain name. In those systems, entering the full name can accidentally create a longer hostname. Review the dashboard’s displayed result before saving.
Confusing verification records with routing records
A provider may request a TXT record to prove domain control and a CNAME to route a subdomain. These records usually belong at different names. Follow the provider’s labels carefully.
Never remove an unrelated TXT, MX, or verification record just to make a form accept a new entry. A conflict at one subdomain does not justify changing email records or records for another service.
Why the apex domain needs special treatment
The apex, or root domain, is example.com without a host label such as www. Traditional DNS rules do not allow a normal CNAME at the apex because the zone needs other records there, including authoritative NS and usually SOA records.
Some DNS providers offer an ALIAS, ANAME, or CNAME flattening feature. These features can present CNAME-like behavior at the root while managing the underlying DNS requirements. They are provider-specific and do not behave identically everywhere.
For that reason, do not copy a subdomain CNAME instruction to the apex. First determine whether the provider supports an apex feature. Otherwise, use the A or AAAA addresses supplied for the root domain, if available.
The ICANN overview of the Domain Name System provides useful context about domain delegation and nameservers. Your DNS host’s documentation still controls the available record features.
A safe CNAME record conflict subdomain troubleshooting sequence
1. Record the intended change
Write down the full hostname, record type, target, provider instructions, and current value. Note whether the change affects a live website, application, redirect, or certificate.
Capture the current DNS entries before editing. A screenshot or exported zone file can support rollback. Also record the DNS provider and the authoritative nameservers listed for the domain.
2. Inspect the exact hostname
Search the DNS zone for the requested label. Look for A, AAAA, CNAME, TXT, MX, NS, and any synthetic records. Some dashboards show records in separate tabs, so check advanced or imported entries too.
Do not confuse a record at example.com with one at app.example.com. DNS names are specific labels. A record at the parent domain does not automatically create a CNAME conflict at every subdomain.
3. Compare the provider’s instructions
Confirm the requested record name and target from the provider’s current setup page. Check whether the service needs an additional TXT record or asks you to activate the hostname inside its own portal.
Some services require the CNAME before they issue a certificate or enable traffic. Others expect a CNAME only for verification and use a separate address for production traffic. Treat those as different tasks.
4. Remove only the incompatible record
If the subdomain should now use a CNAME, remove the old A or AAAA record at that same label. Avoid broad cleanup. Preserve records for email, unrelated subdomains, and active services.
Before saving, confirm that you are editing the authoritative DNS provider. A registrar, hosting panel, CDN, and DNS service may all display different record screens.
5. Verify authoritative data
Check the authoritative nameserver directly when possible. A public resolver may still show cached data from before the change. Authoritative results tell you what the zone currently publishes.
Then check the hostname through one or more normal resolvers. Compare the CNAME target and any resulting address records. A successful lookup does not prove that the application accepts the hostname, so continue with an application test.
For a broader diagnostic model that separates DNS, network, and application faults, review DNS, network, and application troubleshooting. That layered approach also supports CNAME record conflict subdomain troubleshooting when DNS appears correct but the service still fails.
Verification tools and evidence
Use tools that show record type and answer details. On many systems, dig can query a specific name and type:
dig CNAME app.example.com
dig A app.example.com
dig AAAA app.example.comRemove the leading space before the second command if you paste this into a shell. On Windows, nslookup can provide similar information. Your hosting dashboard may also include a record checker.
When possible, query the authoritative nameserver named in the domain’s delegation. Then compare that result with a public resolver. Differences may reflect caching, split DNS, or a zone that is not hosted where you expected.
Keep evidence: the timestamp, queried name, server used, response, and application result. This record helps distinguish a DNS publication problem from a provider-side configuration problem.
Changes may take time to appear because resolvers cache answers according to TTL values. The DNS TTL timing guide explains why different users can see different results temporarily.
Application checks after DNS resolves
Once the CNAME appears correctly, test the actual service. Open the intended HTTPS hostname, check redirects, and confirm that the service presents a certificate covering that hostname.
A DNS answer can be correct while the application returns an error. Common causes include an unregistered custom domain, a missing virtual host, an inactive site, an incorrect proxy mode, or a certificate that has not finished issuing.
That final application check completes CNAME record conflict subdomain troubleshooting for the hostname.
If HTTPS reports a name mismatch, investigate the certificate and server configuration separately. DNS only directs the request; it does not automatically configure the web server or certificate.
Also test from the user’s normal network. Corporate DNS filtering, split-horizon DNS, or cached local answers can make one location behave differently from another.
Preventing future CNAME conflicts
- Keep one current DNS inventory with record names, types, targets, owners, and purposes.
- Use a change note for every live DNS edit.
- Confirm the authoritative nameservers before making a change.
- Use provider targets copied from the service’s setup instructions.
- Review both A and AAAA records before adding a CNAME.
- Separate verification records from traffic-routing records.
- Plan rollback using the saved previous value.
- Test DNS and the application after each change.
For more complex zones, a record inventory can expose stale entries before they become incidents. The guide to finding conflicting DNS records offers a related review process.
When to get help
A CNAME change is usually small, but its impact can be broad when a live website, SaaS platform, proxy, or certificate depends on it. Stop before deleting records if ownership is unclear or the zone contains several active services.
Tech Rescue Ops LLC can help review the intended design, verify authoritative DNS, document the change, and test the service without unnecessary edits. Professional remote assistance is appropriate when the provider’s instructions conflict, the apex requires special handling, or DNS results differ across networks.