Cloudflare has logged two email delivery incidents in under three weeks, one as a security gateway and one as a sender. In both, its advice to customers was to exempt Cloudflare infrastructure from downstream filtering. In neither did it say why the filtering happened.
31 August: Cloudflare’s own mail blocked
At 20:16 UTC on 31 August, Cloudflare reported that one-time PIN emails for Cloudflare Access were being blocked by email security gateways. Proofpoint customers were most affected. Proofpoint was deferring the messages with a 421 4.7.0 response, and Cloudflare said its sending IP had been flagged.
Cloudflare’s advice was to allowlist notify.cloudflare.com and six sending addresses in the 104.30.16.0 range. The incident is marked resolved and Cloudflare has since added the allowlisting instructions to its permanent documentation.
Proofpoint has not said why it deferred the mail. Cloudflare has not said why its IP was flagged.
12 August: Cloudflare’s gateway listed by Spamhaus
Nineteen days earlier, Cloudflare had a major incident in the other direction. At 15:04 UTC on 12 August it reported that customers running Spamhaus filtering downstream of Cloudflare Email Security were rejecting mail from its 134.195.26.0/23 egress block. Downstream systems were treating Cloudflare’s gateway as the originating sender.
Cloudflare’s first status update said the block should be allowed in all downstream systems. It added: “We recommend all Cloudflare Email Security customers disable Spamhaus filtering in downstream systems.”
By 16:48 UTC Cloudflare said the addresses were no longer listed. The incident was closed at 17:23 UTC. It was the only incident Cloudflare rated major in a run of thirteen logged on its status page between 7 and 14 August.
For Microsoft 365 customers, Cloudflare said the issue should mainly affect tenants that had not completed the required inbound connector configuration.
Cloudflare has not said why the range was listed. Spamhaus has not commented. No figures have been given for customers or messages affected.
What went wrong, both times
A secure email gateway sits between the internet and the mailbox provider. Anything filtering behind the gateway has to know that the gateway is not the sender. If it does not, a reputation hit on the gateway rejects every message passing through it, whoever sent it.
Cloudflare’s gateway range got a reputation hit. Cloudflare’s transactional sender got a reputation hit. Reputation hits on shared infrastructure do not come from nowhere. Something emitted through those addresses that Spamhaus and Proofpoint decided to act on, or both made a mistake. Cloudflare has offered no account either way, and its remedy in both cases moves the problem to the customer’s allowlist.
Administrators running Cloudflare Email Security in front of Microsoft 365 or Google Workspace should confirm that the connector or inbound gateway configuration includes every Cloudflare egress address, and that downstream filters read the original sender IP rather than the gateway’s. Administrators running Proofpoint or similar in front of anything that relies on Cloudflare Access should decide for themselves whether “allowlist the vendor” is an acceptable answer.
Neither incident is related to the separate Spamhaus restriction on DNSBL queries made through public resolvers such as Cloudflare’s 1.1.1.1, which has been in place for some time and affects lookups rather than delivery.
