How to Resolve DNS Record Conflicts in cPanel Zone Editor (A, CNAME, TXT)

DNS record conflicts are one of the most common stumbling blocks when connecting a third-party service to your domain. This guide explains why they happen, how to spot them in cPanel Zone Editor, and how to resolve them without breaking your email or other services.

Why a CNAME cannot share a hostname with any other record

A CNAME (Canonical Name) record works by telling DNS resolvers to look up a completely different hostname for all queries at that label. Because it redirects every query type - A, MX, TXT, and everything else - the DNS standard (RFC 1034) forbids any other record from existing at the same hostname as a CNAME.

In practice this means:

• If mail.example.com already has an A record pointing to your server IP, you cannot add a CNAME for mail.example.com.
• If example.com itself has an A record (as it almost always does), you cannot add a CNAME at the bare domain (@) - this is sometimes called the "CNAME at apex" problem.
• If a TXT record exists at docs.example.com alongside an A record, adding a CNAME there will still fail because the A record is present.
• MX records at a hostname also block a CNAME at that same label.

The rule is simple: a hostname can have a CNAME record or any other record type, never both.

Checking your existing records in cPanel Zone Editor

Before you add any new record, check what is already at the hostname you want to use.

1. Log in to cPanel. If you are not sure how, see How to login to cPanel.
2. In the Domains section, click Zone Editor.
3. Click Manage next to the domain you want to work with.
4. You will see a full list of every DNS record for that domain. Use the Filter box at the top to type in the hostname you are interested in - for example, type docs to find all records at docs.example.com.
5. Note the Type and Record columns for each matching row. If you see an A, TXT, or MX record at the hostname where you want to add a CNAME, you have a conflict to resolve.

For a broader introduction to what each record type does, see An Introduction to DNS Record Types.

Understanding which conflicts are safe to remove

Not every conflicting record can simply be deleted. Before you remove anything, understand what it is doing.

A records at a subdomain (for example shop.example.com) usually point that subdomain to a server IP. If you are replacing that subdomain with a third-party service, removing the A record and adding a CNAME is safe. If the subdomain is used for email (for example as a mail server hostname), do not remove it.

TXT records are often used for domain verification, SPF, DKIM, or DMARC. A TXT record at docs.example.com does not conflict with a CNAME at docs.example.com in the same way an A record does - but an A record at the same label will still block the CNAME regardless of whether a TXT record is also present. Remove the A record first; the TXT record issue is secondary.

MX records live at the domain apex (@) or occasionally at a subdomain. Never remove MX records unless you are deliberately rerouting email. Adding a CNAME at a label that has MX records is not permitted by the DNS standard.

CNAME records that already exist at the hostname simply need to be edited to point to the new target, rather than adding a duplicate.

How to remove or rename a conflicting record

Removing a conflicting A record at a subdomain

1. In Zone Editor, locate the A record at the conflicting hostname.
2. Click Delete on that row.
3. Confirm the deletion when prompted.
4. You can now add your CNAME at that hostname.

Renaming a subdomain to free up the hostname

If the existing A record is serving a real purpose and you do not want to lose it, consider using a different subdomain for your CNAME. For example, if shop.example.com already has an A record, ask the third-party service whether they can accept store.example.com instead.

Editing an existing CNAME

If a CNAME already exists at the hostname but points to the wrong target:

1. Locate the CNAME row in Zone Editor.
2. Click Edit.
3. Update the Record field to the new target hostname provided by the third-party service. Make sure it ends with a full stop (for example verify.mailchimp.com.) - cPanel adds this automatically if you omit it.
4. Click Save Record.

Adding CNAME records for common third-party services

The steps below follow the same pattern for any service. We use Google Workspace and Mailchimp as examples.

Google Workspace domain verification

Google Workspace asks you to verify domain ownership by adding a TXT record at the apex (@), not a CNAME. However, it also asks you to add several CNAME records for services such as Google Mail, Calendar, and Drive. These CNAMEs use subdomains like mail, calendar, and drive, which are unlikely to conflict unless you have previously set up those subdomains yourself.

1. In Zone Editor, filter for mail, calendar, and drive in turn.
2. If any of those subdomains already has an A record pointing to your Kualo server, delete it - those subdomains will no longer serve content from your hosting once you point them to Google.
3. For each CNAME Google provides, click Add Record in Zone Editor, set the Type to CNAME, enter the subdomain in the Name field, and paste Google's target hostname into the Record field.
4. Leave TTL at the default (3600 seconds) unless you have a specific reason to change it.

For the MX records that route your email to Google Workspace, see Point email to Google Workspace (Google Apps). Do not confuse the MX records (which go at @) with the CNAME records (which go at subdomains) - they serve different purposes and do not conflict with each other.

Mailchimp audience domain authentication

Mailchimp provides two CNAME records for DKIM authentication, typically at subdomains like k1._domainkey and k2._domainkey. These subdomains are almost never used for anything else, so conflicts are rare. If they do exist, delete the conflicting A or TXT records at those labels before adding the CNAMEs.

1. In Zone Editor, click Add Record.
2. Set Type to CNAME.
3. In Name, enter the subdomain exactly as Mailchimp shows it (for example k1._domainkey).
4. In Record, paste the target hostname Mailchimp provides.
5. Repeat for the second CNAME.

For MailMachine domain authentication, which follows a similar pattern, see Authenticate your sending domain.

Other third-party services

Most services follow the same pattern: they give you a subdomain and a target hostname. The process is always:

1. Check whether that subdomain already has any records in Zone Editor.
2. Remove any A records at that subdomain if the subdomain is no longer needed for hosting.
3. Add the CNAME with the subdomain as the Name and the service's hostname as the Record.

TTL guidance

TTL (Time to Live) controls how long DNS resolvers cache a record before checking for updates. A lower TTL means changes propagate faster; a higher TTL reduces DNS query load.

• Default (3600 seconds / 1 hour) is fine for most new records you are adding for the first time.
• Lower TTL (300 seconds / 5 minutes) is useful if you are about to make a change and want it to take effect quickly. Set it 24-48 hours before you plan to make the change, so existing caches expire in time.
• Higher TTL (86400 seconds / 24 hours) is appropriate for stable records that never change, such as your root A record.

For a full explanation of how TTL affects DNS changes, see What is TTL and How Does It Affect DNS Changes?.

After you save any DNS change, allow time for propagation before testing. See What is DNS Propagation and How Long Does It Take? for what to expect.

If something goes wrong

If you delete a record by mistake, you may be able to restore it from a DNS zone backup. See Restoring a DNS zone backup in cPanel for how to do this.

If you are unsure whether a record is safe to remove, or if your domain's DNS is managed outside cPanel (for example at Cloudflare or your registrar), see Pointing Your Domain to Kualo Without Changing Nameservers for context on where your DNS is authoritative.

If you get stuck, raise a support ticket and we will help you work through the conflict safely.