SMTP error 503 5.5.1: EHLO or HELO required before this command

SMTP error 503 5.5.1, with the text "EHLO/HELO required" (or "send HELO/EHLO first"), means

your client attempted a command - most commonly AUTH, MAIL FROM, or sometimes DATA - before

completing the mandatory greeting exchange that must open every SMTP session. The enhanced code

5.5.1 means "invalid command", and this particular wording is the single most common real-world

cause of that code.

Fault: sender, specifically a client or script that violates basic SMTP command ordering.

This is never a server misconfiguration, content issue, or reputation signal.

Why it happens

• A hand-built or scripted SMTP client sends commands without a state machine. Code that

writes raw strings to a socket in sequence, without actually waiting for and checking each

reply, is the classic source - it fires MAIL FROM immediately after connecting, skipping

EHLO entirely.

• A connection is reused across multiple messages without resetting state correctly. Some

pooling implementations send RSET then jump straight back to MAIL FROM, which is valid, but

a buggy pool sometimes skips the greeting on a freshly opened connection instead.

• `STARTTLS` was negotiated, and the client forgets that `EHLO` must be sent again after the

TLS handshake completes. The post-TLS session is a new session as far as the greeting

requirement is concerned, even though the TCP connection is the same one.

• Load testing or fuzzing tools that intentionally or accidentally send commands out of

sequence while probing a server's behaviour.

• A custom retry wrapper that re-sends the last failed command without first checking whether

the connection itself was reset, so it replays MAIL FROM or AUTH on a socket that the

server considers freshly opened and ungreeted.

This is the one error on this list where the fix is almost entirely a code review rather than a

server-side investigation. There is nothing to diagnose about the destination; the destination is

behaving exactly as RFC 5321 requires, and the only variable is the order your own client sends

commands in.

The transcript

$ printf 'MAIL FROM:<sender@yourdomain.com>\r\nRCPT TO:<test@mailpilots.in>\r\nQUIT\r\n' \
    | openssl s_client -connect smtp.example.net:465 -quiet
503 5.5.1 EHLO/HELO required

No greeting was sent at all before MAIL FROM - the server refuses to process anything else

until that happens, exactly as RFC 5321 requires.

Compare the corrected sequence:

$ swaks --to test@mailpilots.in --server smtp.example.net:465
-> EHLO sender.example.com
<- 250-smtp.example.net Hello
<- 250 PIPELINING
-> MAIL FROM:<sender@yourdomain.com>
<- 250 2.1.0 OK

How the big three word it

Diagnose it

$ swaks --to test@mailpilots.in --server smtp.example.net --dry-run
=== Would send:
EHLO sender.example.com
MAIL FROM:<sender@yourdomain.com>
RCPT TO:<test@mailpilots.in>
DATA
...

If swaks's dry-run shows the expected EHLO first but your actual application still produces

this error, the bug is specifically in how your application's library sends commands, not in the

intended logic - a strong hint to capture a live packet trace rather than trust the library's

higher-level API.

$ tcpdump -i any -A -s0 'tcp port 587' -w /tmp/smtp.pcap

The fix, in order

1. Confirm your client sends `EHLO` (or `HELO`) as the literal first command on every new

connection, with no exceptions for reused sockets.

1. Re-send `EHLO` immediately after `STARTTLS` completes, on the same connection, before any

other command.

1. Switch from a hand-rolled socket implementation to a maintained SMTP library if you are

writing raw commands - this entire class of bug disappears with a library that implements the

command state machine correctly.

1. Check connection pooling logic for any path that skips the greeting on what the pool

believes is an already-greeted connection but the server does not.

1. Capture a packet trace if the bug is intermittent rather than constant, since intermittent

ordering bugs are usually a race condition in reused-connection logic.

What not to do

• Do not treat this as a server problem and contact the recipient's postmaster. Every major

receiver enforces this identically; it is not provider-specific behaviour to report.

• Do not add retry logic without fixing the ordering. Retrying the same malformed sequence

produces the same 503 indefinitely.

• Do not assume `STARTTLS` "carries over" the earlier `EHLO`. It does not; the greeting must

be repeated after the TLS handshake on every connection that upgrades encryption mid-session.

• Do not suppress any recipient over this error. The failure happens before RCPT TO is

processed in the broken sequence; no recipient was ever actually evaluated.

MailPilot's warm-up and send paths use maintained SMTP client libraries that implement the full

command state machine, including the re-greeting requirement after STARTTLS, so this specific

protocol-ordering failure does not occur on connections it manages.