Support just filed a ticket: “the password-reset emails bounced.” Nobody can say whether to retry the batch, suppress the addresses, or wait. A bounce is not a complaint, and a 4xx delay is not a hard failure. Classify the DSN first: suppress permanent 5.1.x addressing failures, retry transient 4.x.x with a cap, investigate 5.7.x policy blocks before treating them as list problems, and never retry a complaint.
Bounce vs complaint: they are not the same event
A bounce is a Delivery Status Notification (DSN) from an SMTP system. The receiving or intermediate MTA refused or deferred the message and returned an enhanced status code (RFC 3463). A complaint is a human action: the recipient marked the message as spam. Complaint loops (FBL) and mailbox “Report spam” buttons are not SMTP bounces. Treating them as “soft delays” is how domains pick up a complaint-rate problem under Gmail and Yahoo bulk-sender rules.
Hard bounce vs soft bounce is a useful shorthand, not a complete policy:
- Hard / permanent: class 5.x.x. The address or policy will not accept this message as sent.
- Soft / delay: class 4.x.x. The receiver asked you to try later.
- Policy / auth block: often 5.7.x (sometimes 4.7.x). Fix authentication or reputation; do not assume the mailbox is dead.
- Complaint: not a DSN class. Stop that recipient immediately.
One-page action table
| Signal | Typical codes | What it means | Action |
|---|---|---|---|
| Hard addressing failure | 5.1.1, 5.1.2, 5.1.3 | Unknown user, bad domain, bad address syntax | Suppress the address. Do not resend the same batch. |
| Soft bounce / 4xx delay | 4.2.1, 4.2.2, 4.3.x, 4.4.x | Mailbox busy, full, temporary system or routing issue | Retry with a cap (see wait window below). Do not mark the domain dirty. |
| Policy or auth block | 5.7.1, 5.7.x, some 4.7.x | Rejected for policy, SPF/DKIM/DMARC, or reputation | Investigate DNS and sending setup before suppressing the list. |
| Complaint / FBL / spam button | Not an SMTP class | Recipient asked you to stop | Never retry. Suppress immediately. Inspect list source. |
How to read RFC 3463 / DSN enhanced status codes
The useful digit is the class (first number), not the raw SMTP reply like 550 or 421:
- 2.x.x — success.
- 4.x.x — transient. Retry is the default.
- 5.x.x — permanent. Suppress is the default for addressing subjects (5.1.x).
The second digit is the subject: 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network/routing, 7 = security/policy. That is why 5.1.1 (unknown user) and 5.7.1 (policy) must not share one “hard bounce” bucket.
The two exceptions operators miss
Mailbox full is not always dead. 4.2.2 is a delay: retry later the same day. 5.2.2 is a permanent-class quota refusal; many receivers still recover when the user clears space. Cap retries (two or three over 24–48 hours). If it stays 5.2.2, suppress until the recipient updates the address through a form — do not keep hammering a full mailbox.
4.7.x is not a free retry. Transient policy or reputation codes need a DNS and reputation check first: sending enabled, DKIM and custom MAIL FROM in place, domain not already noisy. Blind retries on 4.7.x can look like an attack. See domain vs IP reputation and warming a new domain if the cluster is new volume, not a list problem.
What to do with email bounces in three real jobs
Password-reset batch: 8% 5.1.1
Those addresses do not exist. Suppress them in your application or list tool. Do not resend the same 5.1.1 set “to be safe.” Template and timing issues belong in the password-reset deliverability guide; bounce policy here is only suppress-and-move-on. Pair this with list hygiene so the next reset wave is smaller.
Receipt job: cluster of 4.2.2
Retry later that day. Do not pause the domain or open a reputation incident. A mailbox-full cluster on a payment day is a recipient-side quota event, not proof that your From domain is dirty.
Newsletter: one complaint from a purchased list
Stop that address. Do not “warm through” a complaint. Inspect how the address entered the list. One complaint is a list-source problem; a rising complaint rate is a sending-risk signal under bulk-sender requirements, not a delay to retry.
How long a 4xx delay should stay in “wait”
Use a cap, not an open queue:
- First retry: 15–30 minutes for 4.2.1 / 4.3.x system busy.
- Mailbox full (4.2.2): wait hours, not minutes. Two or three attempts over 24 hours is enough.
- Routing (4.4.x): backoff across several hours. If still 4.4.x after 24 hours, stop and inspect MX / destination, not your template.
- Hard stop: 48 hours or four attempts, whichever comes first. After that, park the address and require a fresh user action (login, checkout, preference center).
Keep the policy in your application. Arawa Mail does not document a first-party outbound suppression API. Industry products such as Amazon SES suppression lists show the same pattern: store the decision next to the recipient, not in a hope that the ESP will remember.
Where to look in Arawa Mail if you only have a message id
Stay inside documented tools:
- Retrieve Email returns the accepted message and a
last_event(the docs example issent). That field is not inbox placement and is not a bounce taxonomy. Do not invent bounce or complaint event names on top of it. - Outgoing webhooks fire on inbound mailbox mail for helpdesk and CRM routing. They are not outbound delivery, bounce, or complaint callbacks. Do not wait for an Arawa Mail bounce webhook; it is not documented.
- Give support the send log, not a Slack guess. That is the point of showing agents what the API accepted.
- The mailbox Spam folder is inbound: mail rejected by inbound checks, plus senders the mailbox user reports. That is not an outbound complaint loop and must not be treated as FBL telemetry for campaigns you sent.
- If you need headers from a DSN sitting in a mailbox, the free email tools page is the right hub for inspection utilities.
Outbound sending itself still requires Enable Sending on the domain. Authentication (DKIM and custom MAIL FROM) is configured when sending is activated. A 5.7.x cluster after a domain change is often “sending not enabled or auth incomplete,” not “bad list.” Contrast inbound webhook payloads in the published transactional email webhooks article so nobody wires a bounce handler to the wrong event.
How we analyzed this
This policy uses RFC 3463 class digits (stable since the DSN model) plus operator exceptions that break the “4xx = soft, 5xx = hard” slogan: recoverable 5.2.2 quota and investigative 4.7.x / 5.7.x policy codes. Arawa Mail product claims are limited to public docs: Retrieve Email last_event, inbound-only outgoing webhooks, Enable Sending, Send Email, and the inbound mailbox Spam folder. No outbound bounce webhook, delivery SLA, or in-product suppression list is assumed.
FAQ
What is the difference between an email bounce and a complaint?
A bounce is an SMTP DSN with an enhanced status code. A complaint is the recipient hitting spam. Complaints have no 4.x.x retry window.
Should I retry a 4.2.2 mailbox-full?
Yes, later the same day, with a small cap. Do not treat it as a dead address on the first hit.
Should I suppress 5.7.1 the same way as 5.1.1?
No. 5.1.1 is an addressing failure. 5.7.1 is policy or authentication. Fix sending setup first.
How long should a delay stay in wait?
Cap at 24–48 hours or a handful of backoffs. Then park the address until the user acts again.
Where do I look if I only have an Arawa Mail message id?
Retrieve Email for the accepted message. Do not expect a documented outbound bounce webhook. Classify any DSN you receive at the mailbox or from your own retry logs using the table above.