SMTP 511: not a valid reply code — what you actually received

511 is not a defined SMTP reply code. RFC 5321's permanent (5xx) reply codes are limited to 500–504 and 550–555; 511 falls outside both ranges and no major mail provider or standard MTA issues it as an actual server response. Some deliverability dashboards and list-validation tools use "511" informally to mean "bad email address," but that's a tool-side label, not a wire-level SMTP reply.

Who is at fault

If the underlying real condition is what "511" is usually used to represent — a non-existent or malformed address — the fault is the same as for a genuine 550 5.1.1: either a typo in the address or stale list data.

What the real reply actually looks like

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<badaddress@example.com>
550 5.1.1 <badaddress@example.com>: Recipient address rejected: User unknown

This is a genuine 5xx permanent failure with a real, defined enhanced status code — 5.1.1, "bad destination mailbox address" — the same condition covered in the 554 5.1.1 post in this cluster, since Gmail and Microsoft 365 both typically pair this enhanced code with base code 550 rather than 554.

How the big three word the real condition

Diagnose it

Pull the raw SMTP transcript or bounce detail from your sending platform rather than trusting a summarised "511" label from a third-party validator or dashboard.

$ grep -B2 -A2 "RCPT TO" /var/log/mail.log | grep -E "^5[0-9]{2}"

Fix it, in order

1. Get the raw reply code and text from your mail logs or ESP's bounce detail — treat "511" from any tool as a label needing translation, not a code to act on directly.
2. Treat the underlying condition as a hard bounce: remove the address, as you would for a confirmed 550/554 5.1.1.
3. Don't retry. Whether the real code is 550 or 554, 5.1.1 is permanent — the mailbox doesn't exist.
4. If this is coming from a list-validation tool rather than a live send, understand it's a prediction, not a confirmed bounce — validate against actual send attempts before purging addresses at scale on a validator's say-so alone.

Why some tools use numbers outside the valid ranges at all

It's worth understanding the mechanism, since it recurs across several of these nonstandard-code posts: RFC 5321 permanent reply codes are limited to 500–504 and 550–555, and temporary codes to 421, 450–452, and 455. A tool built around an internal severity scale (say, 1 = informational through 9 = fatal) sometimes maps that scale onto a three-digit "code" that coincidentally looks like an SMTP reply without being one — 511 reads as "5-something, severity 1," which is exactly the shape a validator's internal bad-address classification would take, even though it has no relationship to the actual wire protocol. Any three-digit number you see outside those two defined 5xx ranges, or outside 421/450–452/455 for temporary failures, should be treated the same way: as a tool-invented label requiring translation back to a real reply.

An additional check against your own send history

$ grep "RCPT TO.*recipient@example.com" /var/log/mail.log -A1

If you have actually attempted to send to the flagged address before, rather than only validated it, pull the real transcript from that attempt — a confirmed live delivery result is stronger evidence than any validator's prediction, in either direction.

Why there's no retry window to consider

As with any genuine 550/554 5.1.1, there's nothing to wait out: the underlying condition — a mailbox that doesn't exist — doesn't resolve with time or a backoff schedule the way a 4xx deferral does. The only thing worth timing is how long you give a pre-send validator's prediction before you trust it over an actual attempted delivery; a single real send attempt that succeeds should override a validator's "511" every time.

What not to do

• Don't look for "SMTP 511 removal" or "fix" guidance from a provider. None of the major providers document this code because none of them send it.
• Don't treat a tool's "511" the same as a confirmed live bounce if it came from a pre-send validation pass rather than an actual delivery attempt — validators can be wrong, and a real send attempt is better evidence either way.
• Don't keep sending to an address flagged this way without checking the real reply at least once. The label might be wrong, but if the real code is a genuine 5.1.1, continuing to send is actively harmful to reputation.

MailPilot works from the actual SMTP reply and enhanced status code on every bounce, not a normalised or invented label, so a validator's shorthand doesn't get treated as ground truth.