Cloudflare Does Not Proxy SMTP: Ports 25, 465, 587

You switched your DNS nameservers to Cloudflare or enabled the orange cloud proxy, and inbound messages now bounce while your own clients can no longer send. The cause is almost always the same: the proxy carries HTTP and HTTPS only, so SMTP on ports 25, 465 and 587 never reaches your mail server.

Cloudflare does not proxy SMTP, on port 465 or on any other mail port

The orange cloud is a reverse proxy for web traffic. It accepts HTTP and HTTPS connections on a closed list of ports and forwards them to your origin server. Anything that is not HTTP or HTTPS on one of those ports has no handler at the edge at all. Cloudflare's documentation states it plainly: the proxy only handles HTTP and HTTPS traffic, and proxying a record used for another protocol routes that traffic to Cloudflare, which drops the non-HTTP connection.

Here is the complete list of ports the proxy carries by default, on every plan:

HTTP: 80, 8080, 8880, 2052, 2082, 2086, 2095
HTTPS: 443, 2053, 2083, 2087, 2096, 8443

That is the entire list. SMTP on 25, 465 and 587, IMAP on 143 and 993, and POP3 on 110 and 995 appear nowhere in it, and no plan level and no toggle adds them to a proxied DNS record. Two consequences follow directly:

Only A, AAAA and CNAME records carry a proxy status at all. MX and TXT records are always DNS only, by record type. There is no orange cloud to turn off on an MX record, which is precisely why the problem is so easy to miss.
A single hostname cannot serve both a proxied website and a mail service. The web half would keep working, the mail half would not, and the site looking healthy is what sends most people looking in the wrong place.

The one documented exception is Spectrum, a Layer 4 proxy that supports all TCP and UDP ports on the Enterprise plan. It is a poor fit for mail and Cloudflare says so: Spectrum passes traffic through without acting as a mail server, the connecting address seen by the receiving server becomes a Cloudflare edge address unless Proxy Protocol is enabled, and Spectrum applications have no reverse DNS entries, which is exactly the check most receiving mail servers run before accepting a message. On a Free, Pro or Business zone the question does not arise: mail records go grey cloud.

Ports 25, 465 and 587: inbound and outbound are two different problems

The outbound half of this question causes the most confusion, and the two directions fail for different reasons and are fixed in different places. Separating them saves hours of searching for a setting that does not exist.

Inbound, port 25

Remote mail servers delivering to you always use port 25. They resolve your MX record, get a hostname, resolve that hostname to an A or AAAA record, and open a TCP connection to port 25 on the resulting address. If that address is a Cloudflare anycast address because the mail hostname is proxied, nothing at the edge answers SMTP. The sending server does not receive a rejection it can report immediately, it receives silence. It queues the message, retries for hours, and eventually returns a bounce to the original sender. Your website works normally throughout, which is why the incident is always reported as broken email rather than broken DNS.

Outbound, ports 465 and 587

Ports 587 (submission) and 465 (submission over implicit TLS) are not used by remote servers delivering to you. They are used by your own mail clients and your own applications to hand a message to your mail server for onward delivery. Nothing happens at the Cloudflare edge here, because the proxy is not on that path: it is a reverse proxy, it only sees connections that the rest of the internet opens towards your hostnames, never connections your server or your laptop opens towards somebody else.

So the proxy does not intercept, inspect, throttle or block outbound SMTP. Cloudflare's documentation is explicit on the point: unless Spectrum has been configured for SMTP, email is delivered directly to your mail server and does not pass through the Cloudflare network at all.

When outbound mail breaks right after a migration, the cause is therefore never traffic interception. It is name resolution:

Your mail client or your application is configured with a submission host such as smtp.example.com or mail.example.com.
That record is proxied, so it now resolves to a Cloudflare anycast address instead of your mail server.
The client opens port 465 or 587 towards that address, nothing answers, and you get a connection timeout in Outlook, Thunderbird or your application logs.

The fix is the same as for inbound: DNS only on that hostname. The distinction matters mostly because it tells you where not to look. There is no Cloudflare option to allow outbound SMTP, no security rule to write, no port to open at the edge. Only the DNS record is at fault.

The outbound consequence nobody expects

Because outbound mail never crosses the Cloudflare network, it leaves from your origin server's real address. The proxy hides that address from web visitors; it does not hide it from the receiving mail server, and it must not. This is why listing Cloudflare's ranges in an SPF record would be meaningless, and why your SPF record has to authorize the actual sending address of your origin, or the include mechanism of your sending platform.

One more outbound failure is regularly blamed on Cloudflare and has nothing to do with it: a great many hosting providers and cloud platforms block outbound port 25 from their own networks by default, to limit spam. If port 25 fails from your server while 465 and 587 work normally, ask your host, not your DNS provider.

Why an MX record must never point at a proxied hostname

An MX record has no proxy status of its own. The dashboard shows no cloud icon for it, and Cloudflare keeps MX records DNS only by record type. The trap sits one level below: the MX points at a hostname, and that hostname has an A or AAAA record that can perfectly well be orange-clouded, most often because it is the apex domain that also serves the website.

Concretely, when mail runs on the same name as the site:

dig MX example.com +short returns 10 mail.example.com.
dig A mail.example.com +short returns a Cloudflare anycast address rather than your mail server.
A remote server opens port 25 on that address and waits for a 220 greeting banner that never arrives.
After the retry window, typically a first delay warning within a few hours and a final failure after several days depending on the sender's queue lifetime, the message bounces back to its author.

There is a second, structural rule: an MX record must point to a hostname that has address records, never to an alias. Pointing an MX at a CNAME is invalid, and receiving implementations handle it inconsistently, which produces the worst category of outage, the one that only affects some senders and looks random.

Cloudflare also documents a related best practice worth applying while you are rebuilding the zone: do not host the mail service on the same machine as the web resource you are protecting. Bounces sent back to a non-existent recipient carry the mail server address, and if that address is also your web origin, the proxy stops hiding anything.

Putting the grey cloud on the mail subdomain, step by step

Work through these steps in order and check the result of each one before moving on. More hands-on guides like this one are collected in our Cloudflare guides hub.

Read your DNS the way mail servers see it, before touching anything. From any machine:
```
dig MX example.com +short
dig A mail.example.com +short
dig A smtp.example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +short
```
The first command shows where inbound mail is directed, the next two show what your mail hostnames resolve to today, the last two show the SPF and DMARC policies. If you know your DKIM selector (often default or google), add dig TXT default._domainkey.example.com +short. Write the answers down: they are your before state.
Audit the proxy status of every mail-related record. In the dashboard, open DNS > Records and check the cloud icon of each hostname used by mail: the target of every MX record, the submission host configured in your clients, the IMAP or POP3 host, and the autodiscover or autoconfig entries your provider requires. Each one must read DNS only. Your website records, and webmail if it is served over HTTPS, can stay proxied without any effect on mail.
Switch each mail hostname to DNS only. Click Edit on the record, click the orange cloud in the proxy status column so that it turns grey and reads DNS only, then save. The record type and content do not change, only the proxy status does. Cloudflare applies the change immediately at the authoritative level; what takes time afterwards is resolver caching, not Cloudflare.
Fix the MX targets themselves. Each MX entry must point to a hostname that has a direct, unproxied A or AAAA record. Remove stale entries left over from the previous provider and keep a single clean target with priority 10, unless your provider documents several with explicit priorities.
Check CNAME flattening on provider records. Several providers require a real CNAME for DKIM or autodiscover. When flattening is enabled globally or on that specific record, the CNAME is served as an A record and the provider can no longer read what it expects. Turn flattening off for those records.
Check for a delegated mail subdomain. If mail.example.com is delegated to another DNS provider through NS records, its address record does not live in your Cloudflare zone at all, and changing anything in Cloudflare will have no effect. Fix it at the provider that is authoritative for that subdomain.
Check Email Routing. If you run your own mail server or use an external provider, Email > Email Routing must be off. When it is on, Cloudflare manages your MX records itself and the records it creates conflict with your provider's, which silently overrides your production routing. Email Routing also forwards inbound mail only; it does not make your domain a sender.
Confirm from the outside. Re-run the dig commands from step one: the answers must now be your mail server's real address. Then confirm that the service actually answers, using the checks in the next section, and send a real message from an external mailbox before declaring the incident closed.
Lower the TTL before your next change. Mail records left at a 24-hour TTL mean any future mistake stays in circulation worldwide for a full day. A TTL of five minutes on mail records turns a rollback into a coffee break.

Observable symptoms: error messages, codes, and what the tools return

The signature of this failure is remarkably consistent, and recognising it saves you from auditing your whole mail configuration.

What senders and clients report

Sending servers report a timeout, never a refusal. Postfix logs a line of the form connect to mail.example.com[198.51.100.1]:25: Connection timed out, defers the message with a 4.4.1 status, and issues a final 4.4.7 or 5.4.7 "delivery time expired" notice once the queue lifetime runs out.
Mail clients report a connection timeout on the submission port, 465 or 587: "the connection to the server has timed out" in Thunderbird, "cannot connect to the outgoing server" in Outlook.
Nothing reports a certificate error or an authentication failure. That absence is a useful signal in itself: the failure happens before any SMTP dialogue starts, so it cannot be a credentials or TLS problem.

What telnet shows

telnet mail.example.com 25

A working mail server answers within a second with its greeting banner, for example 220 mail.example.com ESMTP. Against a proxied hostname you get one of two results: either the connection hangs at Trying 198.51.100.1... until your client gives up, or the TCP session opens and then stays completely silent, with no banner at all.

That second case deserves an explanation, because it makes the port look open. Cloudflare's anycast addresses serve many products, and Cloudflare documents that ports other than 80 and 443 can be reported as open by netcat or a security scanner, since traffic for other customers is served on them. An open TCP port that never sends a 220 banner is still a dead mail path. Judge on the banner, not on the port state.

What openssl s_client shows

For implicit TLS on port 465, the exact case in most of these incidents:

openssl s_client -connect mail.example.com:465

A working server completes the TLS handshake, prints its certificate chain, and then sends the 220 banner. Against a Cloudflare address the handshake never starts: on Linux, openssl exits on connect:errno=110, the code for a connection timeout, without a single line of certificate output.

For STARTTLS on port 587:

openssl s_client -starttls smtp -connect mail.example.com:587

Same behaviour, one step earlier: openssl cannot even read the initial banner it needs before issuing the STARTTLS command. A quick equivalent with curl returns the timeout explicitly:

curl -v --max-time 10 telnet://mail.example.com:465

On a proxied hostname this ends on Connection timed out after 10000 milliseconds. On a correctly configured one it opens silently and waits, which is the expected behaviour for a raw TCP session.

Confirming the cause in one command

dig +short mail.example.com

If the answer falls inside one of Cloudflare's published address ranges, the hostname is proxied and you have your diagnosis without opening the dashboard. Run the check on the MX target specifically, not only on the apex domain: the two are frequently different records with different proxy statuses.

What this does to SPF, DKIM and DMARC

Proxy status and mail authentication are independent mechanisms, but a zone migration usually breaks both at once, which is why the symptoms get mixed up and the diagnosis drifts.

SPF is a TXT record, so it is never proxied. What breaks is its content: it must authorize the real address your origin sends from, or the include mechanism of your sending platform. Proxying your web record changes nothing here, because outbound mail does not cross the proxy. Two v=spf1 records in the zone, or more than ten DNS lookups, produce a PermError that receivers treat as an outright failure.
DKIM is a TXT record too, and often a very long one. Migrations truncate them. A key split into 255-character chunks that loses one chunk still resolves and still looks present, while failing every signature check. Some providers publish DKIM as a CNAME instead, which brings back the flattening problem described above.
DMARC needs SPF or DKIM to pass and to align with the visible From domain. A technically valid SPF record that authorizes the right server but does not align still fails DMARC, which is the single most common reason a domain with correct records keeps landing in spam.

If authentication rather than routing is your real problem, the full procedure, from sender inventory to a policy in enforcement, is in our guide on setting up SPF, DKIM and DMARC on Cloudflare DNS. The same origin-side hygiene matters for web traffic too; our guide on intermittent 521, 522 and 524 errors covers the reachability side of the origin.

Common mistakes that break mail silently

MX records pointing at the proxied apex: when mail runs on the same domain as the website, the MX is often aimed at the root A record, which is proxied. Inbound mail is then dropped at the Cloudflare edge even though every other record in the zone is correct.
Looking for a port setting that does not exist: there is no option to open port 465 or 587 on a proxied record, on any plan. Time spent in the security settings looking for one is time not spent on the DNS record that is actually wrong.
Editing records without lowering the TTL: a 24-hour TTL cached by resolvers worldwide means the old broken answers keep circulating for hours after the fix. Lower the TTL a day ahead of any migration.
Keeping several SPF records: adding a second v=spf1 record instead of merging its includes into the existing one invalidates both. Merge, never append.
Pasting DKIM keys without the 255-character splitting: DNS stores long TXT values as several quoted strings, and reformatting them by hand frequently drops a fragment, producing signatures that fail only on some receivers.
Leaving Email Routing half-configured: turning the feature on without complete forwarding rules takes over the MX records while delivering nothing, which looks exactly like a total mail outage.

Frequently asked questions

Does Cloudflare proxy SMTP on port 465?

No. The Cloudflare proxy carries HTTP and HTTPS on a closed list of ports: 80, 8080, 8880, 2052, 2082, 2086 and 2095 for HTTP, and 443, 2053, 2083, 2087, 2096 and 8443 for HTTPS. Port 465 is not on that list, and neither are 25 and 587. A connection opened to port 465 on a proxied hostname finds no mail service at the edge, and the non-HTTP connection is dropped. There is no plan level and no setting that adds mail ports to a proxied DNS record. The only documented exception is Spectrum, a Layer 4 proxy available on the Enterprise plan, which Cloudflare itself flags as a poor fit for SMTP because Spectrum applications have no reverse DNS entries.

Does Cloudflare proxy SMTP traffic on port 465 for outbound traffic?

No, and in that direction the proxy is not even on the path. Cloudflare's proxy is a reverse proxy: it only handles connections opened from the internet towards your hostnames. A connection your server or your mail client opens towards port 465 never touches the Cloudflare network, so Cloudflare cannot intercept, throttle or block it. When outbound mail breaks right after a migration, the cause is name resolution, not traffic interception: the submission host configured in your client, smtp.example.com for instance, is proxied and now resolves to a Cloudflare anycast address. Set that record to DNS only and submission works again. There is no outbound setting to change on the Cloudflare side.

Which ports does the Cloudflare proxy actually carry?

HTTP on ports 80, 8080, 8880, 2052, 2082, 2086 and 2095, and HTTPS on ports 443, 2053, 2083, 2087, 2096 and 8443. That is the complete default list. Every other port, including SMTP on 25, 465 and 587, IMAP on 143 and 993, and POP3 on 110 and 995, requires the record to be set to DNS only so that the traffic bypasses the Cloudflare network and reaches your server directly.

Can I keep the orange cloud on my mail hostname?

No. The Cloudflare proxy speaks HTTP and HTTPS on web ports only; it does not forward SMTP, IMAP or POP3 connections. Any hostname used for mail must be set to DNS only, otherwise mail clients and remote servers reach the edge and the connection is dropped. Web hostnames and webmail served over HTTPS can stay proxied without any effect on mail.

Does switching my mail record to grey cloud expose my server IP?

The mail host becomes publicly visible, but that is inherent to email: MX records are public by design and reveal a mail endpoint regardless of the proxy. Bounce messages also carry the mail server address back to whoever triggered them. Cloudflare's own recommendation is therefore not to run the mail service on the same machine as the web resource you are protecting, and to use addresses from different ranges, so that exposing the mail endpoint tells an attacker nothing about your web origin.

How long does it take for email to work again after fixing the records?

Routing follows DNS TTLs: a few minutes to a few hours depending on the values that were cached. Messages already queued by sending servers are retried for up to several days, so mail deferred during the outage is usually delivered once the records are correct. Spam-folder reputation, on the other hand, rebuilds over days of consistent SPF, DKIM and DMARC passes.

Do SPF, DKIM and DMARC require a paid Cloudflare plan?

No. TXT, MX and CNAME record management is identical on the Free plan, with no cap on these record types. The difficulty is never the plan, it is getting the values right: a single SPF record, complete DKIM selectors, and a DMARC policy that matches your real sending sources. Note that a security rule false positive can also block the web forms that trigger your notifications, a separate problem with its own diagnosis.

Why Your Business Email Stopped Working After Moving to Cloudflare™