When the mail server never answers
A mailbox check usually ends in one of three states: deliverable, undeliverable, or catch-all (the server says yes to every address, so the real answer is unknown). There is a fourth, and it is the one that quietly decides how good your list looks: no answer at all.
What "no answer" covers
| What you see | What it usually is | What to do |
|---|---|---|
| Connection refused on port 25 | Outbound mail ports are blocked on many networks and hosting ranges - your probe never left the building | A routing problem, not a dead address. Re-probe over a route that may open the port |
| Handshake opens, then silence | The receiving server holds the session and never completes it; greylisting and load shedding both look like this | Not a verdict. Retry on a schedule before writing anything off |
| Answers, then stops answering | Rate limiting: the server tolerates N probes from one source and then goes quiet | Slow down, spread the probes - the contacts are probably fine |
| Timeouts across a whole domain | The domain has no working MX, or has one that does not respond at all | Treat as a domain-level finding, not an address-level one |
Every row describes a measurement failure rather than a mailbox fact. The address may be perfectly good - the probe simply did not get an answer.
Why this state must not be collapsed
Tools and pipelines like tidy results, so unanswered probes get folded into one of the other two states. Both directions cost money:
- Folded into undeliverable. A good contact is deleted. Nothing downstream will ever report that loss, because there is no event attached to a lead that was never contacted.
- Folded into deliverable. The address goes into the send. If it was genuinely dead, you bought a bounce with the same send you spent anyway - and a bounce spends sending reputation too.
The re-probe policy that works
- Keep the timestamp of the failed attempt. A timeout with no date is indistinguishable from a mailbox that died six months later.
- Re-probe before the send, not after. The whole point of checking is to decide whether a contact goes into a send.
- Do not re-probe in a loop. Repeated immediate retries from one source are what turned the server silent in the first place.
- If it is still unanswered, decide explicitly. Either leave the unresolved contacts out of the batch, or accept the risk on a small test send and read the result - but write down which of the two you chose.
What TAPAC returns instead of a guess
The mailbox check runs inside the search that found the contact. Each result carries its state - deliverable, undeliverable, or unknown for catch-all domains - together with the time of the call and the source page or profile the address came from, so an unresolved probe stays visible and dated rather than becoming a silent deletion or a silent bounce.
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
Checked contacts carry a published 2-5% bounce rate against 10-35% for static, resold databases; TAPAC is pay-per-use at $0.10-0.50 per contact with 100 free searches.
Related: when no delivery log arrives, checking on entry versus at the send, and what the SMTP conversation actually says.
← Back to TAPAC