Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

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) ↗. When an email is forwarded, the destination server may not be able to verify the original sender's authentication because the email now comes from Cloudflare's servers rather than the sender's. ARC is an email authentication system that allows an intermediate email server (such as Email Routing) to attach a record of the original authentication results so the destination server can verify the email was legitimate before forwarding. Google also supports ARC.

Contact information

The best way to contact us is using our community forum ↗ or our Discord server ↗.

DKIM signature

DKIM (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 adds two new signatures to the emails in transit, one on behalf of the Cloudflare domain used for sender rewriting (email.cloudflare.net), and another one on behalf of the customer's recipient domain.

Below is the DKIM key for email.cloudflare.net:

Terminal window
dig TXT cf2024-1._domainkey.email.cloudflare.net +short
"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiweykoi+o48IOGuP7GR3X0MOExCUDY/BCRHoWBnh3rChl7WhdyCxW3jgq1daEjPPqoi7sJvdg5hEQVsgVRQP4DcnQDVjGMbASQtrY4WmB1VebF+RPJB2ECPsEDTpeiI5ZyUAwJaVX7r6bznU67g7LvFq35yIo4sdlmtZGV+i0H4cpYH9+3JJ78k" "m4KXwaf9xUJCWF6nxeD+qG6Fyruw1Qlbds2r85U9dkNDVAS3gioCvELryh1TxKGiVTkg4wqHTyHfWsp7KD3WQHYJn0RyfJJu6YEmL77zonn7p2SRMvTMP3ZEXibnC9gz3nnhR6wcYL8Q7zXypKTMD58bTixDSJwIDAQAB"

You can find the DKIM key for the customer's example.com domain by querying the following:

Terminal window
dig TXT cf2024-1._domainkey.example.com +short

DMARC enforcing

Email Routing enforces Domain-based Message Authentication, Reporting & Conformance (DMARC). DMARC allows domain owners to publish a policy that tells receiving servers what to do when an email fails SPF and DKIM checks. Depending on the sender's DMARC policy, Email Routing will reject emails when there is an authentication failure. Refer to dmarc.org ↗ for more information on this protocol.

It is recommended that all senders implement the DMARC protocol in order to successfully deliver email to Cloudflare.

Mail authentication requirement

Cloudflare requires emails to pass some form of authentication, either pass SPF verification or be correctly DKIM-signed to forward them. Having DMARC configured will also have a positive impact and is recommended.

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:

Terminal window
dig mx gmail.com
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.
Terminal window
dig AAAA gmail-smtp-in.l.google.com
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:

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 ↗ 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 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/19

IPv6

2405:8100:c000::/38

Ranges last updated: December 13th, 2023

Outbound hostnames

In addition to the outbound prefixes, Email Routing will use the following outbound domains for the HELO/EHLO command:

  • cloudflare-email.net
  • cloudflare-email.org
  • cloudflare-email.com

PTR records (reverse DNS) ensure that each hostname has an corresponding IP. For example:

Terminal window
dig a-h.cloudflare-email.net +short
104.30.0.7
Terminal window
dig -x 104.30.0.7 +short
a-h.cloudflare-email.net.

Sender rewriting

Every email has two sender addresses: the envelope sender (the MAIL FROM address used during the SMTP transaction, which receiving servers check against SPF records) and the header From: address (what the recipient sees in their email client). When Email Routing forwards an email, the original sender's SPF record does not authorize Cloudflare's servers to send on their behalf, so SPF checks would fail at the destination.

To prevent this, Email Routing rewrites the envelope sender (MAIL FROM) to the forwarding domain using the Sender Rewriting Scheme ↗. The header From: address remains unchanged — recipients still see the original sender's address.

SMTP errors

In most cases, Email Routing forwards the upstream SMTP errors back to the sender during the same SMTP connection (in-session), rather than generating a separate bounce message later.

Realtime Block Lists

Email Routing checks the sender's IP address against blocklists — databases of IP addresses known to send spam or abusive email. These blocklists, called Realtime Block Lists (RBLs), are queried through a Domain Name System Blocklist (DNSBL) service. When the system detects an abusive IP, it blocks the email and returns an SMTP error:

554 <YOUR_IP_ADDRESS> found on one or more RBLs (abusixip). Refer to https://developers.cloudflare.com/email-routing/postmaster/#spam-and-abusive-traffic/

We update our RBLs regularly. You can use combined block list lookup services like MxToolbox ↗ to check if your IP matches other RBLs. IP reputation blocks are usually temporary, but if you feel your IP should be removed immediately, please contact the RBL's maintainer mentioned in the SMTP error directly.

Anti-spam

In addition to DNSBL, Email Routing uses advanced heuristic and statistical analysis of the email's headers and text to calculate a spam score. We inject the score in the custom X-Cf-Spamh-Score header:

X-Cf-Spamh-Score: 2

This header is visible in the forwarded email. The higher the score, 5 being the maximum, the more likely the email is spam. Currently, this system is experimental and passive; we do not act on it and suggest that upstream servers and email clients do not act on it either.

We will update this page with more information as we fine-tune the system.

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 ↗. Refer to the SPF Record Syntax ↗ to learn the SPF syntax.

Email Routing's SPF record contains the following:

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 ↗ 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:

_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 ↗ 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 ↗. Email Routing only supports internationalized domain names ↗.

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 ↗ 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).

"." is treated as a normal character for custom addresses

The . character, which performs special actions in email providers like Gmail, is treated as a normal character on custom addresses.