Seconded. I’ve also noticed this with my domains. All routes, workers and drop rules get skipped when catch-all is enabled and they just go to the catch-all address only.
The expected behavior (which was working fine until this morning) is that only incoming emails which do not match any route should be forwarded to catch-all email address.
But right now, all routes are being skipped and all incoming emails are going to the catch-all address.
This same issue is happening for me too.
The catch-all address gets all of the emails, even when the destination address is a custom email address for which there is a route configured and active.
This was working OK until some time yesterday (Friday 11th August about 11am UTC+1). I had not touched the config at all and it just stopped working as expected.
To illustrate the problem in a little more detail…
My cloudflare account is managing my domain, example com.
I am using Cloudflare for DNS for example com, including DNSSEC.
I see (under routing / settings) a green lozenge saying ‘Email DNS records configured’.
I have been using Cloudflare’s Email Routing service for this domain for the last month or so with no problems until yesterday.
Looking in routing / routes, I have a custom email address configured in Email Routing, lets say this is custom1 example com and it is configured with the action ‘Send to an email’ and the destination is myname1 mailprovider1 com. The status of this item in the list of custom email addresses shows a green tick in a slider and the word ‘Active’.
I have a catch-all address configured too, which is configured to ‘Send to an email: myname2 mailprovider2 com’.
When an email is sent (from some other email system) to custom1@example <dot> com, that email is not routed to myname1@mailprovider1 <dot> com but is instead routed to myname2@mailprovider2 <dot> com.
Both myname1@mailprovider1 <dot> com and myname2@mailprovider2 <dot> com are working email addresses that each receive email OK and neither of them forwards to the other.
Note that I have deliberately used intended recipient email addresses on different mail providers so that I can be absolutely sure that the misdirection is happening in Cloudflare’s Email Routing system and not in the intended recipient email system(s).
I don’t know if this is a related issue or not, but from the dashboard, when looking at the ‘Activity Log’ in routing / overview, I can see that Cloudflare always shows the recipient email address in the ‘Custom Address’ field, even when the recipient email address is NOT an email address that appears under ‘Routing’ as a custom email address.
Perhaps the Activity log always worked that way, but it is surprising that the words ‘Custom address’ that head the 3rd column in the activity log does not refer to the same thing as the words ‘Custom address’ in the filter drop-downs at the head of the Activity Log.
E.g. I sent an email to newaddress@example <dot> com, where newaddress is not in the list of email addresses for which a route is configured, and in the Activity Log I see newaddress@example <dot> com in the column ‘Custom address’, but I do not see newaddress@example <dot> com in the drop-down list called ‘Custom address’ which can be used to filter the Activity Log, that drop-down list instead including - as might be expected - only the Email addresses on example com for which a ‘Custom address’ appears in the routing list.
And just to say that disabling the catch-all kinda solves the problem - but not having a functional catch-all means that I have just had to create >50 routes so that the email addresses I have given out assuming that I had a catch-all will work. I hope I haven’t missed any!
The catch-all was the feature that spurred me to use Cloudflare’s service. My previous provider was just dropping support for catch-alls, and most others don’t seem to support it.
Sorry that I keep replying to myself, but I have another domain with Cloudflare which doesn’t exhibit this behaviour.
Go figure…
This other domain doesn’t use DNSSEC, although I have no reason to think that difference is significant.