What 502 Command not implemented Means
502 is a permanent rejection meaning the receiver knows about the command in the SMTP standard but doesn't implement it locally. Per RFC 5321 §4.2, this is the receiver telling you they've intentionally disabled the feature.
Receivers that have disabled rarely-used or security-sensitive SMTP commands. Most often: VRFY (verify address) and EXPN (expand mailing list) are disabled by 90%+ of modern mail servers because they're abused for harvesting. ETRN (queue request) is also commonly disabled.
Your sending platform or mail server is using an SMTP command the receiver intentionally turned off. Most common in cold email contexts: address-verification probes using VRFY (which all modern servers disable), or older sending platforms using legacy extensions the modern receiver no longer supports.
How to Fix 502 Command not implemented
- 1
Identify the rejected command
Check your mail server's SMTP transcript. 502 follows the offending command directly. If it's VRFY or EXPN, you're probably using an address-verification tool that probes via VRFY — switch to a verification service that uses an actual SMTP RCPT TO check (more accurate and broadly supported).
- 2
Don't use VRFY for address verification
VRFY is functionally dead — most receivers either disable it (502) or return inaccurate results to deter harvesting. Use a proper email verification service that performs a full RCPT TO check against the recipient, then disconnects without sending DATA. This is how every credible verification service works.
- 3
If your sending platform is hitting 502 — check its config
If you're seeing 502 in normal send flow (not during verification), your sending platform may be trying to use an SMTP extension the receiver disabled. Common cases: CHUNKING (BDAT) where the receiver only supports DATA, or 8BITMIME. Most modern sending platforms negotiate features correctly based on EHLO, but bugs do happen.
- 4
Switch to a more compatible verification service
If 502 is breaking your prospect verification, use a verification service that uses standard RCPT TO probing (no VRFY). Most major services (NeverBounce, ZeroBounce, ColdRelay's own bounce-classification system) do this correctly.
References
- ◇
- ◇RFC 5321 §3.5 — Commands for Debugging Addresses (VRFY, EXPN)
Explains why VRFY/EXPN are commonly disabled.
502 Command not implemented in the Cold Email Context
The cold email scenario where 502 matters most: address verification. Tools that probe recipient mailbox existence via VRFY get blanket 502s from most modern receivers, so they fall back to less-accurate methods. Better verification services use SMTP RCPT TO probing, which is universally supported and gives a definitive answer (250 = exists, 550 = doesn't). ColdRelay's bounce classification operates downstream — once a send happens, the receiver's RCPT TO or DATA response tells you whether the address is live, and ColdRelay's automation marks invalid recipients so they're excluded from future campaigns.
Frequently Asked Questions
Why is VRFY disabled almost everywhere?
VRFY was originally designed to confirm whether a mailbox exists. Spammers heavily abused it for address harvesting — probing thousands of common usernames against a domain to build target lists. By the late 2000s most receivers disabled VRFY entirely. The same goes for EXPN.
Is 502 different from 500 or 501?
Yes. 500 = command not recognized at all. 501 = command recognized but arguments malformed. 502 = command recognized and arguments valid, but command intentionally not implemented by this server. All three are permanent.
Will my prospect verification ever work via VRFY?
Not reliably. Even receivers that don't return 502 often return non-committal '250 OK' to all VRFY queries regardless of mailbox existence, to deter harvesters. Use RCPT TO-based verification instead.
Can 502 stop my normal sending?
Rarely. 502 in the normal send flow indicates an SMTP-level incompatibility — usually a sending platform bug. The normal send path uses MAIL FROM, RCPT TO, DATA, all of which every receiver supports. If you see 502 mid-send, contact your sending platform's support.