Email bounce rate

How email bounce rate works

When a mail server cannot deliver a message, it sends back a failure notice, and the sender counts a bounce. A hard bounce is a persistent failure, such as a mailbox that does not exist 2. A soft bounce is a temporary failure, such as a full mailbox, too many connections or a connection that times out 2. Amazon SES retries soft bounces several times and stops if the message still cannot be delivered 2.

The failure notice carries a status code, and RFC 3463 makes the first digit the class 3. A 2 means success, a 4 means a persistent transient failure where a later attempt may succeed, and a 5 means a permanent failure that resending in the same form is unlikely to fix 3. The second and third digits give the reason, so X.1.1 means a bad destination mailbox address and X.2.2 means the mailbox is full 3.

Bounces also differ by timing. A synchronous bounce arrives while the two servers are still talking, so the sender sees it during the send 1. An asynchronous bounce comes after the receiving server first accepted the message, sometimes hours later 1. A pre-send check cannot predict that second kind, which is one reason catch-all email domains need their own sending track.

AWS notes that bounce rate usually refers to hard bounces per emails sent 1. Amazon SES counts only hard bounces toward its own bounce rate 2. On many systems, a soft bounce that keeps failing ends as a hard bounce once retries run out 1. Counting the two types apart stops a short outage at one receiver from looking like a bad list. See hard bounce and soft bounce for each type.

What causes a high bounce rate

A high hard bounce rate usually traces back to the list rather than the message.

• Addresses that never existed. Typos, guessed formats and invented addresses fail with a bad mailbox status 3.
• Addresses that used to work. People leave employers and their work mailboxes close, which is how data decay reaches a campaign.
• Domains that cannot receive mail. A domain with no MX record cannot accept mail from anyone 4.
• Suppressed addresses. Amazon SES keeps a global suppression list of addresses that recently hard bounced for any SES customer, and a send to one of them counts as a hard bounce 2.
• Temporary receiver problems, such as a full mailbox or throttling, which show up as soft bounces 2.

The first four are list problems a sender can fix before the send. Email verification catches mailboxes that do not exist and domains that cannot take mail, and a recent check date catches people who have left. The last cause sits on the receiving side, which is one reason Amazon SES keeps soft bounces out of its bounce rate 2.

Example of email bounce rate

The AWS Messaging blog gives the standard calculation 1. A sender sends 10,000 emails and 222 of them bounce, so the bounce rate is 222 divided by 10,000, or 2.22% 1. AWS calls keeping the rate under 5% a usual best practice, and adds that the line is a rule of thumb that is not universal across providers 1.

The status codes show what sits inside that number. Suppose 180 of the 222 bounces carry 5.1.1, a bad destination mailbox, and 42 carry 4.2.2, a full mailbox 3. Under the RFC 3463 classes, the 180 are permanent failures and the 42 are transient 3. A system that counts only hard bounces, as Amazon SES does, would report 180 out of 10,000, or 1.8% 2. The 42 soft bounces get retried and join the rate only if the retries fail 1.

Each class needs a different fix. Remove the 180 addresses and do not mail them again, since AWS strongly recommends against repeated attempts to addresses that hard bounce 2. Leave the 42 to the retry logic, since soft bounces are retried automatically 2. Then look upstream. If most of the hard bounces came from one list source or one import date, verify that source before the next send. Keep the same split for every campaign and store it by list source, so each source builds its own bounce history that you can compare over time. RichAPI's verifier reference says to drop rows where mxFound is false first, because a domain with no mail exchanger cannot receive mail from anyone 4.

Email bounce rate vs email deliverability

People often use the two terms as if they meant the same thing. Bounce rate counts messages the receiving server refused. Deliverability is broader and asks whether accepted mail reaches the inbox or the spam folder. A message can be accepted, so it never bounces, and still land in spam. Bounce rate feeds deliverability, because AWS notes that a high rate can signal an old or bought list to mailbox providers 1. Fixing bounces protects deliverability, but a list with almost no bounces can still land in spam.