Mailchannels X MailFrom / From / Return-Path
You're more than welcome to ping me, and let me know what you're (eventually) finding out with them. 🙂
12 Replies
Did you guys ever figure this out? I want to try to add in some email tracking features: bounce rates, open rates, etc. Usually you would use 'Return-Path' if I understand correctly as a email box to receive bounces email in. But it looks like MailChannels replaces this with the
from email.
Would be great if we can replace the Return-Path somehow, since then for every email we sent we can catch those programmatically with e.g. email workers and mark an sent email id as delivered, e.g. [email protected]
Any thoughts?1. Drop "
from" OUTSIDE of "personalizations".
2. Add the desired SMTP MAIL FROM / Envelope From / Return-Path, as "mailfrom" OUTSIDE of "personalizations".
3. Put the desired RFC5322.From (Header From:, visible from, ...), that your users are supposed to see in their email client, as the "from", INSIDE "personalizations".An example was posted here: https://discord.com/channels/595317990191398933/779390076219686943/1211839171170275410
https://media.discordapp.net/attachments/779390076219686943/1211839171052699678/image.png?ex=660b57ad&is=65f8e2ad&hm=30ed339330d9f423268281657438f0a1f31959d0e79279c737510e2cbc9cd9bb&=&format=webp&quality=lossless
However, for this part:
I want to try to add in some email tracking features: open rates,
since then for every email we sent we can catch those programmatically with e.g. email workers and mark an sent email id as delivered,I'd like to add: These things are NOT something you can use the SMTP MAIL FROM / Envelope From / Return-Path for. The SMTP MAIL FROM / Envelope From / Return-Path address is only for receiving bounces (NDR / non delivery reports). And even for the bounces, it is depending on the (latest) mail server in the chain that actually accepted the message, to be sending them.
Yeah open rates was thinking to add an hidden image + worker to track, but this already greatly helps, thanks!!
You're welcome. Glad I could help. 🙂
I've setup some basics here for the return path/mail from. The email headers seem to look good, guess now I need to wait until I receive some bounces (I tested by sending to some random non-existing emails and the bounce boxes of postmark https://postmarkapp.com/support/article/1239-how-to-test-bounces, but email providers might take a while (48 hours+-) before marking emails as bounced, so I'll be patient for now, after I've received some, I'll try to integrate a email worker that can track these for us :MeowHeartCloudflare:
Re.
but email providers might take a while (48 hours+-) before marking emails as bounced,A such delay should only be seen if it appears to be a temporary issue with the message delivery. Things such as e.g. the "HardBounce" test from their list of test addresses SHOULD be doing it pretty much instantly. However, the ones the mention as "Transient" would typically go in the area of 120 hours (5 days). Re-trying 120 hours (5 days) on what appears to be temporary / intermittent issues is the most common out there, meaning for the transient ones - it may take that long.
@DarkDeviL do you know by any chance whether I need some type of account or use postmark to use their bounce address? E.g. even directly emailing from my personal gmail account to [email protected] doesn't seem to do anything for me.
Hmh I don't know why but if I sent to a non-existing mailbox from my personal account, I get a bounce email back immediately about a DNS Error. If I do this through mailchannels, I don't get an email at all.
Return-Path seems set correctly. From is different, as it should, SPF / DMARC passes but I don't get any messages in my Return-Path email 🤔
Actually, I switched the address to a diffferent mailbox (to an actual gsuite account vs a google group) and now it works but the bounce email from mailchannels ends up in my spam
Okay I figured out why, the bounce emails mailchannels sent are unauthenticated 🤦♂️
Postmark could theoretically (and technically) be limiting their test addresses to only work for their own customers / from their network.
I don't know for sure whether they are doing so, and unfortunately, their own documentation (e.g. on the page you linked) isn't very well at that point.
If we're taking the route that the message You <-> MailChannels <-> Google, assuming that Google is refusing the message with "550 5.1.1" (typical code for "Mailbox does not exist"), then MailChannels needs to send the bounce.
The responsibility for sending the bounce only becomes Google's headache, once Google has actually accepted the message, which they would never have, with a such kind of rejection.
This one, and especially the part with
SPF [bongo.dogwood.relay.mailchannels.net] with ip: part, is indicating that the SMTP MAIL FROM / Envelope From / Return-Path was actually set to @bongo.dogwood.relay.mailchannels.net for that specific message.
That 421 4.7.26, being a temporary rejection code from Google, would mean that MailChannels would be the responsible party for sending the bounce back, which would be to the address ending with @bongo.dogwood.relay.mailchannels.net.
Since 421 4.7.26 is a temporary rejection code, that would often happen after those ~ 120 hours (5 days) that is most common, - or alternatively, whatever custom timeout that MailChannels's infrastructure may have been configured with.Really appreciate the highly detailed responses! I do think it's odd that Mailchannels doesn't authenticate / sign their own emails with dmarc / dkim, but that shouldn't matter too much once I've potentially setup a worker that receives these bounced emails! Thanks again!
You could always argue about that part with authenticating their own emails?
It isn't actually their own emails, but your own emails in this specific case, which would be why I would personally say you need to authenticate them properly from your side.
You can technically add "third party" DKIM signatures to messages, in other words, DKIM signatures on a different domain than e.g. the RFC5322.From / header From: (the sender as visible in email clients).
From looking at the Internet standards / specifications, there seem to be nothing that is directly preventing you from adding such "third party" DKIM signatures.
However, you can argue whether or not that would serve much purpose (or any purpose at all) in regards to email authentication, as it doesn't match the RFC5322.From / header From:.
As an illustration:
How can I actually trust the message would be from Cloudflare here, when the DKIM-Signature is on a different domain, named
mailchannels.com domain, and not directly under cloudflare.com?
Similarly, with the one above, having SMTP MAIL FROM / Envelope From / Return-Path set to:
If it had the visible RFC5322.From / header From: as [email protected], how would I be able to trust it's actually from @itswendell.example, when the (SPF) email authentication happens on @bongo.dogwood.relay.mailchannels.net?
None of these have the alignment to the original domain in RFC5322.From / header From: (e.g. as required in order to pass DMARC) in any way, for neither the given DKIM/SPF authentication mechanism.
So without that alignment (or "link") to the visible sender, - should we trust it, ... or not?