Can the input be parsed as a supported address?
Email verification guide
How to verify an email address
Check the address in stages: its format, its domain’s mail routing and, where appropriate, mailbox acceptance. Use a confirmation link when you need to establish inbox control.
Does the domain advertise a usable mail route?
Can the user complete an inbox confirmation?
What does email verification actually check?
Email verification evaluates evidence about whether an address is usable. A format check answers whether the input resembles a supported email address. DNS checks describe the domain’s mail route. A bounded SMTP check may observe whether a server currently accepts a recipient. A confirmation link establishes that someone can access the destination inbox.
More about What does email verification actually check?
These are separate questions. Before verifying an address, decide what you need: correcting a signup mistake, delivering a requested whitepaper, confirming a subscription or granting access to an account. Match the check to that purpose and keep uncertain results visible.
You can inspect syntax, DNS and some SMTP signals without sending an email. To establish inbox control, send a confirmation challenge. Neither approach proves a person’s legal identity or gives permission to send unsolicited marketing.
1. Clean the input without changing the mailbox.
Trim accidental whitespace around the address and normalise the domain using an appropriate internationalised-domain policy. Preserve the local part before the @ sign, including meaningful plus tags and dots. Lowercasing the entire string or applying one provider’s alias rules to every domain can change the destination.
More about 1. Clean the input without changing the mailbox.
If a likely domain typo is found, show a suggestion and ask for approval. A correction from one valid domain to another can send private information to the wrong person. Store the confirmed address rather than silently replacing what the user typed.
2. Check email syntax with a suitable parser.
For ordinary signup forms, a browser email input gives useful immediate feedback. Your backend still needs validation because browser checks can be bypassed. Use a maintained parser and a documented support policy for quoted local parts, internationalised domains and SMTPUTF8 addresses.
More about 2. Check email syntax with a suitable parser.
A short regular expression can catch obvious mistakes; it cannot verify that a domain or mailbox exists. Overly narrow rules reject legitimate addresses, including long top-level domains or plus-tagged local parts. Provider-specific grammar should only be applied when that provider is reliably identified.
3. Check the domain and its mail route.
Resolve the domain’s MX records to find its advertised mail exchangers and priorities. Check for an explicit Null MX, which declares that the domain does not accept email. If MX records are absent, SMTP can fall back to an A or AAAA record at the domain; missing MX alone is not sufficient to reject the address.
More about 3. Check the domain and its mail route.
Distinguish a nonexistent domain from a DNS timeout, SERVFAIL or another temporary resolver problem. Retry transient failures within a bounded policy. A domain with a working mail route passes a routing check, but an individual recipient can still be absent.
Maail’s free MX lookup is useful for public domain diagnostics. Enter a domain, not a private email address. Public DNS tools do not open an SMTP connection or test mailbox existence.
4. Review disposable, free-provider and role signals.
Disposable email services offer temporary inboxes. Free email providers offer ordinary long-lived accounts. Role addresses such as support@ may be shared by a team. These categories describe how an address may be used; none automatically means that the mailbox is invalid.
More about 4. Review disposable, free-provider and role signals.
People use temporary addresses for privacy as well as short-term access. Apply a policy appropriate to your offer, explain it and allow an alternative address. Provider classifications can become stale, so give genuine customers a review path.
Treat random-looking local parts cautiously. A generated alias can be a legitimate privacy tool. Likewise, a name-like address does not verify a person’s name, age, gender, nationality or employment.
5. Understand what an SMTP check can tell you.
Where permitted and operationally appropriate, a verifier can connect to a recipient mail server and observe a recipient response without sending DATA or a message body. A server rejection may provide useful evidence, but server responses need careful interpretation.
More about 5. Understand what an SMTP check can tell you.
Catch-all domains can accept any recipient during the conversation. Greylisting asks senders to try again later. Some providers block probes, conceal recipient existence or change their response according to the source. Keep accepted, rejected, catch-all, temporary-failure and unknown outcomes distinct.
An accepted recipient is a point-in-time observation. It is not a guarantee of delivery, inbox placement or ownership. Repeated probing can create privacy and abuse risks, so use authorisation, destination restrictions, rate limits and conservative retries.
6. Confirm inbox control for important actions.
Send a single-use, time-limited confirmation link for account activation, address changes or subscriptions when the workflow calls for it. Bind it to the intended action and handle expiry and resending clearly. Successful confirmation shows access to that inbox at that time.
More about 6. Confirm inbox control for important actions.
A confirmation email is different from sending an unsolicited test campaign and waiting for a bounce. Keep subscription consent records separate from technical validation, and do not treat a lack of bounce as proof of ownership.
7. Integrate verification on your backend.
Call the email verification API from your server so credentials never appear in page source. Set a deadline and handle unavailable checks explicitly. Use actionable form messages: ask for a correction on a definitive error, offer retry for a temporary failure and preserve the entered address.
More about 7. Integrate verification on your backend.
In Maail’s v1 specification, /v1/email/clean handles safe cleanup, /v1/email/validate describes syntax and routing, and /v1/email/analyze adds address context. The contract is a design specification; confirm endpoint availability during onboarding. SMTP is disabled by default, and null fields mean unknown or unavailable.
A response can have status=valid while mailbox.status=not_checked: the technical checks passed, but the mailbox was not probed. Keep that distinction in your application rather than presenting “verified person” to the user.
8. Limit the data you collect and retain.
Treat email addresses and inferred name hints as personal data. Use a suitable legal basis, describe the purpose, protect API credentials and agree processor terms where needed. Keep raw addresses out of query URLs, analytics events and diagnostic request IDs.
More about 8. Limit the data you collect and retain.
Maail’s specification calls for no-store responses and no raw payload retention for synchronous address checks. This is separate from operational metadata and from explicitly retained batch jobs or other mail workflows. Review the agreed service terms and privacy notice rather than assuming that every API operation stores nothing.
Email verification checklist
- Preserve the intended destination during cleanup and ask before applying typo suggestions.
- Check syntax and domain routing; recognise Null MX, implicit mail routing and temporary DNS errors.
- Keep disposable-provider and role classifications separate from technical validity.
- Use SMTP evidence conservatively and keep unknown results explicit.
- Confirm inbox control when your workflow requires it and record consent separately.
- Monitor real delivery feedback and suppress hard bounces after sending.
Technical references
The mail-routing and syntax distinctions above follow the SMTP and Internet Message Format standards. SMTPUTF8 support is a separate capability; choose a validation policy that matches your sending infrastructure.
Common questions
Can I verify an email address without sending an email?
You can inspect syntax and DNS routing without sending a message. An authorised SMTP check may observe recipient acceptance, but catch-all servers and anti-probing measures limit certainty. A confirmation message is needed to establish inbox control.
What is the difference between email validation and verification?
Vendors use the terms differently. Specify the actual checks: syntax, domain routing, provider classification, SMTP recipient response and inbox confirmation. Compare those checks and their uncertainty rather than relying on a label.
Can Google search prove that an email address is valid?
A public listing may be old or copied. It does not establish current mail routing, mailbox availability or inbox control. Treat search results as background context rather than a verification result.
Can a verifier reliably detect every spam trap?
Spam traps are not comprehensively identifiable through public DNS or mailbox checks. DNS blocklists describe listed IPs or domains, not proof that a particular recipient is a trap. Permission-based collection and list hygiene remain essential.
Email Verification for Gated Content & Whitepapers
Catch address mistakes at the download form and give interested readers a clear route to your content. Apply your own policy to disposable and shared inboxes.
Explore the guideEmail Validation for One-Field Newsletter Signup
Let readers subscribe with their email address. Catch input mistakes early, then collect preferences when there is a good reason to ask.
Explore the guideAcademic Email Checks for Education Discounts
Use an academic email as a low-friction starting point for education discounts, with a clear fallback when the address alone cannot establish eligibility.
Explore the guideGive every address a clear next step.
Discuss your form, address-quality rules and integration scope. Endpoint availability and enabled checks are confirmed during onboarding.