Email Validator & MX Checker

Free Email Validator and MX Record Checker

Paste an email address and this tool checks whether it is well formed, whether its domain publishes mail exchanger records, whether that domain is a known disposable provider, whether the local part looks like a role account rather than a person, and what kind of provider is behind it. You get a deliverability score out of 100, an expandable breakdown for each check, and exportable results. A bulk tab handles up to 10,000 addresses from a CSV file, processed in batches of 200.

The single most useful thing this page can tell you is also the one most email-verification marketing gets wrong, so it is worth stating up front: an MX record proves that a domain is configured to receive mail. It does not prove that a specific mailbox exists. Everything below follows from that distinction.

What an MX Record Actually Proves

When a sending mail server has a message for alice@example.com, it queries DNS for the MX records of example.com. It gets back a list of hostnames with numeric priorities, lowest first:

The sender tries the lowest priority first and falls back through the list. That is the whole mechanism. The DNS answer is published by the domain owner and describes the domain, not any mailbox within it. Google’s MX records are identical for a company with 40,000 employees and for a domain someone registered this morning and never used.

So an MX check answers a genuinely useful question — is there any chance mail to this domain gets delivered? — and it catches a large share of real-world bad data: typo domains such as gmial.com, domains that expired, and domains that were never configured for mail. It cannot answer “does alice exist there?”

One nuance the tool reports: if a domain has no MX records but does resolve an A or AAAA record, some senders will still attempt delivery to that address as an implicit mail exchanger. That is a legacy fallback, it is unreliable in practice, and it is flagged separately from “proper MX records found”.

Why We Do Not Probe Individual Mailboxes

The technique people expect is an SMTP probe: connect to the mail exchanger on port 25, issue EHLO, MAIL FROM, then RCPT TO: <alice@example.com>, and read the response code without ever sending DATA. A 250 supposedly means the mailbox exists and a 550 means it does not.

In practice that test is unreliable often enough to be dangerous as a data-cleaning input:

• Catch-all domains accept everything. A large share of business domains are configured to accept mail for any local part and sort it later. RCPT TO returns 250 for alice@, zzzz@, and anything else. Every address on such a domain scores as valid, which is worse than no signal because it looks like a positive result.
• Major providers deliberately do not tell you. Microsoft 365 and several large hosts accept at RCPT and reject later, so the probe learns nothing about real mailboxes.
• Greylisting returns a temporary failure to unknown senders by design. A 4xx code means “try again later”, not “invalid”, and verification services that treat it as a rejection discard valid addresses.
• It looks exactly like reconnaissance. Repeated RCPT TO probes without a following message are the classic signature of directory harvest attacks. Mail providers rate-limit, tarpit, and blocklist the source IP addresses that do it — and if you run the probe from your own mail server, you can damage the sending reputation you were trying to protect.
• Outbound port 25 is usually blocked from cloud providers and consumer connections anyway, so the check often cannot run from where you want to run it.

For those reasons the SMTP mailbox simulation in this tool is shown as an upcoming feature rather than a check that runs. If a vendor promises per-mailbox verification with high confidence and no caveats, ask them specifically how they handle catch-all domains and greylisting; the answer is informative.

The reliable way to confirm a mailbox exists is to send it something a human acts on — a confirmation link, a double opt-in email — and to process bounces and complaints properly afterwards.

What the Tool Checks

• Syntax — the local part and domain are validated against RFC 5322 structure, including length limits and the shape of the top-level domain. This catches missing @ signs, trailing dots, illegal characters, and addresses that were truncated by a form.
• DNS and MX records — the domain’s mail exchangers are listed in a table with their priorities, and the A/AAAA-only fallback case is called out explicitly.
• Disposable providers — the domain is matched against a database of throwaway and temporary mailbox services, the kind used to get past a signup gate. High-value for filtering trial abuse.
• Role accounts — local parts such as info, support, sales, admin, noreply, and postmaster are shared mailboxes rather than individuals. They are perfectly valid addresses; they are a poor fit for personalised marketing and often a compliance problem for consent records.
• Provider insight — classifies the address as a free consumer provider, a business domain, or an unrecognised host, with the provider name where it can be identified.
• Deliverability score — a 0–100 gauge combining the above into a single rating, with the reasoning shown per check rather than hidden.

How to Use It

1. Single tab — type or paste one address and validate. Expand each section for the underlying detail: the actual MX table, the syntax rules applied, the disposable match, the provider classification.
2. Bulk tab — upload a CSV of up to 10,000 addresses. They are processed in batches of 200 with the same MX, disposable, role, and provider checks, and the results come back as a downloadable file.
3. API tab — documentation for calling the validation endpoint from your own code, including a sample POST payload and the response shape, for wiring validation into a signup form or a CRM import.
4. History panel — your recent validations are kept in your browser’s local storage with a rolling valid-rate and average score, so you can spot a list that is systematically bad.
5. Export — copy a result as plain text or JSON for attaching to a ticket or an audit trail.

Reading the Result Sensibly

Treat the checks as tiers of confidence, not as a single verdict:

Used this way the tool removes the addresses that are certainly wrong before you spend sending reputation on them, which is where most of the value in list hygiene actually sits. The remainder is confirmed by mail, not by inspection.

Related Tools

MX records are only one of a domain’s mail-related DNS entries. Check SPF, DKIM, and DMARC alignment with the email authentication validator, build a policy record with the DMARC record generator, look up any record type directly with the DNS lookup tool, and check for lookalike sending domains with the domain spoofing detector.

Frequently Asked Questions

Does a valid MX record mean the email address is real?

No. It means the domain has published mail servers and can receive mail. Any local part on that domain will produce the same MX result, whether the mailbox exists or not. Confirming a specific mailbox requires sending a message the recipient acts on.

Why does the tool not verify the mailbox over SMTP?

Because the result would be misleading. Catch-all domains accept every recipient, several major providers accept at RCPT TO and reject afterwards, and greylisting returns temporary failures that are easily misread as rejections. Repeated probing also looks like a directory harvest attack and gets sending IP addresses rate-limited or blocklisted.

What is a catch-all domain?

A domain configured to accept mail addressed to any local part rather than only to defined mailboxes. It is common on business domains so that misspelled addresses still arrive. It is also the reason per-address SMTP verification returns false positives on exactly the domains you most want to check.

What counts as a role account and should I reject them?

Addresses tied to a function rather than a person — info@, support@, sales@, billing@, noreply@. They are legitimate and often the correct contact for a business. Flag them so they go to a shared-inbox workflow rather than a personalised sequence, and be careful about treating one person’s consent as consent for a shared mailbox.

Can I check a whole list at once?

Yes. The bulk tab accepts a CSV of up to 10,000 addresses and processes them in batches of 200, running the syntax, MX, disposable, role, and provider checks on each, with the results available for download.

Is there an API?

Yes — the API tab documents the endpoints, including the bulk validation route, with an example request payload and the JSON response structure so you can validate at signup time rather than after the fact.

Does the domain having no MX record always mean mail will bounce?

Usually, but not always. If the domain has an A or AAAA record, some senders fall back to treating that host as the mail exchanger. The tool reports this case separately because it is a genuinely ambiguous result rather than a clean failure.

How accurate is the disposable-domain list?

It catches the well-known throwaway services, which covers the majority of casual signup abuse. New disposable domains appear constantly, so treat a clean result as “not on the list” rather than “definitely a durable mailbox”. Pairing it with a confirmation email closes the gap.

Is my data stored?

Validation history is kept in your own browser’s local storage and can be cleared from the page. Addresses submitted for validation are processed to run the DNS and list lookups and are not retained as a marketing list.

Will validating a list improve my deliverability?

Removing syntactically invalid addresses and domains with no mail servers reduces hard bounces, and bounce rate is one of the strongest reputation signals mailbox providers use. It will not fix poor engagement, missing authentication, or a list acquired without consent — check SPF, DKIM, and DMARC alignment as well.