Email Bounce Rate: Hard Bounces, Soft Bounces and List Decay

Definition

What is email bounce rate?

Email bounce rate is the percentage of sent emails that come back undelivered: bounced messages divided by messages sent, times 100. It measures the list before the content, because a bounce happens at the receiving mail server before any recipient sees the message.

A bounce is the non-delivery report a mail server returns when it refuses a message or cannot deliver it. RFC 5321, the SMTP standard published in October 2008, requires a server that accepts a message and then fails to deliver it to send a failure notification to the envelope return path. Sending platforms count those notifications, together with refusals during the SMTP session, as bounces.

The calculation needs 2 numbers from one campaign: messages sent and messages bounced. A campaign of 4,000 emails with 60 bounces has a bounce rate of 1.5%. Report hard bounces and soft bounces as separate rates, because each type calls for a different action.

An email bounce rate checker or calculator runs the same division. Its result describes one send, to one list, on one date, so compare rates only across campaigns sent to similar lists.

List verification

How does email list verification work?

Email list verification tests each address for valid syntax, a domain that accepts mail and a mailbox the server recognizes, without sending a message. It labels each address valid, invalid, catch-all or unknown, so addresses that would hard bounce leave the list before the campaign.

A catch-all domain, also called an accept-all domain, routes mail for nonexistent or misspelled addresses into one designated mailbox. Google Workspace documents this setting as catch-all routing. A verifier that tests an address at such a domain gets an acceptance whether or not the named person has a mailbox, so the result stays unconfirmed. Some servers also accept every recipient during the SMTP session and reject the message afterward, and RFC 5321 then requires them to send a failure notification, which arrives as a bounce.

RFC 5321 lets a server disable VRFY, the command that confirms a mailbox by name, and requires a neutral 252 reply in that case. Verifiers test the recipient step of the SMTP session instead.

Verifying guessed attorney email addresses is the step that turns a pattern into a sendable address, because an address built from a firm's format stays a hypothesis until the firm's server accepts it. Attorney records sold on this site are tested by 2 email verification services, and addresses at catch-all domains carry their own flag; the homepage sets out how attorney email addresses are verified.

1. Syntax check: the address follows the local-part@domain form, and RFC 5321 caps the local part at 64 octets.
2. Domain check: DNS returns a usable MX record, or an address record that serves as an implicit MX, and a null MX under RFC 7505 marks a domain that accepts no mail.
3. Mailbox check: the verifier opens an SMTP session, submits the address as a recipient and ends the session before any message is sent.
4. Catch-all check: the verifier submits an address that cannot exist at the same domain, and acceptance marks the domain as accept-all.
5. Role check: shared inboxes such as info@ and reception@ receive a separate label from named mailboxes.

Causes

What causes a high email bounce rate?

A high email bounce rate comes from addresses that no longer exist, domains that stopped accepting mail and sending domains that fail authentication. Guessed addresses, typos and old files add hard bounces, while full mailboxes and throttling servers add soft bounces.

Old files add a second risk. Spamhaus, an organization that publishes DNS blocklists, describes recycled spam traps as addresses that were once valid but are no longer used, and states that they make up the majority of spam traps. An unverified contact file from years ago carries that exposure alongside its hard bounces.

• Job changes: a lawyer leaves the firm, the firm closes the mailbox, and mail to it returns 5.1.1.
• Domain changes: a merged or renamed firm retires its old domain, and mail to it returns 5.1.2 or 5.1.10.
• Pattern guesses: a format such as first.last produces an address the firm never created.
• Typos: one transposed letter in the local part or the domain creates an address that does not exist.
• Authentication failures: a sending domain without SPF, DKIM or DMARC meets policy rejections such as 550 5.7.515 at Outlook.com.
• Mailbox limits: full mailboxes and rate limits return 4.X.X codes that clear on a later attempt.

Reduce bounces

How do you reduce email bounce rate?

Reduce email bounce rate by verifying the list close to the send date, suppressing hard bounces after the first failure and authenticating the sending domain. Send catch-all addresses as a separate segment, and remove any address that keeps bouncing across campaigns.

Google's guidelines also list automatic unsubscription of recipients with multiple bounced messages as a supporting option for senders who manage subscriptions. The sending platform handles bounces, but the list sets the starting point: every day between a file's verification date and the campaign adds exposure to the causes above.

1. Verify the file before each campaign, and compare its verification date with the send date.
2. Suppress every address that returns 5.1.1 or another user-unknown failure, since M3AAWG says such a message must not be retried.
3. Remove addresses that bounce 2 consecutive times over 2 weeks or more, the point M3AAWG describes as best practice.
4. Publish SPF, DKIM and DMARC for the sending domain; DMARC is now specified in RFC 9989, published in May 2026.
5. Send catch-all addresses in their own segment so their bounces stay visible.
6. Lower sending volume when bounces or deferrals rise, as Google's sender guidelines advise, and raise it slowly afterward.