We scanned 50,000 domains. Your cold email list is really four systems.
We scan 50,000 domains every day to see how the world actually configures email. Public DNS lookups, nothing sent, nothing stored.
I was looking at this morning's provider numbers and it reframed how I think about cold email entirely.
Here's who actually receives your mail:
Other / self-hosted: 32.4%
Google Workspace: 28.2%
Microsoft 365: 22.7%
Proofpoint: 5.6%
Mimecast: 3.1%
Everyone else: under 2% each
Google and Microsoft together are 50.9%.
So when you send a campaign to 500 companies, you're not really facing 500 decisions. You're facing about four systems, and half your list sits behind two of them.
That changes what "improving deliverability" even means.
- You've been testing against an average
Most cold email advice treats spam filtering as one thing. Write better subject lines, warm the domain, avoid spam words, done.
But your list isn't one audience. It's three completely different environments stacked together, and your results are the blended average of all of them.
If half your list is Google and half is Microsoft, and one of those is quietly eating your mail, your open rate looks mediocre and you have no idea why. The problem isn't your copy. You're reading one number for two different games.
The fix isn't technical. It's segmentation you're probably not doing.
- The three tiers, in plain terms
Google and Microsoft: 50.9%. Your baseline. Whatever you optimize, optimize for these two, not because they're strictest but because they're most of your list. If you only change one thing after reading this, split your results by provider and look at them separately.
Security gateways: about 10%. Proofpoint, Mimecast, Cisco, Barracuda. These aren't mailbox providers. They're security products a company chose, paid for, and configured. Somebody made a decision to put them there.
You can see it in how those domains behave. In today's data, 61.8% of Proofpoint domains are on DMARC reject, versus 26.9% of Google Workspace domains. These are organizations treating email security as policy, not as a default they inherited.
Practical read: if your prospect sits behind one of these, cold email is a harder channel. Not impossible. Harder. Adjust your expectations rather than your subject line.
Self-hosted and other: 32.4%. The biggest single bucket and the least predictable. Small hosts, agency setups, legacy servers, someone's cPanel from 2014. Filtering ranges from nonexistent to aggressive with no pattern. Some of your best deliverability lives here. So do your strangest bounces.
- One thing worth knowing
You've probably read that Gmail and Yahoo require SPF, DKIM and DMARC above 5,000 sends a day, and that Microsoft added the same rules in May 2025.
True. But those rules apply to their consumer services. Gmail, Outlook., Hotmail, Live.
If you're doing B2B cold email to business domains, you're hitting Google Workspace and Microsoft 365 tenants, and those specific rules technically don't cover you.
I'd still do all three anyway. Consumer standards have a way of becoming business standards, and it's a one-time afternoon of setup. But it's worth knowing what's actually mandatory versus what's recommended, because a lot of cold email content blurs that line to sell you something.
- What I'd actually do with this
None of this requires touching DNS.
Check the MX of your list before you send. Free, no signup, tells you who you're really talking to: https://deliverability.mailtester.ninja/tools/mx-lookup
Split your reporting by provider. Google, Microsoft, gateways, everything else. Four numbers instead of one.
Treat the gateway segment separately. Different expectations, probably a different channel.
Stop optimizing against a blended average. That's the whole point.
And check your own setup while you're at it. Not your prospects. You. Most people have never actually looked: https://deliverability.mailtester.ninja/test
- Honest caveat, since we sell email verification
That's the actual business, for the record: https://mailtester.ninja/.
Now that we've got that out of the way.
None of this fixes a bad list, and a clean list doesn't fix any of this. Different problems that look identical from the outside, because both show up as "my campaign underperformed."
Verification tells you the address exists. It doesn't tell you the message will land. Anyone selling you the second thing while delivering the first is overselling. Including us, if we ever do it.
Full dataset updates daily and is free to reuse with attribution: https://deliverability.mailtester.ninja/
One thing I'm curious about. Does anyone here actually segment campaign reporting by receiving provider? Or is that as rare as I suspect?
Great write-up Danila, the gateway-as-a-behavioral-signal point is spot on. But gotta love Aryan asking for your email for the third time in a thread about cold email deliverability! 😂
A little bit of fun on this beautiful day héhé :p
Good Job Crushing it
Saw your post about cold email systems. Curious what part of the process still feels the most manual right now: finding leads, personalization, or follow-ups?
None of the three, honestly. We don't run outbound as our main channel, so I'm the wrong person for that question. Almost everything we've gotten came from search.
The manual part in my world is upstream of all of it: figuring out which segment is even worth sending to. That's what the post was about, and it's the part no tool solves because it's a judgment call, not a task.
If you're building something in this space, the gap I'd point at is the one from the thread above. Nobody can tell you reply rates by receiving provider. Several people asked for it here and nobody had it.
That's an interesting distinction. It sounds like the real work isn't sending emails, it's reducing uncertainty before sending the first one. That's actually the area I'm exploring with TaskRelay helping founders do the research and validation work that informs those decisions. Out of curiosity, what does that research process usually look like for you today?
Not much of a process, honestly. We look at what people search for, write about it, and see what sticks. Eight years of that.
The validation work you're describing is more of a pre-launch problem, and we're past that stage. So I'd be a poor test case for TaskRelay.
Good luck with it.
Almost nobody segments reporting by receiving provider, and I say that after 20 years inside the Microsoft ecosystem watching enterprise tenants behind Proofpoint and Mimecast quietly quarantine entire sending domains with zero bounce signal. The sender just sees a mediocre open rate and blames the copy. If a prospect sits behind a gateway, I treat email as the warm-up and make LinkedIn or a referral the actual first touch.
The silent part is what makes it so hard to diagnose. A bounce is information. A quarantine with no bounce signal is worse than a rejection, because you keep sending into it and your metrics tell you the campaign is merely mediocre. You can't fix what doesn't report.
And the domain-level piece is the one people miss. It's not the message being scored, it's your sending domain, which means one bad campaign contaminates every campaign after it against that whole segment.
Your gateway approach is the first concrete answer anyone's given in this thread, and I think it settles it. Three people asked what you actually do differently per segment, and the honest answer might be: for the gateway tier, you don't send differently, you stop leading with email.
Twenty years inside the Microsoft ecosystem is a post, by the way. There's very little written about this from that side :D
it's very interesting! thanks for information!
This is a massive mindset shift. Looking at a single 'blended average' open rate explains why so many campaigns unexpectedly flatline behind strict corporate gateways like Proofpoint. I'll definitely start running an MX lookup to segment my lists by provider now. Thanks for the data-driven wake-up call!
This is a useful way to move the deliverability discussion beyond subject lines and generic open rates.
At 6senseHQ, we have seen the same broader problem in outreach analytics: one blended number can hide completely different behaviors across audience segments and infrastructure.
I would be interested to know whether you have also compared actual reply quality by email provider. Opens and clicks can be distorted by security scanners, but differences in qualified replies would make the segmentation even more actionable.
The DMARC reject rate difference between Proofpoint domains (61.8%) and Google Workspace (26.9%) is the detail that would have changed my approach earlier. I used to treat a mediocre open rate as a copywriting problem and go rewrite subject lines. It almost never was. The more useful question was always 'which segment is actually opening?' and I wasn't asking it because I wasn't splitting the data. The gateway-as-behavioral-signal point is underrated too: if a company paid to put Proofpoint in front of their inbox, that's a proxy for how seriously they treat unsolicited contact. Cold email into that segment isn't just technically harder, it's a different audience in terms of receptivity. Worth knowing before you spend time optimizing for it.
The split becomes more useful when paired with address confidence. In a recent small founder-outreach batch, the failures were not mainly Google or Microsoft filtering. They were invalid addresses, missing domains, and misconfigured self-hosted mail servers. That suggests a two-layer matrix before sending: first, confidence that the exact address is current and publicly verified; second, the receiving provider or gateway. Provider segmentation helps explain delivery, but source quality prevents avoidable bounces before delivery is even attempted. Have you compared bounce patterns by where the address was sourced as well as by MX provider?
Answering your closing question: almost nobody segments by provider, and I spent 20 years running a Microsoft partner business where half our prospects sat behind Proofpoint or Mimecast. Your gateway read matches what I saw, those companies chose a security product on purpose, so we stopped fighting the filter and moved that segment to phone, LinkedIn, and partner intros. The MX check before sending is the tactical gem here, it turns a deliverability mystery into a routing decision.
Very useful info .
No, in my experience almost nobody segments by receiving provider, and it's not because the idea is bad, it's because most cold email tools don't give you that breakdown natively. You'd have to export your list, run MX lookups yourself, join that back to your open/reply data, and most people sending a few campaigns a month aren't going to build that pipeline for themselves. It's the kind of thing that's obviously worth doing once someone lays out the reasoning like you just did, but it's friction, not ignorance, keeping people from doing it.
One pushback on the framing though: even within a single provider bucket, deliverability still varies a lot by domain age, sending reputation, and content, not just which of the four systems is receiving. Two companies both on Google Workspace can behave completely differently depending on how aggressively their specific tenant has tuned spam filtering. So segmenting by provider gets you from "one blended number" to "four less-blended numbers," which is real progress, but I wouldn't want anyone reading this to think hitting all three authentication protocols and knowing your provider mix means the deliverability problem is solved. It just removes one confounding variable out of several.
Both fair, and the second one is the correction the post needed.
You're right that four buckets is still four averages. A Google Workspace tenant with aggressive tuning and one on defaults are not the same environment, and my framing invited people to think the split was the answer rather than one variable removed. It isn't. It's one confounder out of several, and the ones you name are probably bigger.
The friction point is the more useful of the two though, and it explains something else in this thread. Several people said they'd start doing this. Almost none of them will, because the pipeline you describe is real work for a marginal gain on a few campaigns a month.
Which means the interesting question isn't whether people should segment. It's why no sending tool surfaces it by default, given they already resolve MX to deliver at all. The data exists inside those platforms. Nobody exposes it.
Someone in this thread pointed out that the actionable version isn't reporting anyway, it's send order. Self-hosted first, Google and Microsoft last and in smaller batches. That needs the split once, before the campaign, not a reporting pipeline after it. Much lower friction, and probably where this actually lands.
Appreciate the pushback. The post was a diagnosis wearing the clothes of a solution.
The provider split is the insight that changes everything. You've got half your list on two systems (Google + Microsoft) that share similar filtering, then a 10% segment on security gateways that operate completely differently (61% vs 27% DMARC reject rates tells the whole story), and 32% that might as well be random. Reporting on a blended open rate across all three hides whether your real problem is domain reputation, list quality, or just "this gateway doesn't like anyone." The segmentation rule applies to any outreach funnel that touches multiple systems - API rates, payment processors, webhook delivery. Different infrastructure = different behavior. One number lying to you about four problems.
The generalisation is tempting and I'd push back on half of it.
For payment processors and API rate limits, you're right and it's the same shape. Different infrastructure, different behaviour, one blended number hiding several problems.
Email is worse than those cases though, in a specific way. Your payment processor tells you when something fails. Your API returns a status code. Email's failure mode is silence, and sometimes worse than silence: someone in this thread pointed out that security scanners follow every link before a human sees the message, so gateway opens read artificially high. The segment that's hurting you most reports as your best performer.
So it's not just one number lying about four problems. On that 10%, the number lies in a consistent direction, which means more volume makes you more confident in the wrong answer rather than averaging out.
On the 32% though, I'd revise what I wrote. Someone here made the case that it isn't random at all. Most small businesses aren't running a mail server in any real sense, they're on whatever their web host bundled, so that bucket is probably a handful of regional hosting defaults repeated thousands of times. Homogeneous per host rather than random. I want to test that.
Not much of a process, honestly. We look at what people search for, write about it, and see what sticks. Eight years of that.
Provider segmentation is rare, and I'd take it further: MX data doubles as lead scoring. Twenty years running a Microsoft MSP taught me that a company paying for Proofpoint has real IT budget and treats security as policy, which makes them a better prospect and a harder inbox at the same time. Splitting reports into those four buckets tells you which game you're actually losing.
This is a great reframe — I've never thought about deliverability as "four systems" rather than one blended average, but it makes total sense once you see the breakdown.
I work adjacent to this from the data side (extracting business contact info at scale), and the "self-hosted and other" bucket you mention is exactly the one that gives me the most unpredictable results too — some domains resolve perfectly clean, others behave in ways that make no sense until you realize it's a random cPanel setup from a decade ago with zero consistent config.
To answer your question: no, I don't think most people segment by provider, mostly because it requires an extra step most tools don't surface by default. Feels like something that should be standard practice given how different Google Workspace vs. security gateways behave. Bookmarking the MX lookup tool, that's genuinely useful.
The 50.9% Google + Microsoft stat is the real insight here. It means deliverability isn't about optimizing for 500 servers — it's about not pissing off two algorithms. For my KDP book covers and Shopify tutorial landing page, I've noticed the same pattern with traffic sources: 95% of conversions will come from one channel, but we waste 80% of effort chasing the other 3. The question this raises for me: if the delivery surface is essentially a duopoly, does cold email become a game of reputation scoring rather than list quality?
It's reputation scoring, but list quality is how you get the reputation. They're not alternatives, they're the same lever at two different moments.
Google and Microsoft aren't scoring your list. They're scoring your sending domain, and what feeds that score is how recipients respond: non-existent addresses, spam complaints, mail that never gets opened. A bad list is just the most efficient way to teach two algorithms that your domain sends unwanted mail. So you don't choose between them. Clean list is upstream, reputation is the output.
Where your framing does hold, and it's the useful part: reputation is durable and campaign performance isn't. A bad campaign costs you that campaign. A bad reputation costs you every campaign after it, and your transactional mail too. Someone in this thread made the point that the real damage from a bad send doesn't land on the send, it lands weeks later on the invoices and password resets you weren't thinking about.
On the 80/20 parallel, I'd be careful transferring it directly. With traffic channels, ignoring the small ones costs you nothing. Here, the 10% gateway tier can quarantine your entire sending domain with no bounce signal at all. The small segment isn't just low-yield, it can damage the big one. Different economics :)
This is a fascinating breakdown! That 32.4% for 'Other / self-hosted' is actually wild.
I’ve been building a backend API to parse and audit SPF, DKIM, and DMARC records recently, and diving into the raw DNS data has been an eye-opener. While Google and Microsoft (making up that ~51%) have very standardized, strict rules for incoming mail now, that 32% self-hosted chunk feels like the Wild West of misconfigured or missing DMARC records.
Did your scan happen to capture how many of those self-hosted domains actually had a valid p=reject or p=quarantine DMARC policy in place compared to the Workspace/365 users?
Great insights, definitely reframes how we should look at inbox placement!
good job!
This is a great reminder that metrics can hide a lot of context. A single open rate or reply rate number can make teams chase the wrong problem when the underlying behaviour is different across segments.
The idea of grouping recipients by their email infrastructure is interesting because it turns deliverability from a "black box" problem into something measurable.
I wonder if this kind of segmentation will eventually become a default feature in outbound tools — similar to how analytics platforms moved from overall traffic numbers to cohort-based analysis.
Great!
Thanks ;)
wow thats a great information
Thank you
50,000 is a big enough sample that i'll take this seriously. the four-systems framing isn't how i'd have split it at all.
The blended-open-rate trap is the useful punchline. 50k domains into Google + Microsoft ~51%, then gateways ~10% with Proofpoint at 61.8% DMARC reject vs Google’s 26.9%, makes “four systems” a diagnosis, not a slogan.
Most cold-email advice still tweaks subject lines while half the list is a different inbox.
When you segment in practice, do you change send infrastructure per bucket, or diagnose and fix the worst lane first?
Neither, based on what came out of this thread.
Separate sending infrastructure per bucket is expensive and mostly solves the wrong problem. Fixing the worst lane first is the instinct, but the worst lane is usually the gateway segment, and the honest answer there came from someone else in this thread: you stop leading with email entirely. Enterprise tenants behind Proofpoint quarantine whole sending domains with no bounce signal at all, so you can spend months optimizing into something that never reports.
The third option, which I hadn't considered until someone here spelled it out, is send order. Same infrastructure, same copy, just sequence. Self-hosted first and largest, since reputation damage there stays local to individual hosts. Google and Microsoft last and in small batches, once you have engagement to show them, because those two weight domain engagement history the heaviest.
That's the version I find most convincing now. It's an action, it costs nothing, and it falls directly out of the split.
One caveat if you try it: don't use bounce rate as your gate for widening batches. Microsoft 365 is far more often catch-all, so it accepts bad addresses and sorts internally. Your Microsoft slice reads artificially clean. Complaint rate is the honest gate there.
Worth reading the Ojin comment further up, it's more rigorous than my post was :))
Not cold email, but your gateway tier maps exactly to something I hit building my SaaS: those security products don't just filter — they open your mail. Proofpoint/Mimecast-class scanners follow every link in the message before the human ever sees it. I found this out when single-use magic-login links kept arriving "already used": the gateway had clicked them. Had to redesign auth to a click-to-confirm button so a machine visit doesn't consume the token.
So I'd add to your tiers: behind a gateway, links don't just get filtered, they get executed. If your cold email has tracking links or one-click anything, your "opens" and "clicks" from that ~10% segment are partly robots — one more reason blended reporting lies.
To your question: I segment nothing by provider today, and after this post that feels like an obvious miss. Taking the MX-check idea.
This is the best correction anyone's made to the post, and it flips something I got backwards.
I framed the gateway segment as the one where your numbers look worse. It's probably the opposite. Tracking pixels get prefetched by the same scanners, so that ~10% can report inflated opens and clicks while actual human engagement is lower than anywhere else on your list.
So the blended average isn't averaging two real numbers. It's averaging a real one with a partly synthetic one, in the direction that makes you feel good about the segment that's hurting you most. That's worse than what I described.
Your magic-link story is the cleanest proof of it I've seen. A machine consuming a single-use token is unambiguous. Nobody can argue that away as a coincidence.
Practical version for anyone doing cold email: if a chunk of your opens come from the gateway tier, treat that number as unreliable rather than good news. And if you're sending anything with a one-time action in it, assume it gets fired before a human sees it.
Thanks for this one
You actually took it a step further than I did — "averaging a real number with a partly synthetic one, in the direction that flatters the worst segment" is a sharper way to say it than I managed. Stealing that framing.
The one thing I'd add to your practical version: it's not just that gateway opens are unreliable, it's that they're unreliable in a consistent direction, so they don't wash out at scale — more volume just means more confidently wrong. The fix that worked for me was to stop counting opens for that tier entirely and only trust an action a scanner can't fake: a reply, or a token that's still unspent when a human shows up.
And yeah — the magic-link one is the story I reach for now precisely because there's no coincidence argument left. A machine spent a single-use token before the recipient did. That's the whole thing in one line.
Thanks for pushing it further than I had it.
The consistent-direction point is the one that actually matters and I'd underweighted it.
Random noise averages out. Biased noise compounds. So the gateway segment doesn't just make your numbers fuzzy, it makes them wrong in a fixed direction, and every additional send increases your confidence in the wrong answer. More data makes it worse, which is the opposite of how people assume measurement works.
And it explains a failure mode nobody would ever diagnose correctly. If gateway opens read high, that segment looks like your best-performing one. So you send more into it. Which is precisely the tier where somebody in this thread argued you should stop leading with email entirely. The metric points you at the wall.
Your fix is the right shape too, and it generalises past this. Only trust signals a machine can't produce. A reply is one. An unspent token is one. An open is not, and a click barely is.
Which leaves the awkward conclusion that for roughly 10% of a typical list, open rate isn't a weak metric. It's an inverted one. Better to have no number than that number.
Thanks for this whole thread. You've given me more than the post did.
"Better to have no number than that number" is the line I'm keeping — that's the whole thing distilled. Once a metric is biased instead of just noisy it's not a weak signal, it's a liability, and averaging more of it just launders the bias into confidence. You said it cleaner than I did.
The rule I've landed on is the one you named: only instrument signals a machine can't fake. Everything else is decoration you'll eventually mistake for data.
That magic-link incident is actually what got me building a monitor for these silent third-party failures — the ones nobody diagnoses because the number looks fine. If you're ever up for it I'd genuinely value your eyes on it; you think about this more carefully than most people I've talked to.
l'idée que la passerelle soit un signal comportemental est tout à fait pertinente. Mais il faut avouer qu'Aryan te demande ton adresse email pour la troisième fois dans une discussion sur la délivrabilité des emails de prospection
great post
I'm happy if I can help :)
useful info
Glad it was useful. Curious, are you currently running cold outreach yourself or mostly researching this space?
Thank you for this !
You told aryan_sinh this is currently a diagnostic rather than a workflow, and that it becomes a workflow the day someone shows that acting on the segment changes outcomes rather than merely explaining them. Here is one case where it does, on an axis this thread has not touched: it is not cold email.
Disclosure, I work on growth at Ojin. We are preparing a send to roughly 136 people who opted into our community list a long time ago and have heard nothing from us since. Consent is fine. Deliverability is the risk, and those two get conflated constantly.
Your provider taxonomy turns out to change the send ORDER, which is an action rather than a report. Google and Microsoft weight engagement history for the sending domain most heavily, and together they are 50.9% of a typical list. A stale list is exactly the case where you have no positive engagement signal with them, so a large first send into that half generates a wave of non-engagement attached to your domain, and the resulting reputation damage then degrades mail reaching your live paying customers. The cost does not land on the campaign. It lands on transactional email you were not thinking about.
So the ordering that falls out of your data: send the self-hosted and other bucket first and largest. Filtering there is idiosyncratic, but the reputation consequences are mostly local to individual hosts rather than global to your domain. Watch bounce and complaint rates, then go to Google and Microsoft last and in the smallest batches, once you have some engagement to show them. That inverts the natural instinct, which is to start with the segment you understand best.
One caveat that cuts against my own suggestion, drawn from your catch-all point. Because Microsoft 365 accepts unknown recipients at SMTP and sorts internally, using bounce rate as the go or no-go gate for widening a batch will read falsely clean on the Microsoft segment specifically. For a reactivation send that slice needs complaint rate as its gate, not bounce rate.
And to your actual question: no, we were not splitting reporting by provider before reading this. We will be for this send, and for the reason above rather than for diagnostics.
I noticed your comment about reactivation campaigns and deliverability. It sounds like a lot of growth work involves these small operational pieces that are important but easy to postpone. Curious do you handle all the list research, segmentation, and campaign prep internally?
very useful info, prob will save me a lot of wastage
my pleasure
I hadn't considered checking MX records before evaluating campaign performance. That's a practical tip. It would be interesting to see reply rates broken down by provider as well, not just opens.
Exactly. Would love to see that split myself.
This is a really interesting way to look at cold email deliverability.
Most people optimize the email itself (copy, subject lines, sending volume), but ignore the infrastructure behind the recipient. Segmenting by receiving provider makes a lot of sense because a 40% open rate on Google Workspace and a 15% open rate on a security gateway are completely different situations.
Curious if you’ve seen any meaningful difference in reply rates between Google Workspace and Microsoft 365 after controlling for list quality?
Honest answer: I can't tell you. We see DNS and SMTP responses, never the campaign. Someone verifies a list, sends it elsewhere, and we're gone before anything lands.
But there's a difference we do see, earlier in the chain.
Microsoft 365 domains are far more likely to be catch-all. They accept everything at the SMTP layer, bad addresses included, and sort it out internally. Google tends to reject unknown recipients outright.
So your Microsoft segment shows a lower bounce rate than your Google segment on a list of identical quality, because Microsoft swallowed the failures instead of reporting them. Which means controlling for list quality using bounce rate doesn't actually control for it.
Your 40% vs 15% example might be understating the gap rather than overstating it.
No idea whether reply rates follow the same pattern. If you've got campaign data, you're better placed to answer that than I am.
Interesting finding. We've seen something similar—having more leads rarely improves results if the data quality and buying intent aren't there. Segmentation usually has a much bigger impact than list size.
Agreed, though I'd separate two things that often get merged.
Segmentation by buying intent is a targeting decision. Segmentation by receiving provider is an infrastructure one. Both matter, but the second is invisible in your CRM, which is probably why almost nobody does it.
Curious what your segmentation is actually based on. Firmographics, behaviour, something else? :))
the invisible-in-your-CRM framing is right, and i think it is actually worse than invisible: the metric your CRM does show you lies in the same direction.
microsoft 365 tenants are far more likely to be catch-all, accepting at the smtp layer and sorting it out internally. so on exactly the segment where your list is dirtiest, your bounce rate reads clean. you can mail a list full of dead addresses and recycled traps and the number on the dashboard looks fine, right up until reputation damage shows up somewhere with no obvious cause.
blended open rate being a trap is the punchline everyone took from this thread. blended bounce rate is the quieter one, because the provider that suppresses the most signal is the same one that accepts the most.
the practical consequence is for verification too. a vendor marking a catch-all domain valid is telling you accepted, not exists. treating catch-all as unknown rather than good, and keeping it in its own lane, is the only version that does not quietly rot.
Answering from an odd corner of your data. I run LeadGrid (leadgrid.eu), which builds local-business lists — trades, clinics, salons — so my lists sit almost entirely in that 32.4% "other" bucket. I essentially never see Proofpoint or Mimecast.
Two things from down there that might be worth a column in your index.
The bucket splits further than "self-hosted." Most local businesses aren't running a mail server in any meaningful sense, they're on whatever their web host bundled, so the MX belongs to a regional hosting company. In Germany it's IONOS, Strato, All-Inkl over and over. Filtering there is the host's default config, which makes it homogeneous per host rather than random. Cluster that residual by hosting provider and I suspect a lot of the unpredictability resolves into maybe fifteen configs.
The second one changed how I build lists. For a real share of these businesses the working inbox and the domain MX aren't the same thing. The site says info@salon-x.de, the owner actually reads a Gmail address that's in the footer of their Facebook page, and mail to the domain sits unopened for months. Verification says the address exists, the MX lookup says Google or the host, both are correct, and the message still goes nowhere. Same gap you drew between "exists" and "will land," one layer earlier — the address is real, the human isn't behind it.
On your actual question: no, I don't split reporting by provider, and I'd guess few people selling into local SMBs do, because our variance lives in whether the address is one the owner reads at all. Different failure mode, and it looks identical from the outside too.
On the hosting cluster: you're probably right, and it's testable. We resolve the MX, then roll everything we don't recognise into "other" and stop looking. If regional hosts dominate that bucket, the filtering isn't random, it's a handful of default configs repeated thousands of times. That turns an unpredictable segment into a known one. Worth checking.
The second point is the one I don't have an answer to.
We can confirm a mailbox accepts mail. We can't tell you a human reads it. For a shop where the domain address is a formality and the owner lives in a Gmail account, we return a clean result on a dead channel. Correct, and useless. Same gap I drew between "exists" and "will land", one layer earlier, and I hadn't seen it framed that way.
I don't think that's fixable on our end. Nothing in the protocol tells you whether anyone is home.
The hosting idea is going on the list. If it works I'll publish it and credit where it came from.
the reframe is genuinely useful, but the practical takeaway is even sharper: if 51% of your list is Google + Microsoft, then "improving deliverability" mostly means passing THEIR two filters, not chasing a hundred edge cases. and those two reward the same thing, sender reputation and engagement, not clever copy tricks. so the highest-leverage move for a cold sender isnt more a/b testing subject lines, its the boring infrastructure: warmed domain, clean SPF/DKIM/DMARC, low volume per inbox, and actually getting replies (engagement is the signal both giants weight most). one question your data raises, that 32% "other/self-hosted" is interesting because those are often smaller shops with stricter or weirder setups, do you see them bounce harder, or is it the opposite because theres no big-provider ML filter in the way? that split might matter more than the google/microsoft one for anyone selling upmarket vs down.
One of the sharpest deliverability posts I've read, and "you're reading one number for two different games" is the part most people miss and shouldn't. The self-limiting honesty at the end (verification proves the address exists, not that the message lands, "including us if we oversell") does more for trust than any feature claim could.
To your question, do people segment reporting by receiving provider: almost nobody does. But there's a second-order version of your insight worth naming. It's not just that the segments filter differently, they represent different buying postures, which changes the channel decision, not just the deliverability tactic.
A company that deliberately bought and configured Proofpoint or Mimecast didn't just harden email, they signaled that unsolicited outreach is culturally unwelcome. The DMARC-reject gap you cited (61.8% Proofpoint vs 26.9% Google) isn't only a technical wall, it's a proxy for "this org has an opinion about cold email." So the gateway segment isn't just harder to land in, it's a place where landing might not help, because the org has pre-decided the channel is noise. Different channel entirely, like you said, but the reason is behavioral, not just technical.
The self-hosted 32.4% bucket is the interesting one strategically. Unpredictable filtering, but the segment least likely to have a formal "no cold email" posture. Your best deliverability AND your least-defended prospects probably overlap there. Might be the segment to lead with, not despite the unpredictability but because the humans behind it haven't institutionalized resistance yet.
Do you see engagement (replies, not just opens) track the provider split too? Whether the gateway segment actually converts when you do land would tell you if it's worth the effort at all.
The gateway-as-behavioral-signal read is better than what I wrote, and I'm slightly annoyed I didn't get there myself. You can push it further too: most orgs don't buy Proofpoint proactively. They buy it after an incident. So you're not just looking at a security posture, you're often looking at an organization that has a written policy and a person whose job it is to enforce it. The wall is technical, the decision behind it isn't.
On the self-hosted bucket, agreed on the strategy, but I'd add a counterweight from our side of things.
That bucket is the least institutionally defended and the most hazardous for your list at the same time. Legacy servers, abandoned mailboxes, domains nobody has audited since 2014. Nobody's pruning anything. It's where dead addresses and recycled spam traps concentrate, and a trap hit costs you more than a hundred non-replies from a gateway.
So it's the friendliest segment to reach and the easiest one to hurt yourself in. Different risk, not less risk. I'd still lead with it, just not raw.
On your question, I have to give you a disappointing answer. I don't know, and structurally I can't. We see DNS and SMTP responses. We never see the campaign. Somebody verifies a list, sends it somewhere else, and we're gone before anything happens. Wrong end of the funnel entirely.
The people who could answer it are the sending platforms, and I'd genuinely like to see that data. Reply rate split by receiving provider, controlled for company size, would settle whether the gateway segment is worth the effort or just worth skipping. My instinct says the effort is better spent elsewhere, but that's an instinct, and instincts are how you end up with a nice theory and no evidence.
If you're in a position to check that on your own numbers, I'd read that post.
The "bought after an incident, so there's a written policy and a person paid to enforce it" addition is the sharper version, and it changes the read: behind a gateway you're not up against a filter, you're up against someone's job. That's not a wall you out-copy, it's a decision you don't get to appeal.
And the spam-trap counterweight is the thing I glossed. "Least defended" and "most hazardous" are the same property from two sides. Nobody pruning means nobody resisting AND nobody removing the landmines. "Lead with it, just not raw" is exactly right, the segment rewards reach and punishes laziness in the same breath.
On the turned-around question, as honest as you were about your funnel: I can't give you the clean dataset either. What I can offer is a directional read from doing outreach in communities rather than cold email, different channel, same underlying dynamic (institutional resistance vs individual receptivity). The pattern holds: places with formal gatekeeping convert worse even when you get through, because getting through isn't the hard part, the pre-decided "this is noise" posture is. The signal that predicts a reply isn't whether you landed, it's whether the recipient's context had already filed your category as unwelcome before you arrived. Gateways are that classification made technical.
Which agrees with your instinct: effort's probably better spent elsewhere, because landing and converting are governed by two different things. Deliverability is a transport problem. Reply rate is a permission problem. The gateway segment fails the second even when you solve the first.
The one who could settle it is a sending platform willing to publish reply-rate-by-provider controlled for company size. If I ever get a clean enough sample, I'll write it and tag you. One of the better threads I've had here.
Self-hosted segments can be tricky because abandoned mailboxes and dead addresses often hide legacy spam traps that hurt deliverability.
The interesting shift is that you're turning deliverability from a sending problem into a segmentation and intelligence problem.
What would convince you that provider-level segmentation is something teams will build into their workflow, rather than just another diagnostic they check when campaigns underperform?
You've put your finger on the weak spot, and I think you're right.
Today it's a diagnostic. People check it after a bad week, not before a campaign. It becomes a workflow the day someone proves that acting on the segment changes outcomes, not just explains them. I can tell you Google and Microsoft behave differently. I can't yet tell you what to do differently beyond adjusting expectations, and I'd be overselling if I pretended otherwise.
My guess is the sending tools surface it before anyone builds a habit around it. Nobody adopts a workflow that costs them a manual step.
Have you seen anyone actually test different sequences per provider?
People usually check metrics as a diagnostic after a bad week rather than making it a proactive part of their campaign workflow.
Appreciate the honesty and context.
Would be good to continue the conversation as you explore whether this becomes part of the workflow or stays a diagnostic layer.
What's the best email to reach you on?
Happy to keep talking, but let's do it here. Nothing I've said is private, and anyone reading the thread later benefits from it.
If you land on something concrete, or you're in a position to test the segmentation on real sends, post it and tag me. I'll show up.
My contact is on my profile if you need it for something specific :)
Appreciate that, Danila.
Makes sense. I agree the discussion itself is valuable here.
I think email might be a better place for a more detailed exchange when there’s more context to share, but happy to continue here as well.
Sounds good. Whenever you've got something concrete on the sending side, here or by email works.
Still curious about the original question if you ever come across an answer ;)
Appreciate that, Danila.
I think this conversation may be easier to continue over email when there's more context to share.
What's the best email to reach you on?