Instead of relying on unverified third-party industry averages, engineering teams should measure deliverability using deterministic SMTP telemetry from their own mail streams. Part 1 of this four-part technical series covers how mailbox providers classify bounces under RFC 5321 and RFC 3463, and how pre-send email verification prevents avoidable failures.
Hard bounces vs. soft bounces at the protocol layer
Every bounce originates as an SMTP reply code combined with an Enhanced Mail System Status Code (X.Y.Z):
- Permanent failures (
5xx/5.X.X): indicate a hard bounce that must be suppressed immediately. Common codes include550 5.1.1(bad destination mailbox address) and550 5.1.2(bad destination system address). - Transient failures (
4xx/4.X.X): indicate a soft bounce such as452 4.2.2(mailbox full) or421 4.7.0(temporary rate limit or greylisting). Senders should back off and retry on a bounded schedule before converting repeated failures into suppressions.
Pre-send verification vs. post-send bounce handling
Waiting for an ESP to record a 550 5.1.1 bounce means your sending domain has already absorbed the reputation cost of attempting delivery to a dead mailbox. Running lists through ValidReach's verification pipeline before import catches syntax errors, dead MX domains (no_mx), disposable addresses and invalid mailboxes before a single message leaves your MTA.
Operational thresholds to monitor
- Keep complaint rates below
0.1%and never reach the0.3%enforcement ceiling documented in Google's Email Sender Guidelines. - Quarantine
catchalland sharedroleinboxes into dedicated low-volume segments so uncertain recipients cannot spike your hard-bounce ratio.
Sources
- IETF RFC 5321 — Simple Mail Transfer Protocol — accessed 2026-11-04
- IETF RFC 3463 — Enhanced Mail System Status Codes — accessed 2026-11-04
- Google Workspace Admin Help — Email sender guidelines — accessed 2026-11-04
- ValidReach Verification Results Reference — accessed 2026-11-04
