Hard bounce vs soft bounce: the difference, and what to do with each one

A delay is not a bounce yet. While our mail servers are still retrying a 4xx reply you get email.delivery_delayed; it becomes a Transient bounce only when the retries run out. A third type, Undetermined, means our mail servers could not tell from the reply whether the problem is lasting. It is rare; count it as a soft bounce.

Every refusal comes with a short error number: a three-digit reply code (RFC 5321) and usually an enhanced code after it (RFC 3463), such as 5.1.1. The first digit says permanent (5) or temporary (4). The middle digit says whose problem it is:

These are the replies you will see most, as the receiving servers write them. In the dashboard, open a bounced email in Emails and its timeline shows the same line; in a bounce event it arrives in diagnosticCode after smtp;.

550 5.1.1 The email account that you tried to reach does not exist.
550 5.4.1 Recipient address rejected: Access denied
550 5.2.1 The email account that you tried to reach is inactive.
452 4.2.2 The recipient's inbox is out of storage space.
552 5.2.2 The recipient's inbox is out of storage space and inactive.
421 4.7.0 Try again later, closing connection.
550 5.7.26 Unauthenticated email from acme.example is not accepted due to domain's DMARC policy.

Deleting addresses over a 5.7.x only hides the incident. The authentication article covers the usual fixes.

Some replies carry no enhanced code at all, only a reply code and a sentence, and some receivers put a missing address under the wrong code. For both, M3AAWG’s sender best practices (section 2.2) say the same thing: read the descriptive text. Treat a reply as a bad address only when the words are unambiguous, such as “user unknown” or “does not exist”. RFC 5321’s stock 550 text, “mailbox unavailable”, is used for policy refusals too, so it is not enough.

• Refuses addresses that cannot receive mail, before sending. A send to a known typo of a big provider’s domain (gmial.com), a reserved domain, or a domain with no MX and no address record, or a null MX, is refused with a “Did you mean” suggestion where there is one. It never becomes a bounce: a single send gets a 422, and a campaign records that recipient as email.suppressed with reason invalid_recipient. If the DNS lookup fails, the send goes through.
• Remembers addresses that cannot exist. An address that hard-bounced as non-existent (a 5.1.1 or 5.1.10, or a reply our mail servers classify as “no such address”) is refused for every team for 180 days after its last such bounce, so nobody’s reputation pays for it twice. If a customer’s address is refused this way and they say it works, ask us to lift it.
• Retries soft failures. An email.bounced event with type Transient means the retries have already stopped. Do not add a second retry layer that resends the same message.
• Suppresses hard bounces and complaints. Every bounce reported as Permanent adds the address to your team’s suppression list, its do-not-send list, as does every spam complaint. Later sends to it, marketing and transactional alike, are stopped and reported as email.suppressed.
• Leaves soft bounces alone. Transient and Undetermined bounces never suppress. When a repeating soft bounce means “gone” is your call; the next section shows the rule.

One gap to know about: a refusal that arrives as Permanent is suppressed whatever its code, policy refusals included. During an authentication outage that can be hundreds of good addresses in an hour. Once the cause is fixed, lift them:

1. In the dashboard, open Emails and click Suppressions at the top right.
2. Set the origin filter to bounce and the date to the day of the outage. Each row shows the address and when it was added; open one to see the email that bounced.
3. Remove the affected addresses with Remove. The dashboard removes one at a time; there is no bulk lift there yet.

For more than a handful, use the API: GET /suppressions?origin=bounce with start_date and end_date lists them, and POST /suppressions/batch/remove lifts them in one call. Tracing a missing email walks through finding which case you are in.

M3AAWG’s Sender Best Common Practices (version 4.0, August 2026, section 2.2) say addresses should be removed when they “consistently bounce with any failure code or descriptive text”, and that “generally it is considered a best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more.” Platforms pick their own counts; this is the published baseline. The two-week spread is what keeps one bad day at the receiver from costing you a customer. Reset the count whenever a message to the address is delivered.

Until an address reaches that line, keep it in your next campaign. One full-mailbox bounce says nothing about next week, and a customer who empties their inbox expects your mail to resume. A campaign’s report shows how many recipients bounced, and its list of bounced recipients has a bounce type column, so the soft ones are easy to pick out.

Rasket has no built-in view of repeat soft bounces yet, so without code the check is manual. For a store sending a few thousand emails a month it takes a few minutes, once a month:

1. Open Emails, set Status to Bounced and the date to the last 30 days, and click Export this page for each page of results.
2. In the spreadsheet, sort by recipient. An address listed twice or more, with its first and last bounce at least two weeks apart, has met the rule.
3. On Suppressions, click Add email address and paste them in, one per line. Addresses whose bounce was Permanent are already there.

Past that volume, the handler at the end of this article applies the rule on every event instead.

Measure bounce rate as bounced recipients over recipients with an outcome, delivered plus bounced. That is how GET /emails/metrics reports bounce_rate, per day and per sending domain.

No mailbox provider publishes an email bounce rate limit. M3AAWG says large volumes of permanent failures count against a sender’s reputation and usually point to a poor sign-up process or an old list, without giving a number. The published numbers are sending platforms’ enforcement lines. Our terms warn a team at 2%, cut its sending back at 5% and stop it at 10%. Those apply to a team’s sending as a whole, and a new account is watched more closely from its first emails, so they are a ceiling for the team, not a target for one campaign.

No one publishes a healthy number either, so compare each send with your own previous ones. A slow climb means the list is decaying faster than you clean it. A spike almost always traces to one import, one form without validation, or one integration writing the wrong field into the address: compare the day’s bounces by sending domain and by campaign, and the culprit is usually alone. Before mailing an old or imported list, send to its most recently active part first and check the bounce rate before sending the rest.

A low rate does not prove a clean list. Catch-all domains accept mail for every address and never bounce (list-validation tools flag them as “catch-all” or “accept-all”), and an abandoned mailbox at such a domain only shows up as a reader who never opens or clicks. Retiring inactive readers, below, is what catches those.

Business addresses bounce differently from consumer ones. A company’s mail gateway is more likely to accept a message and send the bounce to your return path (the bounce address your mail carries) later, hours or even days after it looked delivered (M3AAWG notes this for B2B mail). Weigh a late bounce exactly like an immediate one: the code decides, not the channel. In Rasket a late bounce replaces the delivered status on that email. Corporate refusals are also more often policy (5.7.x) or a directory answer (5.4.1, above), so group them by domain before removing anyone.

Rasket already refuses typo and mail-less domains when you send. A check at the form is still worth having, because it catches the customer while they are on the page and can fix it.

• Check the domain can receive mail. A form you control can look up the domain’s MX record, the DNS entry that names its mail server, at sign-up (dig +short MX example.com from a terminal shows what it will find). No MX and no address record, or a null MX, means every message will bounce. On a hosted store where you cannot add code, skip this one: Rasket’s send-time check covers it, and the next one is what you control.
• Catch typos. Suggest gmail.com for gmial.com before the form submits. A typo before the @, like jane.smtih, gets past every check, so show the address back on the confirmation page.
• Confirm before marketing. A confirmation email the person must click proves the mailbox works. The double opt-in article shows the flow.
• Retire the inactive. Abandoned addresses start hard-bouncing, and some are later turned back on as spam traps. The list cleaning guide has a sunset policy.

When a receipt or password reset bounces, the suppression also stops every later transactional email to that address, so a resend fixes nothing. Show a banner in the customer’s account, and give support a reply to send by another channel, such as the phone number on the order:

Thanks for your order. Our confirmation to jane.smtih@gmail.com was returned:
the receiving server says that address doesn't exist, so we haven't been able to
email you. Could you confirm the right address? We'll update your account and
resend the confirmation straight away.

Once they confirm a new address, update the account and resend; the old one stays suppressed. On a hosted store with no developer to add a banner, open the order in your store’s admin, correct the customer’s email there and resend the confirmation from the order: the support reply and that edit are the whole fix. Only mail you send through Rasket appears in its dashboard; if your store platform sends its own order emails, their bounces are in the platform’s admin.

A bounce arrives as an email.bounced webhook. Its bounce object carries type (Permanent, Transient or Undetermined), a subType, the receiving server’s message, and diagnosticCode lines. One bounce notice can hold the lines for several recipients of the same email, so the handler below reads only the line that names its address (or names nobody), pulls the enhanced code out of it, catches the receivers that report a missing address under another code, and sorts each bounce into one of three outcomes.

// Your own functions: the handler only decides which one to call.
declare function alertTeam(message: string): Promise<void>;
declare function markAddressBad(address: string): Promise<void>;
declare function recordSoftBounce(
  address: string,
  code: string | null,
  permanent: boolean,
): Promise<void>;

const API = "https://api.rasket.com";

type Bounce = { type: string; message?: string; diagnosticCode?: string[] };
type Verdict = "bad-address" | "our-problem" | "soft";

// The enhanced code follows the three-digit reply code: "550 5.1.1" or "552-5.2.2".
const ENHANCED = /\b[245]\d\d[ -]([245]\.\d{1,3}\.\d{1,3})\b/;

// A missing or abandoned mailbox reported under another code. Match the words too:
// Gmail also uses 5.2.1 for a mailbox that is receiving mail too fast.
const GONE_UNDER_OTHER_CODES = [
  { code: "5.4.1", words: /recipient address rejected/i }, // Microsoft 365
  { code: "5.2.1", words: /inactive|disabled/i }, // account switched off
  { code: "5.2.2", words: /inactive/i }, // Gmail: full and abandoned
];
// Unambiguous wording, whatever code it came under: a starting list to extend from
// your own bounce logs. RFC 5321's stock "mailbox unavailable" is used for policy
// refusals too, so it is not here.
const GONE_WORDS = new RegExp(
  "user unknown|unknown user|no such (user|mailbox|recipient)|does not exist" +
    "|doesn't have an? [\\w.-]+ account|mailbox is disabled",
  "i",
);

// 5.1.7 and 5.1.8 are about your own sender address, not the recipient's.
const SENDER_SIDE = new Set(["5.1.7", "5.1.8"]);
// One recipient's own policy rule (Gmail's wording): soft, so the two-bounce rule
// drops it if it repeats. Never when the text is about authentication or reputation.
const RECIPIENT_RULE = /policy that prohibits the email/i;
const ABOUT_SENDER = /spf|dkim|dmarc|authenticat|reputation|block ?list/i;

/** The server's reply. One notice can hold several recipients' lines: use ours. */
function replyText(bounce: Bounce, address: string): string {
  // `message` usually repeats the first diagnostic line, hence the Set.
  const lines = [...new Set([...(bounce.diagnosticCode ?? []), bounce.message ?? ""])];
  const own = lines.filter((line) => line.toLowerCase().includes(address.toLowerCase()));
  // No line names us: use only lines that name nobody, never another recipient's.
  const ours = own.length > 0 ? own : lines.filter((line) => !line.includes("@"));
  return ours.join("\n");
}

/** The RFC 3463 code inside the reply, such as "5.1.1". */
export function enhancedCode(text: string): string | null {
  return ENHANCED.exec(text)?.[1] ?? null;
}

export function classify(bounce: Bounce, address: string): Verdict {
  const text = replyText(bounce, address);
  const code = enhancedCode(text);
  const subject = code?.split(".")[1]; // see the middle-digit table

  if (GONE_UNDER_OTHER_CODES.some((x) => x.code === code && x.words.test(text))) {
    return "bad-address";
  }
  const recipientRule = RECIPIENT_RULE.test(text) && !ABOUT_SENDER.test(text);
  if (subject === "7" && recipientRule) return "soft";
  const aboutAddress =
    bounce.type === "Permanent" && subject !== "7" && !SENDER_SIDE.has(code ?? "");
  if (aboutAddress && (subject === "1" || GONE_WORDS.test(text))) return "bad-address";
  if (SENDER_SIDE.has(code ?? "") || ["5", "6", "7"].includes(subject ?? "")) {
    return "our-problem"; // your sending or your message
  }
  return "soft"; // includes 3 (their mail system) and 4 (routing)
}

/** Call this for each verified email.bounced event. */
export async function onBounce(data: { to: string[]; bounce: Bounce }): Promise<void> {
  // Rasket has already suppressed every Permanent bounce, whatever this decides.
  const permanent = data.bounce.type === "Permanent";

  for (const address of data.to) {
    const reply = replyText(data.bounce, address);
    const code = enhancedCode(reply);
    const verdict = classify(data.bounce, address);
    if (verdict === "our-problem") {
      const lift = permanent ? " (suppressed)" : "";
      await alertTeam(`${address} refused us${lift}: ${reply}`);
    } else if (verdict === "bad-address") {
      await markAddressBad(address); // ask the customer for a new address
    } else {
      await recordSoftBounce(address, code, permanent);
    }
  }
}

const TWO_WEEKS_MS = 14 * 24 * 60 * 60 * 1000;

/** M3AAWG section 2.2: two or more bounces in a row, spread over at least two weeks. */
export async function suppressIfPersistent(
  address: string,
  streak: { count: number; firstAt: Date },
): Promise<void> {
  if (streak.count < 2 || Date.now() - streak.firstAt.getTime() < TWO_WEEKS_MS) return;

  const response = await fetch(`${API}/suppressions`, {
    method: "POST",
    headers: {
      authorization: `Bearer ${process.env.RASKET_API_KEY}`,
      "user-agent": "acme-mailer/1.0",
      "content-type": "application/json",
    },
    body: JSON.stringify({ email: address }),
  });
  if (!response.ok) throw new Error(`suppress failed: ${response.status}`);
}

It does the three jobs the platform cannot. It alerts a person when the refusal is about your sending, including a Transient 4.7.x whose retries ran out: that is a rate or reputation problem, not a soft bounce to count against the address. It marks the address as bad in your own database, so your product can ask the customer for a new one at their next login. And suppressIfPersistent applies the two-weeks rule to soft bounces: call it from recordSoftBounce with the address’s streak, and reset the streak on email.delivered. The permanent flag keeps your records in step with Rasket’s list. Deliveries can arrive twice, so deduplicate on svix-id as the webhooks article shows.