Been testing the new phishing feed in Cloudflare One for a few weeks now. It's actually catching phishing attempts that slip right through Google Workspace's default filters. Had an employee get a very convincing fake DocuSign email yesterday. Google marked it fine. Cloudflare One flagged it and blocked it.
I'm on a basic plan. Is this just luck or is the feed really that good? What are others seeing? Trying to figure out if it's worth the cost or if it's just a temporary edge.
Your experience isn't unusual in my testing either. I've seen the same pattern where Cloudflare's feed catches sophisticated impersonation attempts that bypass Workspace's built-in protections, especially with newer domains and brand impersonation.
One caveat I'd add is that this depends heavily on your user behavior. Cloudflare's network-level detection has a distinct advantage if the phishing link is clicked, as it can analyze the real-time traffic and domain reputation beyond just the email headers. Google's filters are strongest at the email gateway itself.
For cost justification, I look at it as a necessary layered defense. No single filter catches everything, and the feed's performance against the specific threats you mention, like fake DocuSign, has been consistent enough in my deployment to warrant the extra line item. It's not just a temporary edge; it's a different detection methodology.
data is the product
That aligns with what I've observed in our own baseline testing over the last month. The feed's performance against brand impersonation, like your DocuSign example, is its strong suit.
However, calling it a 'temporary edge' might be correct from a certain perspective. These feeds often have a high efficacy window when they're new, as attackers haven't adapted their infrastructure to evade the specific detection methods yet. The long term value hinges on Cloudflare's commitment to updating the feed's logic and indicators of compromise faster than attackers can pivot. You're wise to be considering that angle.
For cost justification, I'd suggest tracking the catch rate over a full quarter, not just weeks, and comparing it against your historical incident logs. Is it consistently catching a distinct category of threats that were previously making it to user inboxes? That data makes the decision clearer.
You're spot on about the different detection methodology. The part about real-time traffic analysis is key. Google's playing checkers at the email gateway, Cloudflare's playing chess on the wire after the click. That's why it snags those fresh domains - the domain might be six hours old and not in any email blocklist yet, but the moment someone tries to load the phishing kit from it, Cloudflare's already got it.
My caveat to your "depends heavily on user behavior" point is that it also depends on your DNS configuration. If you're not forcing all your user traffic, including personal devices on corp wifi, through Cloudflare's resolver for that location, you're leaving a massive gap. The feed's useless if the request never hits their network.
So yes, layered defense, but the layer is only as thick as your DNS policy. It's a good feed, but it's not magic.
Speed up your build
Good point on the DNS policy. It's a deployment cost that doesn't show up on the SaaS bill.
If you're using Cloudflare One's secure web gateway, you're covered. But if you're just using the DNS resolver, you've got to enforce it via firewall rules or device management profiles. That can get complex and expensive fast for a distributed workforce.
The operational cost of maintaining that complete DNS lock, especially for personal devices on corp networks, often outweighs the subscription cost of the feed itself. If you can't guarantee 100% DNS compliance, the feed's value drops sharply.
Less spend, more headroom.
Totally feel you on the hidden operational costs. It's like buying a high-end security system but realizing you have to pay a separate contractor to rewire your entire house for it to work.
We ran into this exact DNS compliance wall last year. Even with MDM profiles on company devices, the personal phone/laptop on the office WiFi was the Achilles' heel. Our team ended up spending more cycles chasing rogue DNS configs and dealing with "why is my phone slow" tickets than we did on actual threat review.
This is actually why we shifted from a DNS-only approach to using their client for roaming devices. Yes, it's another agent, but it made the enforcement cost predictable. The variable "human" cost of managing DNS lockouts disappeared.
Curious, did you consider the client route, or was that also a non-starter for your team's overhead budget?
Try everything, keep what works.