A client forwards a bounced message and asks what it means, and the honest answer is that "bounce" covers a dozen unrelated problems wearing the same disguise. A mistyped address, a full mailbox, a missing DNS record and a banned sending IP all come back as the same kind of email, a non-delivery report, and the difference between them is three numbers buried a few lines into the text. Atriomail's own support queue gets this question from resellers managing someone else's domain just as often as anyone running their own, since the fix for one bounce code is a one-line DNS edit and the fix for another is a conversation with a different company's administrator.

This guide reads a bounce the way a mail server actually writes one: the enhanced status code first, then what it means in Gmail's and Microsoft's own wording, then what to do about it. Atriomail's migration tool runs into a version of this problem before it ever becomes a bounce, covered in the last section before the FAQ.

Table of Contents

Key Takeaways

Point Details
Three numbers decide who has to fix it The enhanced status code, written as class.subject.detail, is defined in RFC 3463. The first digit (4 or 5) says temporary or permanent; the rest narrows the actual cause.
A 5.x.x code means stop resending the same message Permanent failures like 5.1.1 (bad address) or 5.7.1 (policy, not authorized) won't resolve by trying again unchanged.
A 4.x.x code is not automatically safe to ignore Some temporary codes clear on their own; a 4.4.7 that repeats on every retry for hours usually means a receiving-side problem that needs a human to fix it.
Gmail and Microsoft each layer extra detail codes on top of the RFC 550-5.7.26 (Gmail, unauthenticated sender) and 5.7.509 (Microsoft, DMARC reject) point straight at an authentication gap, not a typo in the address.
Atriomail's migration tool tests sign-in before it starts For a single-mailbox job, a wrong password shows up in seconds, before it can ever produce a bounce in the new mailbox.

Most of the permanent codes below trace back to a missing or misaligned DNS record. Atriomail generates SPF, DKIM and DMARC records for every domain in the panel, and publishes them automatically on a connected Cloudflare or Namecheap account. Creating an account is free and needs no card; mailboxes are billed from the first one.

Create a free account   See pricing

Before You Start

Have these ready before trying to diagnose a bounce:

  • The complete non-delivery report, not the one-line summary a mail client shows at the top. Webmail often truncates the message to a sentence; the enhanced status code and the server's own SMTP response text sit a few lines further down, under a heading like "Diagnostic information for administrators".
  • The name of the server that generated the report versus the one that actually rejected the message. An intermediate relay sometimes passes along a code from further down the chain, and fixing the wrong end wastes the rest of this process.
  • Access to the sending domain's DNS zone, in case the fix is an SPF, DKIM or DMARC record rather than something to discuss with the recipient.
  • Whether this is a one-off or a pattern. One bounce to one address is usually a typo. The same code against several recipients at once, especially across a multi-client book, points at something systemic: a DNS record, a reputation problem, or a rate limit.

The Three Numbers That Matter: Reading the Enhanced Status Code

Every bounce that reaches this point carries an enhanced status code in the format class.subject.detail, defined by RFC 3463 (rfc-editor.org, checked October 2026). The three parts narrow the problem from general to specific:

  • Class is a single digit. 2 means success (rare to see in a bounce; it shows up in delayed delivery confirmations). 4 is what the RFC calls a "persistent transient failure": the message itself is valid, but some temporary condition stopped delivery. 5 is a permanent failure, "not likely to be resolved by resending the message in the current form."
  • Subject is one to three digits that name the general area: 1 is the address, 2 is the mailbox itself, 4 is the network or routing, 7 is security or policy.
  • Detail narrows it further within that subject.

Put together, 5.1.1 reads as permanent failure, address problem, specifically "the mailbox specified in the address does not exist" (RFC 3463's own wording, checked October 2026). 5.2.2 reads as permanent failure, mailbox problem, specifically a full mailbox: "the mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity." 5.7.1 reads as permanent failure, security or policy, specifically "the sender is not authorized to send to the destination."

The RFC only defines the code itself. The sentence next to it, the one actually worth reading first, is written by whichever mail system rejected the message, and that's where Gmail's and Microsoft's own wording comes in further down.

Knowing the format is step one; matching it against a real DNS record is step two. Each domain on Atriomail shows its own DNS status in the panel, with a refresh button that re-checks the live SPF, DKIM and DMARC records on demand.

See pricing   Read the setup guide

Permanent Failures (5.x.x): When Resending Won't Help

A 5.x.x code means the receiving system has already decided the message won't go through as written. Resending the identical message produces the identical bounce. The ones worth knowing:

Code Meaning Typical fix
5.1.1 Bad destination mailbox address; the address doesn't exist on the receiving system. Confirm the address with the recipient. Also check for a stale address-book cache if the mailbox was recently moved or renamed.
5.2.2 Mailbox full; the recipient has exceeded their storage quota. Nothing fixable on the sender's end. The recipient (or their admin) has to free up space or raise the quota.
5.7.1 Delivery not authorized, or the sending system was never authenticated by the receiving one. Depends on the wording attached. "Client was not authenticated" means the receiving server requires credentials; "sender not authorized" usually means a moderated address accepting only specific senders.
5.4.1 Relay access denied; the receiving mail server doesn't accept mail for that recipient domain at all. Usually an MX record pointing at the wrong server, on either side. Confirm the domain's own DNS records match the mail host actually in use.

A good share of 5.7.x codes, on both Gmail and Microsoft's systems, turn out to be an authentication gap rather than an access-control decision: no DKIM signature, a failing SPF check, or a DMARC policy set to reject with nothing passing underneath it. If a client's domain had its DKIM signature stop verifying after a host change, or its DMARC policy was recently moved to enforcement, that history is usually the first place to look before assuming the recipient blocked something on purpose. The same authentication gap is also the reason DNS automation matters more for deliverability than it first appears: a record that was never published correctly produces exactly this family of bounce.

A smaller group of codes, Microsoft's 5.1.8 and 5.7.502 among them, both mean "banned sender" because the account was compromised and started sending spam (learn.microsoft.com, checked October 2026). Bounces like these for mail the client doesn't remember sending are a sign a password reset alone isn't the fix.

Temporary Failures (4.x.x): When to Wait and When to Act

A 4.x.x code means the message is still valid and the sending server will keep retrying on its own, usually for a few days, before giving up and converting it into a permanent failure. Not every 4.x.x deserves the same patience:

  • 4.4.7, message expired in queue. Microsoft's own documentation describes this as the sending server trying to relay or deliver the message, but the action not completing before the message's expiration time (learn.microsoft.com, checked October 2026). A single occurrence usually clears on retry. The same code repeating on every attempt for hours points at a receiving-side problem, not a blip, and is worth escalating rather than waiting out.
  • 4.7.0, a general connection or policy issue. This one is intentionally vague; it covers everything from a missing reverse-DNS record to a receiving server temporarily rate-limiting the connection. The accompanying SMTP response text, not the bare code, usually says which.
  • 450 4.2.1, the recipient is receiving mail too quickly. Google's own guidance describes this as the receiving mailbox being "too busy to accept mail" at that moment, with a suggestion to resend later (knowledge.workspace.google.com, checked October 2026). A single message almost always goes through on retry; a bulk send hitting this on many recipients at once is a sending-pace problem, not a per-message one.
  • Rate-limit codes tied to authentication, such as Gmail's 421 4.7.27 for SPF or 421 4.7.30 for DKIM. These look temporary, a grace period, but won't clear until the record is fixed. An SPF record returning a permerror from too many DNS lookups is a common cause.

How Gmail and Microsoft Add Their Own Codes on Top

RFC 3463 defines the format, but the detail codes in the third position are an open registry, and the two largest inboxes have each added their own.

Gmail uses 550 5.7.26 for "this email has been blocked because the sender is unauthenticated," since Google now requires every sender to pass SPF or DKIM (knowledge.workspace.google.com, checked October 2026). It's easy to misread this as a generic policy block when it's specifically an authentication gap. Gmail also uses 550 5.7.28 for an unusual rate of unsolicited mail from a sending IP, which is a reputation signal, not a per-message error.

Microsoft 365 and Exchange Online run a much longer private registry in the 5.7.5xx and 5.7.6xx ranges for banned senders and blocked IPs: 5.7.511 for a banned sending IP, 5.7.509 for a sending domain that fails DMARC against a policy of reject, and 5.7.1 reused for three different causes depending on the attached text ("Client was not authenticated," "Unable to relay," plain "Delivery not authorized," learn.microsoft.com, checked October 2026). The number alone doesn't distinguish these; the exact wording attached to it does, and that's the practical rule for any code from either inbox.

How to Verify It Worked

Confirming a bounce is actually fixed depends on which kind of code it was:

  • For an address or mailbox problem (5.1.1, 5.2.2), resend a test message once the recipient confirms the fix, and confirm no new bounce arrives within a few minutes.
  • For an authentication problem (5.7.26, 5.7.509, the SPF/DKIM-tied 4.7.x codes), check the sending domain's records directly. Atriomail's free DNS checker at /dns-checker/ confirms a domain's MX, SPF, DKIM and DMARC records exist and are well-formed without needing an account; it answers whether the record is right, not whether a past bounce is gone, so pair it with an actual resend.
  • For a policy or access block (5.7.1, 5.4.1), get written confirmation from the recipient's own administrator that the sending address was allow-listed, since there's nothing to check on the sending side.
  • For a reputation or rate-limit code (5.7.28, 450 4.2.1 at volume), expect the fix to take longer to confirm than a DNS change, since reputation signals lag behind the behavior that changed.

Common Mistakes and How to Avoid Them

  • Reading only the one-line summary. Symptom: giving up because "mailbox unavailable" sounds unfixable, when the diagnostic text further down names a specific, fixable code.
  • Treating every 4.x.x as "it'll sort itself out." Symptom: the same 4.4.7 or 4.7.0 reappears on every retry for hours, meaning the receiving side has a standing problem, not a momentary one.
  • Confusing a bounce with silent filtering. Symptom: a client insists a message "never arrived," but no report exists anywhere, because the receiving server accepted it and routed it to Junk instead, a different diagnosis entirely.
  • Assuming every 5.1.1 is a typo. Symptom: the address was entered correctly, because the real cause is a stale recipient cache after a mailbox moved, or a mailbox deleted since the last time the sender used it.
  • Fixing the wrong domain's DNS. Symptom: the code describes the recipient's own policy (a moderated list, an allow-list), and no amount of editing the sender's SPF or DKIM record changes it.

Doing This on Atriomail

Atriomail doesn't parse or summarize a client's bounce messages inside the panel; reading the non-delivery report happens in whatever mail client received it, the same as on any platform. What Atriomail does cover is the layer behind most of the permanent, authentication-related codes above. For every domain, the panel generates SPF, DKIM and DMARC records ready to copy, and on a connected Cloudflare or Namecheap account publishes them directly into that domain's zone. Each domain shows its own DNS status with a refresh button that re-checks the live records on demand, the fastest way to confirm a 5.7.26 or 5.7.509-style bounce has a fixed record behind it before resending.

Outgoing mail from an Atriomail mailbox goes through Amazon SES, shared infrastructure rather than dedicated to one account. Because that reputation is shared, the Acceptable Use Policy bans bulk and unsolicited mail outright, the same behavior that produces Gmail's 5.7.28 and Microsoft's tenant-level rate-limit codes elsewhere. That's not an advantage over any other platform, just the same shared-infrastructure tradeoff most hosted mail runs on, stated plainly rather than hidden.

The one place Atriomail prevents a version of this problem before it starts is migration. Moving a client's mailbox in, the built-in IMAP migration tool tests the sign-in for both the old and the new mailbox before the job runs, so a wrong password shows up in seconds instead of a cryptic failure days later. For a larger book of mailboxes from the same old server, every account still needs its own working password checked the same way. None of this replaces reading a bounce correctly when one does arrive from outside; it just removes one category of them first. Mailboxes are billed at a flat $1.39 per mailbox, a usage-based rate rather than a tier, and support for anything the panel's own checks don't explain is available during business hours through live chat, the same support workflow most resellers already run for their own clients. Testing any of this first just needs a free account.

Moving a client's mailboxes somewhere that tests credentials before it migrates anything beats debugging a bounce code after the fact. Atriomail's migration tool checks the sign-in for both the old and new mailbox before it starts, so a wrong password shows up in seconds. Creating an account is free and needs no card, and mailboxes are billed from the first one.

Create your account   See pricing

Frequently Asked Questions

What's the difference between a bounce and mail landing in Junk?

A bounce is a non-delivery report with an enhanced status code, generated because the receiving server refused or failed to deliver the message. Mail landing in Junk produces no bounce at all: the receiving server accepted the message, then filed it based on its own spam scoring. If there's no bounce in sight, the fix is a filtering and reputation problem, not anything covered by a status code.

Does a 4.x.x code mean I should just resend the message?

Usually the sending server already retries automatically without anyone resending anything. The code is worth acting on manually when the same one keeps coming back on every attempt for hours, since that pattern means a standing problem on the receiving side rather than a momentary delay.

Can Atriomail's free DNS checker tell me why a message bounced?

Not directly. It reads a domain's public MX, SPF, DKIM and DMARC records and confirms they exist and are well-formed. For an authentication-related bounce code, that's the exact thing to check next, but it won't read the bounce itself or confirm a specific past message would now get through.

Does migrating a client's mailbox to Atriomail ever produce one of these bounce codes?

The migration tool itself moves existing mail into the new mailbox over IMAP; it doesn't send new outbound mail that could bounce. The credential check before a job starts is there specifically to catch a wrong password before it becomes a failure of any kind.

Why do Gmail and Microsoft show different codes for what looks like the same problem?

RFC 3463 defines the three-number format and a handful of common codes, but the specific detail numbers are an open registry, and both Gmail and Microsoft have added large numbers of their own on top for their own internal reasons (banned-sender ranges, rate-limit tiers, and so on). The number alone is a starting point; the exact wording attached to it is what actually disambiguates the cause.

Who fixes a 5.7.1 "client was not authenticated" error, the sender or the recipient?

The sender's mail system. It means the receiving server requires authentication before accepting the message, and the sending server didn't provide it, so the sending side's administrator needs to configure outbound authentication correctly for that destination.

Latest from the blog