A hard bounce is a permanent delivery failure caused by an invalid or nonexistent email address. A soft bounce is a temporary failure — a full inbox, a server timeout, a greylisting event. For Instantly users, the distinction is critical: hard bounces above 2% will trigger account warnings, damage your sending domain’s reputation, and in severe cases get your infrastructure flagged by Google Postmaster. Soft bounces are recoverable. Hard bounces are not.
What Is a Hard Bounce?
A hard bounce is a permanent, unrecoverable delivery failure. When you send to a dead or invalid address, the receiving mail server returns a 5xx SMTP error code — typically 550 or 551 — telling your sending infrastructure that this address does not exist and will never exist. Instantly logs this immediately. Every hard bounce is a data quality failure, full stop.
In practice, the addresses that generate hard bounces fall into two categories: addresses that were never valid, and addresses that were valid when you scraped or bought the list but have since been deactivated. The second category is where most cold email agencies get blindsided. A contact leaves a company. Their inbox gets shut down. Your list data is three months old. The address looks clean in ZeroBounce because it was valid during their last crawl — but it hard bounces the moment you hit send.
What Is a Soft Bounce?
A soft bounce is a temporary delivery failure, typically returned with a 4xx SMTP code. Common causes include a full recipient mailbox, a receiving server that’s temporarily unavailable, or greylisting — where the server intentionally defers unknown senders on first contact. Instantly and Smartlead both retry soft bounces automatically over a period of hours.
Soft bounces don’t directly damage your domain reputation the way hard bounces do. But they’re not noise either. A pattern of soft bounces on a specific domain — particularly one that’s consistently greylisting your sends — signals that those domains may be running catch-all configurations that accept all incoming mail at the server level, then silently defer or drop it. That’s a different problem, and one that binary verification tools consistently fail to flag.
Why Hard Bounces Destroy Instantly Deliverability Faster Than You Expect
Instantly enforces a bounce rate threshold. Exceed it — industry consensus puts the danger zone above 2%, with Google’s own Postmaster guidelines citing 2% as a critical threshold — and your sending account gets flagged. Sustained hard bounce rates above 3% on a domain will accelerate its path to blacklisting.
What we see consistently with agencies that onboard a new client list: they run it through a standard verification pass, get a 95%+ valid rate back, launch their sequence, and hit 4-6% hard bounces on day one. The verification passed those addresses as valid. The addresses were not valid at send time. The gap between when verification data was collected and when you actually send is where domain reputation gets destroyed.
This is the core failure mode of database-cached verification. Tools that query a stored result rather than probing the address live cannot catch deactivations that happened after their last crawl. A real-time SMTP probe — one that makes a live connection to the receiving mail server and tests deliverability at the moment of verification — catches these. VerifyFlow’s deep SMTP probing runs this check at verification time, classifying every address as SAFE, PROTECTED, RISKY, or DEAD so you know exactly which segments to suppress before a sequence goes live.
How to Use the Hard/Soft Bounce Distinction to Protect Your Sending Infrastructure
The practical workflow for Instantly users is straightforward. Before uploading any list — especially a purchased one — you need to segment aggressively, not just remove the obvious invalids.
- DEAD addresses (confirmed 5xx failures on live SMTP probe): Remove unconditionally. No exceptions.
- RISKY addresses (addresses on domains with suspicious MX behavior, high deactivation signals, or SMTP anomalies): Suppress from primary sequences. These are your latent hard bounce risk.
- PROTECTED addresses (catch-all domains that accept all mail but may not deliver): Treat as soft bounce risk. Warm these separately or exclude from high-stakes campaigns.
- SAFE addresses (confirmed deliverable via live SMTP handshake): Send with confidence.
Soft bounces from catch-all domains deserve specific attention. NeverBounce and similar binary tools mark catch-all addresses as valid because technically the server accepted the message. But acceptance at the MX level doesn’t mean delivery to a real inbox. Running a second-pass verification specifically designed to probe and classify catch-all behavior — rather than treating every accepted address as equivalent — is the layer most agencies skip and most deliverability incidents trace back to.
Frequently Asked Questions
Q: Does Instantly count soft bounces against my bounce rate?
A: Instantly tracks hard bounces and soft bounces separately. Hard bounces — permanent 5xx failures — are the ones that damage your sending reputation and trigger account warnings. Soft bounces are retried automatically and do not count against your core deliverability threshold, though persistent soft bounce patterns on specific domains are worth monitoring.
Q: Can a catch-all email address cause a hard bounce?
A: Yes. Catch-all domains accept all inbound mail at the server level, which means standard verification marks them as valid. But if the specific mailbox doesn’t exist, the message may be accepted, then bounced internally — registering as a hard bounce in your sending platform. This is a major blind spot in binary verification tools that don’t probe catch-all behavior at the subdomain level.
Q: I already ran my list through ZeroBounce — do I still need to verify again?
A: If your list is more than 30 days old or was sourced from a third-party provider, yes. ZeroBounce uses database-cached results — if an address was valid during their last crawl but has since been deactivated, it returns as valid. A second-pass real-time SMTP probe run immediately before your campaign launch catches those deactivations before they hard bounce inside Instantly.