One in Six Emails Never Arrives. Nobody Will Tell You Which.
Your app sent a password reset. The API returned 200. The provider's dashboard says "delivered." The customer says it never came.
All three of those statements can be true at once, and for a meaningful share of the email you send, they are.
The number
Validity has published an email deliverability benchmark every year for most of a decade. The 2025 report puts the cross-industry average inbox placement rate at just under 85%. The 2026 edition breaks it out by provider: Gmail at 87%, Microsoft at under 76%.
Inbox placement is the share of legitimate, permission-based mail that actually lands in the inbox, as opposed to the spam folder or nowhere at all. So the polite way to say it is "85% inbox placement." The honest way is that roughly one in six emails that a real company sent to a real subscriber did not arrive where anyone would read it.
Those benchmarks measure marketing mail, and transactional mail generally does better: people asked for the receipt, they are waiting for the reset link, engagement is high, and mailbox providers notice. But "does better" is not "does not fail," and the ways transactional mail fails are exactly the ways nobody tells you about.
Four ways an email goes missing without an error
It bounced, and the bounce was swallowed. A full mailbox, a typo in the address, a domain that expired. Your provider records a hard bounce. Your app, which called send() and got a 200, has no idea. The customer emails support a week later asking why they never got their invoice.
It was suppressed, months ago. After a hard bounce, most providers put the address on a suppression list so you stop mailing it. That protects your sending reputation. It also means a customer whose mail server had a bad four hours in March has been silently refused every email since, by you, and there is no error because refusing was the intended behaviour. This post walks through the audit.
Authentication drifted. Since February 2024, Google and Yahoo require SPF, DKIM and a DMARC policy from bulk senders, and a spam-complaint rate under 0.3%. Those are DNS records. DNS records get edited. Someone moves the domain, rotates a provider, cleans up "unused" TXT records, and your mail goes from inbox to spam folder overnight with no code change and no alert. The plain-English explanation of the three records is worth ten minutes if you have never looked at yours.
It arrived, in the spam folder. Technically delivered. Practically not. This is where most of the missing sixth goes, and it is invisible from your side unless someone measures placement, which almost no small team does.
None of these produce an exception. That is the whole problem. A failed database write throws. A failed email returns success and then fails somewhere you are not looking.
Why it costs more than the email
The HubSpot research on response times found that 90% of customers rate an "immediate" reply as important, and 60% define immediate as ten minutes or less. A password reset that never arrives is a ten-minute expectation failed by a day. A receipt that never arrives is a support ticket, plus the accounting question that comes with it.
And it compounds. PwC found that 32% of customers will leave a brand they like after one bad experience. An email that never came is a small bad experience, but it is the kind that happens at the worst moment: while the customer is locked out, or waiting for proof they paid.
What "knowing" looks like
You cannot make delivery perfect. You can make it observable, which is a different and achievable goal.
The minimum is a delivery log you actually read: every send, with its status (sent, delivered, bounced, blocked, held), the block reason when there is one, and the suppression it hit if it hit one. When a customer says "I never got it," the answer should be one lookup, not a shrug and a manual resend.
The next step is putting that log next to the tickets, because "I never got the receipt" arrives as a ticket, and the person answering it should not have to open a second product to find out why. When the email log, the suppression list and the ticket are in the same desk, the reply writes itself: your address was suppressed after a bounce in March; I have cleared it and resent the receipt.
And the last step is letting something watch on your behalf. Helmdesk's Email Health agent checks SPF, DKIM and bounce rates across every project once a week and tells you in one line, with the fix. The email log and suppression list are readable over the API and from your editor, so "why didn't Dana get her receipt" is a sentence, and the answer comes back with the row.
One in six is the industry's number. Yours is probably better. The point is that right now you do not know what it is, and neither does the customer waiting for the link.
Sources: Validity, Email Deliverability Benchmark 2025 and 2026; Mailgun on the 2024 Google and Yahoo sender requirements; HubSpot Research on response time expectations; PwC, Experience Is Everything.
Know which email did not arrive
A delivery log, a suppression list you can see, and a weekly health check, in the same desk as the ticket that asks about it.