Azure inboxes -- bulk Microsoft 365 mailboxes sold cheap, often 50 to 100 crammed onto a single domain -- are losing deliverability fast. The core reason is that domain-based blocklists like SURBL are listing the domains these inboxes depend on, and cheap TLDs like .info are getting hit hardest. Because the model stacks dozens of mailboxes on one shared domain and leans on Microsoft licensing loopholes, a single listing takes the whole batch down at once. Winnr deliberately never sold this model. Here is why it breaks, and what actually holds up.
For the last couple of years, cheap Azure inboxes were the open secret of high-volume cold email. Vendors spun up Microsoft 365 mailboxes in bulk, packed dozens of them onto a single domain, and sold them for pennies. They worked well enough, for a while, by riding Microsoft's strong default reputation. That trade is now unwinding.
Senders are reporting that batches of Azure inboxes have stopped performing, sometimes inside a single week: open and reply rates falling off a cliff, more mail landing in spam, and entire sets of mailboxes going quiet at the same time. This is not a random blip. It is the predictable result of how these inboxes are built colliding with how modern spam filtering actually works. This guide explains the mechanism, why it was inevitable, and what to move to.
What Senders Are Seeing
The pattern being described across the cold email community is consistent. Mailboxes that were landing fine suddenly degrade together. Not one inbox, but a whole cohort that shares the same domain or the same batch. Placement drops, bounces and deferrals climb, and warmup scores sag. Many operators are responding by migrating back to Google Workspace or standing up new infrastructure in the background, even though pre-warmed Google accounts get expensive quickly.
When inboxes fail in correlated batches like this, the cause is almost never the individual mailbox. It is something shared above the mailbox level: the domain, the tenant, or the IP space the whole batch sits on. For Azure inboxes, the shared layer that is failing right now is the domain, and the thing doing the failing is domain-based blocklisting.
What "Azure Inboxes" Actually Are
In the cold email world, "Azure inboxes" refers to Microsoft 365 mailboxes provisioned in bulk on Microsoft's infrastructure and resold cheaply for outbound. The defining characteristic is density and cost. To make the per-mailbox price as low as possible, vendors:
- Cram 50 to 100 mailboxes onto a single domain. One domain, often a throwaway TLD, carries the entire batch so the domain cost is amortized to almost nothing.
- Lean on Microsoft's default sending reputation. Mail goes out through Microsoft's shared infrastructure, which historically enjoyed strong inbox placement, so the inboxes felt healthy out of the gate.
- Depend on licensing arbitrage. The cheap pricing relies on getting Microsoft 365 seats far below retail, whether through trial tenants, partner and reseller channels, or other loopholes in how Microsoft prices and provisions seats.
The appeal is obvious: instant, cheap inboxes that borrow a trusted provider's reputation. The hidden cost is that every one of those advantages is shared and borrowed, not owned. You do not own the domain reputation, you do not own the sending infrastructure, and you do not own the licensing position. When any of those shared foundations shifts, the whole batch moves with it.
What SURBL Is and Why It Matters
SURBL stands for Spam URI Realtime Block Lists. It is a domain-based blocklist, and that distinction is the whole story.
Most senders think about blocklists in terms of IP addresses: a sending server gets a bad reputation, lands on an IP blocklist like Spamhaus, and its mail gets blocked. SURBL works at a different layer. Instead of listing the IP that sent the message, it lists the domains that appear inside spam -- the URIs in message bodies, and the sending and link domains that show up in footers, signatures, calendar links, and tracking. Filters such as SpamAssassin and Rspamd, along with many corporate secure email gateways, query SURBL for every domain they find in a message.
Here is why that matters for cold email. Because the listing is attached to the domain, it follows that domain everywhere:
- It follows the domain across every IP. Moving to a new sending server does nothing.
- It follows the domain across every mailbox on it. If your domain is listed, all 50 to 100 inboxes on it are tainted, not just the one that triggered the listing.
- It taints any message that references the domain, including legitimate ones, because the receiving filter sees a listed domain in the body or headers and scores the message as spam.
This is the difference between IP reputation and domain reputation, and it is exactly why domain-based listing is so destructive to the bulk inbox model. We cover the broader distinction in our guide on IP reputation versus domain reputation, but the short version is simple: domain-based blocklists make your domain the single point of failure, and the cheap Azure model puts everything on one domain.
Why Azure Inboxes Are Getting Hunted
Domain-based detection thrives on shared fingerprints, and bulk Azure inventory is nothing but shared fingerprints. The mailboxes in a batch tend to share a registration pattern, a cheap TLD, a near-identical DNS setup, similar send volumes, and often templated content. To a blocklist that scores domains by how closely they match known spam patterns, this is a gift.
The mechanism plays out like this:
- A batch of inboxes on one domain starts sending outreach at volume.
- Some of that mail hits spam traps or draws complaints, which is normal at cold email volume.
- The domain gets flagged and added to a domain blocklist like SURBL.
- Because the domain is shared, every mailbox on it inherits the listing at the same moment. The batch dies together.
This is why the failures cluster. It is not that 80 mailboxes independently went bad in the same week. It is that one domain carrying 80 mailboxes got listed once. The density that made the inboxes cheap is the same density that makes the failure total.
The reason this crests in waves is also straightforward. As more vendors pile onto the same cheap-Azure playbook, the shared patterns get easier to detect, and blocklists catch up to them in bursts. Add Microsoft periodically tightening its own rules -- the deprecation of Basic Authentication for SMTP in March 2026 is the most recent example -- and you get periods where large swaths of cheap inbox inventory degrade at once.
Why .info Domains Are Getting Blacklisted
The damage is concentrated on cheap top-level domains, and .info is taking the worst of it. There is a clear reason. .info is one of the least expensive TLDs to register, which has made it a perennial favorite for spam and abuse. That long history means filters and blocklists already treat .info with suspicion, and they weight newly registered .info domains especially heavily.
Cheap inbox vendors gravitate to .info and similar bargain TLDs precisely because they are cheap, which concentrates an entire industry's risk on the exact TLD that filters distrust most. When those domains are then used for high-volume outreach, they get listed quickly, and the low registration cost that made them attractive turns into the reason the inboxes are now worthless. The TLD you send from is part of your reputation, which is why we are deliberate about TLD selection -- see our breakdown of which TLDs are safe for cold email.
Why the Cheap Model Was Always Going to Break
Strip away the specifics of SURBL and .info, and you are left with two structural weaknesses that guaranteed this outcome.
One domain is a single point of failure
Domain reputation is shared by every mailbox on the domain. Put three mailboxes on a domain and a single complaint affects three inboxes. Put 100 mailboxes on a domain and that same complaint, spam trap, or blocklist match affects 100 inboxes. The cheap Azure model does not spread risk, it concentrates it. There is no version of cramming 50 to 100 mailboxes onto one domain that is resilient, because the entire batch shares one reputation and one fate. This is also why we recommend a small number of mailboxes per domain rather than maximizing density.
The economics depend on loopholes that keep closing
The reason these inboxes are cheap is not efficiency, it is arbitrage. The pricing depends on obtaining Microsoft 365 seats far below their intended cost and on packing mailboxes densely enough to amortize the domain. Both of those levers depend on Microsoft not noticing or not caring, and Microsoft has been steadily closing the doors: tightening trial and tenant abuse, deprecating Basic Auth, and pruning provisioning paths that were never meant for bulk outbound. Every time a loophole closes, a wave of inboxes either gets more expensive or stops working. A business model built on a provider's unclosed loopholes is not a business model, it is a countdown.
Put those two together and the conclusion writes itself. You are renting reputation you do not control, on infrastructure you do not own, through a pricing loophole that is actively being closed, with all of your risk concentrated on one domain. That is a brittle stack by design.
Why Winnr Never Sold Cheap Azure Inboxes
Winnr made a deliberate choice not to sell this model, even though it would have been the cheapest inventory to list and the easiest to market on price. The reason is that we optimize for deliverability that compounds rather than arbitrage that decays. In practice that means the opposite of the cheap-Azure playbook on every axis:
- We run our own SMTP infrastructure. Winnr sends on its own servers and dedicated IPs rather than piggybacking on Microsoft 365 or reselling Google Workspace. Your deliverability does not depend on another provider's tolerance for outbound, and there is no licensing loophole to close.
- We keep mailbox density low. Dedicated domains carry three to five mailboxes each, not 50 to 100. If a domain ever has a problem, the blast radius is tiny by design.
- We authenticate every domain fully. SPF, DKIM, and DMARC are configured automatically on every domain, with DMARC set to p=reject. Authenticated, dedicated domains are the opposite of the anonymous shared domains that blocklists hunt.
- We avoid junk TLDs and warm properly. We are deliberate about TLD selection and include built-in warming, so inboxes build real reputation instead of borrowing someone else's until it runs out.
This costs more than a cardboard inbox that sells for a few cents. It also does not evaporate the week a blocklist updates its rules or Microsoft closes another door. The whole point of infrastructure is that it should still be standing after the shortcut collapses.
What to Do If Your Azure Inboxes Are Cooked
If a batch of your Azure inboxes just stopped performing, here is the practical path forward.
Stop trying to rehabilitate the burned domain
If the shared domain is the problem, warming it back up will not fix it. A domain that 50 to 100 mailboxes burned through high-volume outreach is usually not worth recovering. Pause sending on it, stop pointing new campaigns at it, and treat it as retired. Our domain reputation recovery guide covers when a domain is salvageable and when it is not.
Spread out instead of stacking up
Replace the one-giant-domain architecture with many dedicated domains carrying a handful of mailboxes each. The same total inbox count spread across more domains with lower density is dramatically more resilient, because no single listing can take down more than a few mailboxes.
Move to infrastructure you control
The durable options are dedicated SMTP infrastructure that you do not share with the rest of the bulk-inbox market, or properly provisioned Google Workspace with low mailbox density. Whichever you choose, the architecture matters more than the brand: dedicated domains, low mailbox counts, full DNS authentication, and warming. Re-buying the same cheap Azure model from a different vendor just restarts the countdown.
Migrate without downtime
Stand up the new inboxes first, with automatic SPF, DKIM, and DMARC, and warm them for two to three weeks while your existing campaigns keep running. As the new accounts finish warming, shift volume over gradually and retire the burned batch. For the full sequence, our cold email best practices guide and SMTP versus Google and Microsoft comparison walk through the migration step by step.
Frequently Asked Questions
Are Azure inboxes dead for cold email?
Not dead, but structurally fragile and trending the wrong way. The cheap Azure inbox model crams 50 to 100 mailboxes onto a single domain and leans on Microsoft licensing loopholes. Domain-based blocklists like SURBL list the shared domains these inboxes run on, and a single listing takes every mailbox on that domain down at once. Many senders are seeing whole batches degrade inside a single week. The mailboxes that survive longest are the ones on dedicated domains with low mailbox counts, which is the opposite of how cheap Azure inventory is built.
What is SURBL and why does it matter for cold email?
SURBL (Spam URI Realtime Block Lists) is a domain-based blocklist. Unlike IP blocklists that track sending servers, SURBL lists the domains that appear in spam, including the sending and link domains that cold emailers put in their footers, signatures, and tracking links. It is consumed by SpamAssassin, Rspamd, and many secure email gateways. Because the listing is tied to the domain, it follows that domain across every IP and every mailbox on it. For cold email, that means one flagged domain can sink all of its inboxes simultaneously.
Why are .info domains getting blacklisted for cold email?
.info is one of the cheapest and most abused top-level domains, with a long-standing poor reputation. Blocklists and filters apply extra suspicion to newly registered .info domains because so much spam originates from them. Cheap inbox vendors gravitate to .info to keep per-mailbox costs low, which concentrates risk on exactly the TLD that filters already distrust. When those domains are used for high-volume outreach, they get listed quickly, and every mailbox on them goes with it.
How many mailboxes should I put on one domain for cold email?
Keep it low. Winnr recommends three to five mailboxes per domain. Domain reputation is shared by every mailbox on the domain, so a low mailbox count limits your blast radius if one mailbox draws a complaint or a spam trap. Cramming 50 to 100 mailboxes onto a single domain does the opposite: it concentrates all of your risk in one place, so a single blocklist match or reputation hit cooks the entire batch at once.
Does Winnr use Azure or Microsoft 365 inboxes?
No. Winnr operates its own SMTP infrastructure with dedicated IPs rather than reselling Microsoft 365 or Google Workspace. Inboxes are provisioned on dedicated domains with a healthy three to five mailboxes per domain, full SPF, DKIM, and DMARC authentication, and built-in warming. Winnr deliberately never sold the cheap bulk-Azure model because it depends on Microsoft loopholes and high mailbox density that are not sustainable.
Can I recover a domain that SURBL has blacklisted?
Sometimes, but it is rarely worth it for cold email. You can request delisting and pause sending, but if the domain was used for high-volume outreach across many mailboxes, the reputation damage usually outlasts the delisting. The faster and more reliable path is to retire the burned domain, move to fresh dedicated domains with low mailbox counts, authenticate them fully, and warm them before sending. Trying to rehabilitate a domain that 50 to 100 mailboxes burned is usually a losing trade.
Are Google Workspace inboxes safer than Azure inboxes for cold email?
Properly provisioned Google Workspace inboxes tend to be more durable than bulk Azure inboxes, but pre-warmed Google accounts get expensive quickly, and Google has its own suspension risk for cold email patterns. The more important variable is not the provider but the architecture: dedicated domains, a low mailbox count per domain, full DNS authentication, and warming. A poorly built Google setup with too many mailboxes per domain fails for the same reasons a cheap Azure setup does. Owning your sending infrastructure removes the dependency on either provider's tolerance.
What This Means Going Forward
The collapse of cheap Azure inboxes is not an anomaly, it is the same lesson the cold email market relearns every couple of years. Shortcuts that depend on shared reputation, borrowed infrastructure, and provider loopholes work right up until the provider or the blocklists catch up, and then they fail all at once. The senders who keep deliverability through these waves are the ones who never built on the shortcut in the first place.
Sustainable deliverability is boring on purpose: dedicated domains, a handful of mailboxes on each, full authentication, real warming, and sending infrastructure you actually control. It costs more than a few cents per inbox, and it is still working the morning after the cheap inventory gets blacklisted. If the latest Azure wave caught your campaigns, treat it as the signal to move onto infrastructure that was built to last rather than built to be cheap.
Related guides: Read what changed with Microsoft 365 for cold email in 2026, learn the difference between IP reputation and domain reputation, see which TLDs are safe for cold email, find out how to recover a burned domain, or review the full cold email best practices guide.