SMTP 電郵驗證實際如何運作，以及哪些情況會造成誤判

By Email Validation (Email Validation LLC). Learn more at https://email-validation.org.

An email address can pass a syntax check, look plausible, and still bounce. It can also look suspicious and be perfectly deliverable. SMTP verification exists to close that gap, but it does not remove uncertainty. It measures it, stage by stage, until a server either confirms a mailbox, rejects it, or refuses to say.

The pipeline

A careful verifier does not jump straight to the mail server. Each step removes a different kind of bad address, and each step can also stop early when the answer is already clear.

1. Syntax check. The address is parsed against the basic shape of a mailbox: a local part, an @, and a domain. This catches typos such as a missing @, spaces, or an empty domain. It says nothing about whether the mailbox exists.

2. Domain and MX lookup. The verifier looks up DNS records for the domain, especially MX records, which name the servers that accept mail for that domain. No domain, or no mail records, means mail has nowhere to go. A domain that exists but has never accepted mail is a different problem from a domain that simply cannot be reached right now.

3. SMTP handshake. The verifier connects to the mail server and starts a normal SMTP conversation, without sending a message. It sends EHLO to introduce itself, MAIL FROM with a return address, and then RCPT TO with the address being checked. The server's reply to RCPT TO is the key signal: acceptance suggests the mailbox exists, while a clear rejection, such as a 550 error, usually means it does not.

4. Catch-all detection. Before trusting an acceptance, the verifier probes a random, almost certainly nonexistent address at the same domain. If that address is also accepted, the domain is catch-all: it accepts everything, so a single acceptance proves very little.

5. Disposable and role-account flags. The address is compared with lists of disposable domains and role names such as info@, support@, or sales@. A disposable address may work today and be abandoned tomorrow. A role address may belong to a team rather than a person, which matters for consent, replies, and engagement, even when delivery succeeds.

6. Final status. Only then does the verifier combine the signals into a status and a reason. The reason matters as much as the status, because it tells you whether to remove the address, retry it, or treat it with caution.

Where it lies

The SMTP conversation is a real protocol exchange, but it is not a sworn statement. Several common server behaviors make its answers misleading if they are read literally.

Catch-all domains accept everything. Small businesses, some corporate domains, and many hosted domains accept mail for any local part and sort it out later, or discard it silently. A verifier that reports such an address as simply valid is overstating what it learned. The honest result is catch-all: delivery is possible, but the individual mailbox is unconfirmed.

Greylisting causes false "unknowns." Greylisting is a spam defense that temporarily rejects an unfamiliar sender, usually with a 4xx code, and expects a retry later. A verifier that checks once and stops will record the address as unknown, or worse, as invalid. A better verifier retries after a delay and distinguishes a temporary refusal from a permanent rejection.

Some providers accept, then bounce. Yahoo has historically been cited for accepting addresses that later bounce, and Microsoft's servers can use tarpitting, deliberately slowing responses to discourage bulk probing. In both cases, an immediate acceptance is not the same as a delivered message. The verifier must watch for delayed bounces in its own sending, not just the handshake result, and must avoid aggressive probing that gets its servers blocked.

SMTP probes can be blocked. Firewalls, rate limits, and anti-abuse systems may refuse connections, drop them, or return generic errors. When a probe is blocked, the verifier has no evidence about the mailbox. A good verifier retries with backoff, grades its confidence, and returns unknown rather than inventing a yes or no. Faking certainty is worse than admitting a gap, because a false valid pollutes a list and a false invalid deletes a real subscriber.

What statuses really mean

Most verification results fall into five buckets:

• Valid: The mailbox was confirmed, as far as the check could establish. Send to it, but still watch bounces, because mailboxes close and servers change their behavior.
• Invalid: Mail to this address will not arrive. Remove it. Common causes are a nonexistent mailbox, a dead domain, or malformed syntax.
• Catch-all: The domain accepts everything, so this mailbox cannot be confirmed. Do not mix these addresses with confirmed valid addresses when measuring list quality. Send to them only when the contact matters, and monitor bounces separately.
• Disposable: The address comes from a throwaway service. It may deliver briefly, but it is not a durable contact. Remove it from marketing lists and do not count it as a subscriber.
• Unknown: The verifier could not get a definite answer this time. This is an honest answer, not a failure of the tool. It usually means a timeout, a temporary server refusal, greylisting, or a blocked probe. Retry later, ideally with a fresh check, rather than guessing.

The practical difference is in the action. Valid means send. Invalid and disposable mean remove. Catch-all means send with caution and segment. Unknown means retry. A system that collapses all five into valid and invalid will eventually do all four of the wrong things at once.

Worked example with the Email Validation API

The Email Validation API follows the same pipeline and returns a status, a reason, and flags you can act on. The full endpoint is documented at https://email-validation.org/docs/api/validate/.

curl -X POST https://api.email-validation.org/v1/validate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "someone@example.com"}'

A sample response looks like this:

{
  "email": "someone@example.com",
  "status": "valid",
  "reason": "accepted",
  "action": "send",
  "role_account": false,
  "disposable": false,
  "catch_all_domain": false,
  "mx_found": true
}

Read the fields together. status is the verdict, reason explains why, and action is the recommended next step. The flags add context: role_account and disposable change how you treat an address even when it is deliverable, and catch_all_domain tells you whether an acceptance should be trusted. For EU data residency, requests can be sent to https://api-eu.email-validation.org/v1/validate.

For lists rather than single sign-ups, use bulk validation instead of looping single checks and hoping rate limits and retries work out. Credits are pay-as-you-go at $35 per 10,000, with up to 500 free credits to start.

The same checks are also available through an MCP server for AI agents, so an assistant can validate addresses, check a credit balance, and run bulk jobs from a chat client without building a separate integration. See https://email-validation.org/docs/mcp/ for setup details.

Closing: practical rules for list hygiene

1. Verify before sending. Check addresses at sign-up and before a campaign, not after a bounce has already damaged your sender reputation.
2. Re-verify old lists. People change jobs, close accounts, and abandon domains. A list that was clean a year ago is not clean now.
3. Treat catch-all segments separately. Do not let unconfirmed addresses dilute your engagement metrics or hide deliverability problems in your confirmed segment.
4. Retry unknowns, do not delete them on sight. A temporary refusal is not evidence that a person does not exist.
5. Act on the reason, not just the label. The difference between invalid, disposable, and catch-all is the difference between removing, suppressing, and monitoring.

SMTP verification is useful precisely because it is limited. It can tell you when a mailbox is clearly dead, when a domain accepts everything, and when it honestly does not know. Build your list hygiene around those distinctions, and your sending will be quieter, cleaner, and easier to trust.