Email bounced back: a server refused your message

A mail server between your outbox and the recipient refused your message and sent you a report, called a bounce. One line in that bounce has a three-digit code and a sentence giving the reason. A code that starts with 5 is permanent, and one that starts with 4 means the sending server is still retrying.

Have you been blocked? Usually not. Most bounces are address errors or full mailboxes.

1. Scroll to the bottom of the notice and find the line that starts with 3 digits.
2. Check the first digit. A 5 is permanent, and a 4 means the server is still retrying.
3. Find your code in the table below to see who fixes it.

Where the reason line is

Scroll to the bottom of the notice. Look for a line that starts with 3 digits, followed by a dotted number and a sentence:

That sentence is the reason, and the first digit says how final the refusal is. A 5 means the server stopped for good. A 4 means it is still trying. Those classes come from RFC 3463. It defines a permanent failure as one that "is not likely to be resolved by resending the message in the current form".

Lower down, the notice repeats the same result in labeled fields:

Diagnostic-Code carries the other server's own reply, so it usually repeats the reason line word for word. Read that field first. Action: failed and Action: delayed are the machine-readable form of the same verdict. Those field names come from RFC 3464, so they read the same whichever system sent the notice. The Mail Delivery Subsystem page goes through the fields one by one, and Delivery Status Notification (Failure) covers the subject line itself.

The reason line in Gmail, Outlook and Apple Mail

• Gmail sends the notice from Mail Delivery Subsystem. Google tells you to open it and read the error message inside. For the raw version, click More next to Reply, then Show original.
• Outlook and Microsoft 365 put a plain summary under a Cause heading, with the detail under More info for email admins. Older reports split in two: User information, then Diagnostic information for administrators. That second block shows the server that refused you and quotes its reply. To read the headers in new Outlook or on the web, choose More actions, then View, then View message details. Classic Outlook for Windows keeps them under File, then Properties.
• Apple Mail on a Mac shows the notice as an ordinary message. Apple's Mail User Guide gives the path to the full detail: choose View, then Message, then All Headers.

I copy that line into a note before I close the bounce, along with the address on the Final-Recipient line.

Who fixes each code

Find your code in this table to see who can fix it.

Reason line	Who fixes it	What they do
5.1.1 no such mailbox	The sender	Correct the address, send again
4.2.2 or 5.2.2 out of storage	The recipient	Clear space, or read mail elsewhere
4.x.x other temporary failure	The sending server	It retries, then gives up
5.7.1 spam or a mail rule	The recipient's admin	Allow the sender, or edit the rule
5.7.26 or 5.7.515	The sending domain's admin	Repair the DNS records
Reports for mail you did not send	Nobody stops them arriving	Check Sent, then leave them

Address errors

Gmail returns 550 5.1.1 with the text "The email account that you tried to reach does not exist", and Microsoft's code table lists 5.1.1 as Bad destination mailbox address. Microsoft also returns 5.4.1 with "Recipient address rejected: Access denied", which the same table explains as an address that does not exist.

Compare the address in the Final-Recipient line against the one you meant to type. Check the domain as carefully as the name, because a wrong domain still resolves and still bounces. If the address used to work, the person may have left, or an admin deleted the mailbox. Microsoft gives one more cause inside a single company: a mailbox that moved while Outlook's recipient cache kept the old address. Microsoft's fix is to remove that address from the sender's Outlook cache and start a new message. Resending the original one fails the same way.

The sender corrects this one. No admin on either side can fix it.

Full mailboxes

Gmail returns 452 4.2.2 with "The recipient's inbox is out of storage space", which is temporary, and 552 5.2.2 with "The recipient's inbox is out of storage space and inactive", which is not. Google tells the sender to ask the person to clear space in their account storage before they can receive new mail.

Only the recipient can clear it. Reach them another way, such as a phone call, and tell them. Sending again won't clear it.

An out-of-office reply looks like a bounce in a busy inbox. RFC 3834 treats them as different things. Delivery status notices report on a delivery. An "out of office" or "vacation" notice tells the sender that the message is unlikely to be read for some amount of time. It carries no status code.

4xx delays

A code starting with 4 means the receiving server said "not now". RFC 3463 defines that class next to the permanent one quoted above. The message as sent is valid, and a temporary condition delayed it. The sending server keeps the message queued and tries again on a schedule its operator sets.

Exchange Online "repeatedly tries to deliver the message over 24 hours", and only after those 24 hours does the sender get a 550 4.4.7 QUEUE.Expired; message expired report. A delay notice before then leaves the message in the queue.

So when you get a delay notice, wait. Resending puts a second copy in the same queue, and the recipient gets both copies once the receiving server accepts them. If a delay turns into a failure a day later, treat the failure as the real event and start again at the reason line. Gmail's rate-limit version is 421-4.7.28, which the sending server retries.

5xx blocks

When a 5xx bounce says nothing about the address, the receiver refused the message under a policy, and the sentence beside the code says which one. If your notice says the message was blocked, the line underneath it gives the cause. Message blocked has the fixes for that notice.

• Spam scoring. Gmail returns 550 5.7.1 with "This message is likely unsolicited email". The content, the links or the sending IP triggered a filter.
• A blocked sending IP. Microsoft has 2 forms of this, and each one has its own fix. 550 5.7.606-649 Access denied, banned sending IP goes through the Office 365 Anti-Spam IP Delist Portal at https://sender.office.com. Microsoft's delist portal documentation says that portal doesn't work for 550 5.7.511 Access denied, banned sender. Forward that report to delist@microsoft.com with the full code and IP. Microsoft says it contacts you within 48 hours with the next steps.
• A rule on the receiving side. Microsoft's 5.7.1 also covers "Delivery not authorized". A distribution list or a transport rule returns that when it refuses your message, and only the recipient's admin can change it.
• Authentication. Gmail prints 550-5.7.26 in two versions: one says the sender is unauthenticated, and the other says the mail "is not accepted due to domain's DMARC policy". Microsoft returns 550 5.7.515 when a bulk sender misses its requirements. These are the ones you can fix from your own DNS.

A block aimed at your domain or your sending IP applies to every message you send to that receiver. You're also the only person who hears about it. The notice goes to the sender, and nobody tells the recipients that their copy was refused. You find out when one of them asks why you never replied.

Authentication rejections say which check failed, or say the sender is unauthenticated. Start with 550-5.7.26, which explains Gmail's two versions, and 550 5.7.515 for the Microsoft form. When the error quotes your own policy back at you, DMARC fail with p=reject explains what receivers do under your policy.

Our SPF, DKIM and DMARC checker reads all three records live with no signup, and it counts the SPF lookups against the limit of 10. Add a selector if you want the DKIM leg. It reads your DNS, so it shows you the rules that receivers apply to your mail.

Bounces for mail you didn't send

Check your Sent folder for the original message before you assume someone broke into your account.

Delivery reports go to the envelope sender, which is a separate address from the one your reader sees. Section 6.1 of RFC 5321 is explicit about it. The notice goes to "the address from the envelope return path (or the Return-Path: line)". A spammer who forges your address in that field sends every resulting report to you. Spamhaus calls the result backscatter: "incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam".

When Sent holds no matching message and you do not recognize the attached original, somebody forged your address in the envelope, and your account is not the source. The Mail Delivery Subsystem page has the longer version of this check, including what a p=reject policy does and does not stop.

Hard bounce vs soft bounce

Hard and soft are labels that sending platforms use. SMTP doesn't use them. Amazon SES defines a hard bounce as "a persistent email delivery failure. For example, the mailbox does not exist", and a soft bounce as "a temporary email delivery failure. For example, the mailbox is full". SES retries soft bounces and does not retry hard bounces.

Platforms usually go by the first digit of the status code. A 4 is a soft bounce, and a 5 is normally a hard one. Gmail's full-mailbox code is the exception. 552 5.2.2 starts with 5, and most platforms still treat it as soft. Mailchimp says providers bounce messages "based on their own rating systems and definitions". Mailchimp allows 7 soft bounces for an address with no subscriber activity, and up to 15 for a contact with past activity. After that, the soft bounce becomes a hard one.

A platform stops mailing an address once it passes those counts. For a single message from your own mailbox, read the code and act on it.

Free checks

Google's Admin Toolbox Check MX reads MX and SPF records for a domain. Microsoft's Remote Connectivity Analyzer runs an Outbound SMTP Email test, and Microsoft's own bounce pages point admins at it.

For reputation problems at Gmail, Google Postmaster Tools is free and covers the mail you send to personal Gmail accounts. Google hides a day's numbers when the message count for that day is too low, to protect the privacy of individual users. Add the domain before you need the data.

A bounce covers one message on one day. Receivers already send a report for your domain listing every server that sent as your domain, usually one file a day each, in XML. These DMARC aggregate reports show every sender at once. Cloudflare's DMARC Management lists each sending source and whether it passed. Cloudflare offers it on every plan to a domain that uses Cloudflare DNS. Postmark's DMARC Digests mail one summary a week. When I last checked, the free tier listed the top 10 mail sources with 5 IPs each and kept 7 days.

We built DomainCanary to read those reports for you. Your reason line pointed at one sender, and the next one can break on any day. On a paid plan, we mail you when that failing report arrives, so you hear about a new failing source on the day we see it. You don't wait for the following Monday's digest. You can tell us to hold the digest on a week with nothing wrong. We record it on the dashboard instead, and after 8 held weeks we send the next clean digest anyway. Your first domain is free, and the realtime alerts come with the Starter plan, at $19 a month for 3 domains. An aggregate report counts messages by sending IP and never carries a bounce notice, so we can't read the bounce you have open.