Why 'looks like an email' isn't the same as 'is a real inbox'

"Validating" an email address usually means one of two very different things, and mixing them up leads to either overly strict forms that reject real addresses, or overly loose ones that accept obvious garbage.

Format validation

This checks that a string is *shaped* like an email address — has an @ symbol, a domain with at least one dot, no illegal characters. It's fast, requires no network calls, and catches typos and obviously malformed input. What it cannot tell you is whether that address actually exists or can receive mail — "notarealaddress@gmail.com" passes format validation just as easily as a real inbox does.

Domain and deliverability checks

A step further, checking whether the domain has valid MX records (mail server entries in DNS) confirms the domain is actually set up to receive email at all — catching typo'd domains like gmial.com that pass format validation but would bounce immediately. This still doesn't confirm the specific mailbox exists, just that the domain could theoretically receive mail.

True verification

The only way to actually confirm an inbox exists and is monitored is to send something to it and get a response — a confirmation link, a one-time code. This is why signup flows that matter (anything tied to account recovery, billing, or notifications) should always include an actual confirmation email rather than relying on format or domain checks alone.

A sane approach for most forms

• Use format validation client-side for instant feedback on obvious typos.
• Add a domain/MX check server-side if bounced signups are a real cost to you.
• Reserve full email confirmation for flows where a wrong address is actually costly — account creation, payment receipts, password resets.

Processa's email validator checks both format and domain/MX records in one step, which catches most bad input without needing a full confirmation-email flow for lower-stakes forms.