Email bounce codes explained: hard, soft and policy rejections

A bounce is the receiving server refusing your message, and its codes tell you what went wrong: the address, the recipient's mailbox, your sending rate, or your authentication and reputation. Each needs a different response. Removing a subscriber because Gmail throttled you loses a good address, and resending to an address that doesn't exist tells the receiver your list is stale. Read the code before you act.

How to read a bounce

A bounce line from Gmail looks like this:

550 5.1.1 The email account that you tried to reach does not exist.

It has three parts:

• 550 is the SMTP reply code from RFC 5321. A 4xx reply is a transient failure: the condition is temporary and the sending server should try again. A 5xx reply is permanent: the sending server should not repeat the same request.
• 5.1.1 is the enhanced status code from RFC 3463, written as class.subject.detail. The class repeats the severity (4 for a persistent transient failure, 5 for a permanent one), and the subject says where the problem is.
• The text is the receiver's own explanation. Gmail documents its variants in its SMTP error reference, and one code can cover several unrelated problems, so read it.

The subject digit, as RFC 3463 defines it:

• X.1 addressing: the address itself, such as a mailbox that doesn't exist.
• X.2 mailbox: the mailbox exists but is full or disabled.
• X.3 mail system: something at the destination system.
• X.4 network and routing: DNS, routing, or the message expiring before delivery.
• X.5 mail delivery protocol.
• X.6 message content or media.
• X.7 security or policy: authentication, reputation, rate limits and filtering.

Hard bounces, soft bounces and policy rejections

Most tools sort bounces into hard and soft. A third group, policy rejections, needs its own handling.

• A hard bounce is a permanent failure about the address. It doesn't exist or has been disabled, and it will fail every time.
• A soft bounce is a temporary problem at the recipient's end, like a full mailbox. A later attempt can succeed.
• A policy rejection is the receiver refusing your message or your sending pattern. The address is usually fine. These are mostly X.7 codes and arrive as 4xx (deferred or throttled) or 5xx (blocked).

A 550 5.7.1 is final for that message and says nothing bad about the address. Treat policy rejections as hard bounces and you delete real subscribers. Treat them as soft bounces and keep resending, and you add volume to a sender the receiver is already pushing back on.

Remove the address

These say the address can't receive mail:

• 550 5.1.1: at Gmail, the account doesn't exist. RFC 3463 defines X.1.1 as a mailbox that does not exist.
• 550 5.2.1: at Gmail, the account is inactive.
• 552 5.2.2: at Gmail, the inbox is out of storage and inactive. That is an abandoned mailbox, unlike the temporary 452 4.2.2 below.
• 553 5.1.2: at Gmail, the recipient's domain wasn't found, often a typo such as gmial.com.
• 553 5.1.3: the address isn't valid under RFC 5321.

Stop mailing these addresses. Microsoft's Outlook.com policies say a sender must stop trying a recipient after multiple non-delivery responses. A batch of unknown-user bounces usually means part of the list is old or wasn't collected with consent; see email list hygiene. Correct a typo only when the person confirms the address.

Retry later

These are temporary problems at the receiving end:

• 452 4.2.2: the recipient's inbox is out of storage. RFC 3463 says a full mailbox should be reported as a persistent transient failure.
• 450 4.2.1: the recipient is receiving mail too quickly.
• 421 4.3.0 or 451 4.3.0: a temporary problem at the receiving server.
• 451 4.7.26: Gmail couldn't finish authentication checks because of temporary DNS errors. Retry, and make sure your DNS host answers reliably.

Your mail server or email provider retries these with backoff, so you don't resend by hand. Yahoo's error code guide says the same about its 421 and 451 replies. If one address soft-bounces on send after send and never gets a delivery, treat it as dead.

Slow down

These mean the receiver thinks you're sending too much, too fast, for your history:

• 421 4.7.28: Gmail has detected an unusual rate of email, or of unsolicited email, from your IP address or netblock, your DKIM or SPF domain, or a domain linked in the message.
• 550 5.7.28: an unusual rate of unsolicited email from your IP address, and the message is blocked.
• Yahoo deferrals with a TS code: temporary, often caused by complaints, spam-like content, poor IP reputation or unusual traffic.

Gmail's sender guidelines say that when you exceed your quota, Gmail typically rejects with 4.7.28, and give this procedure for mail server operators:

1. Stop sending for at least 10 minutes.
2. Resume from a single connection.
3. If that connection fails, wait another 10 minutes.
4. If it succeeds, add connections one at a time.

The same page says to reduce volume when messages start bouncing or being deferred, until the error rate drops. On a shared email provider you don't control connections, but you control volume: pause the campaign and send the rest over the following days, starting with your most engaged recipients. Don't start a second campaign while the first is being deferred. Retries and new sends both add to the rate Gmail is reacting to, and deferrals can turn into 550 5.7.1 rejections. See how to warm up a new sending domain and how often to send marketing email.

Fix authentication

Resending never clears these. Fix the DNS record, then check the headers of a test message:

• 550 5.7.26: the message is unauthenticated, hits an SPF hard fail (-all) for the sending IP, or fails the From domain's DMARC policy.
• 421 4.7.26: rate limited because the message is unauthenticated.
• 421 4.7.27 or 550 5.7.27: SPF didn't pass.
• 421 4.7.30 or 550 5.7.30: DKIM didn't pass.
• 421 4.7.32: the From: header isn't aligned with the SPF or DKIM domain.
• 421 4.7.40 or 550 5.7.40: the sending domain has no DMARC record or policy.
• 550 5.7.25 or 451 4.7.23: the sending IP has no PTR record, or the PTR and forward DNS don't match.
• 421 4.7.29 or 550 5.7.29: the message wasn't sent over TLS.
• 550 5.7.515 from Outlook.com: the sending domain doesn't meet the authentication level Microsoft requires of high-volume senders.

PTR and TLS belong to the sending server, so on an email provider, report them to the provider. The rest are DNS records on your domain. Query them directly:

dig TXT send.example.com +short                # SPF, on your return-path domain
dig TXT selector._domainkey.example.com +short # DKIM, with your selector
dig TXT _dmarc.example.com +short              # DMARC

For fixes, see SPF record not found, DKIM verification failing and Gmail, Yahoo and Microsoft bulk sender requirements.

Stop and fix the cause

These are reputation and content blocks:

• 550 5.7.1 saying the message is likely unsolicited: Gmail blocked it as probable spam.
• 550 5.7.1 or 421 4.7.0 citing the very low reputation of your sending IP or domain.
• 421 4.7.0 for suspicious content or links.
• Yahoo PH codes: content blocked for policy reasons such as malware or phishing links. Yahoo says not to retry a 553 or 554.

Resending the same message gets the same answer. Pause sending and work through the likely causes: imported, old or never-confirmed addresses that draw complaints, your spam rate and domain reputation in Postmaster Tools, volume well above your recent history, and links through shorteners or domains with a poor reputation. Keep the addresses; the block is about the sender and the message. See how to recover a damaged sender reputation and email copy that hurts deliverability.

How Unitpost handles bounces

Hard bounces and spam complaints add the address to your workspace's suppression list automatically. The list is enforced on every send (single, batch and campaign), including CC and BCC, and suppressed recipients are excluded from the send instead of failing it. Complaint suppressions can't be removed self-serve. A single soft bounce doesn't suppress the address or count as a hard bounce, and a policy refusal (a 5.7.x block) never suppresses it. As the docs describe, three soft bounces in a row do suppress it, and so does one from a domain that doesn't exist or accepts no mail.

Your webhooks get email.delivery_delayed while delivery is still being retried and email.bounced once it's final, with bounce.type set to Permanent or Transient and the receiver's reply in bounce.diagnostic_code. Match on the SMTP codes there. If a campaign's hard bounces or complaints climb past a safe line while it sends, Unitpost pauses that campaign and tells you why.