Bad email addresses in a signup form don't just clutter your database, they wreck deliverability. A high bounce rate signals to mailbox providers like Gmail and Outlook that your sending domain isn't trustworthy, and that reputation hit follows every email you send afterward, not just the bad ones.
If you're building a signup flow, a CRM integration, or a bulk import pipeline, ".com, missing TLD) before you spend a network round-trip on it.
A reasonably strict pattern catches the common cases, but don't over-engineer a fully RFC-compliant regex by hand. The spec allows for edge cases (quoted strings, escaped characters) that are rarely worth supporting and easy to get wrong. Use a maintained library or an API's syntax layer instead of a hand-rolled 200-character regex.
Layer 2: MX record / domain validation
MX record validation checks whether the domain after the @ symbol actually has a mail server configured to receive email. This is a DNS lookup, not an SMTP connection, fast, cheap, and it eliminates a large chunk of fake or typo'd domains (gmial.com, company.con) before you go further.
dig MX gmail.com +short
# 10 alt1.gmail-smtp-in.l.google.com.
# 5 gmail-smtp-in.l.google.com.
# ...
No MX record (and no fallback A record) means no mail can be delivered to that domain, full stop — it's a safe automatic reject.
Layer 3: SMTP handshake verification
SMTP verification opens a connection to the recipient's mail server and asks whether a specific mailbox exists, without actually sending a message. This is the layer that catches deleted accounts, typos in the local part (jhon@ vs john@), and mailboxes that were never created, the failures that syntax and MX checks can't see.
The sequence looks like this:
- Connect to the domain's MX server on port 25
- HELO/EHLO handshake to identify your sending server
- MAIL FROM: rather than opening raw SMTP connections from their own infrastructure. A dedicated service maintains IP reputation and rotation specifically for this, so your app's own sending domain never takes the hit.
Catch-all domains and why they break SMTP checks
A catch-all domain accepts mail to any local part at that domain, so SMTP verification can't distinguish a real mailbox from a nonexistent one. If [email protected] returns the same 250 OK as [email protected], the server is configured to accept everything and reject nothing at the mailbox level.
This shows up more often than you'd expect on smaller business domains where the mail admin never disabled catch-all routing. A verification pipeline should flag these as a distinct status: catch-all or unknown, rather than lumping them in with confirmed-valid or confirmed-invalid results. Treating a catch-all result as a hard "valid" inflates your list quality numbers without actually reducing bounce risk.
Build vs. buy: when an email verification API makes sense
Running your own SMTP verification at low volume (a signup form doing a handful of checks a day) is fine to build in-house. It stops being fine once you need to verify lists in bulk, because you run into IP reputation limits, greylisting delays, and the maintenance burden of keeping disposable-domain and role-based-address blocklists current.
Self-built SMTP check
Verification API
Setup time
Hours to days
Minutes (API key)
IP reputation risk
Your infrastructure absorbs it
Provider's dedicated IPs absorb it
Disposable/role-address detection
You maintain the list
Maintained for you
Catch-all handling
Manual logic required
Built-in status
Bulk list cleaning (100k+)
Slow, rate-limit prone
Built for volume
Best for
Low-volume, internal tooling
Signup forms, bulk list cleaning, CRM sync
If you're past the "quick regex check" stage and need mailbox-level accuracy without babysitting SMTP rate limits, an API like MailValid handles syntax, MX, SMTP, catch-all, and disposable-domain detection behind a single endpoint — useful if you'd rather ship the feature than maintain the verification layer.
A minimal Node.js example
Here's a bare-bones example combining syntax and MX checks (the two layers safe to run yourself), with a placeholder for handing off SMTP-level verification to an API:
CODE
javascriptconst dns = require('dns').promises;
const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
async function validateSyntax(email) {
return EMAIL_REGEX.test(email);
}
async function validateMX(email) {
const domain = email.split('@')[1];
try {
const records = await dns.resolveMx(domain);
return records && records.length > 0;
} catch (err) {
return false; // no MX record, or domain doesn't resolve
}
}
async function verifyEmail(email) {
if (!(await validateSyntax(email))) return { valid: false, reason: 'syntax' };
if (!(await validateMX(email))) return { valid: false, reason: 'no_mx_record' };
// SMTP-level (mailbox existence) verification is best delegated to an API
// to avoid IP reputation issues from raw SMTP probing at scale.
// const result = await mailValidClient.verify(email);
return { valid: true, reason: 'passed_syntax_and_mx' };
}
This gets you two-thirds of the way there for free. The remaining one-third, mailbox-level confirmation is where the infrastructure tradeoffs above actually matter.
Frequently Asked Questions
Does email verification guarantee zero bounces?
No. Verification confirms a mailbox accepted the address at check time, but mailboxes get deleted, quotas fill up, and spam filters can still soft-bounce a valid address. Verification reduces hard bounces significantly; it doesn't eliminate all bounce risk.
Is SMTP verification the same as sending a test email?
No. SMTP verification stops before the DATA command, so no message is actually delivered or seen by the recipient. It only confirms the server's response to RCPT TO.
Why do some verification tools mark valid-looking emails as "unknown"?
Usually because the domain is a catch-all, the mail server is temporarily unreachable (greylisting), or the server refuses to confirm mailbox existence for anti-harvesting reasons. "Unknown" is a legitimate result, not a failure of the tool.
Can I do this entirely client-side in the browser?
Only the syntax layer. MX and SMTP checks require server-side DNS/network access that browsers don't expose for security reasons.↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR