Understanding SMTP error codes and bounces: 4xx, 5xx and what to do
An email bounces, and the message contains a string of numbers that was never written for humans. This guide sorts the codes out: which ones you can ignore because the server handles them itself, and which ones need your attention right away.
4xx or 5xx: temporary or permanent
The first digit determines everything else.
- 4xx means temporary. The receiving server is saying: not right now, try again later. Your server does that automatically, usually over several hours to days. As a rule, you do not need to do anything.
- 5xx means permanent. The recipient will not accept this message, and trying again will not change that. This is where you need to act, either on the address or on your configuration.
The three-digit code is often followed by a second, more detailed one: 5.1.1, 4.7.0 and so on. That one usually tells you more than the three digits before it. And the text after it tells you the most of all, because that is where the large mailbox providers spell out what is actually going on.
One misconception up front: a 5xx does not mean you did something wrong. "Mailbox does not exist" is a 5xx and only means the address is out of date.
Lookup table of the most common codes
| Code | Meaning | What to do |
|---|---|---|
550 5.1.1 | Recipient does not exist | Check the address and remove it from your list. Repeated attempts hurt your domain's reputation. |
550 5.7.1 | Rejected, often due to policy or suspected spam | Read the response text. Often SPF or DKIM is missing, or the content triggered a filter. |
554 5.7.1 | Blocklist, the IP is blocked by the recipient | Find out which list is responsible, fix the cause, request delisting. |
550 5.7.26 | Authentication missing or does not match the sender | Set up SPF and DKIM for the sender domain, check DMARC alignment. |
550 5.7.708 | Traffic from this IP is not accepted | Send through a relay service with a well-maintained reputation instead of a shared hosting IP. |
552 5.2.3 | Message too large | Shrink the attachment or send a link instead. Limits are often between 10 and 25 MB. |
552 5.2.2 | Recipient's mailbox is full | Do nothing. Usually the recipient gets in touch, or it resolves itself. |
421 4.7.0 | Too many connections, throttling | Do nothing, the server will retry. For bulk sending, lower the rate. |
451 4.7.1 | Greylisting, please try again later | Do nothing. The second attempt usually gets through, typically after 5 to 30 minutes. |
452 4.2.2 | Mailbox temporarily full | Do nothing, the server will retry. |
535 5.7.139 | Login rejected, basic authentication disabled | Affects submission, not delivery. See the Microsoft 365 article further down. |
530 5.7.57 | Submitted without authentication | Enter the credentials in the device or application, set encryption to STARTTLS. |
The five cases behind most bounces
550 5.1.1: the address does not exist
By far the most common permanent bounce. The causes are typos, employees who have left and address lists that have been dragged along for years. What matters is what you do about it: these addresses need to come off your list, and quickly. Receiving servers read a high rate of unknown addresses as a sign that someone is working through unmaintained lists, and they downgrade the sender's reputation. A single typo is harmless; a double-digit percentage is a problem.
554 5.7.1: blocklist
Your sending IP address is on a list that the recipient trusts. This happens especially often to servers at large hosting providers, where many customers share one address: it is enough for another customer on the same block to have sent spam. Delisting only helps for good if the cause has been fixed. That is why sending through a service that treats reputation as its job is usually more stable than sending from your own address or the hosting provider's shared one.
421 4.7.0: too many connections
Not an error, but a brake. Large providers limit how many messages they accept from one address in a short period. With newsletters sent from your own mail server, this is the classic case: the first hundred go through, then the gate closes. Your server retries automatically, but delivery drags on. The fix is to spread out the sending and route it through an address the providers already know.
550 5.7.26: authentication does not match
The recipient finds neither valid SPF nor valid DKIM for the sender address, or the domain that was checked does not match the one shown in the inbox. This is purely a configuration problem and can be solved completely, see setting up SPF, DKIM and DMARC. Since the large mailbox providers tightened their requirements, this code has become much more common.
552: the message is too large
Depending on the recipient, limits are between 10 and 35 MB, and they apply after the attachment has been encoded, which makes a file roughly a third larger. So a 20 MB file can fail against a 25 MB limit. For scans and invoices, it pays to lower the resolution or send a link instead of the file.
Bounce rate: when it gets dangerous
As a rule of thumb, hard bounces below one percent are normal. Between one and three percent, you should take a look at your address list. Above that, it gets critical, because receiving servers start treating your valid messages with more suspicion too.
Soft bounces do not count here. They tell you something about the load on the other side, not about the quality of your addresses.
Suppress hard bounces automatically
The most important step is also the most boring one: addresses that were permanently rejected must not be emailed again. If you maintain that by hand, you will forget. That is why sending services keep a suppression list that hard bounces flow into automatically.
For your own application, the rule is simple: if the error is permanent, block the address. If it is temporary, do nothing and check again later. The reason field of the MailBridge API is built on exactly this distinction, with a stable key for each cause that you can code against.
Where to find the codes in MailBridge
In the portal, every submitted message shows its status, and every bounce shows the original response from the receiving server plus a plain-language explanation with a recommended action. The day's bounce rate and the most common reasons of the last seven days are on the dashboard. Details are in the guides to bounces and NDRs and to the log.
If the error message appears when you submit the email rather than when it is delivered, the problem is the login. There is a separate article for the most common case: SMTP relay for Microsoft 365.
Sources and technical background
- RFC 5321: Simple Mail Transfer Protocol, accessed August 28, 2026: the three-digit reply codes and the meaning of 4xx versus 5xx, Section 4.2
- RFC 3463: Enhanced Mail System Status Codes, accessed August 28, 2026: the three-part codes in the form 5.7.1
- RFC 3464: An Extensible Message Format for Delivery Status Notifications, accessed August 28, 2026: structure of the non-delivery report