Email verification comes down to a simple question: will the mail server accept mail for this address? The only way to know for certain is to ask the mail server directly via SMTP.
Most email verification tools skip this step. Instead, they: - Look up DNS MX records to confirm the domain has mail infrastructure - Check against lists of known bad addresses (disposables, syntax errors) - Pattern-match against known company naming conventions - Hope for the best
All of these are useful signals, but none of them actually verify the address.
Real verification uses the SMTP RCPT TO command. Here's what happens:
2. Server responds: 220 mail.company.com ESMTP ... 3. Client sends: EHLO my-verification-server.com 4. Server responds: 250-mail.company.com Hello 5. Client sends: MAIL FROM:<noreply@my-server.com> 6. Server responds: 250 OK 7. Client sends: RCPT TO:<target@company.com> 8. Server responds: 250 OK (deliverable) OR 550 (undeliverable)
Step 7-8 is the verification. The mail server either accepts the address (250 OK) or rejects it (550, 551, 552, etc.).
DNS tells you where mail goes. It doesn't tell you if a specific mailbox exists.
Think of it this way: knowing Google has an MX record for gmail.com doesn't mean jane.smith@gmail.com exists. The mail server has to check its own mailbox database.
Some mail servers are configured to accept mail for any address:
250 OK
This doesn't mean the address exists. The mail goes to a catch-all mailbox where it either gets filtered or bounced by support staff.
It's tempting for a verification tool to accept the 250 OK and return "verified." Weeks later, when the emails start bouncing, the sender reputation quietly degrades. The tool has already moved on.
Coalstoke returns these as `catch_all` with a confidence-scored guess of the real pattern — so you know upfront that this address needs a different segmentation than a strict-verified one.
The SMTP protocol defines specific codes for different outcomes:
- **250**: OK - address accepted - **450**: Temporary failure - retry later - **550**: Permanent failure - address doesn't exist - **551**: User not local - try another server - **552**: Storage exceeded - mailbox full - **553**: Syntax invalid - bad format
Many services collapse these codes to a binary verified/unverified. That's easier to display in a UI, but it throws away the information you'd use to decide what to do next.
Coalstoke returns the actual code so you understand why an address was rejected. Is the mailbox full? Is it a syntax issue? Did the connection timeout? Each of those has a different next step.
Incomplete verification creates downstream costs:
1. **Bounce rate degrades sender reputation** - ISPs monitor bounce rates. High bounces = lower delivery. 2. **Verification credits are cheap compared to sender reputation loss** - A single 5% bounce rate hit can cost thousands in lost mail delivery across a campaign. 3. **Catch-alls inflate your false positives** - Pattern guesses on catch-all domains have accuracy 45-65%. You need either high confidence scores or manual review.
The math is simple: spend 1 credit on real verification or lose $1000s in sender reputation and delivery.
1. Connect to the destination MX server 2. Run RCPT TO against the actual mailbox 3. Return the SMTP code (250, 550, 450, etc.) 4. Flag catch-alls and protected systems separately 5. Return a confidence score and status code the client can act on
Real verification. No guesses dressed up as answers.