Search DevTools

Jump to any tool or page

Advanced Email Validator

Comprehensive email validation with DNS records, security analysis, and deliverability insights.

Address

Report

Validate an email address to see its DNS, security, and deliverability details here.

API Development

About Email Validator

Check email addresses for syntactic validity, domain resolution, and common typos, either one at a time or across a pasted list in bulk. Syntax and deliverability are separate questions: an address can be perfectly well-formed, sit on a domain with valid MX records, and still bounce because no mailbox exists behind it.

Related API Development tools

API Test SimulatorAPI to ModelsWebhook TesterPhone ValidatorOpenAPI Explorer

Frequently asked questions

Why not just use a fully RFC 5322 compliant regex?
Because the grammar permits quoted local parts, escaped characters, nested comments, and folding whitespace, a genuinely complete pattern runs to several thousand characters and is unmaintainable. Worse, it accepts addresses no mail provider will issue, such as "a b"@example.com. Practical validation uses a deliberately stricter subset — single @, no leading or trailing dot in the local part, a domain with at least one label and a valid TLD — and accepts that it rejects a handful of technically legal but never-used forms.
What does an MX-record check actually prove?
That the domain publishes at least one mail exchanger, so mail sent there has somewhere to go. It says nothing about whether the specific mailbox exists. A domain with no MX record but a valid A record is still deliverable under the implicit-MX fallback in RFC 5321, so treating a missing MX as an automatic failure produces false rejections. Conversely, a valid MX on a parked domain will happily accept and discard everything you send.
Why can't SMTP verification reliably confirm a mailbox exists?
The classic technique opens a connection and issues RCPT TO without sending data, reading the response code. Most serious providers defeat it. Catch-all domains accept every recipient at the SMTP layer and bounce later, so you get a 250 for addresses that do not exist. Greylisting returns a temporary failure on first contact regardless of validity. And repeated probing from one IP earns a reputation penalty. The only conclusive test is a confirmation email with a click-through link.
How should disposable and role-based addresses be handled?
They are different problems. Disposable providers rotate domains constantly, so any blocklist is perpetually stale and blocking them outright costs genuine signups from privacy-conscious users. Role addresses — info@, support@, noreply@ — are usually valid but reach a shared inbox, which matters for password resets and for CAN-SPAM style consent, since no single person consented. Flag both as risk signals feeding a decision rather than as hard rejections at the form.
Are Gmail dots and plus-addressing the same address?
At Gmail, yes for dots and yes for the plus suffix: a.b+tag@gmail.com and ab@gmail.com deliver to one mailbox. That behaviour is provider policy, not standard — RFC 5321 says the local part is case-sensitive and opaque to everyone but the destination host. So normalising by stripping dots is safe only for known Gmail domains and wrong elsewhere. If you deduplicate accounts by normalised address, apply provider-specific rules, and never lowercase-and-strip generically.