State of the domain CNAME records

Something is not clicking with our domain, particularly when it comes to records. I’m trying to figure out things but have little experience with domains. The domain is hosted by a 3rd party but about 2 weeks ago we moved the records to a Cloudfare account. I have access to both the cpanel and the Cloudfare console. I’m trying to figure out a couple of things.
1 - The main problem is with the CNAME records as the hosting company is telling me that everything is OK but I’m not sure. This is what Cloudfare shows:

However, I’ve tried several tools (MxToolbox, dnschecker and NsLookupo) and all of them state that www.domain and mail.domain are either not found or not active, whereas ‘’ is working properly. Here, I don’t know if this is caused by the latter showing as ‘DNS only’ and the former two appear as proxied. My question is whether things are fine (as claimed by the hosting company) or if some action is required (as I suspect).
2 - The cpanel shows a total of 20 records but Cloudfare lists an extra TXT record for the domain with the content
v=spf1 +mx +a +ip4: +ip4: +ip4: ~all
This was added per the suggestion of the newsletter company that we are working with. What I don’t understand is why it doesn’t shows in the cpanel. Maybe this is not that important, but I want to make sure that everything is set up optimally.


Thank you for asking.

In terms of e-mail, usually the MX record should point to a hostname such as mail , and the A (or CNAME ) type record for that hostname should be set to :grey: (DNS Only).

Steps needed to fix an issue with e-mail functionallity while using Cloudflare:

  1. Remove CNAME mail
  2. Add new A mail and point it to your email/hosting IP address
  3. Check your MX and make sure it’s target is set (pointed to) hostname

May I suggest checking below article if your e-mail records (usually the A mail and the MX record) are configured properly while you are using Cloudflare for your domain name:

Both CNAME www is okay → :orange: and CNAME bmdeda._domainkey is okay - :grey: as it should be.

1 Like

Hi @fritex. Thanks for the feedback. Just for clarification, there has been no issue sending/receiving emails from the different domain accounts. The only problem (that we are aware of) has been sending a newsletter (through another company) as some of the newsletter emails never reached any inbox whereas others reached their destinations and a few went to spam folders. That is what prompted me to check that everything related to the domain and its records is working properly.

Thank you for feedback.

But you still have an issue with e-mail, please do as instructed from my previous post :point_up: to remove the possible issues.

Furthermore, regarding your newsletter service, I can see multiple TXT records for SPF → that’s the issue:

You would have to “combine” two “SPF” records into one, or rather as I check more in detail, kindly remove the one of them and leave the other to fix this “newsletter bouncing/SPAM issue” which you are experiencing:

;ANSWER 300 IN TXT "MS=ms28941301" 300 IN TXT "v=spf1 +mx +a +ip4: +ip4: +ip4: -all" 300 IN TXT "v=spf1 +mx +a +ip4: +ip4: +ip4: ~all"

Remove this one at DNS tab of Cloudflare dashboard:

 "v=spf1 +mx +a +ip4: +ip4: +ip4: -all"

Keep this one at DNS tab of Cloudflare dashboard:

"v=spf1 +mx +a +ip4: +ip4: +ip4: ~all"
1 Like

OK. I’ll read the tutorial and contact the hosting provider (as they’re the ones that actually added the records). Thanks.

If I do what you are suggesting, I’d have the same number of records (20) in the cpanel and Cloudfare, but the TXT record for SPF would have different contents. Then, wouldn’t I need to edit the one in the cpanel?

Since your domain is using Cloudflare nameservers, meaning Cloudflare manages DNS records for your domain name, any change in cPanel doesn’t reflect to it and the changes you made in cPanel “Zone Editor” doesn’t have impact.

Any DNS change you want to make, you do it under the DNS tab of the Cloudflare dashboard for your domain name.

Leave them “as-is” in the cPanel - just for some kind of a “backup” in case you will need them.

Hi @fritex. I have completed the following changes:
1 - Erase the extra SPF record
2 - Create a new MX record for mail
3 - Modify the CNAME record from Proxied to “DNS only”
The first should be OK, but the problem for the other 2 is that I’m getting the message “This record exposes the IP behind which you have proxied through Cloudfare.”
This is the current state:

Should I orange-cloud these 2 records or leave as DNS only as suggested in the tutorial?

Thank you fore feedback.

There is still a slight change which needs to be done I believe
The CNAME mail is now :grey:, but it’s target is → that’s the A which is :orange:. So, still need a fix, remove CNAME mail, add new A mail and point it to the IP address and make sure it’s set to :grey: (DNS-only).

If you’re running something other than a website on your server, you have to expose the Origin IP address because Cloudflare only proxies HTTP/S. *Unless you’re using the Spectrum Service which is either an Enterprise feature, or you’ve enabled it for SSH or Minecraft.

No need to worry about it. You can freely ignore this as your web and email DNS records are pointing to the same IP address.

A good article about This record exposed the IP behind can be read from below link:

Usually, no need to worry too much. When using an e-mail service, the A mail record needs to be :grey: cloud to make it work propperly as Cloudflare does not proxy traffic for e-mail. It is well described on the above linked & referenced articles.

Kindly, consider reading the second article from above under the section “ Best practices for MX records on Cloudflare → Follow these guidelines to ensure successful delivery of your mail traffic: ”.


Cloudflare’s default configuration only allows proxying of HTTP traffic and will break mail traffic.

After all, from your screenshot, I do see 3 or 4 TXT records related to _dmarc? :thinking:

This is also an issue - should be one of them, only? :thinking:

May I ask if your web hosting provider is also your email provider, despite “newsletter service”, or not?

Seems like you’ve used web hosting & email the same, then had some different one email provider to me? At least, the MX records are saying this too.

So, receiving/sending an e-mail might be trouble here.

Hi @fritex,
Sorry but I had a previous appointment that took the last couple of hours. I usually don’t like blaming other people but all these records were set up by the hosting services company (maybe they didn’t use a very orthodox approach for some reason ). The web hosting provider is for both the web and the email (we are not running anything else from it). The newsletter is a separate matter: When the first campaign failed to reach several people, they suggested adding the SPF and extra CNAME records to strengten the identification of newsletter emails.
Anyway, per your suggestion, I removed the CNAME record for mail and added an A record pointing to the IP. Per the tutorial the IP will be exposed but I’m getting 2 warning triangles. Did I do the right thing by setting the A record for as DNS only?

The other 2 MX records ( and were set up by the hosting company but I don’t know for which purpose.
As far as the _dmarc records, I see that the first 3 only differ in the value of p (quarantine, none or reject), whereas the 4th seems to be related to mxtoolbox. I guess that I could delete this 4th one but don’t really know which one to keep between the other 3.

Thanks for sharing info and updates.

Kindly, switch A to :orange: I really don’t remember instructing you to do so :thinking:

A mail is good now :+1:

Thank you for feedback about it. I was curious as they point to some other hosting, maybe some of their email provider if they use 3rd-party or some external? I really cannot know.
Maybe both of them are odd/obsolete and should be removed? :thinking:

Can you ask your web hosting company to check those two MX pointed to


If so, then kindly remove the two MX pointed to

Yep, a bit confusing as either I don’t know who is your email provider :man_shrugging:
Whom you’ve used so far?


;ANSWER 300 IN TXT "v=DMARC1;p=none;sp=none;adkim=r;aspf=r;pct=100;fo=0;rf=afrf;ri=86400" 300 IN TXT "v=DMARC1;p=reject;sp=none;adkim=r;aspf=r;pct=100;fo=0;rf=afrf;ri=86400" 300 IN TXT "v=DMARC1;p=quarantine;sp=none;adkim=r;aspf=r;pct=100;fo=0;rf=afrf;ri=86400" 300 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

From above 4, leave this one only:

"v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

Just add your e-mail here in case for troubleshooting your e-mails for the the rua=mailto:[email protected]; and ruf=mailto:[email protected]; as far as we don’t know who created mxtoolbox record, neither who is monitoring these reports and getting them → you should. Later on, we can adjust this DMARC.

Nevertheless, check your e-mail client (MS Outlook, Mozilla Thunderbird, AppleMail …) if you are using hostname for “sending/receiving” server (POP3/IMAP/SMTP).

Going next, if you are using FileZilla or some FTP client and using for Host, then switch A ftp to :grey: (DNS-only). Otherwise, remove it completly and just use the “IP address” for Host when connecting → security concern.

The A cpanel, I prefer to have it :grey: (DNS-only) as far as there know to be some issues when we are using File Manager which “transfers” sessions between cPanel cookie and that external app. Also, there is some issue for example if using Cloudflare WAF, you might not be able to “save” the editor.
Despite of the two of them, if you are going to download or upload a file larger than 100MB, you are going to encounter another issue as by default limit on :orange:.

Step by step and we will fix your issues together :wink:

Thank you for patience

Hi @fritex
Hope I got everything right (it definitely looks a lot trimmer).

I’m not sure about your question about the email provider, it should also be tmdhosting as the web hosting; I don’t think that they would outsource it to someone else. As far the email client, I’m using bluemail with IMAP (incoming: SSL/TLS 993; outgoing: SSL/TLS 465).
Do you need any other data?

Ture, right.

All good.

Now what I am curious, have you got any DNS records related to your newsletter company?
Or how are you using their services? I know for a few like MailGun, SendGrid … some of them require adding some DNS records.

Hi @fritex,
The newsletter company is called BenchmarkEmail ( Initially, they didn’t ask to add or update anything; it was only when the first campaign didn’t go as planned that they made the following suggestions:

  1. Update the SPF record for your sending domain. SPF records play an important role in email authentication and tell the ISPs if the IP address sending the email is authorized to send emails on your behalf or not. If not already updated, we would suggest that you publish your SPF policy and also include “” to it. Please update the SPF records for your domain “” as suggested below.
    v=spf1 +mx +a +ip4: +ip4: +ip4: ~all

  2. Publish CNAME record for the Double DKIM:: Once you have the SPF in place it is time to move to the next step. We suggest that you add a new CNAME record for your sending domain and publish it like the one below:
    Host: bmdeda._domainkey

After adding these 2 items, some tests also showed problems and that is when I started to dig a bit deeper into the whole domain setup.

1 Like

Hi @fritex,
I’m performing some extra checks. Hopefully, this is my last question. I’m using mxtoolbox to check the records out. This is what I have noticed some potential problems:

For MX,

For A records, &

I really don’t know if any of these warnings is potentially a problem or everything is fine. Thanks.

I can get A and AAAA okay (maybe due to the CNAME flattening).

You should look DMARC for “root domain” only, not for

You are looking AAAA instead of A.
It’s okay as those records aren’t proxied and your origin is working only on IPv4.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.