Cloudflare Gateway's Egress policies can now route by destination domain!

Hey everyone, it's me, Shii-chan! Today I found a Gateway update that should catch the eye of anyone running Cloudflare One as a network admin.

Cloudflare Changelog developers.cloudflare.com

What was announced?

On the Cloudflare Changelog, they announced that Gateway Egress policies in Zero Trust now support new selectors based on a destination's fully qualified domain name (FQDN). Specifically, the Egress policy builder now offers four selectors in beta: Host, Domain, Content Categories, and Application.

The story so far

Egress policies already existed, letting you match traffic by conditions like user identity, source or destination IP, and geolocation to decide which egress IP (a dedicated static IP) to use.

But Egress policies are evaluated at Layer 4 of the OSI model, where only IP addresses are visible — hostnames aren't part of that picture. So controls like "use this IP only for traffic headed to this domain" simply weren't possible before.

What changes

With the new Host, Domain, Content Categories, and Application selectors, you can now split egress IPs based on the destination's domain, app, or category.

For example, if a partner bank API or SaaS service only allows connections from specific IPs, you can route just the traffic headed to that domain through a dedicated egress IP, while everything else keeps using the fastest available path. That's the kind of flexible setup this unlocks.

During the beta, these selectors work with traffic on-ramped through:

• WARP client (requires additional configuration)
• Proxy endpoints (commonly deployed with PAC files)
• Cloudflare Browser Isolation

Dive Deep

Here's the interesting part. Since Egress policies are evaluated at Layer 4, hostnames shouldn't be visible at all — yet Gateway makes the Host, Domain, Content Categories, and Application selectors work using a two-step trick.

1. When a DNS query comes in for a hostname that matches one of these selectors, Gateway first returns a temporary IP from the 100.80.0.0/16 or 2606:4700:0cf1:4000::/64 range.
2. When traffic actually arrives addressed to that temporary IP, Gateway identifies which hostname the connection belongs to, applies the matching Egress policy, and swaps the temporary IP for the real destination IP before forwarding the traffic.

In other words, Gateway uses the timing of DNS resolution to bridge hostname information into a Layer-4 policy. Pretty clever.

There are a few prerequisites to keep in mind too.

• You need to turn on "Allow egress policy host selectors" under Zero Trust to Traffic policies to Traffic settings in the dashboard (this can also be set via the API)
• Using this with the WARP client requires a minimum version: Windows, macOS, and Linux need 2025.4.929.0 or later; iOS needs 1.11 or later; Android and ChromeOS need 2.4.2 or later
• Traffic that reaches Gateway via DNS locations (sending DNS queries directly to Gateway) doesn't get this treatment

One more thing to note: since these selectors resolve the destination IP at the moment Gateway processes the DNS query, if that resolved location and the egress IP you actually use are in different regions, connections to destinations that enforce geo-restrictions or IP allowlisting can fail. Worth keeping in mind when you configure this.

Wrap-up

• Gateway Egress policies gained four new beta selectors: Host, Domain, Content Categories, and Application
• You can now split egress IPs by destination domain or app, making it easier to match SaaS or partner API IP allowlists
• The beta supports traffic on-ramped through the WARP client (extra config required), proxy endpoints (PAC), and Browser Isolation
• Behind the scenes, a two-step DNS resolution trick using temporary IPs bridges hostname information into Layer-4 egress policies

This one's worth a close read for security and network admins running Gateway Egress policies in Zero Trust!