Email worker

Trying my first email worker. Just a simple one for a domain I am using to test. The idea is to forward all messages to the same user at a different domain.

So, from the domain page/Email/Email Routing I selected the Email Workers tab and created the worker. I then created a default route with Action ‘Send to a Worker’ and selected the worker I created.

That all makes sense, but emails to addresses at that domain instantly fail, apparently due to ‘Delivery failed’.

There seems to be no logging available of any sort with a ‘free plan’ account, so hard to guess what the problem is.

What I do see is that the worker still shows the ‘Create route’ button. However, this only allows binding to a specified single incoming address which is precisely what is NOT correct for a catch-all and that has in any case been defined in the ‘Routes’ tab.

If a Worker is being used as a catch-all destination, why is it still asking to be bound to a route, or is the button for that a red herring and the problem lies elsewhere?

I have to say that this is all appallingly complicated for so simple a task, but I would appreciate any advice on how to get this working so I can better understand the whole process and perhaps use it for actual email processing.

Any email address you try to forward to within a Worker has to be a verified Destination address or it will throw an exception. This is one likely cause of such an issue with that approach.

There is logs. Under the Email Routing Overview tab, you should be able to see the status of your mail. It may take a few minutes to update/get new information in. If you see “Delivery Failure”, and expanded “Worker threw exception”, then you need to debug your worker code.

You can do so by using wrangler tail if using Wrangler CLI, or going to your Worker in the dashboard, going to Logs, and then “Begin Log Stream”, wait a few seconds, and then send the test email. Any console.logs you put in your worker will also be shown here.

The worker route stuff should just be a red herring if you have a wildcard route set.

A few other common mistakes:
It can take a few minutes for new routes to become active. In your Email Routing Overview page, there’s a section at the top labeled “Routing status”. If it is “Active”, then all your routes should be active. If it is “Syncing”, then it’s not done propagating the changes yet.


Routing status actually shows ‘Enabled’, but that appears to mean it’s functional.

I think the problem is that the destination address has to be verified. That’s not going to work for me. While I do know most of the likely destinations, the whole point of using a catch-all like that is to be able to receive from ‘on-the-fly’ addresses, i.e. perhaps something new that cannot possibly have been previously verified.

Thanks for responding (so quickly too), but I have to say that it is all very infuriating now with everyone wanting to impose apparently arbitrary restrictions on what is and what is not allowed. I understand the increasing need for security, but IMO it’s all gone too far. I just want to be able to use my domains to receive and send from any username (at those domains) I choose and not have some other organisation impose their ill-thought out rules and restrictions on what I am allowed to do with what are, after all, my own domains for which I pay, specifically for the privilege of choosing what addresses I use.

So I’ll stick to who I currently use for email processing and provide what I want. However I will almost certainly move my domains to Cloudflare as I like their domain hosting and DNS. I just hoped I could combine it with email. Oh well, never mind. :slightly_frowning_face:

Thanks for responding anyway. :slightly_smiling_face:


Actually, another question about verified destinations has occurred to me. Does the destination of every Worker need to be verified?

What I mean is that there may be some intermediate forwards to within the same domain, before actually being delivered to an external mailbox. Does the destination of every step need to be verified, or just when it leaves that domain?

That could make a difference to usability for me as there are only very few final destination mailboxes that could be easily verified. However, if the destination of every step needs verification, then as I said before, not going to work as they may be previously unknown.

I suspect that verification of every step is how it works, but seems pointless if within the same domain so wondered if maybe that is not the case.

All Email Routing sees is the address it forwards it to, which has to be verified. Any other internal forwarding/etc is handled on your end and not visible to Email Routing. If you’re saying you forward it like [email protected] to [email protected], and then that all goes to [email protected], CF has no way of seeing that, all they see is the initial forward address.

I would view it more as this is a free service Cloudflare is offering, and they are using their own Mail Server IPs/Reputation to forward the mail. So if they forward spam to unverified addresses, everyone else gets affected by it lowering the reputation of those shared IPs.

1 Like

What I really meant was if email is received for [email protected] and is forwarded to [email protected], does the latter need to be verified?

I suspect it does and I think you are saying it does, but would appreciate confirmation and I’m sure would help others understand more about forwarding.

I do understand the need for security, but I also believe it is not the job of SMTP servers to monitor and verify at the individual user/address level. They should deal with security at the domain level. However, I realise opinions differ about this. :wink:


This isn’t an SMTP Server. Email Workers are a platform to process and action on emails, with a way to forward the exact incoming mail as well. It wouldn’t make sense, for example, to let someone verify and send to anyone there. It might make some sense to allow you to freely forward to other domains in your account/same domain, but then you get into other issues with problems that could arise from that/assuming all domains in an account should be trusted to each other. Other platforms, like gmail, are the same way with verifying the receiving address is ok with being forwarded mail. If your goal is to more arbitrarily send mail, you can send mail via MailChannels using Workers for free: Send email using Workers with MailChannels

By SMTP server I just meant intermediate servers that process mail before it is delivered to a mailbox.

Yes, anything in that account should be considered ‘trusted’. Easy enough to include a flag in the account settings “Trust all addresses in account” and leave it up to the account admin as to whether or not verification is required for addresses handled by that account.

The perfect solution always allows the user to make the choice. :slightly_smiling_face: