SMTP "511" is not a real reply code - what you actually received

There is no such thing as SMTP reply code 511. RFC 5321 defines the first digit of a reply as 2 (success), 3 (intermediate), 4 (temporary failure) or 5 (permanent failure), and the second digit as a category from 0 to 5. A valid 5yz reply therefore falls in a narrow set of real-world values - in practice 500 through 504 and 550 through 555 cover essentially every 5yz reply you will see from Gmail, Microsoft 365, Yahoo or any standards-compliant MTA. 511 is neither.

Where "511" actually comes from

If a log, a bounce-processing tool, or a dashboard shows you 511, one of two things happened: a non-SMTP layer invented the number (some webmail bounce parsers and legacy helpdesk integrations misread an enhanced status code's digits, mistaking 5.1.1 for a reply code 511), or someone manually transcribed the error and dropped punctuation. Either way, the server never put "511" on the wire. Address what the sender actually received, which is almost always one of:

• 550 5.1.1 - "no such user here," the mailbox does not exist. Permanent.
• 501 5.1.3 - "bad address syntax," the RCPT TO string itself is malformed. Permanent.

Who is at fault

For 550 5.1.1 the fault is the address - it is wrong, deleted, or was never real. For 501 5.1.3 the fault is the sending application - it submitted a malformed recipient string, often from bad CSV encoding or a missing @ after a find-and-replace. A find-and-replace is a surprisingly common source of this exact malformation: someone edits a

CSV in a spreadsheet application, runs a bulk replace to fix one formatting issue, and the

replace pattern inadvertently touches the @ character in unrelated rows. The result looks fine

in a quick visual scan of a few rows but fails on import or send for the affected ones. Treat any

batch that produced even one 501 5.1.3 or 550 5.1.1 from a recent import as worth a full re-scan,

not just a fix to the one address you noticed - the same editing mistake rarely affects only a

single row.

The exchange (the real reply behind the mislabel)

MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<reciipient@example.com>
550 5.1.1 <reciipient@example.com>: Recipient address rejected: User unknown in virtual mailbox table

How Gmail, Microsoft 365 and Yahoo word the two real conditions

Diagnostic commands

Pull the raw bounce and look at the actual numeric reply, not whatever summary field a tool computed:

$ grep -A3 "status=bounced" /var/log/mail.log | head -8
to=<recipient@example.com>, relay=mx.example.com[203.0.113.5]:25,
delay=1.2, status=bounced (host mx.example.com said:
550 5.1.1 <recipient@example.com>: Recipient address rejected:
User unknown in virtual mailbox table (in reply to RCPT TO command))

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  550 5.1.1 <recipient@example.com>: Recipient address rejected

The ordered fix

1. Re-read the raw SMTP log line, not the tool's paraphrase. Find the actual three-digit code and enhanced status code.
2. If it is 550 5.1.1, remove or correct the address; it does not exist. Do not retry.
3. If it is 501 5.1.3, inspect the exact string you sent in RCPT TO for stray characters, double @, or encoding artefacts from CSV import.
4. Fix your bounce-processing tool so it stops inventing non-standard codes, or at minimum log the raw reply alongside whatever it displays.
5. Re-validate the rest of that import batch - a single malformed address is rarely alone.

What not to do

• Do not search vendor documentation for "SMTP 511." You will find nothing, because nothing emits it.
• Do not retry 550 5.1.1 addresses on a schedule. It is permanent; retrying wastes send volume and can itself look like abuse to the receiving server.
• Do not assume the recipient's domain is broadly unreachable. This is address-specific, not domain-wide.
• Do not skip fixing the parsing tool. If it invented 511 once, it will keep doing it, and you will keep chasing a phantom code.

Why bounce-processing tools invent numbers like this

Most of these mislabelled codes originate the same way: a tool groups similar bounce reasons into

internal buckets for reporting, assigns each bucket an arbitrary number for its own dashboard, and

that number leaks into exports, tickets, or documentation as if it were the server's own reply.

Once it is written down somewhere, it gets copied forward by anyone who did not check the original

source. The only reliable fix once you spot this pattern is to trace every anomalous code back to a

raw log line at least once, and treat any summary field that cannot be traced that way as suspect.

MailPilot's inbox-placement results always carry the real reply code and enhanced status from the receiving server, specifically so a parsing shortcut elsewhere in your stack cannot turn a clear 550 5.1.1 into a code nobody can look up.