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:
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).
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:
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.
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.
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.
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.
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.