When the delivery log never arrives
You send 4,200 messages and the dashboard says: 4,200 accepted. What it does not say is which of those became a bounce, which were deferred, and which were quietly discarded. Without a per-recipient result, three different failures look exactly the same - and they call for opposite actions.
Three failures that hide behind one number
| What happened | What it means | What to do |
|---|---|---|
| Hard bounce (5xx) | The mailbox does not exist; the server said so at the time of the send | Remove it. Sending again costs another bounce and another hit to reputation |
| Soft failure (4xx) | Greylisting, a full mailbox, a rate limit - the answer is "later", not "no" | Retry on a schedule; do not treat as a dead address |
| Silent drop | Your server, or a gateway after it, accepted the message and discarded it | This is a sending-infrastructure question, not a list question - and no list check will ever see it |
"Accepted" is a claim by a mail server about a handoff. It is not a statement about an inbox, and it is not a statement about a person.
Evidence that still exists when the log does not
- The SMTP response at the call. Every mailbox check ends in a code: 5xx is permanent, 4xx is temporary. This is the same conversation your MTA would have had - which is why checking before the send answers the question the log would have answered.
- The bounce address. If the provider honours a per-message Return-Path, bounces come back to you even when the interface shows nothing. Ask for it; when it is honoured, the log is your own mailbox.
- The provider's API, not its dashboard. Most sending services expose per-message events over a webhook or JSON endpoint while the interface shows only aggregates. The data exists - it is just not on the screen you were given.
- A seed mailbox. One address you control, inside the same send. If the seed never arrives, the problem happened before the recipient's server was ever involved.
The triage ladder
- Was the address ever real? A mailbox check answers this directly and before the send, which is the only point at which the answer is cheap.
- Did the handoff happen at all? Compare a seed mailbox against your aggregate count. If the seed arrived, the receiving side is fine and the question moves to individual addresses.
- Are the bounces arriving somewhere? Check the Return-Path configuration before blaming the list - an unhonoured bounce address turns every hard bounce into silence.
- Is the silence a block? A gateway block produces no bounce at all by design. That shows up as a delivery-rate collapse in the provider's event stream, not as per-address errors.
What that comparison is worth
A mailbox check costs $0.10-0.50 per verified contact, pay-per-use, with 100 free searches; a send costs the same whether it lands or bounces, and a bounced send also spends sending reputation. Checked contacts carry a published 2-5% bounce rate against 10-35% for static, resold databases - the gap is what a delivery log would otherwise have to be reconstructed after the fact to find.
What TAPAC returns
The mailbox check runs inside the search that found the contact, so nothing needs to be reconstructed: every result carries the state (deliverable, undeliverable, or unknown for catch-all domains), the time of the call, and the source page or profile the address came from.
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: checking on entry versus at the send, what a normal bounce rate looks like, and how often a stored list needs re-checking.
← Back to TAPAC