Mailbox verification is a sequence: clean the address, inspect its domain mail route, query the receiving system, and decide what to do. The result tells you what to do next: continue with a passing address, suppress a clear failure, or hold an inconclusive result for review.1 A positive verification response is evidence available at that moment, and delivery remains unguaranteed.2
Protect the submitted value first and define what counts as a correction. Keep this stage mechanical so later checks evaluate the submitted address rather than an untracked guess.
Check for accidental spaces, a missing domain, or malformed input.3 Use an email-aware parser or a verification service instead of treating one short regular expression as complete validation.4 A syntax pass means the input fits the rules being checked.5 Keep the syntax result separate as you continue to the domain checks.
Preserve the original address and avoid silently changing it into a different one.6 When a customer-submitted address may contain a typo, ask the customer to correct it instead of guessing a replacement.7 Remove obvious input errors and duplicates, then keep a record of corrections.8, 9 Keep the submitted address, its collection source, and the relevant permission or subscription record together.10
The domain check asks whether the address has a plausible route to a receiving system. It provides domain-level context, while the mailbox check covers the individual recipient.
DNS checks examine the domain's mail-routing configuration.11 An MX record identifies a mail exchanger, but it does not identify individual mailboxes.12 An absent MX record permits an implicit-MX fallback, while a null MX explicitly announces that the domain does not accept email.13 Treat a temporary DNS failure as a condition for review or retry, not as a permanent invalid-address decision.14 Keep domain-level evidence separate from mailbox-level evidence.15
The mailbox-level check collects a response from the receiving infrastructure without creating a real message for the recipient. SMTP verification connects to the mail server and checks whether the specific mailbox is active without sending an email.16 A verification service may evaluate SMTP responses without submitting a message body.17 This is sometimes described as a zero-payload check.18
Treat the response as a signal with limits. A missing delivery leaves the result open because receiving servers can defer checks, restrict probing, accept broad recipient patterns, or return temporary responses.19 Use documented verification behavior and bounded retries, and stop before repeated probing chases a desired answer.20
An accept-all mail server accepts messages sent to any address, real or not, so a verifier cannot fully confirm that the individual mailbox exists.21 A full-mailbox result can mean the address cannot receive messages because storage is insufficient or because the receiving system limits the number of messages it accepts.22
Classify the interpreted response as a pass, a clear failure, or unresolved. Keep an unresolved result out of a simple yes or no until the response has been interpreted.
Use the response to choose the next action, and keep delivery status separate from what the address appears to represent. Continue only when the verification result and your audience rules support the next action.23 Route clear failures and unresolved results separately.24 Treat a blocked or inconclusive check as unresolved. It does not prove that the address is invalid.25
Keep verification status and its context together.26 Store the result with its timestamp and any documented risk indicators.27 Address characteristics and delivery status answer different questions.28 A catch-all domain can leave the individual mailbox unconfirmed.29 A disposable address may be unsuitable for a long-lived account.30 A shared role inbox may support an operational purpose without representing a named individual.31 Apply the policies relevant to your audience and workflow instead of making every characteristic an automatic deletion rule.32
A verification check cannot prove that a particular person controls the inbox, consented to contact, or will receive the next message in the inbox.33 Automated scoring can confirm that a mailbox exists while leaving unresolved whether the person still works there, holds the correct title, or is a genuine decision-maker.34 Use a confirmation email when the user needs to demonstrate access to the mailbox.35 Keep the action, its reason, and enough context for another rep to understand the decision.
Choose the verification path when the address enters your process. The same checks can support an individual record, a list cleanup, or an application flow.
Use a single-address workflow for an individual record, bulk verification for a list, or an API when the check belongs inside a form or application process.36 Run the entire list through contact verification and verify that new addresses are real, active email accounts.37 A professional verification service applies syntax, domain, mail-routing, and receiving-system checks at scale.38
Recheck an address when circumstances change.39 Review stale records, changed data sources, periods of inactivity, or deteriorating actual delivery results.40 Choose a cadence that fits how the data is collected and used.41
What not to do
Common errors happen when one layer of the check is treated as if it answers every question.
- Do not treat a syntax pass as proof that the domain accepts mail or the recipient exists.42
- Do not assume a working website proves that the same domain receives mail.43
- Do not repeat manual probing until a receiving server produces the answer you want, since request limits can make the result misleading.44
- Do not collapse uncertainty into a positive result to simplify a spreadsheet.45
- Do not treat an address generated by an AI system or supplied by a data vendor as ready for contact; it still requires verification and an appropriate basis for contact.46
- Do not overwrite unsubscribe, complaint, or suppression history during cleanup.47