Email Bounce Codes Explained: 4xx vs 5xx and Enhanced Codes (5.1.1, 5.7.1)

A bounce message (a "Delivery Status Notification" or "Undeliverable" email) is cryptic at first glance, yet it usually contains the exact reason delivery failed, in two layers of codes. Learning to read them turns a vague "my email didn't go through" into a specific fix. This guide explains the structure, then walks through the codes you will see most often and what to do about each.

Two layers of codes

A rejection during the SMTP conversation looks like this:

550 5.1.1 <jane@example.org>: Recipient address rejected: User unknown in virtual mailbox table

• 550 is the basic SMTP reply code (RFC 5321): three digits.
• 5.1.1 is the enhanced status code (RFC 3463): class.subject.detail.
• The text afterward is free-form and set by the receiving server.

When two sources disagree, trust the enhanced code plus the text. Servers choose basic codes loosely, and the explanation text often names the actual rule that fired.

The first digit: temporary versus permanent

A 4xx is not an error you must fix in the first minutes. Servers use it for greylisting, rate limits, temporary load, or a recipient mailbox that is briefly unavailable. Retries often succeed on their own. If a 4xx persists for days, it becomes a bounce, and the cause (often reputation or rate limiting) needs real attention.

A 5xx means the receiver decided the message cannot be delivered as sent. Retrying the same message from the same server will usually fail the same way.

Enhanced code structure

The middle number is the subject, the third the detail:

Common permanent failures (5xx)

550 5.1.1: Recipient address does not exist

The mailbox is not there. Causes: a typo, a person who left, or an alias never created. Fix on the sender's side: correct the address, and remove it from your list if it is a contact you mail repeatedly. Repeatedly sending to nonexistent addresses damages reputation; see email going to spam.

If you are the recipient's admin and the address should exist, check that the mailbox, alias or group was created and that the domain's MX points to the right system (with the MX Lookup).

550 5.1.2: Bad destination system address (domain not found)

The domain after the @ does not resolve, or has no usable MX. Typos in the domain (gmial.com) are the usual cause, but an expired or misconfigured domain also gives this. If it is your recipient's domain and it should work, check DNS with the MX Lookup. If the domain publishes a null MX (see MX records explained), expect a related permanent error such as 5.1.10, meaning the domain does not accept mail.

552 5.2.2: Mailbox full (sometimes 4.2.2)

The recipient's mailbox is over quota. Often temporary and returned as 4.2.2; some servers return it as permanent.

552 5.3.4: Message too big

The message or attachments exceed the recipient server's size limit. Attachments are encoded, which inflates size by about a third, so a 20 MB file can exceed a 25 MB limit once sent. Share a link instead.

550 5.4.1: Recipient address rejected: Access denied

Seen with Microsoft 365 / Exchange Online when the receiving tenant rejects mail for an address that does not exist there (directory-based edge blocking). Treat it like 5.1.1: the address is wrong or not provisioned.

5.4.4: Unable to route

The destination server could not be found or reached, which points to DNS or MX trouble on the receiving side. Check for missing A records on the MX target.

550 5.7.1: Delivery not authorized, message refused

The widest bucket in the whole system: "policy says no". Read the text. Typical reasons:

• Your sending IP is blocklisted. Check the IP in the Blacklist Checker and read the removal guide.
• The receiver rejected your message because of SPF, DKIM or DMARC failure. Test with the Email DNS Checker and the SPF Record Checker.
• The recipient is restricted to internal senders, or you are not on an allowed sender list.
• A content or spam filter flagged the message. The text may include a reference link.
• Relaying is not allowed: you tried to send through a server without authentication.

550 5.7.26 and related: authentication required

Gmail uses 5.7.26 (among other codes) for mail that is unauthenticated, or fails a DMARC policy, typically with text such as "unauthenticated email from example.com is not accepted due to domain's DMARC policy". Fix SPF and DKIM alignment; see the DMARC rollout guide.

550 5.7.25: PTR record missing or mismatched (Gmail)

Gmail rejects mail from IPs without a valid reverse DNS record. Fix the PTR; see reverse DNS for email.

550 5.7.509 (Microsoft)

Exchange Online uses this for mail from a domain with a DMARC policy of reject that the message fails ("Access denied, sending domain does not pass DMARC verification"). Fix the sender's authentication alignment.

554 5.7.1 or 554 Transaction failed

A generic final refusal. Again, read the text for the policy or list name responsible; often it names the blocklist or reputation system.

553 5.1.3: Invalid address syntax, and 5.1.7: bad sender address

The address is malformed, or your envelope sender (the return-path) is invalid or not a real, resolvable domain.

5.6.x: Message content problems

Malformed MIME, bad headers or unsupported media. Check how the message was generated, often by a script or application.

Common temporary failures (4xx)

If your own server is issuing 4xx deferrals to everyone, check disk space, load and your resolver.

Reading a full bounce message

A bounce typically has three parts: a human-readable summary, a machine-readable message/delivery-status section, and the original headers. In the status section look for:

Final-Recipient: rfc822; jane@example.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.org
Diagnostic-Code: smtp; 550 5.1.1 <jane@example.org>: Recipient address rejected: User unknown

Action: failed is permanent; Action: delayed means your server is still retrying. Remote-MTA tells you which server said no, which tells you whose problem it is: if it is the recipient's server, the policy is theirs; if it is your own relay, the problem is nearer to you.

A triage routine

1. Is it 4xx or 5xx? If 4xx, wait and watch.
2. Read the enhanced code and the text.
3. For 5.1.x check the address. For 5.7.x check authentication and blocklists.
4. Send a test through the Email Deliverability Test to see how your message authenticates.
5. Look up the sending address in the IP Lookup if you need to know which server and network actually sent the message.

Next steps

• Check your sending IP with the Blacklist Checker.
• Verify authentication with the Email DNS Checker.
• Run a full test with the Email Deliverability Test.
• Work through the spam diagnostic checklist.

FAQ

What is the difference between a soft bounce and a hard bounce?

A soft bounce is a temporary failure (4xx) such as a full mailbox or greylisting. A hard bounce is a permanent failure (5xx) such as a nonexistent address. Remove hard-bounced addresses from your lists promptly.

Should I retry after a 550 error?

Not the same message to the same address unless you changed something. A 550 is permanent, so fix the cause first: wrong address, blocklist, authentication.

What does 550 5.7.1 mean?

The receiver refused the message for policy reasons. The text usually names the reason: blocklist, SPF/DKIM/DMARC failure, restricted recipient, or relaying denied.

Why did I get a bounce from a server I never sent to?

Likely backscatter caused by someone forging your address, or by a forwarder. Strong SPF, DKIM and DMARC reduce the chance that others can spoof you.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.