Email Routing was announced during Birthday Week in 2021 and has been available for free to every Cloudflare customer since early this year. When we launched in beta, we set out to make a difference and provide the most uncomplicated, more powerful email forwarding service on the Internet for all our customers, for free.
We feel we've met and surpassed our goals for the first year. Cloudflare Email Routing is now one of our most popular features and a top leading email provider. We are processing email traffic for more than 550,000 inboxes and forwarding an average of two million messages daily, and still growing month to month.
All this is good, but what about more features, you ask?
The team has been working hard to enhance Email Routing over the last few months. Today Email Routing leaves beta.
Also, we feel that this could be a good time to give you an update on all the new things we've been adding to the service, including behind-the-scenes and not-so-visible improvements.
Let’s get started.
Public API and Terraform
Cloudflare has a strong API-first philosophy. All of our services expose their primitives in our vast API catalog and gateway, which we then “dogfood” extensively. For instance, our customer's configuration dashboard is built entirely on top of these APIs.
The Email Routing APIs didn't quite make it to this catalog on day one and were kept private and undocumented for a while. This summer we made those APIs available on the public Cloudflare API catalog. You can programmatically use them to manage your destination emails, rules, and other Email Routing settings. The methods' definitions and parameters are documented, and we provide curl examples if you want to get your hands dirty quickly.
Even better, if you're an infrastructure as code type of user and use Terraform to configure your systems automatically, we have you covered too. The latest releases of Cloudflare's Terraform provider now incorporate the Email Routing API resources, which you can use with HCL.
IPv6 adoption is on a sustained growth path. Our latest IPv6 adoption report shows that we're nearing the 30% penetration figure globally, with some countries, where mobile usage is prevalent, exceeding the 50% mark. Cloudflare has offered full IPv6 support since 2011 as it aligns entirely with our mission to help build a better Internet.
We are IPv6-ready across the board in our network and our products, and Email Routing has had IPv6 ingress support since day one.
➜ ~ dig celso.io MX +noall +answer celso.io. 300 IN MX 91 isaac.mx.cloudflare.net. celso.io. 300 IN MX 2 linda.mx.cloudflare.net. celso.io. 300 IN MX 2 amir.mx.cloudflare.net. ➜ ~ dig linda.mx.cloudflare.net AAAA +noall +answer linda.mx.cloudflare.net. 300 IN AAAA 2606:4700:f5::b linda.mx.cloudflare.net. 300 IN AAAA 2606:4700:f5::c linda.mx.cloudflare.net. 300 IN AAAA 2606:4700:f5::d
More recently, we closed the loop and added egress IPv6 as well. Now we also use IPv6 when sending emails to upstream servers. If the MX server to which an email is being forwarded supports IPv6, then we will try to use it. Gmail is one good example of a high traffic destination that has IPv6 MX records.
➜ ~ dig gmail.com MX +noall +answer gmail.com. 3362 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3362 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3362 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 3362 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3362 IN MX 40 alt4.gmail-smtp-in.l.google.com. ➜ ~ dig gmail-smtp-in.l.google.com AAAA +noall +answer gmail-smtp-in.l.google.com. 116 IN AAAA 2a00:1450:400c:c03::1a
We’re happy to report that we’re now delivering most of our email to upstreams using IPv6.
Email Routing is effectively another system that sits in the middle of the life of an email message. No one likes to navigate blindly, especially when using and depending on critical services like email, so it's our responsibility to provide as much observability as possible about what's going on when messages are transiting through our network.
End to end email deliverability is a complex topic and often challenging to troubleshoot due to the nature of the protocol and the number of systems and hops involved. We added two widgets, Analytics and Detailed Logs, which will hopefully provide the needed insights and help increase visibility.
The Analytics section of Email Routing shows general statistics about the number of emails received during the selected timeframe, how they got handled to the upstream destination addresses, and a convenient time-series chart.
On the Activity Log, you can get detailed information about what happened to each individual message that was received and then delivered to the destination. That information includes the sender and the custom address used, the timestamp, and the delivery attempt result. It also has the details of our SPF, DMARC, and DKIM validations. We also provide filters to help you find what you're looking for in case your message volume is higher.
More recently, the Activity Log now also shows bounces. A bounce message happens when the upstream SMTP server accepts the delivery, but then, for any reason (exceeded quota, virus checks, forged messages, or other issues), the recipient inbox decides to reject it and return a new message back with an error to the latest MTA in the chain, read from the Return-Path headers, which is us.
Audit Logs are available on all plan types and summarize the history of events, like login and logout actions, or zone configuration changes, made within your Cloudflare account. Accounts with multiple members or companies that must comply with regulatory obligations rely on Audit logs for tracking and evidence reasons.
Email Routing now integrates with Audit Logs and records all configuration changes, like adding a new address, changing a rule, or editing the catch-all address. You can find the Audit Logs on the dashboard under "Manage Account" or use our API to download the list.
Unsolicited and malicious messages plague the world of email and are a big problem for end users. They affect the user experience and efficiency of email, and often carry security risks that can lead to scams, identity theft, and manipulation.
Since day one, we have supported and validated SPF (Sender Policy Framework) records, DKIM (DomainKeys Identified Mail) signatures, and DMARC (Domain-based Message Authentication) policies in incoming messages. These steps are important and mitigate some risks associated with authenticating the origin of an email from a specific legitimate domain, but they don't solve the problem completely. You can still have bad actors generating spam or phishing Attacks from other domains who ignore SPF or DKIM completely.
Anti-spam techniques today are often based on blocking emails whose origin (the IP address of the client trying to deliver the message) confidence score isn't great. This is commonly known in the industry as IP reputation. Other companies specialize in maintaining reputation lists for IPs and email domains, also known as RBL lists, which are then shared across providers and used widely.
Simply put, an IP or a domain gets a bad reputation when it starts sending unsolicited or malicious emails. If your IP or domain has a bad reputation, you'll have a hard time delivering Emails from them to any major email provider. A bad reputation goes away when the IP or domain stops acting bad.
Cloudflare is a security company that knows a few things about IP threat scores and reputation. Working with the Area1 team and learning from them, we added support to flag and block emails received from what we consider bad IPs at the SMTP level. Our approach uses a combination of heuristics and reputation databases, including some RBL lists, which we constantly update.
This measure benefits not only those customers that receive a lot of spam, who will now get another layer of protection and filtering, but also everyone else using Email Routing. The reputation of our own IP space and forwarding domain, which we use to deliver messages to other email providers, will improve, and with it, so will our deliverability success rate.
Internationalized domain names, or IDNs for short, are domains that contain at least one non-ASCII character. To accommodate backward compatibility with older Internet protocols and applications, the IETF approved the IDNA protocol (Internationalized Domain Names in Applications), which was then adopted by many browsers, top-level domain registrars and other service providers.
Cloudflare was one of the first platforms to adopt IDNs back in 2012. Supporting internationalized domain names on email, though, is challenging. Email uses DNS, SMTP, and other standards (like TLS and DKIM signatures) stacked on top of each other. IDNA conversions need to work end to end, or something will break.
Email Routing didn’t support IDNs until now. Starting today, Email Routing can be used with IDNs and everything will work end to end as expected.
8-bit MIME transport
The SMTP protocol supports extensions since the RFC 2821 revision. When an email client connects to an SMTP server, it announces its capabilities on the EHLO command.
➜ ~ telnet linda.mx.cloudflare.net 25 Trying 188.8.131.52... Connected to linda.mx.cloudflare.net. Escape character is '^]'. 220 mx.cloudflare.net Cloudflare Email ESMTP Service ready EHLO celso.io 250-mx.cloudflare.net greets celso.io 250-STARTTLS 250-8BITMIME 250 ENHANCEDSTATUSCODES
Most modern clients and servers support the 8BITMIME extension, making transmitting binary files easier and more efficient without additional conversions to and from 7-bit.
Email Routing now supports transmitting 8BITMIME SMTP messages end to end and handles DKIM signatures accordingly.
We’ve been making other smaller improvements to Email Routing too:
- We ported our SMTP server to use BoringSSL, Cloudflare’s SSL/TLS implementation of choice, and now support more ciphers when clients connect to us using STARTTLS and when we connect to upstream servers.
- We made a number of improvements when we added our own DKIM signatures in the messages. We keep our Rust ?DKIM implementation open source on GitHub, and we also contribute to Lettre, a Rust mailer library that we use.
- When a destination address domain has multiple MX records, we now try them all in their preference value order, as described in the RFC, until we get a good delivery, or we fail.
Route to Workers update
We announced Route to Workers in May this year. Route to Workers enables everyone to programmatically process their emails and use them as triggers for any other action. In other words, you can choose to process any incoming email with a Cloudflare Worker script and then implement any logic you wish before you deliver it to a destination address or drop it. Think about it as programmable email.
The good news, though, is that we're near completing the project. The APIs, the dashboard configuration screens, the SMTP service, and the necessary Cap'n Proto interface to Workers are mostly complete, and "all" we have left now is adding the Email Workers primitives to the runtime and testing the hell out of everything before we ship.
Thousands of users are waiting for Email Workers to start creating advanced email processing workflows, and we're excited about the possibilities this will open. We promise we're working hard to open the public beta as soon as possible.
We keep looking at ways to improve email and will add more features and support to emerging protocols and extensions. Two examples are ARC (Authenticated Received Chain), a new signature-based authentication system designed with email forwarding services in mind, and EAI (Email Address Internationalization), which we will be supporting soon.
In the meantime, you can start using Email Routing with your own domain if you haven't yet, it only takes a few minutes to set up, and it's free. Our Developers Documentation page has details on how to get started, troubleshooting, and technical information.