Email routing many clients to customers

Hello,

I have a question regarding email routing. Let me describe the situation:

Our customers use our SAAS tool to send emails to their clients, for instance, using demo@ourdomain.com.
We've set a reply-to header, but unfortunately, it's sometimes ignored by email clients.

In cases where one of their clients sends an email to demo@ourdomain.com, we want to forward it to our customer's email address instead of it arriving in our inbox.

Currently, we are using Google Workspace for our inboxes and are manually adding forwarding rules each time. We were hoping there could be a way to automate this so that when an email arrives at demo@ourdomain.com, it can be correctly forwarded to info@democompany.com.

Is this possible with Cloudflare's email workers? Or through normal routing? It involves hundreds of companies to which the emails need to be forwarded.

We are open for any suggestions, we would like to keep using the google workspace if possible. If not possible thats also ok.

RRoy Hello, I have a question regarding email routing. Let me describe the situation...

Chaika•1/8/24, 4:10 PM

Email Workers require each destination to be verified (which is done via a verf email and them clicking a link)
They would also have to take over your mailservers for the root domain in that case, or iirc Workspace has some forwarding features which may work but ymmv, I suspect you may be blocked by the first requirement there regardless

RoyOP•1/8/24, 4:15 PM

So there is no way of forwarding the mails without the verification mails?

RoyOP•1/8/24, 4:21 PM

Is it maybe possible to use our own smtp for forwarding the e-mails?

RRoy So there is no way of forwarding the mails without the verification mails?

Chaika•1/8/24, 4:21 PM

not using CF's built in forward stuff

RRoy Is it maybe possible to use our own smtp for forwarding the e-mails?

Chaika•1/8/24, 4:22 PM

I mean you could use an Email Worker to receive and send it to your own http server via fetch

Chaika•1/8/24, 4:22 PM

Workers also have TCP Connect() but smtp ports are blocked, couldn't even connect back to your smtp server

RoyOP•1/8/24, 4:24 PM

Hmmm. And our own mailboxes that are currently in the google workspace. Everyone in the company has his/her own E-mail and we were wondering how this could work together. Would we need to use the workspace on a subdomain. Or can the workers work on a subdomain and the workspace on the root domain.

RoyOP•1/8/24, 4:25 PM

Or can we intergrate this in a totally different way. (Doesn't have to be google workspace)

RRoy Hmmm. And our own mailboxes that are currently in the google workspace. Everyone...

Chaika•1/8/24, 4:27 PM

If you skip the getting started setup you can just setup email routing on a subdomain yea

Chaika•1/8/24, 4:27 PM

there's also a way to make specific addresses/etc go to email routing using aworkspace feature, haven't tried it myself
https://discord.com/channels/595317990191398933/812577823599755274/1179096763605467236

RRoy Hello, I have a question regarding email routing. Let me describe the situation...

DarkDeviL•1/8/24, 5:14 PM

Our customers use our SAAS tool to send emails to their clients, for instance, using demo@ourdomain.com.

I would recommend you to look in to this part ASAP.

First of all, this severe operational failure, as I would call it, is the root cause to your problem.

Additionally, it is also a very weak security policy of your company, e.g. the domain ourdomain.comourdomain.com in your example, that any customer can just send out using your company's domain name.

What if I were sending out junk through your SaaS platform? Your domain would obviously appear as the culprit, and be the one taking a dive in it's reputation, causing consequences for all of your customers at once.
What if I were sending out illegal stuff, or otherwise stuff that is (generally) considered nasty, through your SaaS platform? It would literally appear to be originating from your domain, ... so who would the public see, as the one to blame in that case?

DarkDeviL•1/8/24, 5:15 PM

You can of course always argue that you can always come with "What if"'s here and there, and sure, you can do that...

DarkDeviL•1/8/24, 5:18 PM

My recommendation would be to change your set up, so that if I should be able to send messages out through your SaaS platform, I would have to onboard my own domain to your platform first, so that it appears in the relevant sections (e.g. MAILFROM, header From:, ... et al).

Not only would it fix the potential disaster in regards to your domain's lost reputation and so.

It would also solve your problem once and for all, without the need for the forwarding, as I am understanding your explanation and the underlying problem.

RoyOP•1/9/24, 8:54 AM

You indeed make a good point, we hadn't thought about it that way before. However, we often see major parties like Intercom also offering email services through their own domain. Intercom does use @intercom-mail.com instead of the main domain, is this a better solution?

We've discussed it and are considering doing it your way for existing customers and for new customers in trial periods to retain the standard mail function but in a limited capacity.

DDarkDeviL > Our customers use our SAAS tool to send emails to their clients, for instance,...

DarkDeviL•1/10/24, 10:14 PM

Corrected:

Additionally, it is also a very security policy of your company,

to:

Additionally, it is also a very weak security policy of your company,

RRoy You indeed make a good point, we hadn't thought about it that way before. Howeve...

DarkDeviL•1/10/24, 10:17 PM

Regardless of whether you do e.g. @intercom.com@intercom.com vs e.g. @intercom-mail.com@intercom-mail.com, you would literally just be moving the problem from e.g. pointer #1 above from your main domain and to another domain.

With the newer "-mail-mail" example, your customers would likely still be coming to you regularly, with stuff like e.g. "My stuff is landing in spam, why can't you do it properly?".

DarkDeviL•1/10/24, 10:19 PM

I would however say that it cannot be considered any better at all that way:

Alone a change to from e.g. @intercom.com@intercom.com to @intercom-mail.com@intercom-mail.com, @intercom-mail.com@intercom-mail.com would still be able to sound like it would be the official domain of Intercom, and could give further things that needs to be considered with your organisation's risk assessments.

Email routing many clients to customers

Similar Threads

Similar Threads

Similar Threads