Why did that email bounce?

Every so often a customer forwards a bounce message to Momentum Hosting with three words: “please fix this.” Sometimes the customer does not bother to explain what they were trying to do. The bounce message is attached, and the assumption is that we can take it from there. And usually we can. But the more useful conversation would start earlier, with the customer having read the bounce, because in almost every case the answer is already inside it.

An email bounces when the recipient’s mail server refuses to accept it and returns a numeric response code with an explanation. Every bounce message contains three things: the recipient address that was tried, the response code (4xx for temporary, 5xx for permanent), and a short plain-English reason. Seven common causes account for almost every 5xx bounce a small business will see: a typo in the recipient address, the recipient’s domain not existing, the mailbox being full, the message being too large for the recipient’s server to accept, the recipient’s server rejecting the sending IP for reputation reasons, the sending domain failing SPF, DKIM or DMARC authentication, or the recipient’s content filter scoring the message as spam. Reading the code and the reason identifies the category in seconds.

An SMTP bounce message is a diagnosis, not a symptom. The receiving mail server told the sending server exactly why the message was refused, and the sending server forwarded that answer to the sender’s inbox.

The pattern before the phone call

One email fails, and there is a moment of surprise but no story yet. Two emails fail in a day and the story starts to form: something is off. Three emails fail in a week and the story is fully written. “My email has been playing up lately.” The next thing that happens is a phone call or a ticket, forwarded bounce attached, and the sentence “can you fix this?”

The bounce that arrived after the first failure explained precisely what happened. So did the second. What the customer is really reporting is not that email has been playing up. It is that two specific messages went to two specific recipients and were refused for two specific reasons, and the pattern of feelings is easier to notice than the pattern of causes.

A bounce is a structured diagnostic, not a symptom

Email delivery over SMTP (RFC 5321) is a conversation. When one mail server tries to hand a message to another, the receiving server replies with a numeric code and a short explanation. If it accepts, the code is in the 200s and the sender never sees the exchange. If it defers, 400s. If it refuses, 500s. Either of the latter two produces the bounce report that lands back in the sender’s inbox.

The report is structured. It always contains the recipient address that was tried, the numeric response code, and the receiving server’s explanation. Depending on the mail client showing the report, some of that gets buried under generic wording, but the specific reason is always there if you look for it.

The problem is not that bounces are opaque. It is that they arrive in moments of frustration, and the human response to a frustrating message in the inbox is to close it and escalate.

4xx or 5xx: temporary or permanent

The most important single distinction is the response code’s leading digit. Temporary (4xx) and permanent (5xx) bounces are different problems with different remedies, and treating them the same is where a lot of the confusion starts.

4xx codes are temporary. The receiving server is deferring the message for a reason it considers survivable. The sending mail server will normally retry for a period, then eventually give up if the same response keeps coming back. Common causes: recipient mailbox temporarily unavailable, recipient server under load, greylisting (a first-time-seen sender told to try again shortly), or rate limiting (421 4.7.0) after too many messages in too short a period. Most 4xx cases resolve on retry without action. A 4xx bounce that reaches the sender’s inbox usually means the retry period expired without success, which quietly means the situation was less transient than the code suggested.

5xx codes are permanent. The receiving server is refusing the message and telling the sender not to bother trying again as sent. Something about the address, the sender, or the message itself has to change first.

The pair to remember: 452 4.2.2 versus 552 5.2.2. Both say “mailbox is full”. The first is temporary: the receiving server is telling the sending server to try again later, and the sending server will. The second is permanent: the mailbox has been full long enough that the receiving server has stopped bothering to defer. The RFC 3463 enhanced status code (the second number set, X.2.2) is identical in both cases; the leading class digit (4 or 5) is what changes the remediation. This distinction is one of the most commonly missed.

What each 5xx bounce code actually means

Almost every 5xx bounce a small business will ever see falls into one of seven categories. What follows is a working field guide, not a reference manual, so the codes shown are generic examples of the common patterns rather than an exhaustive list. Verbatim example strings are drawn from Gmail’s SMTP error reference; other providers use similar wording.

Code	What the server is saying	Verbatim example (Gmail)	Who has to do what
550 5.1.1	Recipient address does not exist at that domain.	The email account that you tried to reach does not exist	Sender: check for a typo.
553 5.1.2	Recipient’s domain does not exist.	We weren't able to find the recipient domain	Sender: check the domain.
552 5.2.2	Recipient’s mailbox is permanently over quota.	The recipient's inbox is out of storage space and inactive	Recipient: clear space. Sender: contact by other means.
552 5.3.4	Message exceeds the receiving system’s size limit (Gmail caps at 25 MB).	Your message exceeded Google's message size limits	Sender: send the file another way. See Mail is not freight.
550 5.7.1	Sending IP is rejected, usually because it appears on a blocklist the receiving server consults.	This message is likely unsolicited email	Sending IP operator: understand why and address the cause.
550 5.7.26	Sending domain failed SPF, DKIM or DMARC alignment.	Unauthenticated email from ... is not accepted due to domain's DMARC policy	Sender’s admin: fix alignment (usually SPF or DNS).
550 5.7.x	Recipient’s content filter (Proofpoint, Mimecast, Barracuda etc.) rejected the message on category or scoring rules.	Varies by filter.	Situational: sender changes something, or recipient whitelists the sender.

The two typo cases (5.1.1 and 5.1.2) are the most common cause of “my email is broken”. They are also the fastest to diagnose. If the bounce says the recipient does not exist, it is almost always right, and the fix is to look at the recipient’s address one more time. If the recipient does exist and the address is spelled correctly, that specific bounce means someone at the recipient’s end changed something and did not tell the sender.

The 2024 bulk sender rules

One of the 5xx categories in the table (5.7.26) traces to a policy change that took effect in early 2024 and has expanded since. The provider-specific equivalent used by Microsoft (5.7.515, shown further down in this section) shares the same underlying rules. Yahoo enforces the same authentication requirements but does not publish a specific enhanced status code in its public error-codes reference. It is worth understanding on its own terms because the mechanism catches a lot of small senders who never thought of themselves as bulk.

As at September 2026, the three largest recipient providers all enforce sender-authentication requirements on high-volume senders. Google and Microsoft each define “bulk” as more than 5,000 messages per day to their users; Yahoo enforces the same underlying requirements on bulk senders but explicitly declines to publish a numerical volume threshold. Google and Yahoo announced their rules in October 2023 and enforced them from 1 February 2024. Microsoft announced its equivalent in April 2025 and began enforcing from 5 May 2025.

The requirements are consistent across the three providers:

• Both SPF and DKIM authentication must pass on outbound mail, and the From: header domain must align with one of them for DMARC purposes.
• A DMARC record must exist on the sending domain. The policy can be p=none, but the record must be present.
• Marketing and bulk messages must carry a working one-click unsubscribe header conforming to RFC 8058.
• The spam-complaint rate, measured in Google’s Postmaster Tools, must stay below 0.3% (Google’s hard ceiling), with 0.1% as the stated target.

Failing any of these produces a provider-specific rejection code:

• Gmail: 550 5.7.26 for authentication or DMARC failures.
• Microsoft (Outlook.com, Hotmail): 550 5.7.515.
• Yahoo: returns a 5xx authentication-failure rejection but does not publish a specific enhanced status code in its public error-codes reference. Third-party deliverability sources commonly report 5.7.9 for this case; it is not confirmed by Yahoo’s own documentation.

The threshold applies to the sending domain, not the sender’s server. A customer sending 6,000 messages a day through a plugin from their WordPress site is subject to the same rules as a marketing platform sending from its own infrastructure. The threshold does not care that the customer had no idea their form-to-mail plugin counted as bulk. Primary references: Google’s Email sender guidelines, Yahoo’s sender best practices, and Microsoft’s April 2025 announcement of Outlook’s new requirements for high-volume senders.

”My mail server is down” is a different signal

None of the seven 5xx categories in the table mean “your host’s mail server is broken”. A broken mail server does not produce bounces. It produces silence: the message goes into the outbound queue and stays there because there is no server to hand it to. When your mail server itself has failed, you will notice because no mail moves, not because this mail bounced.

A bounce, by definition, means the conversation happened. Your mail server reached the other side, spoke to it, and was told no. The accusation “my host is broken” almost never fits a bounce, because if the host were broken there would be nothing to bounce.

What can be true is that a specific bounce is an RBL or alignment case that involves the shared sending infrastructure. Those cases are worth understanding because they are the ones that produce the most confusion.

How a shared IP ends up on a blocklist

A shared IP address is used by many customers to send mail. Its reputation, as far as the internet is concerned, is a running average of the sending behaviour of everyone on it. Blocklists like Spamhaus and Barracuda, and the internal reputation systems of Gmail and Microsoft, do not put IPs on their lists at random. They put IPs on their lists because something coming out of those IPs matched a pattern that they classify as abuse.

The pattern is usually one of a small number of things.

• A customer’s mailbox has been compromised, and is being used by an attacker to send spam or phishing. The attacker’s traffic goes through the shared IP, matches abuse signatures, and the IP starts to be marked.
• A customer has set up a bulk-email service through Momentum Hosting’s SMTP: a newsletter platform, a marketing automation stack, or any other service whose primary purpose is generating large-volume outbound mail. Bulk email through the shared infrastructure is prohibited under AUP-14, regardless of whether the operator claims recipient consent or the sending stack is technically RFC-compliant. Customers with a legitimate bulk-sending requirement should use a dedicated bulk-mail platform such as Mailchimp, Postmark or SendGrid, whose infrastructure and reputation sit separate from the shared IPs.
• A CRM sending through Momentum Hosting’s SMTP is generating non-transactional mail. Under AUP-15, CRM traffic is permitted only where every message is transactional and the sender can demonstrate an existing business relationship with the recipient. A CRM sending cold outreach or prospecting is not permitted use, and its traffic pattern will match bulk marketing at the receiving end.
• A form-to-email plugin on a customer’s site is generating “thank you for your enquiry” auto-replies to every submission. Momentum Hosting prohibits auto-reply forms under AUP-16, because a scripted submitter with a spoofed sender address turns the form into a spam vector: every submission triggers an unsolicited email from a shared IP to whichever mailbox the attacker chose. The visible confirmation to the submitter must be a page redirect or on-page message, not a mail-out.
• A forwarder is leaking spam through the IP: a customer’s mailbox is set to forward incoming mail to another address, and spam that arrives at the customer is being re-sent by the shared mail server, from Momentum Hosting’s outbound IP, to Gmail, where it is scored as though the message originated with us. This pattern is visible in DMARC aggregate reports the day it starts happening.

None of these are the shared IP going bad on its own. Every one is a specific behaviour originating from a specific account that provokes the reaction. When it happens, Momentum Hosting’s job is to find the source and stop the behaviour so that the IP reputation recovers.

A customer whose outbound deliverability had been degrading for approximately four months, in a pattern that pointed strongly at their sending, was moved onto a dedicated IP of their own to isolate the effect. Within about two weeks the dedicated IP was listed on Spamhaus SBL and two other public reputation feeds. The isolation experiment answered the question: the sending behaviour, not the shared environment, was the cause. The customer then had a concrete, actionable problem to fix rather than a general feeling that email was broken, and once fixed the deliverability came back.

That specific experience is not universal. Sometimes the source is a compromised account, sometimes a misconfigured forwarder, sometimes a plugin nobody remembers installing. But the mechanism is always the same. An IP that recipients treat as bad is being treated that way because of a specific pattern coming out of it, and finding the source is where the resolution has to happen.

What Momentum Hosting does about blocklist entries

Momentum Hosting operates a fleet-wide DMARC observability tool called Provenly, which ingests DMARC aggregate reports from every domain the shared mail infrastructure sends for. Rather than waiting for the first customer to notice a delivery problem and phone in, we watch the reports every day. When a customer domain starts sending from an unexpected IP, we see it. When authentication starts failing on outbound mail, we see it. When volume on a specific domain breaks from its normal pattern, we see it. Most reputation problems announce themselves in the DMARC data days before they translate into blocklist entries.

When the entries do happen, delisting is Momentum Hosting’s work. We know the process for each of the major blocklists and have the documentation ready to submit. When the cause is a specific customer’s behaviour, that conversation happens directly. Both halves of the response happen without the customer having to notice first. There is a fuller account of the DMARC tool in a previous piece.

What to do when a bounce lands in your inbox

Read the code. It is always in the message somewhere, usually in the first line after “the following addresses had permanent errors” or a similar phrase.

Categorise. Look at the first three digits and the enhanced status code (the second number set, like 5.7.1).

Act.

• If it is a typo case (5.1.1 or 5.1.2), correct the address and resend. If the address looks correct, contact the recipient by another channel and confirm it with them.
• If it is a mailbox-full case (5.2.2), you cannot resend that message until the recipient clears space. Contact them another way and let them know.
• If it is a message-too-big case (5.3.4), send the file another way. Read Mail is not freight for the pattern.
• If it is a blocklist case (5.7.1), forward the whole bounce to Momentum Hosting. Include the recipient address. We will look at whether the block is against the sending IP or against your domain, whether it applies to just that recipient or is broader, and what has to happen to fix it.
• If it is an alignment case (5.7.26 for Gmail, 5.7.515 for Microsoft, or the equivalent 5.7.x auth-failure code from another provider), the same. Usually the fix is an SPF or DNS change on your domain, which we help with.
• If it is a content-filter case (recipient’s Proofpoint, Mimecast or similar rejecting the message), the fastest fix is often for the recipient to whitelist your address on their end. We can help you draft that request.

In none of these cases is the useful thing to do “forward the bounce with the sentence ‘please fix’”. The bounce contains information that lets Momentum Hosting act quickly. A bounce forwarded without context, without the recipient address, and without the specific SMTP response is a bounce we have to reconstruct before acting on it. Sending us the full message with three lines of context (“I was emailing X at recipient@example.com about the invoice, the message bounced, here it is”) costs you nothing and gets you an answer in the next reply rather than after a round trip to gather the missing details.

The one-failed-email trap

A single failed delivery to one recipient does not mean email has stopped working. Most SMTP failures are recipient-specific or message-specific. The recipient’s mailbox is full today. The recipient’s provider is temporarily deferring because of load. The recipient’s employer has a filter that scored today’s message half a point too high. Any of these produces one bounce today and nothing the rest of the week.

Two failed deliveries to two different recipients on the same day, especially if they are on different mail providers, is starting to be a signal worth investigating. Two failed deliveries to the same recipient over a week is a signal about that specific delivery relationship. Two failed deliveries to two different recipients on the same day that both cite Momentum Hosting’s sending IP is the point at which Provenly has already flagged the pattern and the response is already underway.

Between “one email failed” and “email is broken” is a lot of information the bounce message has already handed over. Reading it is almost always faster than escalating without.