The biggest number on a sending dashboard is usually "delivered". It reads like a statement about people, and 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: the address existed, the domain was reachable, the handoff succeeded. What it does not say is whether a human ever had a chance to see the message.
| The report says | What it 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 | A silent drop and a filter decision look identical from your side |
The bounce row is the only unambiguous one. That is also why a low bounce rate is a weaker statement than it sounds: it tests the checker, not the reply rate.
Four layers sit between delivered and read
- Acceptance - the layer the counter describes. Visible in the report.
- Placement - spam folder, quarantine, or a greylist that accepted and then dropped. No universal figure exists; it depends on your domain, authentication and reputation rather than on your list.
- Throttling past the gateway - a provider accepts a message and decides the rest of the batch is not happening today. Nothing comes back 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 count and a reply count can differ by an order of magnitude without anything being broken. They measure different layers, and only one of them is about a person.
What to measure instead
- Bounce rate on your own sends, computed only over addresses a checker called deliverable. That is your real false-positive rate and the only honest test of the check.
- Reply rate per segment, not per campaign. It separates "did not land" from "did not interest anyone".
- A seed mailbox inside the same send. If the seed arrives, the handoff happened and the question moves to placement or content.
- The provider's event stream rather than the aggregate count, where one exists.
The published gap that survives all of this is 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 it looks like implemented
TAPAC runs the mailbox check inside the search that found the contact, and each result carries its state - deliverable, undeliverable, or unknown for catch-all domains - with the time of the call and the source page or profile. That timestamp is what lets one "delivered" be compared against the age of the check behind it.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status
# hosted: https://tapacapi.com/mcp
# REST: POST https://tapacapi.com/v1/contacts/search
Pay-per-use, $0.10-0.50 per contact, 100 free searches.
Top comments (0)