Email Routing First Impressions

Just got access to Email Routing and put it though a few paces to test some use cases that would seem to be consist with the market for this. Here are my impressions:

First, the use cases I’ve designed presume this is going to be used by someone without a full-blown email system they manage, but who has the sophistication to manage their own domain and presumably some resource infrastructure delivering internet content. If you don’t have a vanity domain then you don’t have anything to manage in Cloudflare; likewise if you don’t have resource servers you manage you don’t have any need for Cloudflare.

So we’ve established that the target for this isn’t the “single mailbox on Yahoo” use case…it is something a little more sophisticated. I’ve crafted use cases I think fit that model.

First, the simplest use case: Forwarding email from the vanity domain to an arbitrary address. Works as expected with little latency.

Unfortunately, that’s where the good news ends.

Analyzing the received headers, the forwarder generated a Return-Path header is the format: original-username=original-domain(at)clouflare-domain, so if the originating address was buzz(at)nasa(dot)gov and the Cloudflare domain buzzaldrin(dot)com, then the Return-Path was generated as buzz=nasa(dot)gov(at)buzzaldrin(dot)com. This is the address that any upstream NDRs should be sent to, but sending any email to that address did not trigger a forward back to buzz(at)nasa(dot)gov. As a result, upstream NDRs will be lost.

Next, I wanted to see if the system would accept a unique delivery port so I could test delivering mail on a port other than 25. This would be useful in those scenarios where the Email Routing could not publish their own mail server on port 25 and use direct DNS MX delivery, but still want to maintain an email infrastructure. To test this, using the example above, I generated a routing rule for username buzz on buzzaldrin(dot)com to redirect to buzz(at)mail.buzzaldrin(dot)com:587 and set an A record for mail.buzzaldrin(dot)com to point to a server hosting mail services authoritative for both buzzaldrin(dot)com and mail.buzzaldrin(dot)com and hosting a mailbox with proxy addresses buzz(at)buzzaldrin(dot)com and buzz(at)mail.buzzaldrin(dot)com. No MX record was created for mail.buzzaldrin(dot)com, which is still compliant with rfc5321 section 5.1.

Unfortunately, the verification email was never received, so further testing of this use case wasn’t possible.

To summarize, Email Routing seems to work fine for the simplest “single mailbox on Yahoo” use case, but the target for a feature like this probably wants more. And the feature could be so much more if he following capabilities were added:

  1. Ephemeral bounce routing for generated Return-Path. Perhaps 72 hours.

  2. Target addressing that conforms to rfc5321 section 5.1 with an extension to permit specifying a target port to override default connections to port 25.

  3. Domain validation though DNS TXT record to verify all target addresses at a domain.


I’d be interested to know who/what the bounce routing is for? Someone emails me (via Cloudflare), so Cloudflare accepts their email and then tries to forward it to me. If that forward to me eventually fails, isn’t the bounce back to the original sender (which Cloudflare knows)?

Thanks for the detailed review.

Upstream NDRs/bounces aren’t a concern for the Email Routing service as it works in a synchronous way.
While an email is received by Cloudflare it will forward it to the upstream SMTP. If the upstream rejects the email, Cloudflare will also reject the email. Then, we rely on the sender to retry. This is so we never have to queue or store emails.

The service currently doesn’t support sending email to an A record, this should be fixed under the week. No alternative submission port is supported at the moment.

I’m wondering if the verification email wasn’t send because our email sending service doesn’t support A records as well.

I hope that helps


Upstream NDRs/bounces aren’t a concern for the Email Routing service as it works in a synchronous way.

But the service doesn’t know if the receiving MTA is authoritative for the recipient. If the receiving MTA is just a bridgehead without knowledge of the directory (extremely common), then it will accept the mail for relay and rely on NDR generation happening closer to the mail store. When this MTA generates the NDR because the user is unknown, it will send the NDR to the Return-Path address where you black-hole it. The sending user never knows the message wasn’t delivered.

BTW, this behavior of the bridgehead is by design. By hiding the validity of the envelope recipient (RCPT TO) from the sender, two goals are accomplished:

  1. Valid address harvesting cannot occur. This reduces spam.
  2. NDR generation can be restricted to verified originators (i.e. where SPF and DKIM pass). This is to minimize backscatter.

@sven2 is the sender notified of this?

Also it would be nice to see a log to ensure every email is being forwarded

Remember that because of what I state above, the log can only show the email was forwarded. It cannot show that it was delivered.

If the ephemeral bounce routing is added, then the log can show that a bounce was received on the generated Return-Path address, which would indicate an NDR.

@mike110 good point I hadn’t considered that. We’ll need to add bounces but it’s not supported yet.

1 Like

@sven2: Is there a release log for Email Routing to track progress on this enhancement?

Not at the moment, but we are planning to publish a postmaster doc with technical infos. Maybe a changelog would be useful there


Got in to the preview today, so quick first impressions. I started with a very simple usecase of forwarding a catch-all email to a account.

  • The setup procedure was elegantly simple and easy. DNS records were generated automatically, which leaves no room for typos or copy-paste errors.
  • On the other hand, the user has to manually delete possible old conflicting DNS records. The wizard warned me of the old records, but did not offer to delete them for me – this could be automated?
  • The dashboard could have some simple statistics or a counter about the number of emails forwarded. Since this service forwards the mails to a third party mailbox, it might be useful for troubleshooting problems to see whether the emails reaches Cloudflare and was actually forwarded.
  • As Cloudflare profiles itself as an Internet security company, does the routing service apply anti-spam rules or other defences? This is unclear for me and if it does, again some stats or logs would be useful at the dashboard.

Overall this service very easy to start with and it is very practical to have email routing where your DNS services are. In the future the logical step is the development of the sending/SMTP features, as one directional forwarding does not take you very far.

It doesn’t, it’s just proxy and obviously some DDoS protection. No actual action is taken on emails.

1 Like

My First Impressions (4 hours later)

Works great for what I need it to do
– I am just a regular person, I do not have a business or anything special. I do however have multiple domain names and two of my domains have their own hosting services attached.
– My favorite domain does not have hosting attached and is used in conjunction with a reverse proxy to expose all of my favorite home servers to the net with a convient hostname
+++That being said, I hosted my own email server on a home PC in order to have an email account for that domain (google wasnt very fond of it however, even with DKIM/PTR/SPF/DMARC). I did not like hosting my own email server honestly but I do like that email address…
Now I can easily keep that desired email account and cloudflare forwards it to my other domain/hosting service flawlessly. Inside of that hosting service, I have set it to reply to emails as if it was my favorite domain. Works great, not listed as spam but google says email recieved from via which is perfectly fine for me (also its 100% true).

So as a home user, this has solved a problem for me. Not only that but it was painfully simple to deploy =)
Thanks guys for providing this service and allowing me to be part of the testing group!

1 Like

google wasnt very fond of it however, even with DKIM/PTR/SPF/DMARC

The reason for this is most likely your sending IP address was on Policy Block Lists and your email was scored as spam because of it.

That and having a dynamic ip address and inability to change my public hostname… Nevertheless, I am glad that I do not have to host my own server anymore =)

This thread got hijacked a few times, but the “silent-failure” NDR issue by @mike110 seems like a good reason this service is still marked “beta”. Is there any update on this NDR issue specifically, any way to see changes so we don’t need to ask, or any visibility into “blockers” like this keeping the service “beta”?

1 Like

obviously not :frowning: