Email & delivery / FIELD GUIDE

What is Email verification?

Email verification checks an address for evidence that it is correctly formed and potentially able to receive mail, using checks such as syntax, domain configuration and available mailbox-level signals.

Key takeaways

  • Verification evaluates evidence about an address; it cannot promise inbox placement.
  • Keep invalid, valid, catch-all and unknown outcomes distinct.
  • Check the right person, current context and suppression separately from mailbox status.

Overview

Verification reduces uncertainty; it does not guarantee inbox delivery or permission to contact someone. Results depend on the checks performed and the receiving server’s behavior. Some servers accept any recipient or hide mailbox status. Keep valid, invalid, catch-all and unknown outcomes distinguishable, and retain the verification date because addresses and mail systems change.

How it works

  1. Check syntax and the domain’s mail configuration.

  2. Apply available mailbox checks without interpreting blocked probes as definitive answers.

  3. Record a dated status and route risky or unknown results according to policy.

Understand what each check can establish

Email verification may combine syntax checks, domain and mail-routing checks, and observations from mail-server behavior. Each answers a different question. A syntactically valid address can have no usable destination, while a domain that accepts mail can still leave the existence of a specific mailbox uncertain. Read the provider’s status definitions rather than assuming every green indicator means the same thing.

A check also describes a point in time. Mailbox configuration, employment and receiving policies can change afterward. Preserve the method and check date alongside the result. The address’s verification status should not be inferred from the fact that it appeared in a company directory or was returned by an enrichment provider.

Interpret common verification outcomes
OutcomePractical meaningAppropriate next decision
Accepted by the verification policyAvailable checks support the addressStill check relevance, identity and suppression
InvalidA defined check found a disqualifying problemExclude or correct with evidence
Catch-allThe domain may accept unknown recipient namesApply an explicit uncertainty policy
UnknownThe check could not establish the needed resultReview or use a bounded recheck policy

Place verification before the consequential handoff

Normalize obvious formatting defects and resolve the contact identity before verification. Checking a deliverable mailbox for the wrong person does not make the prospect record correct. After verification, apply account exclusions and suppression close to delivery so a recent opt-out cannot be missed by a list prepared days earlier.

When a contact’s email changes, treat the new address as a new value requiring its own status. Do not carry a previous verification result across a field overwrite. Keep discovery, verification and communication permission as separate fields so another system cannot accidentally interpret one as proof of the others.

Evaluate the policy, not just the returned percentage

In an illustrative 1,000-address batch, 700 meet the verification policy, 100 are invalid, 120 catch-all and 80 unknown. A vendor that folds catch-all into “valid” will appear to have higher valid coverage than one that reports it separately. Compare the same status definitions and review how the workflow treats uncertainty.

Inspect later delivery failures by source, age and verification category, while remembering that rejection can result from sender or content policy rather than an invalid mailbox. Avoid claiming a universal accuracy rate from a small campaign. A useful evaluation reports the population, check date, outcome definitions and limitations.

ILLUSTRATIVE EXAMPLE

What this looks like in practice

A correctly formatted address points to a domain with mail service, but the server accepts every tested recipient. The workflow labels it catch-all rather than claiming the named mailbox is confirmed.

Examples explain the concept; they are not reported customer results.

What to check

Ask what each status means, how catch-all domains are handled and how results age. Measure real delivery outcomes without confusing acceptance with inbox placement.

Common mistake

Calling every syntactically valid address verified or treating verification as proof of consent, identity or future deliverability.

Email verification vs. Email deliverability

Verification assesses address-related evidence. Deliverability concerns whether a sent message reaches the intended inbox, which also depends on authentication, reputation, content and recipient behavior.

Read the Email deliverability definition →

Questions answered

What is Email verification?

Email verification checks an address for evidence that it is correctly formed and potentially able to receive mail, using checks such as syntax, domain configuration and available mailbox-level signals.

Can a verified email still bounce?

Yes. Mailboxes, policies and server conditions can change, and verification methods have limits. A status is evidence at a point in time, not a guarantee.

Should unknown results be treated as invalid?

Not automatically. Unknown can mean the server prevented a conclusive check. Keep it separate and decide whether to retry, review or exclude it for the intended use.

Does email verification send a message to the recipient?

Methods vary by provider. Some checks inspect syntax, DNS and SMTP behavior without delivering a message, while other workflows may use confirmation messages. Read the service’s documented method and side effects. Do not assume every product labeled verification performs the same operations.

Should unknown addresses be retried indefinitely?

No. An unknown result may reflect a temporary issue or a receiving system that does not reveal mailbox status. Use a bounded, provider-appropriate policy and preserve uncertainty when it remains unresolved. Repeated checks do not automatically turn an unobservable fact into a verified one.

References and further reading

Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.

  1. RFC 5321: Simple Mail Transfer ProtocolIETF / RFC Editor
  2. Email sender guidelinesGoogle

Continue reading on the blog

Explore all articles and guides →

Put the concept to work.

Explore the relevant AstroFabric workflow and see how the pieces connect.

Help keep this guide useful. Suggest a correction or browse the full glossary.