SMTP verification returned 4xx: why the address should usually remain “unknown,” not “invalid”

Verification is subject to the same SMTP reply classes

A verifier that uses SMTP commands is interacting with a real receiving server. RFC 5321 semantics still apply: 4xx indicates a transient negative response and 5xx indicates a permanent negative response for that command. A 450 or 451 during verification can be caused by temporary policy or resource conditions. Converting it to “mailbox invalid” invents certainty that the server did not provide.

Greylisting is designed to make first attempts uncertain

Some receivers intentionally return temporary failures to unfamiliar senders and expect legitimate MTAs to retry later. A one-shot verification probe may therefore be rejected even though ordinary queued mail would eventually be accepted. This is one reason third-party verification products disagree on the same mailbox. Your own hygiene model should have an unknown or retryable state so a temporary anti-abuse response does not become permanent lead deletion.

Do not hammer the recipient server

Repeatedly probing the same domain in a tight loop can look abusive and can worsen rate limits. Batch verification by domain, respect connection and recipient limits, and back off after temporary responses. If many leads share one MX, one provider-level 4xx should not trigger hundreds of immediate retries. Small outbound systems gain more from conservative verification than from squeezing every address into pass/fail within one minute.

Separate domain reachability from mailbox acceptance

A successful MX lookup and SMTP connection proves the domain has reachable mail infrastructure, but RCPT-level policy may still hide whether an individual mailbox exists. Catch-all servers may accept random recipients; hardened servers may reject probes; some systems defer unknown senders. Record the layer that produced the result: DNS, connection, MAIL FROM, RCPT TO, or later delivery. This makes “unknown” informative rather than vague.

Use real delivery outcomes to update confidence

If a risky address later receives a real campaign message and the provider accepts it, that is stronger evidence than a prior transient verification probe. If it returns a permanent 5.1.1-style unknown-user response, suppress it globally. The verification state should evolve with higher-quality evidence. Do not keep re-probing an address after you already have a clear recipient-level delivery result.

A practical retry policy

After one 4xx verification, mark temp_unknown with the code and timestamp. Retry after a longer interval, preferably with domain-level rate limits. If the same server continues to return policy deferrals, stop probing and decide whether the lead is worth a cautious real send or should be excluded from the campaign. The right choice depends on your risk tolerance; what is not justified is relabeling the mailbox nonexistent without a permanent signal.

Avoid using your main sending identity for aggressive probes

SMTP verification can affect how remote servers view the probing host and domain. Do not build a verifier that fires thousands of RCPT commands from the same infrastructure used for business mail without understanding the consequences and provider terms. For a solo founder, syntax, DNS, suppression history, and reputable verification services may be safer than custom high-volume probing. If you do operate verification, pace it conservatively and keep the infrastructure role explicit.

Store the reason so list QA remains explainable

A lead table should show verification status, layer, SMTP class, diagnostic text, checked_at, and retry_after. An operator reviewing an “unknown” address can then see whether it was a DNS timeout, catch-all domain, or 450 recipient deferral. This prevents repeated unnecessary checks and makes source-quality analysis possible: if one list vendor produces many temporary or permanent failures, you can address the acquisition problem instead of blaming deliverability after sending.

Give verification results a confidence state instead of forcing yes/no

An SMTP verification attempt that receives a 4xx response has learned that the server is not giving a final negative answer now; it has not proved the mailbox exists and has not proved it is invalid. Greylisting, rate controls, temporary backend failures, and policy throttles can all produce temporary replies. Repeating the probe aggressively can make the situation worse and can cause the verifier itself to look abusive. Use exponential or otherwise bounded backoff, cap verification retries, and retain the original diagnostic so uncertainty is visible to the list operator.

A practical data model can use states such as `deliverable-evidence`, `permanent-invalid`, `temporary-unknown`, `catch-all-or-ambiguous`, and `not-tested`, with a timestamp and reason beside each. Domain-level DNS checks can run before SMTP, but recipient acceptance remains a separate layer. If a lead is important and verification stays temporary, the safest real-world evidence may eventually come from a normal, low-volume campaign send through your authenticated infrastructure rather than from repeated RCPT probing. Update confidence from subsequent accepted deliveries or standards-based DSNs. This avoids the false precision of a green/red verifier while still preventing clearly dead domains and permanent recipient failures from entering repeated outbound sequences.

Rate-limit verification by destination domain

A verifier that processes a large list in parallel can unintentionally turn many individually modest probes into a burst against one recipient provider. Apply concurrency and rate limits by destination domain or MX group, not only globally. That protects the verifier from manufacturing the very 4xx results it then labels as uncertainty. Queue a later check rather than immediately fanning out more connections, and record whether the temporary response appeared after a burst. This makes verification evidence cleaner and reduces the chance that list hygiene activity harms the sending reputation or network identity used elsewhere.

Field checklist

• Map 4xx verification results to temporary/unknown rather than invalid.
• Back off by domain instead of immediately probing again.
• Store which verification layer returned the response.
• Upgrade or downgrade confidence when real delivery evidence arrives.
• Keep custom verification traffic conservative and separate from campaign logic.
• Persist code, timestamp and retry_after for every uncertain result.