Email Verifier

An email verifier tells you whether an address is worth sending to before you hit send, import it into your CRM or let it sign up for your app. Our free Email Verifier and email checker checks one address or a pasted list of up to 50. It verifies the email address format against the rules mail servers follow, spots common typos such as gmial.com, confirms the domain exists and has mail servers (MX records), detects domains that refuse all mail, and flags disposable inboxes, role addresses like info@ and free providers. You also get the domain's SPF and DMARC status as a trust hint. Each address gets a clear verdict, valid-looking, risky or invalid, with the reasons behind it. We never send mail to the address, and we do not store what you check.

How to use the Email verifier

1. 1 Choose one address or a listUse One address for a quick check, or switch to Bulk list and paste up to 50 addresses, one per line. Commas and semicolons also work, and duplicates are removed.
2. 2 Run the checkPress Verify. For a list, the addresses are checked in small batches and the progress bar shows how far along it is. You can stop a long run at any time.
3. 3 Read the verdict and reasonsEach address is marked Looks valid, Risky or Invalid. The reasons explain why: a syntax error, a domain that does not exist, a disposable provider, a likely typo and so on.
4. 4 Open the detailsSee the MX records with their priorities, the mail provider when we recognise it, whether the domain publishes SPF and DMARC, and the role, free and disposable flags.
5. 5 Fix, remove or exportAccept a typo suggestion with one click, remove invalid addresses, and copy the table or export it as CSV to clean up your list in a spreadsheet.

What an email verifier checks

Most bounced emails fail for boring, predictable reasons: a typo in the address, a domain that has expired, a company that moved to a new domain, or a throwaway inbox that was deleted an hour after sign-up. A verifier catches as many of these as possible without sending a message, so you can fix the address while the person is still on your form or before the address reaches your mailing list.

This tool runs a series of checks in order and stops early when an address clearly cannot work. Syntax comes first, because there is no point looking up a domain for an address that no mail server would accept. Then it looks at the domain in DNS, the public directory that tells senders where to deliver mail. Finally it compares the address against lists of disposable domains, role-based mailboxes and free providers, which do not make an address undeliverable but do change how much you should trust it.

• Syntax: the format rules from RFC 5321 and RFC 5322, such as one @ sign, no spaces, no double dots and a length limit of 64 characters before the @.
• Typos: near misses of big providers, such as gmial.com, hotmial.com or gmail.co, and mistyped endings such as .con.
• Domain: whether the domain exists at all, and whether it has A or AAAA records.
• MX records: the mail servers for the domain, in priority order, plus detection of a null MX record that says the domain takes no mail.
• Disposable, role and free flags, and the domain's SPF and DMARC records as a hint about how well it is run.

Syntax rules that trip people up

The official rules for email addresses are surprisingly permissive. RFC 5322 allows quoted local parts with spaces inside them, comments in brackets and a long list of punctuation characters. In practice, very few mail systems and sign-up forms accept the unusual forms, so this verifier follows a practical subset. It accepts letters, digits and the characters ! # $ % & ' * + / = ? ^ _ ` { | } ~ . and - before the @, and it marks quoted addresses as risky rather than invalid, because they are technically allowed but often rejected.

The most common real-world errors are simple: a missing @, a space copied from a document, a comma instead of a dot, two dots in a row, or a dot at the very start or end of the name. The domain part must have at least one dot, each label can only use letters, digits and hyphens, a label cannot start or end with a hyphen, and the ending must look like a real top-level domain. Plus addressing, such as jane+newsletter@example.com, is valid and widely supported, so the tool does not flag it.

Internationalized addresses are handled too. A domain written with accented or non-Latin characters is converted to its ASCII form (punycode) before the DNS lookup. A local part with non-ASCII characters is allowed by RFC 6531, but plenty of mail servers still cannot deliver to it, so it is marked risky.

MX records, null MX and domains that cannot receive mail

When someone sends you an email, their server looks up the MX records for your domain to find out which servers accept mail for it. Each MX record has a priority number, and lower numbers are tried first. A domain with no MX records at all is a strong sign that it was never set up for email. RFC 5321 does allow senders to fall back to the domain's A or AAAA address in that case, but domains that genuinely receive email almost always publish MX records, so the verifier marks the address as risky rather than valid.

Some domains go further and publish a null MX record, defined in RFC 7505. It is a single MX record with priority 0 and a target of a lone dot, and it means "this domain does not accept email, do not try". Organisations use it for domains that only host a website or that exist purely for brand protection. An address on a null MX domain is invalid, however real the domain looks.

If the domain does not exist in DNS at all, the lookup returns NXDOMAIN and any message to it will bounce. That is common with typos, expired domains and made-up addresses typed into forms to get past a gate.

Disposable, role-based and free addresses

Disposable or temporary email services hand out inboxes that work for minutes or days and then disappear. People use them to grab a download or a discount code without giving a real address. They are not invalid at the moment of sign-up, which is why simple format checks miss them, but they will never read your follow-up emails. This tool flags them as risky using the open disposable-email-domains list, a community-maintained list of several thousand domains published on GitHub and dedicated to the public domain under CC0. Subdomains of a listed domain are matched too. New throwaway services appear all the time, so no list is complete.

Role-based addresses, such as info@, sales@, support@ or admin@, reach a team, a shared inbox or sometimes nobody. They are perfectly normal for business contact, so they keep a valid verdict with a note. On marketing lists, though, several people may see the message and any one of them may hit the spam button, so many senders treat them with care. No-reply addresses are marked risky, because mail sent to them is usually discarded or bounced.

Free providers such as Gmail, Outlook.com, Yahoo and iCloud are flagged for information only. A free address is a real, deliverable mailbox; the flag simply tells you it is not tied to a company domain, which matters if you sell to businesses or want to confirm that a sign-up comes from a particular organisation.

Why no tool can guarantee a mailbox exists

Some verification services connect to the recipient's mail server and start an SMTP conversation, asking whether it would accept mail for a given address and then hanging up before sending anything. We deliberately do not do this. Many large providers accept every address at that stage and only bounce later, some reply the same way whether or not the mailbox exists, and repeated probes from one server look like a spammer harvesting addresses, which can get that server blocklisted. Many hosting providers also block outgoing connections on port 25 for the same reason.

Catch-all domains make the problem worse. A catch-all domain is configured to accept mail for any address, so jane@ and xyz123@ both look fine to every outside check, even if only one of them is read by a person. The only reliable way to prove an inbox exists and is wanted is to send a message and get a response, which is what a double opt-in confirmation email does. Treat Looks valid as "nothing we can see would stop delivery", not as proof that a person reads that inbox.

SPF and DMARC as a trust hint

SPF and DMARC are DNS records a domain publishes to protect its own outgoing mail. SPF lists the servers allowed to send for the domain, and DMARC tells receivers what to do with messages that fail authentication, with a policy of none, quarantine or reject. They have nothing to do with whether the domain can receive your email, so they never change the verdict.

They are still a useful signal. A business domain that publishes both, especially with a DMARC policy of quarantine or reject, is usually actively managed. A domain with neither is more likely to be old, parked or set up in a hurry. If you are checking your own domain and SPF or DMARC are missing, our SPF and DMARC checkers explain how to add them.

Privacy, limits and how to use the results

Addresses you check are processed during the request and sent back to your browser. We do not save them, log them or add them to any list, and we never email them. The only thing cached, for a few minutes, is the public DNS information for each domain, so checking several addresses at the same company is fast. You can check up to 50 addresses per run; for larger lists, split them into several runs.

Use the results to clean, not to punish. Fix obvious typos and remove invalid addresses before importing a list. Review risky addresses rather than deleting them automatically: a role address may be your best contact at a small business, and an address on a domain without MX records may belong to someone who forwards mail in an unusual way. For sign-up forms, combine a quick check like this with a confirmation email, and respect the email marketing and privacy rules that apply where you and your subscribers are based.

Examples you can copy

jane.doe@gmail.com       Looks valid  Free provider
sales@acme-widgets.com   Looks valid  Role-based address (note)
someone@gmial.com        Risky        Did you mean someone@gmail.com?
test@mailinator.com      Risky        Disposable email domain
noreply@example.org      Invalid      Reserved documentation domain
hello@nomail.org         Invalid      Null MX (RFC 7505), takes no mail

acme-widgets.com.  MX  10 aspmx.l.google.com.
acme-widgets.com.  MX  20 alt1.aspmx.l.google.com.

Lower numbers are tried first. A null MX looks like:
nomail.org.        MX  0 .

Common mistakes to avoid

Frequently asked questions