Quick answer: Email deliverability is whether your email actually reaches the recipient's inbox. It is not the same as delivery. Delivery means your server handed the message to their server successfully. Deliverability means a human can find it. Most email that "fails" was delivered perfectly and then filed somewhere nobody looks, or refused at the door without anyone telling you. Deliverability is decided by three things: whether you are authenticated, what your domain's reputation is, and how recipients behave when your mail arrives.
This is the distinction that costs people the most money, so it is worth being precise about.
Delivery is a transaction between two servers. Yours connects to theirs, hands over the message, and gets an acceptance code back. That is it. Your sending tool marks the message as "sent" or "delivered" and moves on.
Deliverability is what happens next, inside the receiving system, where you have no visibility. The message can be:
Only the first one is what you wanted. Your dashboard reports the same green "delivered" for the first three.
We learned this on our own infrastructure. Our internal alerting sent its notifications to an address on our own domain. Our own mail server treats that domain as internal, so it never performed a public DNS lookup for it — the messages were handed straight to a mailbox on the same machine. Every send was recorded as a success, because at the transport level every send genuinely was one: our outbound mail server's delivery log holds 2,665 Delivery records between 2026-04-15 and 2026-07-13 for messages sent from the one address our internal alerting sends as — not our support or no-reply addresses, which carry different mail. They did not arrive at a steady rate — one day accounts for 224 of them. What the transport log can show is that the mail was accepted for delivery; it cannot show that anyone read it, so that is not claimed here. The delivery was perfect. The deliverability was zero. The fix was not a better retry policy: our alerting now refuses to send to our own domain at all.
If your sending tool says 98% delivered and your replies have collapsed, those two facts are not in conflict. They are measuring different things.
Before a receiving server looks at your subject line, it checks whether the message is really from your domain. Three DNS records do that work:
If these are missing, broken or misaligned, you can be rejected before anyone reads a word. Under the sender rules Gmail and Microsoft rolled out through 2025 and 2026, unauthenticated bulk mail can be refused outright rather than filtered.
This layer is the one you fully control, it is the cheapest to fix, and it is the one most often quietly broken. When we scanned 175 real business domains, about one in seven had SPF that was broken or entirely absent, and over half had DMARC that enforced nothing.
Receivers keep a running judgement on your sending domain and the IP addresses you send from. It is built from bounce rates, spam complaints, how often people delete without reading, whether you send to addresses that no longer exist, and whether your volume looks natural or looks like a burst.
Reputation is slow to build and quick to lose. A single bad campaign to a purchased list can undo months of good sending, and recovery takes weeks.
Domain reputation now matters at least as much as IP reputation. Moving to a new IP does not shed a damaged domain history.
Modern filtering is largely behavioural. If recipients open, reply, and move your mail out of spam, that tells the receiver your mail is wanted. If they ignore or delete it, that tells the opposite story.
This is the layer people try to fake, and it is the one that has become most dangerous to fake. Simulated engagement is the exact pattern the major providers now hunt for, because the mechanical signature of automated opens is easy to spot at scale. The reliable version is unglamorous: send to people who asked, send things worth opening, and remove the ones who never engage.
Three reasons, and they compound:
Failure is silent. No provider emails you to say "we are filing your mail in spam." Spam placement produces no bounce, no error, no signal at all.
Your tools measure the wrong thing. Sending platforms report on the handoff, because that is all they can see. They cannot see the recipient's inbox and neither can any tool that claims otherwise.
The cause is usually invisible and boring. A missing DKIM key. A second SPF record someone added two years ago. A DMARC policy that enforces nothing. None of these announce themselves, and all of them are DNS records nobody has looked at since setup.
The practical result is that people rewrite subject lines, change sending times, and buy fresh lists, while the actual cause sits in a DNS record that has been broken the whole time.
Honest framing: nobody can guarantee inbox placement. Any tool or agency that promises it is either misunderstanding the problem or misrepresenting it. The receiving provider makes the final decision, using signals you cannot fully see.
What you can control:
That last point deserves its own note. You cannot see inside your recipients' inboxes, and neither can we. What can be checked honestly is your setup, your DNS records, your blacklist status and your reputation signals. Anyone reporting your "inbox placement rate" is measuring test mailboxes they control, not your actual recipients, and they should say so plainly.
If your email has stopped landing, work in this order:
Specific problems we have written up in detail:
There is no single honest number, because the figure depends entirely on how it is measured. Anyone quoting you a universal benchmark is quoting a measurement method, not a fact about your mail. What is useful is your own trend over time: is your authentication passing, is your bounce rate stable, are complaints low, are replies holding steady.
No. Open rate is a rough behavioural signal, and an unreliable one since privacy features began pre-loading images and inflating opens. Deliverability is about whether the message reached a place where it could be opened at all.
No, and treat that promise as a warning sign. The receiving provider decides, using signals no external tool can see or override. What a tool can honestly do is find and fix what is broken on your side and monitor the signals that are visible.
Authentication problems are fixed the moment DNS propagates, often within hours. Reputation damage takes weeks of consistent, clean sending. The order matters: fix authentication first, because reputation cannot recover while your mail is still failing authentication.
Many senders use a separate domain to keep cold outreach risk away from their primary business domain. It is a reasonable precaution, but it is not protection on its own. A new domain with no reputation and broken authentication performs worse, not better.
Every provider filters differently, and each recipient's own behaviour feeds their provider's judgement. Someone who has opened your mail before is far more likely to see the next one in their inbox. This is also why a single "inbox or spam" answer does not exist - placement varies per recipient.