Skip to content
HackIndex logo

HackIndex

Email Verification and Validation

3 min read May 15, 2026

Overview

Email verification confirms whether a discovered or generated address is live and deliverable. Running verification before using an address for further investigation filters out invalid addresses and avoids wasting time on dead leads. It also narrows a pattern-generated candidate list down to confirmed addresses before moving to identity resolution.

SMTP Verification

The most direct verification method connects to the target domain's mail server and checks whether the server accepts the address without actually sending a message. This works by completing the SMTP handshake up to the RCPT TO command and reading the response code.

Manual SMTP probe:

┌──(kali㉿kali)-[~]
└─$ telnet $(dig +short MX $DOMAIN | sort -n | head -1 | awk '{print $2}') 25 
220 mail.example.com ESMTP
EHLO test.com
MAIL FROM:<test@@test.com>
RCPT TO:<target@@example.com>

A 250 OK response to RCPT TO means the address exists. A 550 or 551 means it does not. A 452 or 421 is a temporary rejection and does not confirm or deny existence.

Many organisations configure their mail servers to return 250 OK for all addresses regardless of whether they exist, a configuration called catch-all. If every address you test returns 250, the domain is running a catch-all and SMTP verification is unreliable for that domain.

verify-email and smtp-cli

For automated verification of multiple addresses, tools wrap the SMTP handshake into a repeatable workflow:

┌──(kali㉿kali)-[~]
└─$ pip install verify-email
┌──(kali㉿kali)-[~]
└─$ python3 -c "from verify_email import verify_email; print(verify_email('$EMAIL'))" 
True

API-Based Verification

API services perform SMTP checks, syntax validation, MX record checks, and catch-all detection in a single call. They are more reliable than manual SMTP probing for bulk verification because they handle edge cases, timeouts, and greylisting automatically.

Hunter verification endpoint:

┌──(kali㉿kali)-[~]
└─$ curl -s "https://api.hunter.io/v2/email-verifier?email=$EMAIL&api_key=$HUNTER_API_KEY" | jq '{result: .data.result, score: .data.score, disposable: .data.disposable}' 
{
  "result": "deliverable",
  "score": 92,
  "disposable": false
}

A result of deliverable with a high score is a confirmed live address. risky means the domain has a catch-all or the server behaved inconsistently. undeliverable is a confirmed dead address.

Disposable Address Detection

If the address uses a disposable email provider such as Mailinator, Guerrilla Mail, or temp-mail, it was almost certainly created for a single use and will not help with attribution. The Hunter verifier flags disposable addresses. You can also check manually against public disposable domain lists:

┌──(kali㉿kali)-[~]
└─$ curl -s https://raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposable_email_blocklist.conf | grep -i $(echo $EMAIL | cut -d@ -f2)

A match means the domain is a known disposable provider. Treat the address as a throwaway and do not invest further investigation time in it unless the context specifically requires tracing disposable address use.

Catch-All Detection

Before bulk-verifying a candidate list against a domain, test for catch-all by probing a clearly invalid address first:

┌──(kali㉿kali)-[~]
└─$ curl -s "https://api.hunter.io/v2/email-verifier?email=definitelynotreal_xyz123@$DOMAIN&api_key=$HUNTER_API_KEY" | jq '.data.result' 
"deliverable"

If a nonsense address returns deliverable, the domain accepts all mail and SMTP verification will not distinguish real from fake addresses on that domain. In this case, rely on source-based evidence instead: addresses that appear in actual documents, breach data, or public sources are more reliable than SMTP-verified addresses on catch-all domains.

References