SMTP email verification: what a mailbox probe can tell you
SMTP verification inspects how a receiving mail server responds to an address. It can provide a useful signal, but it is a conversation with a mail system, not a login to someone’s inbox. Many systems intentionally make the answer inconclusive.
Open the relevant free tool →The conversation stops before message content
What happens during a probe
A typical probe establishes an SMTP connection, introduces the checking host, supplies an envelope sender and presents the recipient address. It then quits before transmitting message content. EmailValidly does not send a message during verification. A provider can refuse the connection before it reaches the recipient check, so an inability to probe is not proof of an invalid mailbox.
Read the response in context
An acceptance means the server accepted that command at that moment. A rejection needs its accompanying explanation: recipient errors, access rules and sender policy failures are not interchangeable. Temporary failures should remain temporary in your workflow. Preserve the detailed reason when available, rather than reducing every unsuccessful connection to “email does not exist.” The SMTP protocol’s reply classes provide context, but your sending provider’s delivery report is often the best place to diagnose a real bounce.
Why catch-all behaviour matters
Imagine a server that accepts both pat@company.example and a long random address at the same domain. The first acceptance no longer gives strong evidence for Pat’s individual inbox. The domain may route unmatched mail to a shared inbox or defer its decision until a later stage. Treat the catch-all signal as a reason for review; it does not establish that every address is a real account.
Avoid the retry trap
If a probe times out, repeatedly running it in a tight loop usually adds load without improving the evidence. Save the first result, wait and make a bounded retry. Separate connection failures from explicit recipient rejections in your reporting. When integrating an API, use the same request identifier for transport retries so a network interruption does not create a second billable operation.
When to use a SMTP check
Use SMTP verification when the additional waiting time is justified, like reviewing a small set of uncertain contacts. Start large imports with structural and routing checks, then inspect selected risky or unknown rows. For a signup flow, a confirmation message sent by your application is still the appropriate ownership test. SMTP verification cannot replace that step and cannot predict the receiving spam filter’s decision about your future message.
Worked example
Illustrative sequence: connect → EHLO → MAIL FROM → RCPT TO → QUIT. No DATA command or message body is sent.