Bounce Back Emails: What the Message Means and How to Fix It

A bounce-back is an automated message from a mail server saying your email was not delivered. The useful part is the status code, such as 550 5.1.1, and the diagnostic text next to it. Codes starting with 5 are permanent failures. Codes starting with 4 are temporary, and the sending server may still retry. Fix the cause the code names, then resend.

Gmail sends these from “Mail Delivery Subsystem” ([email protected]), usually with the subject “Delivery Status Notification (Failure)”, according to Gmail Help’s Fix bounced or rejected emails page. Other providers use different senders and subjects, but the structure underneath is the same, and it is standardized.

This guide covers how to read the message, what the common codes mean, how to fix each cause, and what to do if your app generates bounces at volume. For sorting bounces into categories, see soft bounce vs hard bounce.

What is inside a bounce-back message

A bounce-back is a Delivery Status Notification (DSN). RFC 3464 defines it as a multipart/report message with three parts:

1. A human-readable explanation (text/plain), which is what you see in your inbox.
2. A machine-readable message/delivery-status part, which is what software parses.
3. Optionally, the original message or its headers (message/rfc822).

The machine-readable part carries the fields that matter. Reporting-MTA is required and names the server that is reporting the result. Each failed recipient gets a Final-Recipient, an Action (failed, delayed, delivered, relayed or expanded), and a Status code. Remote-MTA and Diagnostic-Code are optional but usually present, and the diagnostic code holds the receiving server’s own words.

Here is an illustrative example, written with reserved example domains and documentation IP addresses (RFC 5737):

Subject: Delivery Status Notification (Failure)
From: Mail Delivery Subsystem <[email protected]>

Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.net
Arrival-Date: Tue, 29 Sep 2026 10:12:44 +0000

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com (192.0.2.25)
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to
  reach does not exist.

Read it from the bottom up. Action: failed means the server gave up. Status: 5.1.1 is the enhanced code. Diagnostic-Code shows what the remote server said, and Remote-MTA shows which server said it. The rejection came from example.com‘s server, not from the one that generated the message, so the fix lives on the recipient side of the address.

If the bounce includes the original message headers, they show the path the message took and where it was refused. See how to read email headers.

How to read the status code

Two code systems appear side by side. The three-digit SMTP reply code (550) comes from RFC 5321. Its first digit tells you the outcome: 2yz is success, 4yz is a transient failure where “the SMTP client SHOULD try again”, and 5yz is permanent.

The enhanced status code (5.1.1) comes from RFC 3463 and follows the pattern class.subject.detail.

Part	Values	Meaning
Class	2	Success
	4	Persistent transient failure: the message is valid, but a temporary condition caused delay or abandonment
	5	Permanent failure
Subject	X.0	Other or undefined
	X.1	Addressing
	X.2	Mailbox
	X.3	Mail system
	X.4	Network and routing
	X.5	Mail delivery protocol
	X.6	Message content or media
	X.7	Security or policy

So 5.1.1 reads as: permanent failure, addressing problem, detail 1 (the mailbox does not exist). Read the subject digit first, and it tells you which side of the problem to look at.

Common bounce codes and what to do about them

Every row below is taken from RFC 3463, Google’s Gmail SMTP error reference, or Microsoft’s Exchange Online NDR documentation.

Code	What it means	Typical cause	Fix
5.1.1	Bad destination mailbox address. RFC 3463: the address to the left of the “@” is invalid	Typo, or the account was removed	Check spelling and spaces, confirm the current address, remove it from your list
5.1.2	Bad destination system address. RFC 3463: the part to the right of the “@” is invalid for mail	Misspelled domain, or a domain that does not accept mail	Fix the domain, then check the domain’s MX record if it is spelled correctly
5.1.10 (Microsoft)	Recipient not found. The SMTP address lookup found no such recipient	Address does not exist in that Microsoft tenant	Verify the address with the recipient
552 5.2.2 (Google)	The recipient’s inbox is out of storage space	Full mailbox	Ask the recipient to free space, or retry later
5.3.4	Message too big for system. RFC 3463: the message exceeds a per-message size limit	Large attachment	Shrink or link the file, then resend
5.7.1	Delivery not authorized, message refused. RFC 3463: the sender is not authorized to send to the destination	Per-host or per-recipient filtering, a restricted distribution group, or a mail rule	Ask the recipient to allow you, or check the diagnostic text for the rule that fired
550 5.7.26 (Google)	Blocked because the sender is unauthenticated. Gmail requires SPF or DKIM	Missing or failing SPF/DKIM, or a DMARC policy failure	Fix authentication (see below)
550 5.7.515 (Microsoft)	Sending domain does not meet the required authentication level	High-volume sender failing SPF, DKIM or DMARC	Publish and align all three (see below)
4.4.7	Delivery time expired (RFC 3463); “Message expired” in Exchange Online	The queue timed out before the receiving server accepted the message	Check the recipient’s address and mail server, then resend
550 (any 5.x.x)	Permanent failure at the SMTP level; the enhanced code names the reason	Varies	See SMTP error 550

Two caveats. First, providers reuse enhanced codes with their own meaning. Exchange Online documents 5.2.2 as “Submission quota exceeded”, meaning the sender hit a rate limit, while Google uses 552 5.2.2 for a full inbox. Always read the diagnostic text, not just the digits. Second, the digits give you the category, but the text names the specific rule that fired.

Fixes by cause

Wrong or nonexistent address. Look for 5.1.1, 5.1.10 or “account does not exist”. Gmail Help suggests checking spelling, removing quotation marks, trailing dots and spaces, and confirming the contact’s current address. Resending the same address will fail the same way.

Recipient domain cannot receive mail. Look for 5.1.2 or “we weren’t able to find the recipient domain”. Google’s reference says to check for spelling errors and stray punctuation after the address. If the domain is correct, its DNS may be missing or misconfigured MX records.

Full mailbox. Look for 5.2.2 with “out of storage” text. Only the recipient can fix this. Resending later works once they free space.

Message too large. Look for 5.3.4 or a size-limit message. Google states the message “exceeded Google’s message size limits”. Compress the attachment or share a link instead.

Blocked by policy or reputation. Look for 5.7.1 with wording about unsolicited mail or policy. Read the diagnostic text for the named rule or blocklist. If your own domain is the one blocked, work on your sender reputation and review email deliverability practices before sending again.

Authentication failure. Look for 5.7.26 at Gmail or 5.7.515 at Outlook.com. Google says Gmail “requires all senders to authenticate with either SPF or DKIM”. Microsoft says that senders of 5,000 or more messages to its consumer services must publish SPF and DKIM records and a DMARC record, and pass DMARC through SPF or DKIM alignment. Set up SPF, DKIM, and DMARC, send a test, and confirm the results before resuming volume.

Rate limiting or temporary deferral. Look for a 4xx code. Google documents 450 4.2.1 for a recipient “receiving email too quickly” and says to resend later. Slow down and let the retry queue do its work.

How long servers retry before bouncing

A 4xx code does not always end quietly. RFC 5321 section 4.5.4.1 says a sending server “MUST delay retrying a particular destination after one attempt has failed”, that the retry interval “SHOULD be at least 30 minutes”, and that “the give-up time generally needs to be at least 4-5 days”.

In practice, a message that keeps getting deferred can turn into a bounce days later with 4.4.7, “delivery time expired”. Exchange Online lists that code as “Message expired”. Servers you do not control set their own limits, so treat the 4 to 5 days as guidance, not a guarantee.

Bounce-backs for emails you never sent

If you receive bounce messages for mail you did not send, the likely explanation is backscatter. Someone forged your address as the sender, and the receiving server accepted the message, then bounced it to the address on the envelope. That address is yours.

RFC 5321 explains why the bounce goes to you: the reverse-path “MUST be used as the target of any mail containing delivery error messages”. Microsoft’s own NDR documentation notes that “the sender’s email address might be forged, and the resulting NDR could have been sent to the unsuspecting sender’s email address.”

You cannot fully stop other servers from bouncing to you, but you can reduce it:

• Publish SPF, DKIM, and DMARC and move DMARC to enforcement once your legitimate senders pass, so receivers reject forged mail instead of accepting and bouncing it.
• Run your own mail server so that it rejects bad recipients during the SMTP conversation rather than accepting and bouncing later, which is how Wikipedia describes the standard mitigation.
• Do not click links or open attachments in unexpected bounces. A real DSN has no reason to ask you to log in.

If your app or campaigns get bounces at volume

Bounces return to the Return-Path (envelope sender) address, not the visible From address. RFC 5321 describes the Return-path as “the address to which messages indicating non-delivery or other mail system failures are to be sent.” When you send through an email service provider, it owns that address, parses the DSNs and turns them into events.

What to do with those events:

1. Subscribe to bounce webhooks so your app hears about failures as they happen. Postmark, for example, describes a bounce webhook as pushing “a JSON event to your application right after Postmark processes the bounce report.”
2. Suppress hard-bounced addresses. Postmark’s documentation calls a hard bounce address “invalid and should be suppressed from receiving further emails” and warns that “Sending to hard-bounced addresses will hurt your sending reputation!”
3. Track your bounce rate per campaign and per source, so a bad list stands out.
4. When a signup address bounces, prompt the user to correct it instead of silently dropping them.

Frequently Asked Questions