Problem with corporate emails through Gmail and Outlook

Good afternoon, community! I’m sorry to bother you. Next week my hosting’s SSL certificate expires, and I decided to start using Cloudflare instead. The problem is that since the day I added my site to Cloudflare, I cannot send or receive emails from my corporate accounts through a third-psrty service. If I use Roundcube, messaging seems to work fine, but if I want to manage my emails through Gmail or Microsoft Outlook, I get a delivery error. And if I want to add a new email to Outlook, for example, it tells me there was an error, it doesn’t even accept my credentials.

I know Cloudflare doesn’t normally affect emails, but it’s very strange that those services stopped working the same day I set it up. Any idea what could be the reason? I add a link to my DNS, just in case. Thank you so much in advance!

https://drive.google.com/file/d/1b4Li8sMKfEPGfy2FjdyiB9qCfxMAp-sV/view?usp=sharing

Your MX record points to mail.deltaq.com.ar which is covered by your wildcard * which in turn is proxied.

If you also connect to mail.deltaq.com.ar in the mail clients, they will fail for the same reason.

Creating a DNS entry for mail pointing to your server IP address, but set to “DNS only” and not proxied will likely let mail work. (You will get a warning that your origin IP is exposed, but if your mail and web servers are on the same IP address, nothing you can do about it).

https://cf.sjr.org.uk/tools/check?486e0188a3734fc591f20d5ac25a8eb4

1 Like

Good morning, first of all happy new year and thank you very much for your response. I did what you suggested and everything seems to work correctly. My question now is: does changing the settings to “DNS only” expose my site or emails in some way? My site and my emails are hosted on the same server/hosting.

Now, that DNS configuration that I shared in the link was the automatic one that Cloudflare made when I added my site. Why does an asterisk appear? That has never happened to me with my other sites (although they are hosted on another hosting and maybe that has something to do with it).

Thank you very much again for your kindness!!

Thanks, and Happy New Year to you too :slight_smile:

It does NOT mean that your emails will be exposed (e.g. that everyone would be able to access and read them, or so), assuming that you have properly secured your server.

It is technically not exposing anything more than if you didn’t use Cloudflare at all.

DNS is technically public data, it isn’t anything you can actually hide, if you want your website (or mail servers) to be accessible from the Internet, such as e.g. allowing others to send emails to you, these others would need to know which IP address to deliver the email to.

The Proxy (:orange:) can proxy HTTP (website) traffic, and it is doing so by replacing the IP addresses that the public Internet sees, with Cloudflare IP addresses, and once they retrieve requests for your website, they will forward (“proxy”) them to your own server.

That way, when having your website traffic Proxied (:orange:) through Cloudflare, any e.g. DDoS attacks sent directly towards your domain (using (:orange:) records), would be retrieved by Cloudflare, and not by your own server, that only sits behind the stage.

If someone knows your own server’s IP address, they can technically attempt to send DDoS attacks directly towards your own server, and since it would targetted directly at your own server, it would be evading Cloudflare in a way, where Cloudflare won’t be able to shield you.

The majority of all DNS records, when talking about email traffic, won’t work with the Proxy status set to Proxied (:orange:).

As such, it can be wise to run your email and website traffic on separate servers.

But regardless what you do, you would technically always be exposing the IP address(es) of your email infrastructure, such as e.g. when you send mail, or when people need to send you mail.

The outbound email infrastructure (e.g. the IP addresses that are connecting to third parties when you’re sending emails), are likely already exposed in your SPF records, for domain authentication.

The asterisk you see is a wildcard.

It would point all sub-domains (where you do not already have other DNS record(s)) to the given IP address.

In your case, alfa.example.com, bravo.example.com, charlie.example.com, and even blah-blah-blah.example.com would point to your server.

However, for _dmarc.example.com, and anything below, such as test._dmarc.example.com, the wildcard isn’t active any more, because the TXT record is there, and that record literally deactivates the wildcard function for it’s own label (“_dmarc”), and everything below.

2 Likes

Thank you so so much for your kind reply and all the information and knowledge you shared with me, explaining exactly what I needed to understand better how this whole thing works. I’m definitely saving this whole topic as a bookmark. I could fix the problem by changing the settings to DNS Only, so thank you @sjr for the suggestion, it worked like a charm.

Thank you both guys, and have a great weekend!

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