SMTP error 500 5.3.3: unrecognized command from a capability mismatch

SMTP error 500 5.3.3 pairs a generic "unrecognized command" base reply with an enhanced

status code (5.3.3) meaning "system not capable of selected features." The combination

describes a specific and unusual situation: the server's own EHLO greeting advertised an

extension, but when the client actually tried to use it, the server (or something between the

client and server) could not honour it after all.

Fault: usually a middlebox, not the client or the final server - this pairing is one of the

more reliable signatures of a firewall or security gateway interfering with the SMTP session

after the greeting was already exchanged.

Why you are seeing two codes at once

A firewall or email-security gateway that performs deep packet inspection on SMTP traffic will

sometimes let the server's genuine EHLO response through untouched (correctly advertising

STARTTLS, PIPELINING, and so on) but then strip or rewrite the subsequent command stream based

on its own, more limited understanding of SMTP. The result: the server's greeting promised a

capability that something downstream of it - from the client's point of view, upstream of the

true server - cannot actually pass through.

How to read the reply

• Base code `500`: generic command-recognition failure.
• Enhanced `5.3.3`: specifically "system not capable of selected features" - a more precise

claim than "I don't understand you" (which would usually be 5.5.1); this is "I understand

what you're asking for, and I cannot do it."

• Reading them together: the server (or something in front of it) recognised the extension

you tried to use but cannot actually process it in this context.

Diagnosing it in under five minutes

$ swaks --to test@mailpilots.in --server mx.example.net --quit-after EHLO
-> EHLO sender.example.com
<- 250-mx.example.net
<- 250-STARTTLS
<- 250 PIPELINING

$ swaks --to test@mailpilots.in --server mx.example.net -tls
-> STARTTLS
<- 220 Go ahead
-> EHLO sender.example.com
<- 250-mx.example.net
<- 250 PIPELINING
-> MAIL FROM:<sender@yourdomain.com>
-> RCPT TO:<test@mailpilots.in>
<- 500 5.3.3 Pipelined commands not supported after STARTTLS

The first EHLO, before TLS, advertised PIPELINING. After STARTTLS, the second EHLO

response dropped it - but the client (in this example, deliberately) still pipelined its commands

anyway, and got exactly this error. In real-world cases the client does not intend to pipeline at

all; a middlebox reordering or batching the post-TLS stream produces the identical symptom

without any client misbehaviour.

What causes it

• A firewall or gateway stripping an ESMTP extension from the post-STARTTLS session while

leaving the pre-TLS EHLO response (which it can still inspect in plaintext) untouched.

• STARTTLS is not actually offered, or silently fails, on the connection despite being listed

in the initial EHLO, because a transparent proxy intercepted the TLS negotiation itself.

• An Exchange or receive-connector misconfiguration where a connector's advertised

capabilities do not match what its underlying transport actually supports for a given source.

• The destination genuinely cannot support a requested extension in this specific context -

for instance, advertising 8BITMIME generally but being unable to honour it for messages routed

through a particular downstream relay.

How the big three word it

The ordered fix

1. Compare the `EHLO` response before and after `STARTTLS`. A capability present in the first

and missing (or behaving differently) in the second points directly at the TLS boundary as the

problem.

1. Test from a network path with no corporate firewall or security gateway in front of it, if

possible - a clean result from an unobstructed network confirms a middlebox as the cause.

1. Disable SMTP deep packet inspection on the firewall/gateway, or add an explicit bypass for

the relevant mail traffic.

1. If administering Exchange, check the receive connector's configured capabilities against

what its transport actually supports, and correct any mismatch.

1. Fall back to the most conservative command sequence (no pipelining, re-issuing EHLO

cleanly after STARTTLS, no assumed extensions) as a temporary workaround while the middlebox

issue is resolved.

What not to do

• Do not treat this as a content or authentication problem. Nothing about the message or

credentials is involved; this is purely a capability-negotiation failure.

• Do not assume the final mail server is broken. The mismatch is very often introduced by

something between you and it, not by the server itself.

• Do not keep retrying with the same pipelined/extended command set. If a middlebox is

stripping the capability, retrying identically will fail identically.

• Do not disable TLS to work around it. That removes encryption to solve what is actually a

capability-advertisement mismatch, and introduces a worse problem than the one you started with.

MailPilot re-checks server capabilities after any STARTTLS upgrade rather than trusting the

pre-TLS greeting for the rest of the session, which avoids this exact class of post-upgrade

capability mismatch on connections it manages.