# Overview URL: https://developers.cloudflare.com/email-routing/ import { Description, Feature, Plan, RelatedProduct, Render } from "~/components" Create custom email addresses for your domain and route incoming emails to your preferred mailbox. It is available to all Cloudflare customers [using Cloudflare as an authoritative nameserver](/dns/zone-setups/full-setup/). *** ## Features Leverage the power of Cloudflare Workers to implement any logic you need to process your emails. Create rules as complex or simple as you need. With Email Routing you can have many custom email addresses to use for specific situations. Email Routing includes metrics to help you check on your email traffic history. *** ## Related products Cloudflare Area 1 Email Security is a cloud-native service that stops phishing attacks, the biggest cybersecurity threat, across all threat vectors - email, web, and network - either at the edge or in the cloud. Email Routing is available to customers using Cloudflare as an authoritative nameserver. --- # Limits URL: https://developers.cloudflare.com/email-routing/limits/ import { Render } from "~/components" ## Email Workers size limits When you process emails with Email Workers and you are on [Workers’ free pricing tier](/workers/platform/pricing/) you might encounter an allocation error. This may happen due to the size of the emails you are processing and/or the complexity of your Email Worker. Refer to [Worker limits](/workers/platform/limits/#worker-limits) for more information. You can use the [log functionality for Workers](/workers/observability/logs/) to look for messages related to CPU limits (such as `EXCEEDED_CPU`) and troubleshoot any issues regarding allocation errors. If you encounter these error messages frequently, consider upgrading to the [Workers Paid plan](/workers/platform/pricing/) for higher usage limits. ## Message size Currently, Email Routing does not support messages bigger than 25 MiB. ## Rules and addresses | Feature | Limit | | -------------------------------------------------------------------------------- | ----- | | [Rules](/email-routing/setup/email-routing-addresses/) | 200 | | [Addresses](/email-routing/setup/email-routing-addresses/#destination-addresses) | 200 | ## Email Routing summary for emails sent through Workers Emails sent through Workers will show up in the Email Routing summary page as dropped even if they were successfully delivered. --- # Postmaster URL: https://developers.cloudflare.com/email-routing/postmaster/ This page provides technical information about Email Routing to professionals who administer email systems, and other email providers. Here you will find information regarding Email Routing, along with best practices, rules, guidelines, troubleshooting tools, as well as known limitations for Email Routing. ## Postmaster ### Authenticated Received Chain (ARC) Email Routing supports [Authenticated Received Chain (ARC)](http://arc-spec.org/). ARC is an email authentication system designed to allow an intermediate email server (such as Email Routing) to preserve email authentication results. Google also supports ARC. ### Contact information The best way to contact us is using our [community forum](https://community.cloudflare.com/new-topic?category=Feedback/Previews%20%26%20Betas&tags=email) or our [Discord server](https://discord.com/invite/cloudflaredev). ### DKIM signature [DKIM (DomainKeys Identified Mail)](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail) ensures that email messages are not altered in transit between the sender and the recipient's SMTP servers through public-key cryptography. Through this standard, the sender publishes its public key to a domain's DNS once, and then signs the body of each message before it leaves the server. The recipient server reads the message, gets the domain public key from the domain's DNS, and validates the signature to ensure the message was not altered in transit. Email Routing signs email on behalf of `email.cloudflare.net`. If the sender did not sign the email, the receiver will likely use Cloudflare's signature for authentication. Below is the DKIM key for `email.cloudflare.net`: ```sh dig TXT 2022._domainkey.email.cloudflare.net +short ``` ```sh output "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnraPy1d8e6+lzeE1HIoUvYWoAOUSREkNHcwxA/ueVM8f6FKXvPu/9gVpgkn8iUyaCfk2z1MW+OVLuFeH64YRMa39mkaQalgke2tZ05SnjRUtYEHYvfrqPuMT+Ouk+GecpgvrtMq5gMXm6ZfeUhQkdWxmMQJGf4fdW5I0piUQJMhK/Qc1dNRSskk" "TiUtXKnsEdjTN2xcnHhyj985S0xOEAxm9Uj1rykPqVvKpqEdjUkujbXOwR0KmHTvPyFpBjCCfxAVqOwwo9zBYuvk/nh0qlDgLIpy0SimrYhNFCq2XBxIj4tdUzIl7qZ5Ck6zLCQ+rjzJ4sm/zA+Ov9kDkbcmyrwIDAQAB" ``` ### DMARC enforcing Email Routing enforces Domain-based Message Authentication, Reporting & Conformance (DMARC). Depending on the sender's DMARC policy, Email Routing will reject emails when there is an authentication failure. Refer to [dmarc.org](https://dmarc.org/) for more information on this protocol. ### IPv6 support Currently, Email Routing will connect to the upstream SMTP servers using IPv6 if they provide AAAA records for their MX servers, and fall back to IPv4 if that is not possible. Below is an example of a popular provider that supports IPv6: ```sh dig mx gmail.com ``` ```sh output gmail.com. 3084 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3084 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3084 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3084 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 3084 IN MX 30 alt3.gmail-smtp-in.l.google.com. ``` ```sh dig AAAA gmail-smtp-in.l.google.com ``` ```sh output gmail-smtp-in.l.google.com. 17 IN AAAA 2a00:1450:400c:c09::1b ``` Email Routing also supports IPv6 through Cloudflare’s inbound MX servers. ### MX, SPF, and DKIM records Email Routing automatically adds a few DNS records to the zone when our customers enable Email Routing. If we take `example.com` as an example: ```txt example.com. 300 IN MX 13 amir.mx.cloudflare.net. example.com. 300 IN MX 86 linda.mx.cloudflare.net. example.com. 300 IN MX 24 isaac.mx.cloudflare.net. example.com. 300 IN TXT "v=spf1 include:_spf.mx.cloudflare.net ~all" ``` [The MX (mail exchange) records](https://www.cloudflare.com/learning/dns/dns-records/dns-mx-record/) tell the Internet where the inbound servers receiving email messages for the zone are. In this case, anyone who wants to send an email to `example.com` can use the `amir.mx.cloudflare.net`, `linda.mx.cloudflare.net`, or `isaac.mx.cloudflare.net` SMTP servers. ### Outbound hostnames In addition to the outbound prefixes, Email Routing will use the domain `email.cloudflare.net` for the `HELO/EHLO` command. PTR records (reverse DNS) ensure that each hostname has an corresponding IP. For example: ```sh dig a0-7.email.cloudflare.net +short ``` ```sh output 104.30.0.7 ``` ```sh dig -x 104.30.0.7 +short ``` ```sh output a0-7.email.cloudflare.net. ``` ### Outbound prefixes Email Routing sends its traffic using both IPv4 and IPv6 prefixes, when supported by the upstream SMTP server. If you are a postmaster and are having trouble receiving Email Routing's emails, allow the following outbound IP addresses in your server configuration: **IPv4** `104.30.0.0/20` **IPv6** `2405:8100:c000::/38` _Ranges last updated: December 13th, 2023_ ### Sender rewriting Email Routing rewrites the SMTP envelope sender (`MAIL FROM`) to the forwarding domain to avoid issues with [SPF](#spf-record). Email Routing uses the [Sender Rewriting Scheme](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) to achieve this. This has no effect to the end user's experience, though. The message headers will still report the original sender's `From:` address. ### SMTP errors In most cases, Email Routing forwards the upstream SMTP errors back to the sender client in-session. ### Spam and abusive traffic Handling spam and abusive traffic is essential to any email provider. Email Routing filters emails based on advanced anti-spam criteria, [powered by Email Security (formerly Area 1)](/email-security/). When Email Routing detects and blocks a spam email, you will receive a message with details explaining what happened. For example: ```txt 554 found on one or more DNSBLs (abusixip). Refer to https://developers.cloudflare.com/email-routing/postmaster/#spam-and-abusive-traffic/ ``` ### SPF record A SPF DNS record is an anti-spoofing mechanism that is used to specify which IP addresses and domains are allowed to send emails on behalf of your zone. The Internet Engineering Task Force (IETF) tracks the SPFv1 specification [in RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). Refer to the [SPF Record Syntax](http://www.open-spf.org/SPF_Record_Syntax/) to learn the SPF syntax. Email Routing's SPF record contains the following: ```txt v=spf1 include:_spf.mx.cloudflare.net ~all ``` In the example above: - `spf1`: Refers to SPF version 1, the most common and more widely adopted version of SPF. - `include`: Include a second query to `_spf.mx.cloudflare.net` and allow its contents. - `~all`: Otherwise [`SoftFail`](http://www.open-spf.org/SPF_Record_Syntax/) on all other origins. `SoftFail` means NOT allowed to send, but in transition. This instructs the upstream server to accept the email but mark it as suspicious if it came from any IP addresses outside of those defined in the SPF records. If we do a TXT query to `_spf.mx.cloudflare.net`, we get: ```txt _spf.mx.cloudflare.net. 300 IN TXT "v=spf1 ip4:104.30.0.0/20 ~all" ``` This response means: - Allow all IPv4 IPs coming from the `104.30.0.0/20` subnet. - Otherwise, `SoftFail`. You can read more about SPF, DKIM, and DMARC in our [Tackling Email Spoofing and Phishing](https://blog.cloudflare.com/tackling-email-spoofing/) blog. --- ## Known limitations Below, you will find information regarding known limitations for Email Routing. ### Email address internationalization (EAI) Email Routing does not support [internationalized email addresses](https://en.wikipedia.org/wiki/International_email). Email Routing only supports [internationalized domain names](https://en.wikipedia.org/wiki/Internationalized_domain_name). This means that you can have email addresses with an internationalized domain, but not an internationalized local-part (the first part of your email address, before the `@` symbol). Refer to the following examples: - `info@piñata.es` - Supported. - `piñata@piñata.es` - Not supported. ### Non-delivery reports (NDRs) Email Routing does not forward non-delivery reports to the original sender. This means the sender will not receive a notification indicating that the email did not reach the intended destination. ### Restrictive DMARC policies can make forwarded emails fail Due to the nature of email forwarding, restrictive DMARC policies might make forwarded emails fail to be delivered. Refer to [dmarc.org](https://dmarc.org/wiki/FAQ#My_users_often_forward_their_emails_to_another_mailbox.2C_how_do_I_keep_DMARC_valid.3F) for more information. ### Sending or replying to an email from your Cloudflare domain Email Routing does not support sending or replying from your Cloudflare domain. When you reply to emails forwarded by Email Routing, the reply will be sent from your destination address (like `my-name@gmail.com`), not your custom address (like `info@my-company.com`). ### Signs such "`+`" and "`.`" are treated as normal characters for custom addresses Email Routing does not have advanced routing options. Characters such as `+` or `.`, which perform special actions in email providers like Gmail and Outlook, are currently treated as normal characters on custom addresses. More flexible routing options are in our roadmap. --- # Demos URL: https://developers.cloudflare.com/email-routing/email-workers/demos/ import { ExternalResources, GlossaryTooltip } from "~/components" Learn how you can use Email Workers within your existing architecture. ## Demos Explore the following demo applications for Email Workers. --- # Edit Email Workers URL: https://developers.cloudflare.com/email-routing/email-workers/edit-email-workers/ import { Render } from "~/components" Adding or editing Email Workers is straightforward. You can rename, delete or edit Email Workers, as well as change the routes bound to a specific Email Worker. ## Add an Email worker 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email Workers**. 3. Select **Create**. ## Edit an Email Worker 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email Workers**. 3. Find the Email Worker you want to rename, and select the three-dot button next to it. 4. Select **Code editor**. 5. Make the appropriate changes to your code. 6. Select **Save and deploy** when you are finished editing. ## Rename Email Worker When you rename an Email Worker, you will lose the route that was previously bound to it. You will need to configure the route again after renaming the Email Worker. 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email workers**. 3. Find the Email Worker you want to rename, and select the three-dot button next to it. 4. From the drop-down menu, select **Manage Worker**. 5. Select **Manage Service** > **Rename service**, and fill in the new Email Worker’s name. 6. Select **Continue** > **Move**. 7. Acknowledge the warning and select **Finish**. 8. Now, go back to **Email** > **Email Routing**. 9. In **Routes** find the custom address you previously had associated with your Email Worker, and select **Edit**. 10. In the **Destination** drop-down menu, select your renamed Email Worker. 11. Select **Save**. ## Edit route The following steps show how to change a route associated with an Email Worker. 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email workers**. 3. Find the Email Worker you want to change the associated route, and select **route** on its card. 4. Select **Edit** to make the required changes. 5. Select **Save** to finish. ## Delete an Email Worker 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email workers**. 3. Find the Email Worker you want to delete, and select the three-dot button next to it. 4. From the drop-down menu, select **Manage Worker**. 5. Select **Manage Service** > **Delete**. 6. Type the name of the Email Worker to confirm you want to delete it, and select **Delete**. --- # Enable Email Workers URL: https://developers.cloudflare.com/email-routing/email-workers/enable-email-workers/ import { Render } from "~/components" Follow these steps to enable and add your first Email Worker. If you have never used Cloudflare Workers before, Cloudflare will create a subdomain for you, and assign you to the Workers [free pricing plan](/workers/platform/pricing/). 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Email Workers**. 3. Select **Get started**. --- # Email Workers URL: https://developers.cloudflare.com/email-routing/email-workers/ With Email Workers you can leverage the power of Cloudflare Workers to implement any logic you need to process your emails and create complex rules. These rules determine what happens when you receive an email. Creating your own rules with Email Workers is as easy or complex as you want. You can begin using one of the starter templates that are pre-populated with code for popular use-cases. These templates allow you to create a blocklist, allowlist, or send notifications to Slack. If you prefer, you can skip the templates and use custom code. You can, for example, create logic that only accepts messages from a specific address, and then forwards them to one or more of your verified email addresses, while also alerting you on Slack. The following is an example of an allowlist Email Worker: ```js export default { async email(message, env, ctx) { const allowList = ["friend@example.com", "coworker@example.com"]; if (allowList.indexOf(message.from) == -1) { message.setReject("Address not allowed"); } else { await message.forward("inbox@corp"); } } } ``` Refer to the [Workers Languages](/workers/languages/) for more information regarding the languages you can use with Workers. ## How to use Email Workers To use Email Routing with Email Workers there are three steps involved: 1. Creating the Email Worker. 2. Adding the logic to your Email Worker (like email addresses allowed or blocked from sending you emails). 3. Binding the Email Worker to a route. This is the email address that forwards emails to the Worker. The route, or email address, bound to the Worker forwards emails to your Email Worker. The logic in the Worker will then decide if the email is forwarded to its final destination or dropped, and what further actions (if any) will be applied. For example, say that you create an allowlist Email Worker and bind it to a `hello@my-company.com` route. This route will be the email address you share with the world, to make sure that only email addresses on your allowlist are forwarded to your destination address. All other emails will be dropped. ## Limits If you encounter any allocation errors while using Email Workers, refer to [Limits](/email-routing/limits/#email-workers-size-limits) for more information. --- # Reply to emails from Workers URL: https://developers.cloudflare.com/email-routing/email-workers/reply-email-workers/ You can 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 are on vacation, or a detailed explanation of why you rejected an email. Reply to emails is a new method of the [`EmailMessage` object](/email-routing/email-workers/runtime-api/#emailmessage-definition) in the Runtime API. Here is how it works: ```js import { EmailMessage } from "cloudflare:email"; import { createMimeMessage } from "mimetext"; export default { async email(message, env, ctx) { const ticket = createTicket(message); const msg = createMimeMessage(); msg.setHeader("In-Reply-To", message.headers.get("Message-ID")); msg.setSender({ name: "Thank you for your contact", addr: "@example.com" }); msg.setRecipient(message.from); msg.setSubject("Email Routing Auto-reply"); msg.addMessage({ contentType: 'text/plain', data: `We got your message, your ticket number is ${ ticket.id }` }); const replyMessage = new EmailMessage( "@example.com", message.from, msg.asRaw() ); await message.reply(replyMessage); } } ``` To mitigate security risks and abuse, replying to incoming emails has a few requirements: * The incoming email has to have valid [DMARC](https://www.cloudflare.com/learning/dns/dns-records/dns-dmarc-record/). * The email can only be replied to once in the same `EmailMessage` event. * The `In-Reply-To` header of the reply message must be set to the `Message-ID` of the incoming message. * The recipient in 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. --- # Runtime API URL: https://developers.cloudflare.com/email-routing/email-workers/runtime-api/ ## Background An `EmailEvent` is the event type to programmatically process your emails with a Worker. You can reject, forward, or drop emails according to the logic you construct in your Worker. *** ## Syntax: Service Worker `EmailEvent` can be handled in Workers functions written using the Service Worker syntax by attaching to the `email` event with `addEventListener`: ```js addEventListener("email", (event) => { event.message.forward(""); }); ``` ### Properties * `event.message` EmailMessage * An [`EmailMessage` object](#emailmessage-definition). *** ## Syntax: ES modules `EmailEvent` can be handled in Workers functions written using the [ES modules format](/workers/reference/migrate-to-module-workers/) by adding an `email` function to your module's exported handlers: ```js export default { async email(message, env, ctx) { message.forward(""); }, }; ``` ### Parameters * `message` EmailMessage * An [`EmailMessage` object](#emailmessage-definition). * `env` object * An object containing the bindings associated with your Worker using ES modules format, such as KV namespaces and Durable Objects. * `ctx` object * An object containing the context associated with your Worker using ES modules format. Currently, this object just contains the `waitUntil` function. *** ## `EmailMessage` definition ```ts interface EmailMessage { readonly from: string; readonly to: string; readonly headers: Headers; readonly raw: ReadableStream; readonly rawSize: number; public constructor(from: string, to: string, raw: ReadableStream | string); setReject(reason: string): void; forward(rcptTo: string, headers?: Headers): Promise; reply(message: EmailMessage): Promise; } ``` * `from` string * `Envelope From` attribute of the email message. * `to` string * `Envelope To` attribute of the email message. * `headers` Headers * A [`Headers` object](https://developer.mozilla.org/en-US/docs/Web/API/Headers). * `raw` ReadableStream * [Stream](/workers/runtime-apis/streams/readablestream) of the email message content. * `rawSize` number * Size of the email message content. * setReject(reasonstring) : void * Reject this email message by returning a permanent SMTP error back to the connecting client, including the given reason. * forward(rcptTostring, headersHeadersoptional) : Promise * Forward this email message to a verified destination address of the account. If you want, you can add extra headers to the email message. Only `X-*` headers are allowed. * When the promise resolves, the message is confirmed to be forwarded to a verified destination address. * reply(messageEmailMessage) : Promise * Reply to the sender of this email message with a new EmailMessage object. * When the promise resolves, the message is confirmed to be replied. --- # Send emails from Workers URL: https://developers.cloudflare.com/email-routing/email-workers/send-email-workers/ import { Render, WranglerConfig } from "~/components" ```toml send_email = [ {name = "", destination_address = "@example.com"}, ] ``` ## Types of bindings There are three types of bindings: * **No attribute defined**: When you do not define an attribute, the binding has no restrictions in place. You can use it to send emails to any verified email address [through Email Routing](/email-routing/setup/email-routing-addresses/#destination-addresses). * **`destination_address`**: When you define the `destination_address` attribute, you create a targeted binding. This means you can only send emails to the chosen email address. For example, `{type = "send_email", name = "", destination_address = "@example.com"}`.
For this particular binding, when you call the `send_email` function you can pass `null` or `undefined` to your Worker and it will assume the email address specified in the binding. * **`allowed_destination_addresses`**: When you specify this attribute, you create an allowlist, and can send emails to any email address on the list. ## Example Worker Refer to the example below to learn how to construct a Worker capable of sending emails. This example uses [MIMEText](https://www.npmjs.com/package/mimetext): :::note The sender has to be an email from the domain where you have Email Routing active. ::: ```js import { EmailMessage } from "cloudflare:email"; import { createMimeMessage } from "mimetext"; export default { async fetch(request, env) { const msg = createMimeMessage(); msg.setSender({ name: "GPT-4", addr: "@example.com" }); msg.setRecipient("@example.com"); msg.setSubject("An email generated in a worker"); msg.addMessage({ contentType: 'text/plain', data: `Congratulations, you just sent an email from a worker.` }); var message = new EmailMessage( "@example.com", "@example.com", msg.asRaw() ); try { await env.SEB.send(message); } catch (e) { return new Response(e.message); } return new Response("Hello Send Email World!"); }, }; ``` --- # Audit logs URL: https://developers.cloudflare.com/email-routing/get-started/audit-logs/ Audit logs for Email Routing are available in the [Cloudflare dashboard](https://dash.cloudflare.com/?account=audit-log). The following changes to Email Routing will be displayed: * Add/edit Rule * Add address * Address change status * Enable/disable/unlock zone Refer to [Review audit logs](/fundamentals/setup/account/account-security/review-audit-logs/) for more information. --- # Analytics URL: https://developers.cloudflare.com/email-routing/get-started/email-routing-analytics/ The Overview page shows you a summary of your account. You can check details such as how many custom and destination addresses you have configured, as well as the status of your routing service. ## Email Routing summary In Email Routing summary you can check metrics related the number of emails received, forwarded, dropped, and rejected. To filter this information by time interval, select the drop-down menu. You can choose preset periods between the previous 30 minutes and 30 days, as well as a custom date range. ## Activity Log This section allows you to sort through emails received, and check Email Routing actions - for example, `Forwarded`, `Dropped`, or `Rejected`. Select a specific email to expand its details and check information regarding the [SPF](https://datatracker.ietf.org/doc/html/rfc7208), [DKIM](https://datatracker.ietf.org/doc/html/rfc6376), and [DMARC](https://datatracker.ietf.org/doc/html/rfc7489) statuses. Depending on the information shown, you can opt to mark an email as spam or block the sender. --- # Enable Email Routing URL: https://developers.cloudflare.com/email-routing/get-started/enable-email-routing/ :::caution[Important] Enabling Email Routing adds the appropriate `MX` records to the DNS settings of your zone in order for the service to work. You can [change these `MX` records](/email-routing/setup/email-routing-dns-records/) at any time. However, depending on how you configure them, Email Routing might stop working. ::: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing**. 3. Review the records that will be added to your zone. 4. Select **Add records and enable**. 5. Go to **Routing rules**. 6. For **Custom addresses**, select **Create address**. 7. Enter the custom email address you want to use (for example, `my-new-email@example.com`). 8. In **Destination addresses**, enter the full email address you want your emails to be forwarded to — for example, `your-name@example.com`. :::note[Notes] If you have several destination addresses linked to the same custom email address (rule), Email Routing will only process the most recent rule. To avoid this, do not link several destination addresses to the same custom address. The current implementation of email forwarding only supports a single destination address per custom address. To forward a custom address to multiple destinations you must create a Workers script to redirect the email to each destination. All the destinations used in the Workers script must be already validated. ::: 9. Select **Save**. 10. Cloudflare will send a verification email to the address provided in the **Destination address** field. You must verify your email address before being able to proceed. 11. In the verification email Cloudflare sent you, select **Verify email address** > **Go to Email Routing** to activate Email Routing. 12. Your Destination address should now show **Verified**, under **Status**. Select **Continue**. 13. Cloudflare needs to add the relevant `MX` and `TXT` records to DNS records for Email Routing to work. This step is automatic and is only needed the first time you configure Email Routing. It is meant to ensure you have the proper records configured in your zone. Select **Add records and finish**. Email Routing is now enabled. You can add other custom addresses to your account. :::note When Email Routing is configured and running, no other email services can be active in the domain you are configuring. If there are other `MX` records already configured in DNS, Cloudflare will ask you if you wish to delete them. If you do not delete existing `MX` records, Email Routing will not be enabled. ::: --- # Get started URL: https://developers.cloudflare.com/email-routing/get-started/ import { DirectoryListing } from "~/components" To enable Email Routing, start by creating a custom email address linked to a destination address or Email Worker. This forms an **email rule**. You can enable or disable rules from the Cloudflare dashboard. Refer to [Enable Email Routing](/email-routing/get-started/enable-email-routing) for more details. Custom addresses you create with Email Routing work as forward addresses only. Emails sent to custom addresses are forwarded by Email Routing to your destination inbox. Cloudflare does not process outbound email, and does not have an SMTP server. The first time you access Email Routing, you will see a wizard guiding you through the process of creating email rules. You can skip the wizard and add rules manually. If you need to pause Email Routing or offboard to another service, refer to [Disable Email Routing](/email-routing/setup/disable-email-routing/). --- # Disable Email Routing URL: https://developers.cloudflare.com/email-routing/setup/disable-email-routing/ Email Routing provides two options for disabling the service: * **Delete and Disable**: This option will immediately disable Email Routing and remove its `MX` records. Your custom email addresses will stop working, and your email will not be routed to its final destination. * **Unlock and keep DNS records**: (Advanced) This option is recommended if you plan to migrate to another provider. It allows you to add new `MX` records before disabling the service. Email Routing will stop working when you change your `MX` records. ## Delete and disable Email Routing 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Settings**. 3. Select **Start disabling** > **Delete and Disable**. Email Routing will show you the list of records associated with your account that will be deleted. 4. Select **Delete records**. Email Routing is now disabled for your account and will stop forwarding email. To enable the service again, select **Enable Email Routing** and follow the wizard. ## Unlock and keep DNS records 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Settings**. 3. Select **Start disabling** > **Unlock records and continue**. 4. Select **Edit records on DNS**. You now have the option to edit your DNS records to migrate your service to another provider. :::caution Changing your DNS records will make Email Routing stop working. If you changed your mind and want to keep Email Routing working with your account, select **Lock DNS records**. ::: --- # Test Email Routing URL: https://developers.cloudflare.com/email-routing/get-started/test-email-routing/ To test that your configuration is working properly, send an email to the custom address [you set up in the dashboard](/email-routing/get-started/enable-email-routing/). You should send your test email from a different address than the one you specified as the destination address. For example, if you set up `your-name@gmail.com` as the destination address, do not send your test email from that same Gmail account. Send a test email to that destination address from another email account (for example, `your-name@outlook.com`). The reason for this is that some email providers will discard what they interpret as an incoming duplicate email and will not show it in your inbox, making it seem like Email Routing is not working properly. --- # Configure rules and addresses URL: https://developers.cloudflare.com/email-routing/setup/email-routing-addresses/ An email rule is a pair of a custom email address and a destination address, or a custom email address with an Email Worker. This allows you to route emails to your preferred inbox, or apply logic through Email Workers before deciding what should happen to your emails. You can have multiple custom addresses, to route email from specific providers to specific mail inboxes. ## Custom addresses 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Routes**. 3. Select **Create address**. 4. In **Custom address**, enter the custom email address you want to use (for example, `my-new-email`). 5. In the **Action** drop-down menu, choose what this email rule should do. Refer to [Email rule actions](#email-rule-actions) for more information. 6. In **Destination**, choose the email address or Email Worker you want your emails to be forwarded to — for example, `your-name@gmail.com`. You can only choose a destination address you have already verified. To add a new destination address, refer to [Destination addresses](#destination-addresses). :::note If you have more than one destination address linked to the same custom address, Email Routing will only process the most recent rule. This means only the most recent pair of custom address and destination address (rule) will receive your forwarded emails. To avoid this, do not link more than one destination address to the same custom address. ::: ### Email rule actions When creating an email rule, you must specify an **Action**: * *Send to an email*: Emails will be routed to your destination address. This is the default action. * *Send to a Worker*: Emails will be processed by the logic in your [Email Worker](/email-routing/email-workers). * *Drop*: Deletes emails sent to the custom address without routing them. This can be useful if you want to make an email address appear valid for privacy reasons. :::note To prevent spamming unintended recipients, all email rules are automatically disabled until the destination address is validated by the user. ::: ### Disable an email rule 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Routes**. 3. In **Custom addresses**, identify the email rule you want to pause, and toggle the status button to **Disabled**. Your email rule is now disabled. It will not forward emails to a destination address or Email Worker. To forward emails again, toggle the email rule status button to **Active**. ### Edit custom addresses 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Routes**. 3. In **Custom addresses**, identify the email rule you want to edit, and select **Edit**. 4. Make the appropriate changes to this custom address. ## Catch-all address When you enable this feature, Email Routing will catch variations of email addresses to make them valid for the specified domain. For example, if you created an email rule for `info@example.com` and a sender accidentally types `ifno@example.com`, the email will still be correctly handled if you have **Catch-all addresses** enabled. To enable Catch-all addresses: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Routes**. 3. Enable **Catch-all address**, so it shows as **Active**. 4. In the **Action** drop-down menu, select what to do with these emails. Refer to [Email rule actions](#email-rule-actions) for more information. 5. Select **Save**. ## Destination addresses This section lets you manage your destination addresses. It lists all email addresses already verified, as well as email addresses pending verification. You can resend verification emails or delete destination addresses. Destination addresses are shared at the account level, and can be reused with any other domain in your account. This means the same destination address will be available to different domains in your account. To prevent spam, email rules do not become active until after the destination address has been verified. Cloudflare sends a verification email to destination addresses specified in **Custom addresses**. You have to select **Verify email address** in that email to activate a destination address. :::note Deleting a destination address automatically disables all email rules that use that email address as destination. ::: --- # DNS records URL: https://developers.cloudflare.com/email-routing/setup/email-routing-dns-records/ You can check the status of your DNS records in the **Settings** section of Email Routing. This section also allows you to troubleshoot any potential problems you might have with DNS records. ## Email DNS records Check the status of your account's DNS records in the **Email DNS records** card: * **Email DNS records configured** - DNS records are properly configured. * **Email DNS records misconfigured** - There is a problem with your accounts DNS records. Select **Enable Email Routing** to [start troubleshooting problems](/email-routing/troubleshooting/). ### Start disabling When you successfully configure Email Routing, your DNS records will be locked and the dashboard will show a **Start disabling** button in the Email DNS records card. This locked status is the recommended setting by Cloudflare. It means that the DNS records required for Email Routing to work are locked and can only be changed if you disable Email Routing on your domain. If you need to delete Email Routing or migrate to another provider, select **Start disabling**. Refer to [Disable Email Routing](/email-routing/setup/disable-email-routing/) for more information. ### Lock DNS records Depending on your zone configuration, you might have your DNS records unlocked. This will also be true if, for some reason, you have unlocked your DNS records. Select **Lock DNS records** to lock your DNS records and protect them from being accidentally changed or deleted. ## View DNS records Select **View DNS records** for a list of the required `MX` and sender policy framework (SPF) records Email Routing is using. If you are having trouble with your account's DNS records, refer to the [Troubleshooting](/email-routing/troubleshooting/) section. --- # Setup URL: https://developers.cloudflare.com/email-routing/setup/ import { DirectoryListing } from "~/components" --- # Configure MTA-STS URL: https://developers.cloudflare.com/email-routing/setup/mta-sts/ MTA Strict Transport Security ([MTA-STS](https://datatracker.ietf.org/doc/html/rfc8461)) was introduced by email service providers including Microsoft, Google and Yahoo 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 communication standards in email. Suppose that `example.com` is your domain and uses Email Routing. Here is how you can enable MTA-STS for it. 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **DNS** > **Records** and create a new CNAME record with the name `_mta-sts` that points to Cloudflare’s record `_mta-sts.mx.cloudflare.net`. Make sure to disable the proxy mode. ![MTA-STS CNAME record](~/assets/images/email-routing/mta-sts-record.png) 3. Confirm that the record was created: ```sh dig txt _mta-sts.example.com ``` ```sh output _mta-sts.example.com. 300 IN CNAME _mta-sts.mx.cloudflare.net. _mta-sts.mx.cloudflare.net. 300 IN TXT "v=STSv1; id=20230615T153000;" ``` This tells the other end client that is trying to connect to us that we support MTA-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-STS. The reason why HTTPS is used here instead of DNS is because not everyone uses DNSSEC yet, so we want to avoid another MITM attack vector. To do this you need to deploy a Worker that allows email clients to pull Cloudflare’s Email Routing policy file using the “well-known” URI convention. 4. Go to your **Account** > **Workers & Pages** and press **Create Application**. Pick the "MTA-STS" template from the list. ![MTA-STS Worker](~/assets/images/email-routing/mta-sts-worker.png) 5. This Worker proxies `https://mta-sts.mx.cloudflare.net/.well-known/mta-sts.txt` to your own domain. After deploying it, go to the Worker configuration, then **Triggers** > **Custom Domains** and **Add Custom Domain**. Type the subdomain `mta-sts.example.com`. ![MTA-STS Worker Custom Domain](~/assets/images/email-routing/mta-sts-domain.png) You can then confirm that your policy file is working with the following: ```sh curl https://mta-sts.example.com/.well-known/mta-sts.txt ``` ```sh output version: STSv1 mode: enforce mx: *.mx.cloudflare.net max_age: 86400 ``` This says that you domain `example.com` enforces MTA-STS. Capable email clients will only deliver email to this domain over a secure connection to the specified MX servers. If no secure connection can be established the email will not be delivered. Email Routing also supports MTA-STS upstream, which greatly improves security when forwarding your Emails to service providers like Gmail, Microsoft, and others. While enabling MTA-STS involves a few steps today, we aim to simplify things for you and automatically configure MTA-STS for your domains from the Email Routing dashboard as a future improvement. --- # Subdomains URL: https://developers.cloudflare.com/email-routing/setup/subdomains/ Email Routing is a [zone-level](/fundamentals/setup/accounts-and-zones/#zones) feature. A zone has a top-level domain (the same as the zone name) and it can have subdomains (managed under the DNS feature.) As an example, you can have the `example.com` zone, and then the `mail.example.com` and `corp.example.com` sub-domains under it. You can use Email Routing with any subdomain of any zone in your account. Follow these steps to add Email Routing features to a new subdomain: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and zone. 2. Go to **Email** > **Email Routing** > **Settings**, and select **Add subdomain**. Once the subdomain is added and the DNS 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. --- # SPF records URL: https://developers.cloudflare.com/email-routing/troubleshooting/email-routing-spf-records/ Having multiple [sender policy framework (SPF) records](https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/) on your account is not allowed, and will prevent Email Routing from working properly. If your account has multiple SPF records, follow these steps to solve the issue: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing**. Email Routing will warn you that you have multiple SPF records. 3. Under **View DNS records**, select **Fix records**. 4. Delete the incorrect SPF record. You should now have your SPF records correctly configured. If you are unsure of which SPF record to delete: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing**. Email Routing will warn you that you have multiple SPF records. 3. Under **View DNS records**, select **Fix records**. 4. Delete all SPF records. 5. Select **Add records and enable**. --- # DNS records URL: https://developers.cloudflare.com/email-routing/troubleshooting/email-routing-dns-records/ 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain. 2. Go to **Email** > **Email Routing** > **Settings**. Email Routing will show you the status of your DNS records, such as `Missing`. 3. Select **Enable Email Routing**. 4. The next page will show you what kind of action is needed. For example, if you are missing DNS records, select **Add records and enable**. If there is a problem with your SPF records, refer to [Troubleshooting SPF records](/email-routing/troubleshooting/email-routing-spf-records/). --- # Troubleshooting URL: https://developers.cloudflare.com/email-routing/troubleshooting/ import { DirectoryListing } from "~/components" Email Routing warns you when your DNS records are not properly configured. In Email Routing's **Overview** page, you will see a message explaining what type of problem your account's DNS records have. Refer to Email Routing's **Settings** tab on the dashboard for more information. Email Routing will list missing DNS records or warn you about duplicate sender policy framework (SPF) records, for example. ---