Mailbox verification is a gate for an outbound record. Start with the submitted value, separate formatting and domain checks from mailbox checks, and turn the response into a route decision you can explain later. A positive response is evidence available at that moment, not a delivery guarantee.1 A blocked or inconclusive check leaves the address unresolved because it does not prove invalidity.2 Build the process around that uncertainty so a technical response does not become permission to contact someone.
Choose the workflow
Match the check to where the address enters your process. Use the same interpretation rules for individual records, lists, and forms.
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.3 A professional verification service can apply syntax, domain, mail-routing, and receiving-system checks at scale.4 For list operations, run the entire list through contact verification and verify new addresses as real, active accounts.5
Run the check in order
- Preserve
- Syntax
- Domain
- Mailbox
- Interpret
Work from the least specific signal to the most specific one. Each stage narrows what you can reasonably do with the address.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Preserve | whether the submitted value and its context are intact | What exact address arrived, and where did it come from? |
| Syntax | whether the value is structurally usable | Does the address contain an obvious formatting problem? |
| Domain | whether the domain has mail-routing evidence | Does this domain appear configured to receive mail? |
| Mailbox | what the receiving system says about this recipient | Can we assess this address without sending a message? |
| Interpret | how much confidence the response deserves | Is this a clear result, or does the response leave uncertainty? |
| Route | what should happen to the record | Should this address continue, be suppressed, or go to review? |
Preserve and clean the input
Start with the record you received. Clean it for use, but keep a trace of what was submitted.
Keep the submitted address, its collection source, and the relevant permission or subscription record.6 Remove obvious input errors and duplicates,7 and keep a record of corrections so later changes remain explainable.8
If a customer-submitted address may contain a typo, ask the customer to correct it instead of guessing a replacement.9 Preserve the original value while the correction is pending. The later verification result should remain connected to the address that entered the workflow.
Separate syntax from domain routing
A well-formed address has passed only an input check. Formatting, domain routing, and mailbox existence are separate questions.
Start with accidental spaces, a missing domain, and malformed input.10 Use an email-aware parser or a verification service to evaluate the address.11 A syntax pass means the input fits the rules being checked.12 It gives no evidence that the domain accepts mail or that the recipient exists.13
DNS checks examine the domain's mail-routing configuration.14 A working website does not prove that the same domain receives mail.15 Keep domain-level evidence separate from mailbox-level evidence.16 An absent MX record invokes SMTP's implicit-MX fallback, while a null MX explicitly announces that the domain does not accept email.17
At this stage, ask whether the domain has a usable routing result and whether the response is stable enough to interpret. Do not turn domain evidence into mailbox evidence.
Check the mailbox response
Once the domain result is clear enough to proceed, inspect the receiving system's response for the specific address. This makes the check mailbox-specific.
SMTP verification connects to the mail server and checks whether a specific mailbox is active without sending an email.18 A verification service may evaluate SMTP responses without submitting a message body.19 This is sometimes described as a zero-payload check.20
Use documented verification behavior and bounded retries.21 Record the response and its status instead of trying to force a more favorable answer. A mailbox check gives you a signal about the receiving system's response at that point in time, so keep the result attached to the address it tested.
Interpret the result
Read the response alongside the conditions that can weaken it. A response can help with routing without supporting a delivery promise.
Receiving servers can defer checks, restrict probing, accept broad recipient patterns, or return temporary responses.22 A catch-all domain can leave the individual mailbox unconfirmed.23 Mailbox conditions can change when administrators delete mailboxes or domains change to accept-all settings.24
Address characteristics also help interpret the result. A shared role inbox may support an operational purpose without representing a named individual.25 A disposable address may be unsuitable for a long-lived account.26 These characteristics and delivery status answer different questions,27 so apply the policies that fit your audience and workflow.28
Mailbox checks cannot prove that a particular person controls the inbox, consented to contact, or will receive the next message in the inbox.29 Keep those questions outside the mailbox result and handle them through the rules that govern your outreach.
Route and retain the result
Give every result a destination. A status without an action will eventually become an unsafe default.
The useful output is a decision: continue with an address that passes available checks, suppress a clear failure, or hold an inconclusive result for review.30 Continue only when the verification result and your audience rules support the next action.31 Route clear failures and unresolved results separately.32
Keep verification status and context together.33 Store the result with its timestamp and any documented risk indicators.34 If the workflow needs the user to demonstrate access to the mailbox, use a confirmation email for that purpose, since it serves a different purpose from address checking.35
Recheck when circumstances change.36 Review stale records, changed data sources, periods of inactivity, or deterioration in actual delivery results.37 Choose a cadence that fits how the data is collected and used.38
What not to do
Keep these mistakes out of the verification workflow.
- Do not treat an MX record as proof that an individual mailbox exists.39
- Do not convert a temporary DNS failure into a permanent invalid-address decision.40
- Do not repeat manual probing after a server starts limiting requests, since the results can become misleading.41
- Do not overwrite unsubscribe, complaint, or suppression history during cleanup.42
- Do not collapse uncertainty into a positive result to simplify a spreadsheet.43