A greylisted probe is not a bad address
A verification run returns three kinds of answers, and only two of them are verdicts. The third - a temporary refusal - is the one that gets misread most often, because it arrives looking like a failure and gets written into the list as one.
The three answer classes, and who gets to decide
| Answer | What the server is saying | Who decides what happens next |
|---|---|---|
| 2xx, accepted | The mailbox exists and accepts mail from you right now | The server has answered; the result is about the mailbox |
| 4xx, temporary failure | Not now - too fast, too soon, or a defence that wants to see you retry | You do, by retrying later: the answer is about your request, not the address |
| 5xx, permanent failure | No such mailbox, or mail from you will never be accepted | The server has answered; the result is about the mailbox |
The distinction is in the SMTP reply code itself: the first digit says whether the reply is a verdict (2, 5) or a condition of the moment (4). Mixing the two is where a clean list starts reporting contacts as dead while they are alive.
Why greylisting exists
Greylisting is a cheap defence against bulk senders that fire once and never come back. The receiving server answers the first attempt with a temporary refusal and accepts the same message if the sending side returns after a short wait. A real mail server retries, because that is what RFC-compliant delivery does. A machine that is only harvesting addresses usually does not, so the defence filters it out at the cost of a few minutes of delay for everybody else.
The side effect for you is that a single pass over a list can collect temporary answers that have nothing to do with the contacts. Repeat the pass and the same addresses answer 2xx, which is why a one-shot verdict on a greylisting server is worth nothing.
What a temporary answer does to a verification run
- It inflates the dead pile. Recorded as undeliverable, a temporary refusal removes a live contact from the list and adds it to a number you report as accuracy.
- It hides behind the average. If most of a batch answers in one pass, a small set of 4xx answers disappears into the total, and the report still looks healthy.
- It punishes the wrong servers. Managed mail platforms and corporate gateways apply these defences more aggressively than small ones, so a naive run systematically under-reports the larger, better-kept domains.
- It cannot be fixed by a better syntax check. The domain has valid records, the address shape is fine, the mailbox is probably there - the answer is about pacing and trust, which is exactly what a retry tests.
How to handle it
- Keep three states, not two. Deliverable, undeliverable, and - for catch-all domains and unanswered probes -
unknown. A temporary refusal belongs in the third bucket, never in the second. - Retry with a widening gap before recording anything. A second attempt minutes later, from the same path the send would use, resolves most temporary refusals into a real answer.
- Never bill a temporary answer as verified. The published 2-5% bounce rate for checked contacts against 10-35% for static resold databases (see what actually gets you blocked) is a claim about attempts, and a 4xx is not an attempt you made.
- Carry the timestamp on the result. A verdict is only true for the moment it was taken; 23% of contacts change jobs annually (ZoomInfo 2025) and 40% of email addresses are dead within two years (NeverBounce), so a stored answer decays no matter how carefully it was obtained.
- Probe at the point of send. The check that matters is the one that runs while a batch is going out, when a temporary refusal can still be retried instead of being filed away.
What TAPAC returns
TAPAC probes the mailbox inside the search that found the contact and returns one of three states - deliverable, undeliverable, or unknown - together with the time of the probe and the source page or profile the address came from. A temporary answer is not converted into a verdict, and it is not carried into the numbers you report as accuracy.
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: what happens in an SMTP handshake, when the mail server never answers, and catch-all domains and the unknown state.
← Back to TAPAC