RCPT TO and Invalid Recipients: How Attackers Enumerate Email Addresses over SMTP
You are reading the mail logs and something feels off. A handful of source IPs are hammering the server, each connection firing one RCPT TO after another, and most of them come back as rejected. There is no spam in any inbox, no attachment, no payload, just a long stream of delivery attempts to addresses that mostly do not exist. What you are watching is not a misconfigured sender. It is SMTP recipient enumeration, the quiet reconnaissance step that maps out which of your addresses are real.
This guide takes the protocol angle. It explains how the SMTP dialogue leaks the existence of an address, why a 250 and a 550 are all an attacker needs, how this feeds a directory harvest attack and later spear phishing, how to spot it in your logs, and how to harden an existing server without rebuilding it.
What is SMTP recipient enumeration?
TL;DR: SMTP recipient enumeration is the act of probing a mail server with many candidate addresses and reading the response to
RCPT TOfor each one. A server that accepts the recipient answers with a250, a server that rejects an unknown mailbox answers with a550. That single difference turns the server into a yes and no oracle, so an attacker can confirm thousands of valid addresses without ever sending a real message. It is the protocol mechanism behind a directory harvest attack.
The trick exploits a normal, helpful feature of email. When a sending server wants to deliver a message, it announces each recipient and expects the receiving server to say whether it will accept it. That answer is useful for legitimate senders, because it lets a real mail server bounce immediately instead of accepting a message it cannot deliver. The same answer, asked thousands of times against a wordlist, becomes an inventory of your mailboxes.
Crucially, no email is delivered. The attacker speaks just enough SMTP to ask the question, reads the code, and moves on. Because nothing lands in an inbox, content filters and antivirus never get a chance to look.
How the SMTP dialogue leaks whether an address exists
A delivery over SMTP is a short, predictable conversation. The sender greets the server, declares an envelope sender with MAIL FROM, then declares one or more recipients with RCPT TO, and only afterwards offers the actual message with DATA. The decisive moment for enumeration is the response to RCPT TO.
Many servers decide right there whether a recipient is acceptable. If the mailbox exists, the server replies with a 250 success code. If the mailbox is unknown, it replies with a 550 rejection, often with a human readable note like user unknown or no such recipient. The attacker never needs to reach the DATA stage. The reply to RCPT TO already answers the only question that matters: does this address exist?
The leak is not limited to the response code. Several side channels can betray the same fact even when the codes look identical:
- Timing differences: if the server checks a directory only for valid users, a hit may take measurably longer or shorter than a miss.
- Message wording: two different
550texts, one for an unknown user and one for a full mailbox, still distinguish a real address from a fake one. - Deferred rejection: if the server accepts every
RCPT TOand only bounces invalid addresses afterwards, the later non-delivery report becomes the same signal one step removed.
A short example dialogue
Here is what an enumeration attempt looks like at the protocol level. Lines the client sends are prefixed with a greater-than sign, the server replies follow.
> EHLO scanner.example < 250 mail.your-company.com > MAIL FROM:<> < 250 2.1.0 Ok > RCPT TO:<jana.berg@your-company.com> < 250 2.1.5 Ok > RCPT TO:<j.berg@your-company.com> < 550 5.1.1 <j.berg@your-company.com>: Recipient address rejected: User unknown > RCPT TO:<info@your-company.com> < 250 2.1.5 Ok > RCPT TO:<nosuchperson@your-company.com> < 550 5.1.1 Recipient address rejected: User unknown > QUIT < 221 Bye
Two addresses came back 250 and are now confirmed. Two came back 550 and are discarded. Notice the empty MAIL FROM:<>, a common tell: the attacker does not intend to send anything, so the envelope sender is left blank or filled with a throwaway value.
From a single 250 to a directory harvest attack and spear phishing
One confirmed address is interesting. A whole confirmed directory is dangerous. Repeated across a generated list of likely names, role accounts and patterns, the 250 versus 550 signal builds exactly the verified address list that a directory harvest attack exists to produce. Enumeration is the protocol mechanism, the directory harvest attack is the campaign that uses it at scale.
The value of that list grows over time. Confirmed addresses feed spam and commodity phishing, but the more damaging use is targeted. Once an attacker knows that firstname.lastname of a specific finance manager resolves to 250, they can craft a convincing spear-phishing or business-email-compromise message aimed at a real person who really works there. The enumeration step is the reconnaissance that makes the later phishing attack credible. This is also why a pure content filter never sees the problem: the harm is decided in the envelope, long before any body text exists.
How to detect it in your mail logs
Enumeration has a recognisable shape. Even without a dedicated tool you can read the pattern out of the logs.
| Signal in the log | Normal sender | Enumeration |
|---|---|---|
| Share of 550 user unknown | Low, occasional typo | High, most attempts rejected |
| RCPT TO per connection | One or a few | Dozens, often sequential |
| Recipient names | Real correspondents | Alphabetical or wordlist order |
| MAIL FROM value | Real, consistent domain | Empty or throwaway |
| Source spread | Many senders | A few IPs, high volume |
| Reaching DATA stage | Almost always | Rarely, connection ends after RCPT |
The single strongest indicator is a burst of 550 rejections for unknown recipients concentrated on one or two source IPs. A legitimate sender almost never hits dozens of nonexistent addresses in a row. When you see that, you are looking at someone mapping your address book, not someone trying to reach an employee.
How to harden the server without rebuilding it
The good news: you do not need a new mailbox platform to close this. You need to change how the server behaves at the envelope stage. Four measures matter, and they reinforce each other.
Make responses uniform
The enumeration only works because valid and invalid recipients look different. Remove the difference. A valid and an invalid address should produce a response that is indistinguishable in code, in wording and, as far as practical, in timing. If every RCPT TO is treated the same way at the protocol surface, the oracle goes silent.
Throttle and tarpit suspicious sources
A source that fires many RCPT TO commands with a high rejection rate should be slowed deliberately. Rate limiting caps how many recipients a connection may test, and a tarpit inserts delays into the conversation so that mass probing becomes slow and uneconomical. The legitimate sender with one or two recipients never notices; the scanner trying thousands grinds to a halt.
Keep recipient verification consistent
Recipient verification is necessary so you do not accept mail for addresses that do not exist, but it must not leak. Apply the same verification path for every recipient so there is no per-recipient timing gap or differing message that quietly distinguishes a real address from a fake one.
Reject known-bad sources early on reputation
Many enumeration runs come from sources with poor reputation. Rejecting those connections up front, before any RCPT TO is processed, removes a large share of the probing without affecting normal correspondents. This is the same envelope-stage thinking that a mail gateway applies in front of the inbox.
Conbool MailGuard applies this in front of your existing server
Conbool MailGuard implements these controls as a layer in front of your current mail platform, whether that is Microsoft 365, Exchange or another server. It detects the enumeration pattern in the connection behaviour, throttles and tarpits suspicious sources, normalises responses so a valid and an invalid recipient look the same, and rejects known-bad sources on reputation. The mailbox platform stays exactly as it is; only the behaviour at the envelope changes. The matching overview is on the directory harvesting protection page.
Frequently asked questions
What is SMTP recipient enumeration?
SMTP recipient enumeration is the practice of testing many candidate addresses against a mail server and reading its responses to learn which ones exist. The attacker opens an SMTP connection and announces a recipient with RCPT TO for each address. From the server reaction, acceptance or rejection, they build a confirmed list of real mailboxes without ever sending a real message.
How does a 250 or 550 response to RCPT TO reveal a valid address?
After RCPT TO, a server that accepts the recipient typically answers with a 250 code, while one that rejects an unknown mailbox answers with a 550 code and a note such as user unknown. If the server decides this at the RCPT stage, the two responses become a yes and no oracle: a 250 marks the address as valid, a 550 marks it as nonexistent. Repeated across a wordlist, that single difference enumerates the whole address space.
How is RCPT TO enumeration related to a directory harvest attack?
RCPT TO enumeration is the protocol mechanism that powers a directory harvest attack. The directory harvest attack is the overall campaign of guessing valid addresses at scale, while the per-address yes and no signal comes from the response to RCPT TO. The confirmed list is later used for spam, phishing and targeted spear phishing against named people whose addresses were proven to exist.
How do I detect SMTP recipient enumeration in my mail logs?
Look for a small number of source IPs producing a high share of 550 rejections for unknown recipients, many RCPT TO commands per connection, sequential or alphabetical recipient names, and frequently an empty or throwaway MAIL FROM. A normal sender rarely hits dozens of nonexistent addresses in a row, so a sudden spike of user unknown rejections from one source is a strong signal.
How do I harden my mail server against enumeration without rebuilding it?
Make responses uniform so valid and invalid recipients look the same, add rate limiting and a tarpit that slows suspicious sources, keep recipient verification consistent so no per-recipient timing or wording leaks, and reject known-bad sources early on reputation. Conbool MailGuard applies these controls in front of an existing server, so the behaviour changes without touching the mailbox platform itself.
Conclusion
SMTP recipient enumeration is a quiet attack with a long tail. It delivers no message, trips no content filter, and yet it hands an attacker the verified address list that powers the next spam wave and, worse, the next targeted spear-phishing campaign. The whole leak comes down to one difference your server reveals at the envelope stage: a 250 for a real address, a 550 for a fake one.
Closing it does not mean replacing your mail platform. It means making responses uniform, throttling probes, keeping verification consistent and rejecting bad sources early. See how Conbool MailGuard applies exactly these controls in front of your existing server on the directory harvesting protection page, or check your domain first with the free transport security check.
Further reading:
