Workers mailer not sending to Gmail domains
I've been using the MailChannels worker integration to send emails to users for the last 12 months, and have only today discovered that this endpoint seemingly cannot send emails to
@gmail domains.
From what I can tell it doesn't seem to have any issues with any other domain endings:
- My test account is an @icloud domain and has been working flawlessly
- I've tested it with my university email address (ending in @qut.edu.au) and it seems to also be working flawlessly
I've tried with both my own and a friend's Gmail email addresses, and both have seemingly lost the email somewhere in transit. It's not available in the spam folders, nor is the worker erroring when sending to those addresses (I receive a 202 Accepted response every time).
My only theory at the moment is that Gmail has far more strict guidelines as to what mail it accepts and blocks, and that the MailChannels partnership has been abused previously so has been silently blocked.
My implementation closely follows the example implementation available on the Cloudflare Blog:
https://blog.cloudflare.com/sending-email-from-workers-with-mailchannels/
Does anyone have any ideas or similar experience? I genuinely don't know what's causing this issue or how it can be resolved without moving away from Workers entirely for mailing tasks, which I would like to avoid.The Cloudflare Blog
Send email using Workers with MailChannels
MailChannels has created an email sending service specifically for Cloudflare Workers that removes all the friction associated with sending emails
8 Replies
An update for anybody who cares: It was a DNS issue!
https://support.mailchannels.com/hc/en-us/articles/200262610-Set-up-SPF-Records
The above article explains that there needs to be an SPF record set up in the domain of the sender's email that allows emails to be sent from there. It seems that most email providers don't check for this fact, but as I suspected Gmail is a lot stricter on its checking and thus blocked everything from this unverified domain.
This article also linked to another one that explained locking domains down with MailChannels' Domain Lockdown to help impersonation, something I've now also interested
(here's the link to that for anyone who cares)
https://support.mailchannels.com/hc/en-us/articles/16918954360845-Secure-your-domain-name-against-spoofing-with-Domain-Lockdown-
This is the kind of thing that needs to be in some sort of centralized documentation by Cloudflare. The fact that I had to comb MailChannels' websites for solutions to this very large issue is insane to me. I'm going to make it my mission for today to setup a better documentation for this stuff that explains DNS, domain lockdown, etc. and post it somewhere useful, then update this when I'm done.
Help Center
Set up SPF Records
Before relaying messages through the MailChannels Outbound filter, SMTP Authentication but be configured to allow a MailChannels owned IP to deliver messages on behalf of your domains(s).
Accurate ...
Help Center
Secure your domain name against spoofing with Domain Lockdownâ„¢
Domain spoofing is a significant issue that threatens email integrity and security. Domain spoofing occurs when attackers pretend to send emails from a domain they do not own, typically with malici...
Alright, for anyone interested I've compiled a few important documents into one unofficial documentation repository on GitHub, hopefully helping a few people out in the future on the off chance they stumble across this!
https://github.com/zaccomode/better-cfw-mailer-docs
GitHub
GitHub - zaccomode/better-cfw-mailer-docs: Improved documentation f...
Improved documentation for the Cloudflare Workers MailChannels integration - GitHub - zaccomode/better-cfw-mailer-docs: Improved documentation for the Cloudflare Workers MailChannels integration
Thank you! I'll have a look into doing that
@zaccomode I submitted a PR for you to look at; the README was out of date in saying that Domain Lockdown is optional. It is now required 🙂
For the record, MailChannels never quietly rejects or loses a message. We always generate a non-delivery receipt if we cannot deliver to the destination. The NDR is delivered in accordance with the DSN RFC (https://datatracker.ietf.org/doc/html/rfc3464). If we choose to reject a message, your API call will result in an error response along with an explanatory message.
I'll take a look at it soon 😀
That's interesting, from what I could tell that's not the behaviour I observed. When sending to Gmail addresses it returned
202 Accepted but never delivered. It wasn't left hanging, and didn't return an error. I suspect that this is because this isn't something MailChannels picks up because it's detected on the mailbox side? But I'm not hugely familiar with how email works so I could be wrong.You may have a legacy account. Some older Workers CF'id's are exempted for now.
Ah, that may explain it. Good to know, and thanks for the feedback on the documentation repo 😀
Thank you for making it!