Skip to content

Why a bounce says 5.1.1 for an address that used to work

A 550 5.1.1 bounce means the receiving server found no such mailbox today, even if mail reached it last month. Here is how to find which of five causes it is.

Koltrix Team4 min read
Wall of numbered mailboxes
Photo by Tasha Kostyuk on Unsplash
On this page(7 sections)
  1. What does 550 5.1.1 actually mean?
  2. Why would an address that worked stop working?
  3. How do you tell which cause it is?
  4. What should support say to the customer?
  5. What should you do with the address afterward?
  6. Can 5.1.1 ever be your own domain's fault?
  7. Bottom line

A customer writes: "I emailed this person last month and it was fine. Now it bounces with 5.1.1. Is your system broken?" Usually it is not. The error is the receiving server's answer to one question, asked right now: does this mailbox exist? Last month's success tells you nothing about today's answer.

This guide explains what 5.1.1 states, the five reasons a once-working address starts failing, and how to tell them apart from the bounce itself.

What does 550 5.1.1 actually mean?

550 5.1.1 is a permanent rejection saying the recipient's mailbox address is bad. The first number, 550, is the SMTP reply from RFC 5321. The second, 5.1.1, is the enhanced status code defined in RFC 3463, where the class 5 means permanent failure and the subject 1.1 means "bad destination mailbox address".

Google's own Gmail SMTP error reference gives the same reading for Gmail: the account you tried to reach does not exist, so check the address for typos or stray spaces. Providers word the text differently ("user unknown", "no such user", "recipient rejected"), but the code is the same. For a wider map of these codes, see SMTP enhanced status codes.

Why would an address that worked stop working?

Five causes account for almost every case. Only the first is a mistake on your side.

Cause What happened How to spot it
The address is slightly different now A typo crept in, or a client autocompleted an old or wrong entry The address in the bounce differs from the one the person gave you
The mailbox was deleted The person left, or an admin removed the account The domain is fine, other colleagues still receive mail
The mailbox was renamed The company changed its naming scheme and the old address was not kept as an alias The person is reachable at a new address
An alias or group was removed sales@ or team@ used to forward to someone and no longer does Role-style address, other addresses at the domain work
A forwarding rule points at a dead address The mail reached the first mailbox, then the forward bounced The bounce names an address you never typed

The last row catches many people out. When a recipient forwards mail to an outside address that no longer exists, the bounce can look as if it came from the address you wrote to. Compare the address inside the bounce with the one you used. If they differ, the problem sits behind the first mailbox. The forwarding rules post shows how those chains fail.

How do you tell which cause it is?

Work through the bounce in this order. It takes a couple of minutes.

  1. Copy the exact failed address from the bounce text, not from your contact record. The bounce shows the address the receiving server tried.
  2. Compare it character by character with the address the person gave you. Look at the domain first: exmaple.com for example.com is the classic slip.
  3. Check whether the address came from autocomplete. Delete the saved entry in the mail client and type the address fresh.
  4. Check where the bounce was generated. The "Reporting-MTA" or the server name in the headers tells you whether the recipient's own server rejected it, or a server behind a forward did.
  5. Ask the person through another channel. A short message works: "Is [email protected] still your address?" This settles deletion and renaming in one answer.

If you need to read those headers, tracing delivery with Received headers walks through them line by line.

What should support say to the customer?

Say that the address no longer exists at the other end, that this is not a delay, and that retrying will not help. Then give the one thing they can do: confirm the correct address with the person.

The message came back because the receiving mail server says the address "[email protected]" does not exist. It worked before, so it may have been renamed or removed on their side. Could you check with them what address to use now? Sending it again to the same address will return the same error.

The same wording, adapted to other bounce types, is in explaining a bounced email to a customer in plain words.

What should you do with the address afterward?

Stop sending to it and keep it out of lists until someone has confirmed it. A 5.1.1 is a hard bounce, and hard bounces should end sending to that address because repeated mail to dead mailboxes harms your sender reputation.

In Koltrix, a permanent 5xx rejection adds the address to the workspace suppression list, and later sends to it are skipped without failing the rest of the recipients. The deliverability docs describe the list under Settings, Blocked senders. Before you remove an address from it, check that the reason has gone: if the mailbox still does not exist, the next message bounces and the address is suppressed again. If you run a platform with many customers, per-customer suppression explains whose list applies.

Can 5.1.1 ever be your own domain's fault?

Sometimes. If outsiders report 5.1.1 for addresses at your domain that do exist, mail may be reaching an old mail host through stale MX records, or an alias was lost in a migration. Check that the domain's MX records point to the provider that holds your mailboxes, and that every alias your team still advertises exists. Do this before telling the sender the address is wrong.

Bottom line

A 550 5.1.1 bounce is the receiving server saying that, right now, no mailbox matches the address. If it used to work, suspect a changed address, a deleted or renamed mailbox, a removed alias or a dead forward, in that order of likelihood. Read the address in the bounce, compare it with what you were given, confirm with the person, and stop sending until you have a verified address.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

SharePost on XLinkedIn