Email Address Validator

What this tool checks

Six things, in roughly the order a real receiving mail server would care about them:

• Syntax. Does the address conform to RFC 5321/5322? The local part is up to 64 characters and made of allowed ASCII; the domain is a valid hostname with a TLD; there's exactly one logical @ separator; no leading, trailing, or consecutive dots in the local part.
• MX records. Does the domain publish at least one mail-exchange record? If not, RFC 5321 §5.1 falls back to the A/AAAA record as an implicit MX. If neither exists, no mail can be delivered.
• Disposable provider. Is the domain on a maintained list of known throwaway-email services (Mailinator, Guerrilla Mail, 10minutemail, the ~121k entries the disposable-email-domains dataset tracks)? Disposable addresses are legal but bad for signup forms.
• SPF. Does the domain publish a v=spf1 TXT record? A domain with no SPF is more likely to be unconfigured or abandoned.
• DMARC. Is there a DMARC policy at _dmarc.{domain}? Same signal — well-run domains publish DMARC.
• Typo detection. Does the domain match a known misspelling of a major provider (gmial.com, hotmal.com, yahoo.co, etc.)? If so, suggest the likely intended domain.

What this tool doesn't do

We don't connect to the mail server and probe whether the specific mailbox exists. There are two reasons:

• Most modern mail servers either reject VRFY outright or always say "user might exist" to anyone who asks — the verification rate is low enough that the cost-benefit doesn't work.
• The IPs that would do the probing get blacklisted fast. Cloudflare Workers can't open outbound SMTP connections anyway, so even the option isn't on the table.

The honest framing: this tool tells you whether an address could receive mail. It can't tell you whether the specific mailbox is currently provisioned. For a typical "is this a usable contact address" question that's enough — invalid syntax catches typos, missing MX catches dead domains, disposable detection catches throwaway signups, and the SPF/DMARC presence catches abandoned or hastily-set-up domains.

Why validate?

Three common workflows:

• Signup forms. Catch typos before sending the welcome email, flag disposable addresses, and avoid wasting credits on bounces. Pair this with a confirmation email — validation isn't a substitute for proving the address is reachable.
• Lead lists. Filter out obvious garbage and disposables before pushing a CSV into a CRM or sending platform.
• Customer support. When a user says "I never got the email," check whether their address even has a working MX before debugging deliverability further.

How disposable email lookup works

Services like Mailinator, Guerrilla Mail, 10MinuteMail, Temp Mail, and dozens of clones provide throwaway inboxes that work for a few minutes or hours and then disappear. They serve a real privacy purpose (signing up for a service you'll never use again), but for businesses they're a signal — disposable addresses can't be re-contacted, can't be invoiced, and are over-represented in fraud and abuse.

The bundled list covers about 121,000 exact domains plus 400 wildcard patterns. It's maintained as an open dataset on GitHub and updated when new throwaway services launch. Refreshing on our side is one npm update and a redeploy.

Cross-checking the domain's email posture

Once we've confirmed the domain can receive mail, the SPF and DMARC checks are bonus signal about how seriously the domain takes email. A domain that publishes a proper DMARC p=reject policy is almost certainly used for real correspondence; one with neither SPF nor DMARC is more likely to be a parked or hastily-set-up domain. For the full breakdown, the SPF checker, DMARC checker, and DKIM lookup give you the per-protocol detail.