← All topicsDeliverability OverviewCore Concepts (Deliverability vs. Delivery)
Accuracy / correctness · 3
arithmeticArticle says '99% delivery... and a 60% inbox placement rate... The other 39% landed in spam or got blocked.' 99 minus 60 is 39, so the article's own '39%' is internally consistent with its 99/60 framing (the 1% that bounced was never delivered). My script says 'still only sixty percent inbox placement, the rest slipped into spam' without quoting the 39% figure, which sidesteps any confusion and stays accurate. No drift introduced.
framingaiSummary specifies delivery = 'an SMTP 250 OK'. I described this as the server saying 'sure, I'll take it' / 'accepted' without naming the 250 code in THIS video (the 250 OK detail is taught explicitly in 002.002.002, the delivered-email video). No factual conflict; the code is deferred to the adjacent video by design, consistent with one-concept-per-video.
framingKept M3AAWG-safe: no inbox-placement promise, no named blocklists (article's 'blacklist-checker' link and Spamhaus-style naming avoided), placement framed as separate from delivery, and authentication framed as a factor in the fix, never as a guarantee of the inbox. Clean.
Would elevate the video · 1
exampleThe article states concrete healthy-range benchmarks: 'A healthy delivery rate is 98% or higher' and 'A good inbox rate is 85% or higher, but many senders hover around 70-80% without realizing it.' I kept the 98% delivery figure (it is a stable, widely-accepted floor) but hedged the inbox-rate side to 'plenty of senders sit lower than they think' rather than stating 85%/70-80% as fact, per the no-unhedged-benchmark rule. RECOMMEND: keep as-is. The 85%/70-80% inbox numbers are exactly the kind of benchmark the spec forbids stating without 'varies by industry' or a source, so hedging is correct. If YT wants the number in, add 'varies by industry and provider' explicitly.
Considered, left out · 2
exampleArticle names specific placement-testing tools (Email on Acid, Google Postmaster Tools for Gmail). I left named tools out of the narration to keep it vendor-neutral and evergreen, and pointed to 'a separate placement test' plus RME free tools in the description. Reason: naming third-party tools dates the video and isn't needed to teach the distinction. The description's RME tools + SOS cover the practical next step.
detailArticle's 'Common mistake: focusing only on bounce rate' paragraph is folded into the TAKEAWAY ('a great delivery rate feels good, but if a big slice is landing in spam...'). Not dropped, just compressed into the payoff line so it lands once rather than twice.
Delivery vs deliverability, the difference that fools your dashboard
Question: 002.002.001 · What is the difference between email delivery and email deliverability? · ~3:30 · single-question video
COLD OPEN
Your dashboard says 99%. Your open rate says otherwise.

Your ESP dashboard is glowing. Ninety-nine percent delivered. So why is nobody opening your emails? Because "delivered" and "reached the inbox" are two completely different things, and your dashboard only measures one of them.

⬡ split-compare, LEFT "Delivery: 99%" (green check) vs RIGHT "Inbox placement: 60%?" (question mark)
BEAT 1, the one-line answer
Delivery = accepted. Deliverability = where it lands.

Here's the whole thing in one breath. Delivery means the receiving server accepted your message. Deliverability means the message actually reached the inbox, where a human can see it. Accepted is not the same as seen.

⬡ split-compare, LEFT "Delivery, the server said yes" vs RIGHT "Deliverability, inbox vs spam"
BEAT 2, what actually happens when you hit send

When you hit send, your server knocks on the recipient's server, say Gmail. Gmail says "sure, I'll take it," and your ESP writes that down as delivered. Done, right? Not quite. After Gmail accepts your message, it runs its filters, checks your reputation, and decides where to put it. Inbox, spam, or straight in the bin. That final decision is deliverability.

⬡ journey-flow, envelope reaches the server node, node lights "accepted", then a fork splits into Inbox / Spam / Trash
BEAT 3, the mailroom (teach ONE idea with a picture)

Picture a big office building. The mail carrier hands your letter to the mailroom at the front desk. That's delivery, the handoff happened. But whether that letter makes it to the right desk, or gets tossed by the mailroom staff, that's a separate step. The carrier finished the job either way. Only one outcome actually gets read.

⬡ journey-flow, letter handed to mailroom desk (delivery), then splits: one path to a desk, one path to the bin
SUBSCRIBE

If this is clearing things up, hit subscribe. We're answering every email question, one at a time.

⬡ title-card, "Subscribe, one question at a time"
BEAT 4, the number that proves it
99% delivered. 60% in the inbox.

Here's where it bites. You can have a ninety-nine percent delivery rate, servers took almost everything, and still only sixty percent inbox placement. The rest slipped into spam or got quietly filtered after being accepted. That's the gap that makes your dashboard look fantastic while your open rates crawl. The dashboard measures delivery. Your readers experience deliverability.

⬡ talking-stat, big "99% delivered", then a second number drops in "60% inbox", the gap highlighted
BEAT 5, what each one measures

So what do you actually track? Delivery rate watches bounces, the hard permanent ones like a dead address, and the soft temporary ones like a full mailbox. Your ESP counts those for free, and healthy usually sits around ninety-eight percent or better. Deliverability, inbox placement, watches where accepted mail truly lands. Your ESP does not show you that. You need a separate placement test to see it, and plenty of senders sit lower than they think without ever knowing.

⬡ split-compare, LEFT "Delivery rate: bounces, ESP shows it" vs RIGHT "Inbox placement: where it lands, needs a test"
BEAT 6, why the two steps exist (the technical bit, kept plain)

Why is it built this way? Because the spam check happens after the server says yes. The server accepts first, then evaluates second. Saying yes does not promise it'll show your message to the user, it just means it's willing to look at it. Filtering every suspicious message away at the front door would be slow and would wrongly reject a ton of real mail. So the server takes it, then decides.

⬡ journey-flow, two-step node: "1. Accept (fast)" then "2. Evaluate (filter)"
TAKEAWAY
Low bounce rate feels good. It isn't the whole story.

So here's the one to remember. A great delivery rate feels good, but if a big slice of that mail is landing in spam, you're still not getting read. Track both. If your delivery is fine but your open rates are grim, that's a deliverability problem, not a delivery one, and the fix lives in your reputation, your content, or your authentication.

⬡ split-compare, LEFT "Delivery fine + opens grim" vs RIGHT "= deliverability problem, not delivery"
NEXT / SUBSCRIBE

Next up: what your ESP actually means when it stamps an email "delivered." And subscribe if you want the rest of the deliverability playbook.

⬡ end-card, Subscribe + Next: "What is a delivered email?" (002.002.002)
DESCRIPTION

Email delivery vs deliverability, explained in under four minutes. Delivery means the receiving server accepted your message. Deliverability means it actually reached the inbox where someone can see it. That's why your ESP dashboard can proudly show 99% delivered while only 60% of your mail lands in the inbox, because the spam-filtering decision happens after the server accepts. We cover what each metric tracks (bounces vs inbox placement), why your ESP shows you one but not the other, and how to tell a delivery problem apart from a deliverability problem.

Chapters:

0:00 The dashboard that lies to you

0:20 Delivery vs deliverability in one line

0:40 What happens when you hit send

1:05 The mailroom picture

1:35 The number that proves it (99% vs 60%)

2:05 What each metric tracks

2:35 Why it's built in two steps

3:00 The takeaway

Concepts in this video:

Email delivery → /emailalmanac/deliverability/overview-and-fundamentals/what-is-email-delivery

Inbox placement → /emailalmanac/deliverability/inbox-placement/how-do-i-test-inbox-placement

Sender reputation → [002.001.003]

Related:

Next: What is a "delivered" email? → [002.002.002]

Deeper: Why can delivery be 99% but inbox placement only 60%? → [002.002.004]

If your delivery looks fine but opens are grim, check your authentication first (SPF, DMARC, blocklist status) with our free tools, or if you're stuck, ask us and we'll walk through it: reviewmyemails.com/sos

Full written guide → reviewmyemails.com/emailalmanac/deliverability/overview-and-fundamentals/what-is-the-difference-between-email-delivery-and-email-deliverability

#email #deliverability #emailmarketing

CONNECTIONS
• next: 002.002.002 What is a "delivered" email?
• related: 002.002.004 Why can delivery be 99% but inbox placement 60%? · 002.001.003 What is sender reputation?
• vocab: email delivery, deliverability, inbox placement, hard bounce, soft bounce