Email DNS propagation issue

I have been having an issue with DNS propagation. The MX records are not correctly propagated to Cloudflare. This has happened 3 times in a row. Twice with iPage and once with Netfirms. The MX records are automatically updated to mx.domain, whereas it should be mx.ipage.com. Becuase of this emails stopped working. Could you please check what is going wrong? This is impacting email delivery.

May I ask what is your domain name?

1 Like

The issue is fixed by manually correcting the domain MX records. But it always happens. I had this problem with 3 different domains. One of the domain that had a similar problem in last 2 month is enlitly.space.

You didn’t answer this, so it makes it difficult to diagnose.

Cloudflare doesn’t replace MX records. Are you using Ezoic?

I am not using Ezoic.

I haven’t used iPage neither Netfirms, not familiar with them.

In terms of automatic “detection” of the records from the domain name while adding a domain name to my Cloudflare account, my best practice is to always do the re-check in terms of the records just in case if some are missing or wrongly configured (somehow).

Nevertheless, I think by default my A mail was always recognized and proxied :orange: in the process, which was why I practice to re-check and make sure it’s :grey: (DNS-only) to make sure my e-mails continue to work while using Cloudflare for my domain name.

Also, in terms of adding a domain which was hosted on some cPanel shared web hosting, I have had to add some more records as they were missing - as far as I remember it was the case few times.

Maybe all the records cannot be detected so far at first.

Only once I have had a case where no records were detected, and that seems to be normal when we register a new domain and immediately add it to Cloudflare - as it cannot detect any of the records since before it didn’t had any, so I have had to add the manually - which is completly understanding (or importing them if so from another provider, if available).

Furthermore, in case if any records are missing, we can always re-check from old provider at his DNS interface what were the DNS records and re-add them as needed.

Why it happens, if so, I am not aware of.

Domain is enlitly.space. I have manually updated the Mx records so its working. But I don’t want this to happen again. It has happened 3 times with 3 separate domains. iPage asked me to contact Cloudflare. They are saying issue is from cloudflare side.

So out of 3 domains, one domain was added long ago. Everything was working fine untill today. When I contacted ipage, they asked to contact Cloudflare about this issue. I updated the MX records and its working fine now, but I am worried that this may happen again.

Only if for example the customer/user expects from Cloudflare to alter it’s DNS record(s) accordingly if something changes at the provider’s side in the meantime?

Like, if the e-mail provider changes something, for example the IP address or the new values for the MX record, meaning by default a user should do and apply the changes for it’s own domain too.
Rather than, for example after a user has added his domain to his Cloudflare account, should it be expected from Cloudflare afterwords to automatically detect those “provider changes” and alter them in the meantime (without any notice to the Cloudflare owner and without any manual user work)? - I doubt. If that would be the case, maybe.

From another point of a view, maybe by default, you have had configured like yourdomain.com hostname for your receiving/sending (POP3/IMAP/SMTP) server at your e-mail reader/client (MS Outlook, Mozilla Thunderbird, etc.). So, after enabling Cloudflare for your domain, the yourdomain.com hostname is proxied :orange: by default, therefore e-mails stops working?

  • or you should use mx.yourdomain.com (below links)

Furthermore, in terms of MX record having the value mx.yourdomain.com, the A mx could be missing or it’s actually :orange: - while it should be set to :grey: (DNS-only) - my first post contains link to E-mail troubleshooting: