Email Address Validator

Instantly check whether an email address matches a practical RFC 5322-style format, and verify whether its domain can actually receive mail (MX record lookup). Free tool for form validation and mailing list cleanup.

Email format verdict examples

Example address Verdict Reason
[email protected] Valid Basic format (local part @ domain part)
[email protected] Valid Tagged address using a period and a plus sign
[email protected] Invalid Two consecutive periods in the local part
@example.com Invalid The local part (before "@") is empty
user@example Invalid The domain has no top-level domain (e.g. .com)
user example.com Invalid No "@" symbol is present

Usage tips

  • Even a correctly formatted address like "[email protected]" is not guaranteed to actually receive mail — the MX record check below gives you a rough idea of that.
  • When cleaning up a mailing list, it is efficient to first filter out obvious typos with the format check, then confirm the domain itself is valid with the MX record check.
  • Major domains like Gmail and Outlook always have MX records, but a company's own domain may lack them right after setup or due to a misconfiguration.
  • A stray trailing space left over from copy-pasting an address can cause the format check to fail — watch for extra whitespace around the input.
  • If you want real-time validation in your own signup form, the practical regular expression discussed in the side note below can be reused directly.

Frequently asked questions

This tool does not support a few unusual constructs that RFC 5322 technically allows, such as a quoted local part or an IP-literal domain (e.g. user@[192.0.2.1]). It uses a practical approximation that covers the vast majority of real-world addresses rather than aiming for full spec compliance.

No. An MX record only shows that the domain has a mechanism to receive mail — it says nothing about whether the mailbox named before the "@" actually exists. The only reliable way to confirm a mailbox exists is to actually send a message and check whether it bounces.

In rare cases a domain falls back to using its A record (the domain's own IP address) to accept mail instead of an MX record. This is a discouraged configuration, though, and almost every mail server today has MX records set up correctly.

The format check and MX lookup are useful as an initial screening step, but before a large send you should also verify your sender SPF/DKIM/DMARC configuration and confirm your list is opt-in. Sending in bulk to invalid addresses can damage your sending domain's reputation.
ツールくん

Side Note — why email validation happens in two stages

Email validation is easier to understand once you split it into two distinct layers: format and existence. The format check is a purely static test of whether a string has the right shape (local part, @, domain part) and never touches the network. Confirming existence, on the other hand, requires a DNS lookup against the domain, which a browser cannot perform directly from JavaScript — it has to happen on the server. This tool splits the two into separate steps precisely because they are technically different kinds of checks.

RFC 5322 defines the formal grammar for email addresses, and it is surprisingly intricate. For example, quoting the local part in double quotes legally permits spaces and consecutive periods that no real-world mail server would ever actually use. Because of this, most practitioners skip a fully compliant parser in favor of the simplified regular expression defined by WHATWG's HTML Living Standard, and this tool follows the same pragmatic approach.

An MX record is a DNS entry that says which mail server should receive mail for a given domain, and lower preference values are tried first. When a company migrates its mail infrastructure, it is common to keep several MX records active at once during a gradual cutover. If no MX record exists at all, mail sent to that domain is very likely to be rejected by the receiving side.

→ Browse all trivia