DEV Community

Steve
Steve

Posted on Edited on

How AWS SES bounce rates can put your account at risk, and how to reduce bad signups before sending

#security #aws #webdev #saas

If you send transactional email through Amazon SES, your bounce rate matters more than most developers realise until it becomes a problem. This post explains how bad signups push it up, what AWS says about thresholds, and one way to reduce the problem before you send. I'm the author of SentriSend, the API mentioned below, so treat this as a builder's perspective rather than a neutral review.

The thresholds

AWS publishes bounce-rate guidance for SES. As I understand it, AWS recommends keeping the rate low (around 2% or under), may place an account under review above 5%, and may pause sending at 10% or more. These numbers can change, so check the current SES documentation rather than relying on this post. Other providers, including SendGrid, have their own rules.

If sending is paused, everything that depends on your email stops: verification codes, password resets and receipts.

Clean DNS doesn't prevent bounces

SPF, DKIM and DMARC matter for deliverability, but they don't stop bounces caused by the addresses you send to. Three common sources:

  • Automated signups with disposable or made-up addresses
  • Typos in real users' addresses
  • Domains that don't exist or can't receive mail

For a small sender, a modest number of bad addresses can move the percentage a lot, because the total volume is low.

Handling it after the fact isn't enough

Many guides cover SNS/SQS bounce notifications and suppression lists. Those are worth setting up, but they run after the message has been sent and the bounce has been recorded. To reduce bounces in the first place, you need to check the address before you send.

A pre-send check

SentriSend is an API that validates an address with one call before you send. It checks that:

  • the address is well formed
  • the domain isn't on a bundled list of about 133,000 known disposable domains (the list is built into the service at build time)
  • the domain exists and can receive mail, using live DNS/MX lookups

If the DNS result can't be determined, the address is allowed with MEDIUM risk, so a slow lookup doesn't block a genuine user.

curl -X POST https://sentrisend.com/api/v1/validate \
  -H "Authorization: Bearer YOUR_SENTRISEND_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'
Enter fullscreen mode Exit fullscreen mode

An allowed address returns HTTP 200:

{ "allowed": true, "disposable": false, "risk_score": "LOW" }
Enter fullscreen mode Exit fullscreen mode

A disposable domain returns HTTP 400:

{ "allowed": false, "disposable": true, "reason": "DISPOSABLE_DOMAIN", "risk_score": "HIGH" }
Enter fullscreen mode Exit fullscreen mode

Your application reads the result and decides whether to continue sending through SES, Resend or whatever you use.

What it doesn't do

  • It doesn't confirm that an individual mailbox exists. A real domain with no such mailbox can still bounce.
  • It doesn't detect bots. It validates the address, so pair it with CAPTCHA or rate limiting on your forms.
  • It doesn't replace bounce handling. Keep your SNS/SQS suppression list.

Privacy

In SentriSend's send audit records, the recipient, subject and message bodies are redacted. Customer account and billing data is stored separately.

Try it

The free tier is 100 requests a month, with no card needed. There's also a live simulator on the site, and the docs and a working example are public.

If you've dealt with bad signups hitting your bounce rate, I'd like to hear how you handle it.

Top comments (0)