agent email bounce handling workflow: what to do when messages come back

Your agent fires off a verification email as part of a multi-step signup flow. Ten seconds later, the receiving server responds with a 550: mailbox not found. The email is dead. But your agent doesn't know that yet. It's sitting there polling for a reply that will never arrive, burning through timeout windows while the rest of the workflow stalls.

This is what happens when agents send email without bounce handling logic. Most agent frameworks treat sending as the hard part and assume delivery is someone else's problem. It isn't. If your agent sends email, it needs a bounce handling workflow baked into its pipeline from day one.

How to handle email bounces in an agent workflow#

1. Receive the bounce event from your email provider via webhook
2. Parse the SMTP error code and extract the bounce type
3. Classify as hard bounce (permanent) or soft bounce (transient)
4. For hard bounces, update the suppression list and halt further sends
5. For soft bounces, apply exponential backoff retry up to a set limit
6. Log all bounce events and trigger alerts if hard bounce rate spikes

That six-step loop is the skeleton. The rest of this article puts muscle on it.

Hard bounces vs. soft bounces#

Not all bounces mean the same thing, and your agent needs to distinguish between them before deciding what to do next.

A hard bounce is a permanent rejection. The address doesn't exist, the domain has no mail server, or the recipient's server has explicitly blocked your sending domain. SMTP codes in the 5xx range (550, 551, 553) signal these. The correct response: stop sending to that address. Immediately. No retries, no "maybe it'll work tomorrow."

A soft bounce is temporary. The recipient's mailbox is full, the server is overloaded, or there's a transient network issue. These show up as 4xx codes (421, 450, 452). Your agent can retry, but with limits. Three attempts over 24 hours with exponential backoff is a reasonable default. After the third failure, treat it as a hard bounce and suppress.

Here's where it gets interesting. Some providers return ambiguous codes. A 550 with the message "mailbox unavailable" could mean the address is gone forever, or it could mean a temporary policy block. This is where bounce reason parsing matters. If your agent can read the human-readable portion of the SMTP response (the text after the code), it can make better classification decisions. An LLM is actually well-suited for this. Feed it the full bounce message and ask it to classify as permanent or transient. It will outperform regex matching on the edge cases that matter most, because non-standard bounce messages are basically free-form English with wildly inconsistent formatting across providers.

What happens when a required email bounces mid-task#

Campaign bounce handling is well-documented. Every email platform has a guide for it. But agent workflows have a problem that marketing tools don't: sometimes the bounced email was the only path forward.

Picture this. Your agent is signing up for a service that requires email verification. It sends a confirmation request, and the receiving server bounces it because the agent's sending domain fails SPF checks. The agent can't complete the signup. The entire downstream workflow (account creation, API key retrieval, data sync) is blocked on a single undeliverable message.

Nobody's day is ruined when a newsletter doesn't arrive. But when an agent's transactional email bounces mid-task, you need escalation logic:

1. If a task-critical email bounces, flag it separately from routine bounce handling.
2. For soft bounces, retry with backoff. For hard bounces on the address, check for an alternate contact.
3. If recovery fails, pause the workflow and notify a human or supervisor agent with the full bounce context: SMTP code, reason text, the blocked task, and suggested next steps.

This kind of mid-workflow bounce handling is absent from most email platform docs because those platforms assume a human is watching a dashboard. Agents don't have that luxury. The escalation path needs to be defined before the first email goes out, not improvised after something breaks.

We covered related sending setup in our guide on email deliverability for AI agents, including SPF, DKIM, and warm-up strategies that prevent many of these bounces from happening in the first place.

Building a suppression list your agent actually uses#

A suppression list is simple in concept: a set of addresses your agent should never email again. In practice, agents ignore suppression lists all the time. The list lives in one system and the agent sends from another.

The fix is to make suppression checking a mandatory gate in the send path. Not optional. Not "check if available." Every outbound email passes through a suppression lookup, and if the address is flagged, the send is blocked before it reaches the email provider.

Store the following for each suppressed address:

• The email address (normalized to lowercase, trimmed)
• Bounce type (hard or soft-exhausted)
• SMTP code and full reason text
• Timestamp of the original bounce
• The workflow or agent that triggered the original send

That last field matters when you're running multiple agents. You need to know which one burned the address so you can debug patterns across your system. One agent's suppression data should propagate to every agent sharing the same sending infrastructure. Otherwise you end up with Agent A suppressing user@example.com while Agent B keeps hammering it, dragging down your entire domain's reputation.

If your agents send at any real volume, the AI sales outreach agent guide walks through sender reputation protection in detail, including how suppression fits into a broader anti-blacklist strategy.

Webhook-driven bounce processing#

Polling for bounce notifications is slow and wasteful. Webhooks are the right pattern. Your email provider sends an HTTP POST to your endpoint the moment a bounce occurs, and your agent processes it in near real-time.

A typical bounce webhook payload looks like this:

{
  "event": "bounce",
  "type": "hard",
  "email": "recipient@example.com",
  "smtp_code": 550,
  "smtp_message": "5.1.1 The email account does not exist",
  "timestamp": "2026-03-30T14:22:00Z",
  "message_id": "msg_abc123"
}

Your webhook handler should validate the signature (never trust unsigned payloads), parse the bounce type, update the suppression list for hard bounces, queue retries for soft bounces, check if the bounced message was task-critical, and log everything. That's the six-step loop from earlier, applied in code.

LobsterMail's webhook system delivers bounce events with the SMTP code, bounce classification, and original message ID, so your agent can correlate bounces back to specific workflow steps without parsing raw SMTP responses. If you'd rather skip building this plumbing yourself, you can set up agent email with bounce webhooks here and have events flowing in minutes.

Alerting on bounce rate spikes#

Individual bounces are normal. A sudden spike in hard bounces is an emergency. It usually means one of a few things: your sending domain's authentication broke, you're hitting a blocklist, or your agent is sending to a stale address list.

Set a threshold. If your hard bounce rate exceeds 2% of total sends over any rolling one-hour window, your agent should pause all outbound email, fire an alert to Slack or PagerDuty, and include the bounce rate, sample SMTP codes, and recent sending activity in the notification.

Don't let your agent keep sending into a spike. Every additional bounced message during a reputation event makes recovery harder. Pause first, diagnose second. Some providers start throttling at 5%, but by that point you've already done real damage to your domain's standing. A 2% trigger catches problems early enough to actually recover from them.

Build the suppression list, wire up the webhooks, set the alert thresholds, and define what happens when a required email can't be delivered. Do all of it before your agent sends its hundredth message, not after your domain lands on a blocklist.