"Server Would Not Confirm": What to Do With Retry Results in Your Email List

"Server would not confirm" means the recipient's mail server refused, deferred or dropped our mailbox check, so we could not tell whether the address exists. The row comes back risky with send advice retry. It is not a verdict on the person. Re-run those rows once after a few hours, treat what is still unconfirmed as risky, and send nothing from this group until a small test batch is clean.

If you are a cold emailer looking at a report with a block of retry rows, here is how to handle it.

What the result actually says

The check did not complete. A mailbox check asks the recipient's server one question. Most servers answer yes or no. Some refuse to talk to a source they do not know, some are slow, and some tell us to try again later. When that happens we have no answer, and we say so instead of calling the address valid or invalid.

The pattern is common enough that it has its own explanation: greylisting and temporary 4xx replies are designed to make unfamiliar senders retry. A verifier is an unfamiliar sender.

Where retry sits among the reasons

Reason	Status	send_advice	What we know
Mailbox exists	valid	safe	The server confirmed the mailbox
Mailbox not found	invalid	do_not_send	The server said it does not exist
Accepts all addresses	risky	care	The server says yes to everything
Role-based address	risky	care	Shared mailbox such as info@ or sales@
Server would not confirm	risky	retry	The server did not answer the question
Mailbox check unavailable	risky	retry	The check could not run

The full column and reason list is in how to read a verification report.

Step 1: group the retry rows

Filter the results file on send_advice equal to retry. Count them against your total. A handful is normal. A large share concentrated on a few domains usually points at those domains' servers, not at a bad list.

Sort by domain. If most of the rows share one or two domains, the problem is that provider, and re-running will not change much.

Step 2: run them once more

One second pass is worth doing; five are not. Servers that deferred the first attempt often answer a later one. Re-submit only the retry rows, a few hours later or the next day. Rows that now return Mailbox exists move to your send list. Rows that return Mailbox not found move to suppression.

Rows that are still unconfirmed are not likely to change on a third try. Stop and decide what to do with them.

Step 3: decide what to send

Treat leftover retry rows as risky, not as valid.

1. Send your valid rows first.
2. Take a batch of 100 to 300 retry rows and send from a warmed inbox. See how to size a test batch.
3. Read the bounce rate before sending more. If it is near your valid-row rate, send the rest at a measured pace. If it is clearly higher, hold them.

This is the same approach as for catch-all rows, covered in catch-all emails: what to do. Never promote a retry row to valid by hand.

What retry rows are not

• Not confirmed dead. Do not suppress them as invalid.
• Not confirmed alive. Do not count them in your valid total when you estimate results.
• Not a reason to switch verifiers. If one tool says valid for every one of them, it is guessing; ours reports what the server said.

Plans

New accounts get 100 free checks with no card. Pro is $39 a month, the first 100,000 checks a month at full speed, then slower, never cut off. Business is $99 and Agency is $249 with 750,000 checks a month. See pricing.

See your own retry rows

Run a sample through the verify page and filter the results on send_advice.