What "delivered" actually means
Open any sending dashboard and the biggest number on it is usually "delivered". It reads like a statement about people. It is a statement about a mail server that answered another mail server.
A handoff, not a handshake with a human
Delivery is the point where the receiving server accepts responsibility for the message. That is a real event and it is worth counting - it tells you the address existed, the domain was reachable and the handoff succeeded. What it does not tell you is whether a human ever had the chance to see it.
| The report says | What it actually guarantees | What it does not |
|---|---|---|
| Delivered | The receiving server accepted the message for that mailbox | Whether it reached the inbox, the spam folder or a quarantine |
| Delivered, no open | The message was accepted | Whether it was read, filtered, or delivered to a mailbox nobody reads any more |
| Bounced | The address did not resolve to a usable mailbox at that moment | Whether it will resolve tomorrow - a full mailbox answers later, not never |
| Nothing at all | No information | Anything - a silent drop and a filter decision look identical from your side |
A bounce is the only one of these four that is unambiguous, which is why it is the number worth reading closely - and the reason a low bounce rate is a weaker statement than it sounds.
Four layers between delivered and read
- Acceptance. Visible in the report. The one layer the counter describes.
- Placement. Spam folder, quarantine, or a greylist that accepted and then dropped. No universal figure exists for it, and it depends on your domain, authentication and reputation rather than on your list.
- Throttling past the gateway. A provider can accept a message and decide the rest of the batch is not happening today. Nothing comes back to you per-address.
- The mailbox itself. Deliveries land in abandoned mailboxes. That is where the decay figures belong: 23% of contacts change jobs in a year (ZoomInfo, 2025) and 40% of email addresses are dead within two years (NeverBounce). A "delivered" from this year's list is a statement about this year.
What to measure instead
- Bounce rate on your own sends, computed over addresses a checker called deliverable. That is your real false-positive rate, and it is the only honest test of the check.
- Reply rate per segment, not per campaign. It separates "the message did not land" from "the message did not interest anyone".
- A seed mailbox inside the same send: if the seed arrives, the handoff happened and the question moved on to placement or content.
- The provider's event stream rather than the aggregate count, when one exists.
The published gap that survives all of this is the one between checked and unchecked contacts: 2-5% bounce on checked contacts against 10-35% for static resold databases. Freshness compounds on top - fresh data outperforms stale databases by 42% (Harvard Business Review, 2024).
What TAPAC gives you to work with
The mailbox check runs inside the search that found the contact, and each result carries the state (deliverable, undeliverable, or unknown for catch-all domains) with the time of the call. That timestamp is what lets one "delivered" be compared against the age of the check behind it. Pay-per-use, $0.10-0.50 per contact, 100 free searches.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
Related: where a pipeline loses contacts, how often a stored list needs re-checking, and what a replied lead really costs.
← Back to TAPAC