Support plus addressing in email routing

Hello! Not sure how to categorize this, but I’ve noticed that plus addressing does not work in the Email Routing beta but that plus addresses fall under the catch-all.

So if I configured my Email Routing as follows:

[email protected][email protected]
[email protected][email protected]
and with catch-all turned off

any email to [email protected] would bounce.

If I turn on catch-all and forward it to [email protected], then [email protected] would end up at [email protected], while [email protected] would go to [email protected].

So, I don’t know exactly if it’s a bug or a feature request (for my situation it’s a bug) but I’d love for this to be fixed if possible.



I was actually looking for this functionality as well.

1 Like

Plus addressing does seem to work for me.
The catchall email on is routed to [email protected]
I can also send en email to [email protected] and it arrives in my [email protected] inbox.

If it’s a catchall, it probably doesn’t care about plus addressing. Any address on the domain gets forwarded to the destination.

1 Like

Yes but I would expect that plus-addressing works like their non-plus addresses and does not rely on catch-all.

I would expect that [email protected] is handled like any email to [email protected]. It should not be handled by the catch-all, and it should still work when the catch-all is turned off.

You can use the catch-all feature to emulate the + sign. We are planning to add more complex routing options.


Hoping to migrate from google domain. Having the same use case as the OP. Multiple users, with multiple + addresses.

For this to work for seamlessly I need the gmail conventions to work. For example:

pete+*[at] ==> pete[at]

frank+*[at] ==> frank[at]

Is this in the “more complex routing options” plans you mention @sven2 ?

Ideally it would be great to have a toggle for the domain. Use gmail conventions: On/Off.



Just a quick note: this is not a google/gmail only feature. See Email address - Wikipedia. See also this RFC - RFC 5233 - Sieve Email Filtering: Subaddress Extension


Right! So a toggle to implement RFC “+” addressing for this domain would be the way to phrase it.



I would really like to see RFC 5233 support. At the moment this can be done via catch-all, but that will attract a lot of unwanted emails. Support sub-addressing without catch-all would be really nice.


I have been trying to figure this out from the docs, but it isn’t clear.

In other services for email forwarding you can setup rules like:

[email protected][email protected]
[email protected][email protected]
[email protected][email protected]

This allows you to give out a per site email, but not need to setup a redirection rule for each. Then if you see an email you know who shared it and where it came from.

The catch all wouldn’t allow this as [email protected] would get sent to the same catch all, but that isn’t the right account.

Other services like Improvmx allow this. It is a great feature.

Thank you!

Regarding the Email Routing Beta

I’ve registered my [email protected] as catch-all email.

The validation email was sent to [email protected] and the forwards are sent to [email protected]. the +spam part is completely ignored.

My plan was to use the +spam as the email for the catch-all option.


To clarify, I’m not asking to create a name+spam email in CF.

I’m asking to the Email Rounting to just route to the email configured instead of deleting everything after the plus when forwarding.

+1 for RFC 5233 support.

I use it since years and it is soo useful. i am looking forward to switch some domains completely to Cloudflare if RFC 5233 is supported/email forwarding is out of beta. would be such a great addition.


Any idea what your + implementation will look like?

Will it be a configurable feature to allow or deny plus addressing on an individual forwarding address basis?

Will you be able to pass through the + to the destination mailbox, or will it just forward to the defined target? (Some mail systems do not support + addressing
me+(something) --> [email protected]
me+(something) --> me+(something)

I’m sure there will be people who will want different + addresses forwarded to different destination mailboxes, so will you also be able to override a catch-all with a more specific rule?

[email protected] --> [email protected]
me+(everything else) --> [email protected]

I’m interested in knowing what this feature will eventually look like.

If I understand the RFC correctly, it’s called “sub addressing” for a reason: me+(anything) should be treated as a sub address of [email protected] and therefore be treated the exact same way. If you would like to create different addresses, you might want to consider not using the plus sign (i.e. [email protected] or just [email protected]) or redirect it in the receiving mailbox using different rules.

For an email forwarding service like Cloudflare offers, I’d be happy if they support sub addressing in its basics, meaning that [email protected] is treated exactly like [email protected].

As above, without sub-addressing support, I simply cannot use this email routing feature. Please can we add this as without email routing for my domain is useless.

P.S. Cloudflare suggesting that a single catch all email rule is a way to implement in is a misleading and clearly not a viable solution unless you a) only have one email account on your domain, b) you want to expose yourself to spammers trying variations of email addresses on your domains. Disappointing that they would even suggest that for their users.


You can use the catch-all feature to emulate the + sign.

Unfortunately, if we have only one custom/destination address existing we can, otherwise we can’t.

Bart doesn’t want to read John’s subaddressed email messages and vice versa.

In an RFC 5233 compliant email system john+{anything}@domain goes to John’s mailbox (whatever {anything} is) and the same works for each and every other user.
In CF Email Routing we merely can redirect john+{anything}@domain together with bart+{anything}@domain and with all subaddresses from all other users and WITH all the junk sent to all not existing addresses to one single email mailbox, not to each discrete mailboxes of John, Bart and whoever else.

Thank you.

1 Like

Yes with the shutdown of free google gsuite, there are many others at investigating where to move their email. Having RFC5233 support would make that much easier to use Cloudflare routing.

1 Like

Currently Gmail alias email addresses with (+) aren‘t routed to the certain email, they can only caught with the catchall address. Will Cloudflare implement this feature in near future?
For example <[email protected]…> should be forwarded to the recipient of <[email protected]>,
<[email protected]…> to <[email protected]>
and so on…

1 Like