Email Routing subdomain support, new APIs and security protocols

By admin

11 min
TIME

read

It’s been

two years
DATE

since we announced

Email Routing
PERSON

, our solution to create custom email addresses for your domains and route incoming emails to your preferred mailbox. Since then, the team has worked hard to evolve the product and add more powerful features to meet our users’ expectations. Examples include

Route to Workers
ORG

, which allows you to process your Emails programmatically using

Workers
ORG

scripts, Public APIs,

Audit Logs
ORG

, or

DMARC Management
ORG

.

We also made significant progress in supporting more email security extensions and protocols, protecting our customers from unwanted traffic, and keeping our IP space reputation for email egress impeccable to maximize our deliverability rates to whatever inbox upstream provider you chose.

Since leaving beta,

Email Routing
PERSON

has grown into one of our most popular products; it’s used by

more than one million
CARDINAL

different customer zones globally, and we forward

around 20 million
CARDINAL

messages

daily
DATE

to every major email platform out there. Our product is mature, robust enough for general usage, and suitable for any production environment. And it keeps evolving:

today
DATE

, we announce

three
CARDINAL

new features that will help make

Email Routing
PERSON

more secure, flexible, and powerful than ever.

New security protocols

The SMTP email protocol has been around since

the early 80s
DATE

. Naturally, it wasn’t designed with the best security practices and requirements in mind, at least not the ones that the Internet expects

today
DATE

. For that reason, several protocol revisions and extensions have been standardized and adopted by the community over

the years
DATE

.

Cloudflare
ORG

is known for being an early adopter of promising emerging technologies;

Email Routing
PERSON

already supports things like SPF, DKIM signatures, DMARC policy enforcement,

TLS
ORG

transport,

STARTTLS
PRODUCT

, and IPv6 egress, to name a few.

Today
DATE

, we are introducing support for

two
CARDINAL

new standards to help increase email security and improve deliverability to

third
ORDINAL

-party upstream email providers.


ARC
ORG

Authenticated Received Chain (

ARC
ORG

) is an email authentication system designed to allow an intermediate email server (such as

Email Routing
PERSON

) to preserve email authentication results. In other words, with

ARC
ORG

, we can securely preserve the results of validating sender authentication mechanisms like SPF and DKIM, which we support when the email is received, and transport that information to the upstream provider when we forward the message.

ARC
ORG

establishes a chain of trust with all the hops the message has passed through. So, if it was tampered with or changed in

one
CARDINAL

of the hops, it is possible to see where by following that chain.

We began rolling out

ARC
ORG

support to

Email Routing
PERSON


a few weeks ago
DATE

. Here’s how it works:

As you can see, [email protected] sends an Email to [email protected] , an Email Routing address, which in turn is forwarded to the final address, [email protected] .


Email Routing
PERSON

will use

@example.com
ORG

’s DMARC policy to check the SPF and DKIM alignments (SPF, DKIM, and DMARC help authenticate email senders by verifying that the emails came from the domain that they claim to be from.) It then stores this authentication result by adding a Arc-Authentication-Results header in the message:

Then we take a snapshot of all the headers and the body of the original message, and we generate an Arc-Message-Signature header with a DKIM-like cryptographic signature (in fact

ARC
ORG

uses the same DKIM keys):

ARC-Message-Signature: i=1; a=rsa-sha256; s=2022; d=email.cloudflare.net; c=relaxed/relaxed; h=To:Date:Subject:From:reply-to:cc:resent-date:resent-from:resent-to :resent-cc:in-reply-to:references:list-id:list-help:list-unsubscribe :list-subscribe:list-post:list-owner:list-archive; t=1697709687; bh=sN/+…

aNbf==
ORG

;

Finally, before forwarding the message to [email protected] ,

Email Routing
PERSON

generates the Arc-Seal header, another DKIM-like signature, composed out of

the Arc-Authentication-Results
EVENT

and Arc-Message-Signature , and cryptographically “seals” the message:

ARC-Seal: i=1; a=rsa-sha256; s=2022; d=email.cloudflare.net; cv=none; b=Lx35lY6..

t4g==
PERSON

;

When

Gmail
PERSON

receives the message from

Email Routing
PERSON

, it not only normally authenticates the last hop domain.example domain (

Email Routing
PERSON

uses SRS), but it also checks the

ARC
ORG

seal header, which provides the authentication results of the original sender.


ARC
ORG

increases the traceability of the message path through email intermediaries, allowing for more informed delivery decisions by those who receive emails as well as higher deliverability rates for those who transport them, like

Email Routing
PERSON

. It has been adopted by all the major email providers like

Gmail
ORG

and

Microsoft
ORG

. You can read more about the

ARC
ORG

protocol in the

RFC8617
GPE

.


MTA
ORG

-STS

As we said earlier, SMTP is an old protocol. Initially Email communications were done in the clear, in plain-text and unencrypted. At some point in time in

the late 90s
DATE

, the email providers community standardized

STARTTLS
PRODUCT

, also known as Opportunistic TLS. The

STARTTLS
LOC

extension allowed a client in a SMTP session to upgrade to

TLS
ORG

encrypted communications.

While at the time this seemed like a step forward in the right direction, we later found out that because

STARTTLS
LOC

can start with an unencrypted plain-text connection, and that can be hijacked, the protocol is susceptible to man-in-the-middle attacks.


A few years ago
DATE


MTA Strict Transport Security
ORG

(

MTA-STS
ORG

) was introduced by email service providers including

Microsoft
ORG

,

Google
ORG

and

Yahoo
ORG

as a solution to protect against downgrade and man-in-the-middle attacks in SMTP sessions, as well as solving the lack of security-

first
ORDINAL

communication standards in email.

Suppose that example.com uses Email Routing. Here’s how you can enable

MTA
ORG

-STS for it.


First
ORDINAL

, log in to the

Cloudflare
ORG

dashboard and select your account and zone. Then go to

DNS > Records
ORG

and create a new

CNAME
ORG

record with the name “ _mta-sts ” that points to

Cloudflare
ORG

’s record “ _mta-sts.mx.cloudflare.net ”. Make sure to disable the proxy mode.

Confirm that the record was created:

$ dig txt _mta-sts.example.com _mta-sts.example.com.

300
CARDINAL

IN CNAME _mta-sts.mx.cloudflare.net. _mta-sts.mx.cloudflare.net.

300
CARDINAL

IN TXT "v=STSv1; id=20230615T153000;"

This tells the other end client that is trying to connect to us that we support

MTA
ORG

-STS.

Next you need an HTTPS endpoint at mta-sts.example.com to serve your policy file. This file defines the mail servers in the domain that use

MTA
ORG

-STS. The reason why HTTPS is used here instead of

DNS
ORG

is because not everyone uses DNSSEC yet, so we want to avoid another MITM attack vector.

To do this you need to deploy a very simple

Worker
ORG

that allows Email clients to pull

Cloudflare
ORG

’s

Email Routing
ORG

policy file using the “well-known” URI convention. Go to your

Account > Workers & Pages
ORG

and press

Create Application
ORG

. Pick the “MTA-STS” template from the list.

This Worker simply proxies https://mta-sts.mx.cloudflare.net/.well-known/mta-sts.txt to your own domain. After deploying it, go to the

Worker
ORG

configuration, then

Triggers > Custom Domains and Add Custom Domain
WORK_OF_ART

.

You can then confirm that your policy file is working:

$ curl

https://mta-sts.example.com/.well-known/mta-sts.txt
ORG

version: STSv1 mode: enforce mx: *.mx.cloudflare.net max_age:

86400
ORG

This says that we enforce

MTA
ORG

-STS. Capable email clients will only deliver email to this domain over a secure connection to the specified

MX
PRODUCT

servers. If no secure connection can be established the email will not be delivered.


Email Routing
PERSON

also supports

MTA
ORG

-STS upstream, which greatly improves security when forwarding your Emails to service providers like

Gmail
ORG

or

Microsoft
ORG

, and others.

While enabling

MTA
ORG

-STS involves a few steps

today
DATE

, we plan to simplify things for you and automatically configure

MTA
ORG

-STS for your domains from the

Email Routing
ORG

dashboard as a future improvement.

Sending emails and replies from

Workers
ORG


Last year
DATE

we announced

Email Workers
ORG

, allowing anyone using

Email Routing
PERSON

to associate a

Worker
ORG

script to an Email address rule, and programmatically process their incoming emails in any way they want. Workers is our serverless compute platform, it provides

hundreds
CARDINAL

of features and APIs, like databases and storage.

Email Workers
ORG

opened doors to a flood of use-cases and applications that weren’t possible before like implementing allow/block lists, advanced rules, notifications to messaging applications, honeypot aggregators and more.

Still, you could only act on the incoming email event. You could read and process the email message, you could even manipulate and create some headers, but you couldn’t rewrite the body of the message or create new emails from scratch.


Today
DATE

we’re announcing

two
CARDINAL

new powerful

Email Workers
ORG

APIs that will further enhance what you can do with

Email Routing and Workers
ORG

.

Send emails from Workers

Now you can send an email from any

Worker
ORG

, from scratch, whenever you want, not just when you receive incoming messages, to any email address verified on

Email Routing
PERSON

under your account. Here are a few practical examples where sending email from

Workers
ORG

to your verified addresses can be helpful:

Daily digests with the news from your favorite publications.

Alert messages whenever the weather conditions are adverse.

Automatic notifications when systems complete tasks.

Receive a message composed of the inputs of a form online on a contact page.

Let’s see a simple example of a

Worker
ORG

sending an email.

First
ORDINAL

you need to create “ send_email ” bindings in your wrangler.toml configuration:

send_email = [ {type = "send_email", name = "EMAIL_OUT"} ]

And then creating a new message and sending it in a

Workers
ORG

is as simple as:

import { EmailMessage } from "cloudflare:email"; import { createMimeMessage } from "mimetext"; export default { async fetch(request, env) { const msg = createMimeMessage(); msg.setSender({ name: "Workers AI story", addr: "[email protected]" });

msg.setRecipient("[email
PERSON

protected]");

msg.setSubject("An
PERSON

email generated in a worker"); msg.addMessage({ contentType: ‘text/plain’, data: `Congratulations, you just sent an email from a worker.` }); var message = new EmailMessage( "[email protected]", "[email protected]",

msg.asRaw
PERSON

() ); try { await env.EMAIL_OUT.send(message); } catch (e) { return new Response(e.message); } return new

Response("email
DATE

sent!"); }, };

This example makes use of mimetext, an open-source raw email message generator.

Again, for security reasons, you can only send emails to the addresses for which you confirmed ownership in

Email Routing
ORG

under your

Cloudflare
ORG

account. If you’re looking for sending email campaigns or newsletters to destination addresses that you do not control or larger subscription groups, you should consider other options like our

MailChannels
ORG

integration.

Since sending Emails from

Workers
ORG

is not tied to the

EmailEvent
ORG

, you can send them from any type of

Worker
ORG

, including

Cron Triggers
ORG

and

Durable Objects
PERSON

, whenever you want, you control all the logic.

Reply to emails


One
CARDINAL

of our most-requested features has been to provide a way to programmatically respond to incoming emails. It has been possible to do this with

Email Workers
ORG

in a very limited capacity by returning a permanent SMTP error message — but this may or may not be visible to the end user depending on the client implementation.

export default { async email(message, env, ctx) { message.setReject("Address not allowed"); } }

As of

today
DATE

, you can now truly reply to incoming emails with another new message and implement smart auto-responders programmatically, adding any content and context in the main body of the message. Think of a customer support email automatically generating a ticket and returning the link to the sender, an out-of-office reply with instructions when you’re on vacation, or a detailed explanation of why you rejected an email. Here’s a code example:

To mitigate security risks and abuse, replying to incoming emails has a few requirements:

The incoming email has to have valid DMARC.

The email can only be replied to once.

The In-Reply-To header of the reply message must match

the Message-ID
LAW

of the incoming message.

header of the reply message must match the of the incoming message. The recipient of the reply must match the incoming sender.

The outgoing sender domain must match the same domain that received the email.

If these and other internal conditions are not met, then reply() will fail with an exception, otherwise you can freely compose your reply message and send it back to the original sender.

For more information the documentation to these APIs is available in our Developer Docs.

Subdomains support

This is a big one.


Email Routing
PERSON

is a zone-level feature. A zone has a top-level domain (the same as the zone name) and it can have subdomains (managed under the

DNS
ORG

feature.) As an example, I can have the example.com zone, and then the mail.example.com and corp.example.com subdomains under it. However, we can only use

Email Routing
PERSON

with the top-level domain of the zone, example.com in this example. While this is fine for the vast majority of use cases, some customers — particularly bigger organizations with complex email requirements — have asked for more flexibility.

This changes

today
DATE

. Now you can use

Email Routing
WORK_OF_ART

with any subdomain of any zone in your account. To make this possible we redesigned the dashboard

UI
ORG

experience to make it easier to get you started and manage all your

Email Routing
PERSON

domains and subdomains, rules and destination addresses in

one
CARDINAL

single place. Let’s see how it works.

To add

Email Routing
PERSON

features to a new subdomain, log in to the

Cloudflare
ORG

dashboard and select your account and zone. Then go to Email > Email Routing > Settings and click “Add subdomain”.

Once the subdomain is added and the

DNS
ORG

records are configured, you can see it in the Settings list under the Subdomains section:

Now you can go to Email > Email Routing > Routing rules and create new custom addresses that will show you the option of using either the top domain of the zone or any other configured subdomain.

After the new custom address for the subdomain is created you can see it in the list with all the other addresses, and manage it from there.

It’s this easy.

Final words

We hope you enjoy the new features that we are announcing

today
DATE

. Still, we want to be clear: there are no changes in pricing, and

Email Routing
PERSON

is still free for

Cloudflare
ORG

customers.

Ever since

Email Routing
PERSON

was launched, we’ve been listening to customers’ feedback and trying to adjust our roadmap to both our requirements and their own ideas and requests. Email shouldn’t be difficult; our goal is to listen, learn and keep improving the service with better, more powerful features.

You can find detailed information about the new features and more in our

Email Routing Developer Docs
ORG

.

If you have any questions or feedback about

Email Routing
PERSON

, please come see us in

the Cloudflare Community
ORG

and

the Cloudflare Discord
ORG

.