How can bounce handling cause email loops?

Picture this: you send a campaign, one email bounces, and your server fires off a bounce notification. Standard stuff. But what if the address that notification gets sent to is also broken? Now that notification bounces too. And your system replies to that bounce with another notification. And on it goes.

That's a bounce loop, and it's more common than you'd think.

The technical name for that bounce notification is a DSN (Delivery Status Notification). When an email can't be delivered, your mail server generates a DSN and sends it to the address listed in the Return-Path header. That Return-Path is the behind-the-scenes envelope address, different from your From address, and it's where all bounce processing happens.

Here's where loops start. If the Return-Path address itself is invalid, broken, or points to a mailbox that auto-replies, you've created a feedback cycle with no exit.

The three configurations that cause this most often:

• Invalid Return-Path address. Your bounce address doesn't exist or has a typo, so the DSN bounces, which generates another DSN, and so on.
• Auto-responder replies to DSNs. A vacation reply or out-of-office on your bounce handling address fires back at every incoming DSN. That reply triggers another DSN. That DSN triggers another reply.
• Forwarding to a broken address. Your Return-Path forwards to a secondary address that no longer works. Same chain, different starting point.

The fix the mail standards actually require is a null envelope sender. A DSN should always go out with an empty Return-Path (written as <> in SMTP terms). That empty address is the circuit breaker. If a DSN itself bounces, there's nowhere for the new notification to go, so the loop can't start.

So most modern mail servers also check for loop indicators before generating a DSN. If they see a message that already has an empty Return-Path, they drop it silently rather than piling on. But not every server is configured correctly, and not every forwarding setup plays by the same rules.

What to look for in your logs if you suspect a bounce loop:

• Rapid repeated messages between the same two addresses
• DSNs about DSNs (you'll see subject lines like "Delivery failure for your Delivery failure notification")
• Unusual spikes in outbound volume that you didn't trigger
• Your bounce address filling up with auto-generated notifications

If you're setting up bounce handling from scratch, keep it simple. Use a dedicated bounce address that does nothing except receive and process. No auto-responders on it, no forwards to uncertain destinations, and make sure your ESP is sending DSNs with a null Return-Path. (Most reputable ones do this automatically, but it's worth confirming.)

If something's broken right now and you're seeing loop-like behavior, our SOS hotline is free and we'll look at your setup with you.