Cold Email Deliverability in 2026: Find Where Mail Dies
Last verified: 2026-09-17A practical guide to finding out where your outbound actually dies — before you buy another tool to fix the wrong thing.
You send 600 emails and get four replies. The obvious conclusion is that cold email deliverability is the problem, so you buy a warmup tool, add three domains, and send again. Six weeks later the number is the same. That happens because "it didn't work" covers three completely different failures, and warmup only addresses one of them.
A message can be rejected at the SMTP handshake and never enter the recipient's mailbox at all. It can be accepted and filed in spam, where it sits unread. Or it can be delivered to the inbox and ignored, which is not a deliverability failure at all — it is a list, timing or offer failure wearing a deliverability costume. Each one leaves different evidence and needs a different fix. Most guides on this topic blur all three into one checklist.
The three failure modes, and how they differ
| Failure | What the evidence looks like | Root cause | What actually fixes it |
|---|---|---|---|
| Rejected | A bounce in your sending tool with a 5xx SMTP code. Microsoft returns 550 5.7.515 for authentication failures. |
Missing or misaligned SPF, DKIM or DMARC; bad PTR record; no TLS; dead address. | DNS and infrastructure. Cheap, fast, and entirely under your control. |
| Spam-filed | No bounce. Sends look successful. Opens and replies both near zero, across every segment. | Complaint rate, domain or IP reputation, sudden volume ramp, content and link patterns. | Volume discipline, list hygiene, and time. Weeks, not hours. |
| Delivered and ignored | Normal bounce rate, some opens, replies clustered in one or two segments and zero elsewhere. | Wrong list, wrong offer, wrong moment, or a message indistinguishable from the other thirty that day. | Targeting and message. No DNS record will help you here. |
The diagnostic order matters. Fix rejection first, because it is binary and solvable in an afternoon. Then look at reputation. Only then start blaming the copy — and be honest that by that point you are no longer working on deliverability.
What the mailbox providers actually require now
The 2024–2025 rule changes were the real break point, and they are now enforced rather than advisory. The thresholds below come from the providers' own documentation.
| Provider | Applies to | Required | Failure behaviour |
|---|---|---|---|
| Gmail | All senders; extra rules above 5,000 messages/day to Gmail accounts | SPF or DKIM for all senders; SPF, DKIM and DMARC plus one-click unsubscribe for bulk senders. TLS connection and valid PTR record required. Spam rate below 0.3%, with 0.10% recommended. | Filtering and, in force since 1 February 2024, rejection of non-compliant bulk mail. |
| Yahoo | All senders, with bulk-sender additions | SPF or DKIM minimum; both plus a DMARC policy of at least p=none with alignment for bulk senders. Functioning list-unsubscribe header, unsubscribes honoured within two days. Spam rate below 0.3%. |
Filtering and blocking. |
| Outlook / Hotmail / Live | 5,000+ messages/day to Microsoft consumer domains | SPF, DKIM and DMARC (p=none minimum, aligned to SPF or DKIM). |
Outright rejection since 5 May 2025: 550 5.7.515 Access denied. Not junk — not delivered at all. |
Two things in that table are worth sitting with. First, the shift from filtering to rejection: a message that is rejected never reaches a spam folder where a curious prospect might eventually find it. Second, 0.3% is not a comfortable ceiling. It is three complaints per thousand delivered messages. A single badly targeted campaign to a cold list can cross it in one morning.
The sending limits nobody reads until they hit them
Separately from reputation, your own mail provider caps what you can push out of a single mailbox. These are hard limits, not guidance.
| Limit | Google Workspace | Microsoft 365 / Exchange Online |
|---|---|---|
| Messages per user per day | 2,000 (500 on trial accounts) | Governed by the recipient rate limit below |
| Recipients per user per day | 10,000 total; 3,000 external | 10,000 |
| Unique recipients per day | 3,000 (2,000 external) | — |
| Recipients per message | 2,000 total, 500 external; 100 via SMTP/POP/IMAP | Up to 1,000, configurable |
| Rate limit | — | 30 messages per minute on SMTP client submission |
| Consequence of exceeding | Sending blocked for up to 24 hours | Excess submissions throttled and carried over |
Note how far these ceilings sit above what is safe. Google Workspace will happily let one mailbox send 2,000 messages in a day. Doing that from a domain with no sending history is the fastest way to move yourself from the first row of the failure table to the second. The platform limit is not a target.
A worked diagnostic you can run this week
Take one recent campaign and split the outcome into the three buckets before you change anything. The arithmetic below uses made-up figures purely to show the shape — replace every number with your own.
Say you sent 1,000 messages:
- Count hard bounces and read the codes. Suppose 90 bounced, and 60 of those carry a 5.7.x authentication code. That is not a list problem, it is a DNS problem. Check SPF, DKIM alignment and your DMARC record before doing anything else.
- Subtract bounces to get accepted mail. 1,000 − 90 = 910 accepted.
- Look at open behaviour by domain group. If accepted mail to one provider shows near-zero engagement while another looks normal, you have a reputation problem specific to that provider, not a global one.
- Look at replies by segment, not in aggregate. If two of your six segments produced every reply, the other four were a targeting error that no amount of warmup will repair.
- Only then count what is left. Mail that was accepted, opened, and ignored is a message problem. Own it as one.
Running this once is worth more than a month of guessing, because it tells you which of three very different projects you are actually on. It also stops you paying for infrastructure to solve a copy problem — the single most common way outbound budget gets wasted.
Cold email deliverability has a ceiling, and it is lower than it used to be
Here is the part most guides skip. You can do all of this correctly — clean authentication, disciplined volume, a verified list, honest copy — and still land far short of where the same effort would have landed you in 2021. The rules got stricter and, independently, buyer inboxes got saturated. Perfect deliverability delivers you into a crowded room; it does not make anyone turn around.
Two further limits are worth naming:
- Your monitoring mostly covers consumer mail. Gmail's Postmaster Tools reports on Gmail. If your buyers sit behind corporate Exchange, a regional host, or a local provider common in MENA, Turkey or South Asia, you are flying with far less instrumentation than the guides assume.
- Volume is the thing that breaks reputation, and volume is what most tooling sells. If a tool's pricing rewards sending more, its incentives and your domain's interests diverge, which is a longer argument made here.
The honest conclusion is that email should be one channel in a sequence rather than the whole motion. Where a buyer's attention actually lives — WhatsApp in much of the world, LinkedIn in others — is a channel question, not a DNS question. Whatever channel you add, consent and disclosure rules still apply.
Where BOSRAI sits, including what it does not do
BOSRAI is an AI sales platform for small teams: ICP definition, lead sourcing, outreach across email, WhatsApp and LinkedIn, follow-up, and a built-in CRM, with a human approving messages before they send. Two parts of that are relevant here.
The approval step is a deliverability control, not just a safety one. Complaint rate is what most directly threatens your domain, and a person reading a batch before it sends catches the mistargeted list that would have generated those complaints. It is a slower model than fully autonomous sending, deliberately.
Being multi-channel means email volume per mailbox does not have to climb to hit a pipeline number, because the sequence is not carrying everything through one channel. That is a structural argument, not a measured one.
What BOSRAI does not do: it does not set up your DNS, it cannot fix a burned domain, and it publishes no deliverability benchmarks, because it has none to publish. There are no customer case studies or inbox-placement figures on this site, and inventing them would be the same behaviour this article warns about. Pricing runs from a free tier to $999/month and is listed on the pricing page.
If you take one thing from this: spend an hour classifying your failures before you spend a dollar fixing them.
Sources
- Gmail sender guidelines, Google — 0.3% spam-rate threshold, 0.10% recommendation, 5,000 messages/day bulk threshold, TLS and PTR requirements, 1 February 2024 enforcement date.
- Google: new Gmail protections for a safer, less spammy inbox — the 5,000 messages/day bulk-sender definition and the one-click unsubscribe requirement.
- Yahoo Sender Best Practices — SPF/DKIM minimum, SPF+DKIM+DMARC for bulk senders, 0.3% spam rate, unsubscribes honoured within two days.
- dmarcian: Microsoft enforces SPF, DKIM and DMARC — 5,000/day threshold for Microsoft consumer domains, 5 May 2025 start,
550 5.7.515rejection. - Validity: Microsoft's new bulk email rules explained — confirmation that non-compliant mail is rejected rather than junked, and the list of recommended-but-not-required practices.
- Gmail sending limits in Google Workspace — 2,000 messages/day per user, 3,000 external recipients/day, per-message recipient caps, 24-hour block on exceeding.
- Exchange Online limits, Microsoft Learn — 10,000 recipients per user per day, up to 1,000 recipients per message, 30 messages per minute on SMTP client submission.