Understanding Email Bounces & Delivery Issues


Normal Delivery

Subject: Meeting tomorrow at 10am
Broadcast Message
Bento Servers
Recipient's Provider
Recipient Inbox
Hard Bounce
Retry Later
Spam Folder

Batch Send

Bento Safely batch sends emails to multiple recipients
Instant

Types of Email Bounces

For the sake of simplicity, bounces are typically grouped into three types: soft, hard, and other. Think of soft bounces like a "you can try again later", hard bounces like a "never gonna happen", and other bounces as "hey something else is going on here".

Soft Bounces (Codes 20-29)

These are temporary failures. The recipient's server is saying "not right now" but might accept the email later. Common causes include:

  • Full mailboxes (Code 22)
  • Server temporarily down (Code 20)
  • DNS failures (Code 21)
  • Rate limiting/throttling
  • Greylisting (temporary rejection to prevent spam)

Recently, we had a customer hit with "421 4.7.28 Gmail detected unusual rate of mail". Their emails were delivering fine until they hit a volume threshold, then Gmail started rate limiting down to 10 emails per hour. We told them to pause their campaign, and resume the next day. All emails were delivered fine the next day.

Hard Bounces (Code 10)

These are permanent failures - the server is saying this email will never be delivered. Common causes:

  • Invalid email address
  • Domain doesn't exist
  • Recipient account deleted

These emails Bento will typically unsubscribe the user and add them to the global firewall.

Other Bounces (Codes 40-59)

These are failures that don't mean the address is invalid, but something else is wrong. Common causes:

  • Spam blocks (Codes 50-55)
  • Content triggers (Code 52)
  • Connection blocks (Code 59)
  • Auto-replies (Code 60)

How Retry Schedules Work

When an email soft bounces, most providers (including Bento) will retry delivery on a schedule:

  • First attempt: Immediate
  • Second attempt: 15 minutes later
  • Third attempt: 30 minutes later
  • Fourth attempt: 1 hour later
  • After that: Every 2-4 hours

Depending on the provider, we may retry earlier or later. Sometimes the providers have maximums that we must respect. The maximum retry period typically extends to 72 hours (Code 120/121).

Common Deferral Scenarios

Temporary Server Issues (450/451 Errors)

  • Connection problems (Code 29)
  • Server maintenance
  • DNS temporary failures (Code 21)
  • Typical retry window: 24-48 hours

Greylisting

  • Initial temporary rejection
  • Usually resolves within first retry
  • Maximum retry period: 24 hours

Rate Limiting & Throttling

Let's talk about rate limiting for a minute because this trips up a lot of people. When we talk about "rate limits" we're actually talking about three different things:

  1. Connection Rate Limits (Code 29/59) This is when Gmail, Yahoo, or whoever says "slow down, you're connecting to our servers too quickly!" Think of it like someone knocking on your door 100 times a minute - eventually you'll stop answering. When this happens, you'll usually get blocked for a few minutes.

  2. Volume Limits This one's straightforward - you're sending too many emails too fast. Every inbox provider has their own rules here. Some might say "only 1000 emails per hour", others might say "no more than 100,000 per day". Go over these limits and they'll typically make you wait a few hours (upto a day) before accepting more.

  3. Recipient Limits This is a sneaky one that a lot of people miss. Even if you're under your total volume limits, providers will throttle you if you send too many emails to the same person or domain too quickly. We've seen customers hit this when they send welcome sequences + transactional emails + marketing all at once to new users. When this happens, you're usually locked out for several hours.

At Bento, we handle all this automatically with batching - it's why we're kinda opinionated about sending speeds. Much better to pace things out than hit these limits and damage your sending reputation.

Here's a real scenario we encountered:

I had a customer run into Gmail's rate limiting because they were trying to send their entire year-end newsletter at once - 421 4.7.28 Gmail has detected an unusual rate of mail originating from your SPF domain. Looking at their data, emails were delivering fine until they hit a volume threshold, then got throttled all the way down to 10 emails per hour. This is why batch sending exists - you need to pace these things out.

Industry Standards & Best Practices

At Bento, we follow these guidelines:

  • Hard bounces (Code 10) are instantly unsubscribed.
  • Soft bounces are only unsubscribed if we believe they are actually a hard bounce (i.e someone has had a full inbox for a few months).
  • We will not unsubscribe reputation or block related bounces.
  • Spam blocks (Codes 50-55) don't trigger unsubscribes (Spam Complaints do)

Email Authentication: Not Optional Anymore

If you're sending any volume of email in 2024, authentication isn't a "nice to have" anymore. Starting February 2024, Gmail and Yahoo require all senders doing more than 5,000 emails per day to have proper SPF, DKIM and DMARC records set up. But honestly? You should do this regardless of volume.

Here's what each piece does:

  • SPF: Think of it as a permission slip that says "these servers can send email from my domain"
  • DKIM: It's like a digital signature on every email proving it really came from you
  • DMARC: Tells receiving servers what to do if an email fails either of these checks

Here's a real example of why this matters:

Recently had a customer getting abnormally low opens. Our monitoring alerted me, investigated and found they deleted their DKIM keys by accident. Paused their campaign, got them to add the records back, and opens jumped from 3% to +20%.

At Bento, we've been pretty opinionated about this from the start. While some providers say "don't bother until you hit 50,000 subscribers", we encourage everyone to set these up immediately. When we detect your records are live, we automatically start using them. It's better to have good security from day one than try to fix delivery issues later.

Final Thoughts

Email delivery isn't complex - it's just detail oriented. Monitor your metrics, clean your lists regularly, authenticate properly, and most importantly: don't rush. Gradual, consistent sending always wins over blasting your whole list at once.

Was this page helpful?