Email address validation

Email validation should be a sendability gate with a limited job. Move from the address itself to the domain, then to the receiving system, and record what each layer actually tells you. 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.¹ A passing result still cannot prove that a person controls the inbox, consented to contact, or will see the next message there.² Build your workflow around those limits, and you avoid turning a technical pass into permission to send.

Set the decision

Decide what your workflow will do with a result before you run the check. A parser result, a domain signal, and a receiving-system response answer different questions, so give each one a place in your decision rule.

Start by defining what "valid" means for the send.³ Email address validation covers correct syntax and functionality.⁴ For outbound, turn that definition into an action rule: can the address enter the send queue, should it be suppressed, or does it need review?

Preserve the original address value and avoid silently changing it into a different address.⁵ Keep the original beside the check result so a reviewer can see what was submitted and what the system evaluated.

Clean the input

Start with the address as it was captured. This stage removes obvious input problems and keeps later checks attached to the right value.

Check for accidental spaces, a missing domain, and malformed input.⁶ Use an email-aware parser or verification service; a short regular expression cannot serve as complete validation.⁷ A syntax pass means that the input fits the rules being checked.⁸ Move on once the address has a clean shape, and keep the domain and receiving-system checks separate.

Check domain routing

Move outward after the address passes the shape check. This stage tells you whether the domain presents mail-routing evidence, while leaving the individual mailbox question open.

DNS checks examine a domain's mail-routing configuration.⁹ An MX record points to a mail exchanger; it does not identify individual mailboxes.¹⁰ A working website is no proof that the same domain receives mail.¹¹

An absent MX record and a null MX carry different meanings. When no MX records return, SMTP defines an implicit-MX fallback; a null MX explicitly announces that the domain does not accept email.¹² Keep domain-level evidence separate from mailbox-level evidence.¹³ That separation stops a healthy domain signal from becoming an unsupported recipient decision.

Test receiving-system signals

With domain evidence recorded, inspect signals from the receiving mail system without putting a message in the recipient's inbox. This layer can inform the send decision while keeping the limits of the check visible.

A verification service may evaluate SMTP responses without submitting a message body.¹⁴ This is sometimes called a zero-payload check.¹⁵ Read the response as a signal from the receiving system, then compare it with the syntax and domain results.

The absence of a delivered message does not make the result definitive. Receiving servers can defer checks, restrict probing, accept broad recipient patterns, or return temporary responses.¹⁶ A positive response is evidence available at that moment, not a delivery guarantee.¹⁷ Record the result with enough context for someone else to understand why the address passed, failed, or needs review.

Choose the campaign action

Now turn the layered result into a campaign action. The useful workflow is one that makes the same decision when the list is small and when a new audience is being added.

These checks can identify invalid addresses and uncertainty before a campaign or CRM import.¹⁸ For cold outreach, validate emails and filter out invalid addresses.¹⁹ Run the check before an address enters the send path, then keep the decision attached to the record.

A last-minute verification pass is possible while setting up a campaign.²⁰ Verifying email addresses on a contact list can improve deliverability rates.²¹ Use that final pass to catch list changes made after the first review, with the same disposition rule already in place.

What not to do

The common failures come from giving one signal more authority than it has. Keep these boundaries in the workflow.

• A syntax pass does not establish that the domain accepts mail or that the recipient exists.²²
• If a submitted address may contain a typo, ask the submitter to correct it instead of guessing a replacement.²³
• A temporary DNS failure should not become a permanent invalid-address decision.²⁴
• Adding new audiences with addresses that are no longer valid may contribute to hard bounces.²⁵
• Validation can block invalid or risky addresses at signup and reduce the likelihood of bounces.²⁶

You can now set the rule once, apply the checks in order, and make campaign entry depend on the result. That keeps technical validation from carrying promises it cannot make.