How long should SMTP 4xx errors be retried before a lead is treated as undeliverable?

The protocol gives a class, not your business deadline

A 4xx response says the requested action was not completed now and that retry may succeed later. SMTP does not define one universal period that every sender must retry. Mail servers choose queue and backoff behavior. Your outbound system therefore needs to know which layer owns retry. If an SMTP relay already queues and retries the message, the campaign scheduler should not independently create another logical send. Separate transport delivery from campaign cadence.

Set queue expiry explicitly

Know how long your provider or MTA keeps a temporarily deferred message before giving up. If you control the MTA, document the queue lifetime and backoff schedule. If a SaaS provider owns transport, find its documented behavior or surface final delivery events in your webhook or logs. The campaign should remain in a delivery-pending state until transport resolves to accepted or expired. This avoids following up with a lead who may receive the original message later.

Do not make 4xx a recipient-quality verdict

A temporary error can reflect provider throttling, mailbox fullness, DNS trouble, or authentication lookup failure. None proves the address itself is invalid. Keep address validity separate from message-delivery outcome. An address becomes a strong suppression candidate when you receive a permanent recipient-level failure or independent verification evidence, not merely because a temporary delivery attempt lasted longer than your preferred campaign schedule.

Use different expiry actions by failure type

When a 4xx queue eventually expires, inspect the final diagnostic. A mailbox-full pattern may justify re-verification or postponement. A sender reputation throttle should pause or reduce the sender domain, not mark recipients bad. A temporary DNS failure may disappear without any list change. The campaign engine can move the touch to a manual-review state while preserving the recipient record. This is more accurate than a single rule such as “three soft bounces equals hard bounce” applied to every 4xx class.

Prevent duplicate sends across retries

Assign one logical message key to the campaign touch and one transport message identifier to each submission. If the transport is retrying, the logical touch remains occupied. A queue worker restart should reload that state rather than enqueueing the same email again. Gmail even publishes a 4.7.28 variant for excessive messages with the same Message-ID, which is another reason to make retry behavior intentional. Idempotence protects both recipient experience and sender traffic shape.

Coordinate follow-up timers with delivery state

A follow-up clock should begin from a meaningful event such as accepted submission or confirmed delivery behavior, depending on your system design—not blindly from the moment the application attempted SMTP. If the first message spends twelve hours deferred, a follow-up scheduled “two days after send” can arrive much sooner relative to the actual first delivery. Store accepted/deferred/final timestamps so cadence logic reflects what happened on the wire.

A practical state machine

Use states such as queued, submitted, deferred, accepted, permanent-failed, expired-temporary, and suppressed. A 4xx keeps the message in deferred while the transport owns retry. A later 250 moves it to accepted. A final 5xx recipient error moves the lead to suppression. If the queue expires without a permanent recipient failure, move the touch to expired-temporary and require a rule or human decision before another attempt. This makes the system explainable during audits.

Measure retry pressure by provider

Retries can silently amplify traffic. If ten Yahoo messages are deferred and each is retried while new campaign mail continues, the provider sees more connections and attempts than your planned-send count. Include transport retries in provider-level pressure metrics. When temporary deferrals climb, pause new sends so backoff can drain. Your daily volume dashboard should distinguish planned new messages from automatic delivery retries; otherwise a “30 sends/day” plan can produce far more SMTP attempts.

Define retry expiry separately from lead eligibility

SMTP says a 4xx reply is temporary, but it does not tell your sales system how long a lead should remain eligible for this particular campaign. Those are two different timers. The delivery queue may retry for hours or days according to transport policy, while the campaign can decide that a message is no longer useful after a narrower business window. If the business window expires, mark the campaign touch as not delivered or expired; do not automatically convert the recipient into a permanently invalid address unless later evidence justifies that state.

This separation prevents follow-up bugs. Suppose step one receives a 4xx and remains queued while the campaign scheduler reaches the date for step two. Step two must not be sent as if step one succeeded. Hold the sequence until the delivery state becomes accepted, permanently failed, or expired according to your rules. If step one is eventually accepted, schedule the follow-up delay from the actual accepted time rather than the original attempted time. Record attempt count and last diagnostic so unusually long retry chains can be investigated by provider. A reliable outbound system therefore has at least three concepts—recipient eligibility, message delivery state, and sequence timing—instead of one boolean called `bounced`.

Set an explicit terminal event for an expired temporary failure

When the retry window ends without acceptance, write a distinct terminal event such as `delivery_expired` with the last 4xx diagnostic. That event should stop the campaign touch and release the sequence from an indefinite pending state, while leaving the recipient’s global validity unresolved. If the same address later accepts transactional mail or a future carefully chosen send, the contact record can reflect that new evidence. This is materially different from `invalid_recipient`, which should require a permanent recipient-level signal. Keeping the states separate lets reporting answer whether a campaign lost messages to temporary infrastructure pressure or to genuinely bad addresses.

Field checklist

• Document who owns retry: your MTA, provider, or campaign worker.
• Record the queue expiry and backoff policy.
• Keep 4xx separate from permanent address invalidation.
• Block duplicate logical sends while transport is still retrying.
• Tie follow-up scheduling to real delivery state.
• Count retries in provider-level traffic pressure.