Soft bounce vs hard bounce: the difference, and what changes when an agent handles bounces

What is the difference between a soft bounce and a hard bounce?

A hard bounce is a permanent delivery failure, like a non-existent address, while a soft bounce is a temporary one, like a full mailbox, and the two demand different handling.

An AI agent that sends email, whether a coding assistant wiring sends into an app or an assistant working over MCP, runs unattended and retries whatever failed. Retrying a hard bounce is the one retry that damages sender reputation, so the platform has to classify each bounce and keep dead addresses out of the next send.

Hard bounces and soft bounces, by SMTP code

What is a hard bounce?

A hard bounce is a permanent delivery failure: the address doesn't exist, the domain is invalid, or the server flatly rejected the mail. A hard-bounced address should be removed and never mailed again, because repeatedly hitting dead addresses is exactly what damages your reputation, and it pushes the bounce rate toward the 5% level where Amazon SES places an account under review.

What is a soft bounce?

A soft bounce is a temporary delivery failure: the mailbox is full, or the server is momentarily down or busy. Soft bounces can be retried, but not forever. Nitrosend suppresses the contact's email channel after three soft bounces.

The SMTP reply code says which one happened. A code in the 5xx class, such as 550, is a permanent failure and marks a hard bounce. A code in the 4xx class, such as 421 or 452, is a temporary failure and marks a soft bounce, which the receiving server expects the sender to try again later. Addresses that are wrong before they are ever mailed can be caught earlier with an email check API.

What changes when an AI agent handles bounces

A person reading a bounce report sees hard and soft bounces as two different things. An agent sees a failed send, and its default is to treat a failure as an error to retry. It may also rebuild a list from whatever file it finds, and it cannot tell a full mailbox from a dead address unless the platform tells it which one it got.

So the classification has to live in the platform, not in the agent's judgment. Delivery events such as delivered, bounced and complained come back through webhooks, so code an agent writes can read the outcome of each send instead of guessing. A hard-bounced address on the suppression list is excluded from all future sends, whatever the agent asks for. So an agent that sends email from an LLM does not have to classify bounces itself, and nobody has to watch every bounce to keep dead addresses out.

Why the distinction matters

Handling them the same way is a mistake in both directions: retrying hard bounces burns reputation, and removing soft bounces too aggressively loses reachable contacts. Good list management branches on the two. It all feeds your overall bounce rate.

Amazon SES places an account under review at a 5% bounce rate and may pause its sending at 10%, according to its enforcement FAQ, which recommends staying below 2%. The bounce rate calculator shows where a send sits, and the guide to email bounce rate covers the formula.

How Nitrosend handles hard and soft bounces

Nitrosend processes delivery failures automatically, by three rules:

• Hard bounce: the address goes on the account suppression list and is permanently excluded from all future sends.
• Three soft bounces: soft bounces are counted, and after the third the contact's email channel is suppressed too.
• Unsubscribes: unsubscribed contacts sit on the same suppression list as hard bounces, tagged differently, so a dead address and a person who unsubscribed are both kept out of the next send and still told apart.

The suppression list covers every send from the account, whether it comes through the email API, from code an agent wrote, or from the MCP tools, so the permanent versus temporary distinction is handled rather than left to the sender to reconcile.

Worked example: an agent cleans up after a send with bounces

The prompt: "Yesterday's newsletter had a lot of bounces. Clean the list and make sure we don't mail those again."

Before. Left unguided, an agent reads the bounces as failed sends, retries every bounced address in one batch, then deletes the soft bounces along with the hard ones. The dead addresses get hit a second time, and customers whose mailboxes were only full drop off the list.

After. With the Nitrosend MCP tools, the agent cleans up first, then gets the next newsletter ready without the dead addresses:

1. nitro_get_insights pulls the email analytics for the newsletter, with trends, benchmarks and recommendations, so the agent sees how far the bounce rate moved. The hard bounces need no action: they are already on the account suppression list and excluded from future sends.
2. nitro_manage_audience checks the subscriptions of the contacts in question, leaves the soft-bounced contacts on the list (Nitrosend suppresses their email channel after three soft bounces, so the agent deletes nobody), and runs explicit prepaid email validation on addresses in doubt, such as ones that came from an old import.
3. nitro_compose_campaign creates the next newsletter as a broadcast draft. It never delivers it.
4. nitro_review_delivery runs a read-only review of the draft, with validation, spam analysis, preflight and previews. It never approves or sends.
5. nitro_send_test_message sends one real test of the campaign to the test recipients set with nitro_configure_account. It never sends to an audience.
6. nitro_control_delivery is where a person approves the campaign, after reading the test.
7. nitro_get_insights, once the newsletter has sent, shows whether the bounce rate came back down.

The difference in one line: the agent stops retrying bounces, the suppression list decides who is mailed, and a person approves the next send.

Where it goes wrong when an agent retries bounces

• Hard bounces retried in a loop. A script that resends every failed address on a timer hits the same dead mailboxes on every pass, and each pass pushes the bounce rate toward the 5% level where Amazon SES places an account under review and the 10% level where it may pause the account's sending.
• Bounced addresses re-imported from an old CSV. An agent asked to restore a list pulls an export from before the bounces, and addresses that failed months ago come back. A hard-bounced address stays on the account suppression list, so it is excluded from all future sends even when an old CSV brings it back through nitro_import_contacts. See the guide to a bounce rate spike after a list import for the cleanup.
• A soft bounce treated as permanent. An agent that deletes every bounced address drops a good customer whose mailbox was full for a day. A 4xx code means try again later, not remove.
• A retry with no idempotency_key. When a batch of transactional sends partly fails and the agent resends the whole batch through nitro_send_message, the addresses that did deliver get the email twice. Reuse the idempotency_key only for an exact retry of the one send that failed.
• A bounce spike from a list the agent assembled. Addresses an agent pieced together from email signatures, old threads or guessed formats were never confirmed by the people behind them, and a share of them do not exist. Validate them before the first send, not after the bounces arrive.

Knowing the difference matters less than acting on it automatically

The classification only matters if something acts on it: hard bounces suppressed for good, soft bounces counted and the email channel suppressed after three. Nitrosend applies those rules automatically to every send from the account, so neither a person reading a report nor an agent retrying a send has to.

FAQ

Go deeper