What to do with unknown email results

Unknown describes missing evidence

Temporary DNS issues, SMTP deferrals, time budgets, and provider restrictions can prevent a conclusive check. Unknown means the check could not reach a decision from the available evidence. It does not prove that the address is invalid, and it does not confirm delivery.

Separate a result from an HTTP failure

An HTTP response containing status unknown is a verification outcome. An HTTP 401 is an authentication failure. An HTTP 402 indicates a credit problem. An HTTP 429 means you must slow down and honor Retry-After. A network timeout gives you no reliable result at all: processing may have finished after your client stopped waiting.

Preserve the first attempt before retrying

Keep the address or an internal contact identifier, timestamp, status, reason, and available timing fields in your own protected records. Review a bulk job before submitting the list again. Unknown outcomes do not consume verification credits, but a repeated attempt that becomes conclusive can consume a credit. A lost response may hide a previously charged result.

• Retry only after a delay and a bounded attempt budget.
• Do not retry an unchanged 401 or 402. Fix the underlying account condition.
• Keep repeated unknowns in a review segment rather than looping forever.
• Do not expose contact addresses, API keys, or raw debug data in public logs.

Use uncertainty as a separate operational state

For signup, let users correct a typo or complete an ownership confirmation flow according to your product policy. For a campaign, hold inconclusive addresses apart from valid contacts and decide whether to retry later. Track unknown share alongside conclusive outcomes so a high unknown rate is visible rather than hidden in an accuracy claim.

• API errors, timing, and retry rules
• Evaluate with the complete denominator
• Catch-all is a different kind of uncertainty