Clay Rows That Say retry_later: How to Re-Run an Unconfirmed Email Check

A retry_later row means the check could not confirm the mailbox this time, not that the address is bad. Filter those rows, run the column on them again later, and keep them out of the main campaign until they resolve. This is Clay's HTTP API enrichment calling SimpleVerifier with your own key, not a native Clay action; the setup is on the Clay integration page.

What lands in this lane

The API gives these risky reasons the action retry_later:

• "Server would not confirm"
• "Mailbox check unavailable"
• "Server refused our check"
• "Provider is blocking our checks; not probed"
• "DNS lookup failed; try again later"
• "Domain valid, mailbox unverified"

Each has its own reason_code (for example server_unconfirmed and server_unreachable). They share one trait: the answer was not a clear yes or no. Compare them with "Accepts all addresses" and "Role-based address", which get send_with_care instead. See valid, risky and invalid explained.

Step 1: make a retry view

Filter the table to action is retry_later. Keep reason and reason_code visible so you can see which cause dominates. A cluster of one reason on one domain usually points to that server, not to your list.

Step 2: re-run the column on that selection

Select the filtered rows and run the HTTP API column on them. Wait a few hours or a day first; servers that were busy or slow often answer on a second try. Keep the rate limit under your key's 120 calls a minute (100 requests per 60,000 ms is a safe setting; see verifying emails in Clay).

Step 3: route what comes back

New result	Do this
action send	Move to the main campaign
action send_with_care	Side campaign
action do_not_send	Drop it, or try another finder
action retry_later again	Retry once more, then hold out

Step 4: when to stop

Two attempts a day apart is enough. A row that still cannot be confirmed is not bad, but it has no evidence behind it. Send it only in a small test batch and watch bounces, as you would for catch-all leads.

What a retry cannot do

• It cannot turn a catch-all into a confirmed mailbox.
• A daily check limit on a free account can also cause retry_later. The reason says so, and the row is fine to re-run after the limit resets.
• Re-running costs another API call unless the address was confirmed in the last 14 days and is served from cache.
• Some providers hide mailbox status permanently, so a retry returns the same answer.

Next step

Retries use calls from your plan's monthly API allowance. See pricing for the numbers, or the API docs for the reasons and codes.