How email validation works

When Truelist validates an email address, it runs through a series of checks to determine whether the address is deliverable. Each check builds on the previous one, and the final result reflects everything we learned along the way.

Step 1: Syntax check

The first thing we check is whether the email address is properly formatted. An address like user@example.com is valid syntax, while user@@example is not. If the syntax is invalid, we stop here and return an invalid result.

Step 2: DNS and MX record check

Next, we look up the domain’s DNS records to find its mail exchange (MX) servers. These are the servers responsible for receiving email for that domain. If the domain has no MX records, it cannot receive email, and we return an invalid result.

Step 3: SMTP mailbox verification

This is the core of the validation process. We connect to the domain’s mail server and ask whether the specific mailbox exists, using the same protocol (SMTP) that email servers use to deliver mail to one another.

The mail server’s response tells us whether the address is deliverable:

• Mailbox exists - The server confirmed the address is valid and accepting mail.
• Mailbox does not exist - The server explicitly rejected the address.
• Temporary failure - The server responded with a temporary error (such as greylisting). Truelist will retry these automatically.

Step 4: Accept-all detection

Some domains are configured to accept mail for any address, even ones that don’t have a real mailbox. For these accept-all domains, the SMTP check will always report that the mailbox exists, so we cannot confirm individual address deliverability. These results are classified as risky.

Step 5: Role and disposable address detection

After the SMTP check, we determine whether the address is a role-based address (like info@, support@, admin@) or belongs to a known disposable email provider.

Role addresses

Role addresses are classified based on what we learned from SMTP verification:

• OK / Role - SMTP confirmed the mailbox is deliverable, but it’s a role address rather than a personal one.
• Risky / Role - The domain is accept-all, so we can’t confirm deliverability, and the address is role-based.
• Invalid / Role - SMTP confirmed the mailbox does not exist.

This means that if a role address is confirmed deliverable by the mail server, it will be classified as ok rather than risky. For more on whether you should send to role addresses, see Is it ok to send to role addresses?

Disposable addresses

Addresses from known disposable or temporary email providers (like Mailinator) are always classified as risky, regardless of the SMTP result. These domains are designed for short-term use and the addresses may stop working at any time.

Additional verification (Enhanced strategy)

When you use the Enhanced validation strategy, Truelist goes beyond SMTP verification. If the SMTP check is inconclusive — for example, if the mail server is unresponsive or returns an ambiguous response — we fall back to additional verification methods. These include cross-referencing third-party data sources and using browser-based verification techniques to determine whether the address is real.

This multi-stage approach means the Enhanced strategy can resolve addresses that would otherwise come back as “unknown” with the Accurate or Fast strategies.

Retries and IP rotation

Mail servers sometimes reject connections temporarily — due to greylisting, rate limiting, or because they’ve blocklisted the connecting IP address. When this happens, Truelist automatically retries the connection from a different IP address. We maintain a pool of sending IPs and rotate between them to maximize the chance of reaching the mail server.

If a mail server blocks one of our IPs, we detect this and route subsequent attempts through a different one. This process is fully automatic and happens behind the scenes. Truelist will make multiple attempts before giving up and returning an unknown result.

Result caching

Truelist caches validation results so that if you validate the same email address again — whether in the same list or a future one — we can return the previous result without repeating the full validation process. This speeds up validation for overlapping lists and reduces unnecessary load on recipient mail servers.

How results are classified

Every email address receives two attributes: an email state and an email sub-state. The email state is the high-level classification, while the sub-state provides the specific reason.

The sub-state tells you why the address received that classification. For a full reference of all sub-states and what they mean, see Understanding the verification results.