SMTP Error-to-Action Decision Table

Use SMTP response class (2xx/4xx/5xx), enhanced-status codes when present, and transport evidence (temporary connection errors, recipient syntax, policy messages, rate-limit hints) to decide whether to retry, suppress, investigate, or escalate. Map each observed condition to a single operational action, an owner, and a stop condition so retries are safe and suppression consistent.

Decision boundary: permanent vs transient evidence

Classify responses first by SMTP reply code family: 2xx (success), 4xx (temporary), 5xx (permanent). Treat 5xx as candidate for suppression, 4xx as candidate for retry, and 2xx as delivery success. When an enhanced-status code (RFC 3463) is present, use its class (e.g., 5.1.x address issues) to refine the decision 2. Identify limits: network-level connection failures (timeouts, connection resets) are transport-level transient signs even if the last SMTP server returned 5xx previously. Conversely, consistent 5xx/5.x.x responses over multiple attempts indicate permanence and justify suppression. Define numeric thresholds (e.g., number of failed attempts or elapsed hours) in your retry policy before changing action.

Evidence types and what they imply

Categorize evidence into three buckets: SMTP reply code plus enhanced status, transport/connection errors, and provider throttling or policy signals (message content/policy invoked). SMTP 5.1.x or 5.2.x with explicit 'user unknown' or 'mailbox unavailable' wording is clear suppression evidence; ambiguous 5xx messages (e.g., 'service unavailable') require investigation. Provider throttling messages often appear as 4xx with rate-limit wording or as documented provider-specific codes; treat these as retryable but instrument them for exponential backoff and owner alerts if they persist. Connection timeouts, DNS failures, and transient TLS errors are retryable; escalate only after configured retry attempts fail.

Practical retry sequence and stop conditions

Define a deterministic retry schedule that escalates owner attention when retries fail. Example sequence: immediate retry for transient transport failures, then exponential backoff (e.g., 1h, 4h, 24h) with a maximum number of attempts (e.g., 3–5) before either suppressing or escalating. Stop conditions include a definitive permanent SMTP 5xx code, successful 2xx response, or reaching the configured retry limit. Record each attempt and final error text in the envelope or delivery log. If enhanced-status codes indicate a different reason midway (e.g., first attempts return 4xx then later 5.1.1), switch the action to suppression immediately and stop retries.

Investigation and escalation rules

Route investigation to a named owner when evidence is ambiguous or when repeated transient responses exceed thresholds. Triggers for investigation: mixed 4xx/5xx history for the same recipient, provider policy hints without clear action, or throttling that persists beyond the backoff schedule. The investigator should gather the last N SMTP session transcripts, DNS/MX resolution history, and any sending rate or pattern changes. Escalate to engineering or ISPs when there is a systemic pattern (many recipients showing the same transport or 5xx class), suspected deliverability blocklisting, or when providers request operator contact. Document the escalation stop condition: provider response resolving the block, a change in error class, or confirmation that suppression is required.

Ownership, logging, and auditability

Assign owners for each action: Delivery queue engine owns retries and backoff enforcement; Suppression list owner (ops) owns permanent suppression decisions; Investigations routed to a deliverability analyst; Escalation routed to engineering or provider liaison. Record discrete fields for: SMTP reply code, enhanced-status, raw server text, connection/tls state, attempt count, timestamps, and final action. Audit trails must allow replay: keep full SMTP transcripts for at least the period of your longest retry window plus an investigation buffer. Use these records to refine thresholds and to justify suppressions to internal stakeholders or providers.

Examples and limits of interpretation

Example: '550 5.1.1 User unknown' is suppression evidence; stop retries immediately and add to suppression list. Example: '421 4.7.0 [TS01] Messages from your IP temporarily deferred' is retryable; apply backoff and monitor rate. State uncertainty: provider-specific wording and undocumented internal thresholds vary; RFCs define enhanced-status conventions but not provider policies 2 1. When a message contains only free-text without an enhanced-status, treat the response conservatively and escalate for human review after a small number of retries.

Practical checklist

• Log SMTP reply code and enhanced-status (if present) for every attempt.
• Apply a fixed retry schedule with exponential backoff and a maximum attempt count.
• Suppress immediately for unambiguous 5.x.x address errors (e.g., 5.1.1).
• Retry transient transport errors (timeouts, DNS failures) and throttle signals with backoff.
• Route ambiguous or mixed-result series to a named investigator after threshold breaches.
• Record ownership and stop condition with each final action (retry, suppress, investigate, escalate).
• Retain full SMTP transcripts for the duration of retry window plus investigation buffer.
• Alert on provider-wide patterns (many recipients with same error) for escalation.
• Document suppression reason and retain evidence to reverse if provider proves recovery.

Where RepMail fits

Use this guide as a practical checklist and decision aid in an outbound workflow: embed the decision table into retry-queue logic, log the discrete fields listed, and assign owners for each action. The table helps reduce unsafe retries and inconsistent suppressions by making each step deterministic and auditable. This document does not state that RepMail implements these policies; it can be used to shape your internal retry and suppression rules.

Continue with A/B Testing Cold Email With Small Samples for the next step in the workflow.

Related RepMail guides

• Campaign Rollback and Pause Decision Table
• Yahoo SMTP Error Codes: Build a Sender-Side Triage Table

Sources