Cloudflare Email Routing Disruption For Emails Sent From gmail.com and google email

General Email Routing
1

What is the name of the domain?

private.co.uk

What is the error number?

None

What is the error message?

None

What is the issue you’re encountering

Cloudflare Email Routing Not Working When Sent From Google Email

What steps have you taken to resolve the issue?

Send an email from any domain hosted on google email (including columbia.edu) to my custom domain, which uses cloudflare email routing. None of those emails have been delivered for the past 2-4 hours. If I send an email from a domain using office365, then cloudflare email routing successfully delivers the email to a google email hosted account. There is some issue with Cloudflare accepting the email from gmail.com and then delivering it to another gmail.com account.

3

I am going to try deleting the mta-sts policy to see if that is the issue. Perhaps Cloudflare or Google took two days to update, and cause a problem because of this?

4

I’m having trouble deleting or editing my post. I change my mta-sts policies to testing mode, and want to confirm whether or not the MX records in the mta-sts policy file should include cloudflare and/or google mx records for both 1) the custom domain that using cloudflare email forwarding 2) the custom domain hosted on google email that receives email forward from cloudflare

5

If you have a MTA-STS policy, and that the set up are not done well enough, that will indeed be able to cause issues.

If you’re sending from Google (e.g. from “[email protected]”) towards a domain name that is using Cloudflare Email Routing (e.g. “[email protected]”), then Google will check the receiving domain (“example.com”) to figure out if it has a MTA-STS policy, and then act upon the policy, such as e.g. not completing the delivery, if the configuration isn’t living up to the MTA-STS policy.

Invalid MTA-STS policies (as well as many other invalid or otherwise broken configurations) will be able to cause something like this.

When you are not actually providing the domain name(s) you’re seeing issues with, it will be impossible to dig in to though.

1 Like
7

Some emails are starting to flow through with up to a 6 hour delay. Seems like a bad mta-sta record followed by cloudflare and/or gmail holding emails, which could not be seen in google apps email delivery logs and also cannot be seen in cloudflare dashboard…

8

The MTA-STS policy for “example.COM” will need to have the MX records for “example.COM” listed in it’s MTA-STS policy.

“example.ORG” (or any other domain’s configuration) isn’t relevant for the MTA-STS policy of “example.COM”

For a domain that is pointed towards Cloudflare Email Routing, you would typically be able to cover each MX host in the MTA-STS policy, like this:

mx: route1.mx.cloudflare.net
mx: route2.mx.cloudflare.net
mx: route3.mx.cloudflare.net

The receiving domain’s MX, so if this is Google Workspace, and that you have set it up according to Google’s instructions, with one “ASPMX” and four “ALT{1,2,3,4}.ASPMX” names in your MX records, your MTA-STS policy would need to cover the names like this:

mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com

It will be the sender (according to the above explanation, it sounds to be Google/Gmail) that is holding the messages.

What happens on sender’s end, such as e.g. when things like MTA-STS (or many other things) fail, is something that may vary a lot from provider to provider.

If you cannot see any inbound delivery attempts on Cloudflare Email Routing, you will need to dig in to the issue from sender’s end, as the message never ended up on Cloudflare Email Routing…

1 Like
9

Thanks, issue is resolved right now.

  1. Missing emails showing up this morning
  2. GSuite Admin email log search dashboard for a custom domain showed emails sent, but not delivered
  3. Cloudflare Email Routing dashboard reporting emails this morning, up to 24 hours after they were sent based on smtp sent success reporting messages.
  4. Google cached mta-sts policy, likely because of age that I have since updated to 5 minutes
  5. Runner for a super simple static website hosting mta-sts policy ran for 2.5 hours due to free minutes running out (either erroneously or due to service degradation during vendor maintenance). This should have taken a few seconds, and I did not get the failure notification for several hours because of the email delivery issue.
  6. I deleted mta-sts dns records from cloudflare because the changes I made were not reflected