Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Unexpected DNS records

Additional records after import

You find several unexpected DNS records after adding your domain to Cloudflare.

Cause

A wildcard (*) record at your previous authoritative DNS provider may have been imported into Cloudflare in a way that creates additional records.

Solution

To solve this issue, you can do one of the following:

acme_challenge TXT records

You might notice TXT records like _acme-challenge.<hostname> are returned by your domain but cannot be found on the Cloudflare dashboard.

Cause

These records are automatically created to allow Cloudflare edge certificates (universal, advanced, and backup) to be provisioned. _acme-challenge records are required by certificate authorities (CAs) so that they can verify your domain ownership before issuing the SSL/TLS certificate. For details, refer to Domain control validation (DCV).

Solution

As these records are tied to the certificates, they cannot be deleted via the Cloudflare dashboard.

If you need more _acme-challenge.<hostname> TXT records in order to provision certificates on your side, you can manually add them under DNS records ↗.

If you want to remove these records:

_dc-mx and dc-##### subdomains

You notice a _dc-mx or dc-##### subdomain that you did not create (for example, _dc-mx.a1b2c3d4e5f6.example.com). This response does not appear in your Cloudflare DNS records table, but will appear in dig responses.

Cause

When your MX or SRV record resolves to a domain configured to proxy through Cloudflare, Cloudflare dynamically inserts a record into DNS responses that resolves to the origin IP address. This record is added at query time to ensure that mail or service traffic bypasses the Cloudflare proxy and reaches your server directly.

The prefix of the auto-generated record depends on the record type that triggered it:

  • MX records: Cloudflare inserts a record with the _dc-mx prefix (for example, _dc-mx.a1b2c3d4e5f6.example.com).
  • SRV records: Cloudflare inserts a record with the dc- prefix (for example, dc-a1b2c3d4e5f6.example.com).

How _dc-mx records work

Before using Cloudflare, suppose your DNS records for mail are as follows:

example.com MX example.com

example.com A 192.0.2.1

After using Cloudflare and proxying the A record, Cloudflare provides DNS responses with a Cloudflare IP address (203.0.113.1 in the example below):

example.com MX example.com

example.com A 203.0.113.1

Since proxying mail traffic through Cloudflare would break your mail services, Cloudflare detects this situation and dynamically inserts a _dc-mx record into DNS responses:

example.com MX _dc-mx.a1b2c3d4e5f6.example.com

_dc-mx.a1b2c3d4e5f6.example.com A 192.0.2.1

example.com A 203.0.113.1

You can verify this behavior by querying your domain's MX records (replace example.com with your domain):

Terminal window
dig example.com mx +short
100 _dc-mx.a1b2c3d4e5f6.example.com.

The _dc-mx record resolves directly to your origin IP:

Terminal window
dig _dc-mx.a1b2c3d4e5f6.example.com a +short
192.0.2.1

Solution

These records are safe — they ensure your mail traffic reaches your server correctly.

If you want to avoid a _dc-mx or dc-##### response, you must address the underlying proxy conflict:

  • If no mail is received for the domain, delete the MX record.

  • If mail is received for the domain, update the MX record to resolve to a separate A record for a mail subdomain that is not proxied by Cloudflare:

    example.com MX mail.example.com

    mail.example.com A 192.0.2.1

    example.com A 203.0.113.1

Incorrect results for DNS queries

You notice DNS queries returning incorrect results even after you waited for the TTL to expire.

Cause

Third-party tools can sometimes fail to return correct DNS results if a recursive DNS cache fails to refresh.

Solution

In this circumstance, purge your public DNS cache via these methods: