Email validation goes wrong in two directions: too loose and you collect typos and bounce your sending reputation, too strict and you reject addresses that are perfectly valid. A workflow that layers cheap checks before expensive ones fixes both. Here is the order that works.
Do not write an RFC 5322 regex. Use the HTML5 input type="email" rule or your language's standard library parser. The limits worth enforcing are the real ones: 64 octets for the local part, 254 octets for the whole address as it appears in an SMTP envelope. Reject addresses with spaces or two consecutive dots; accept plus signs, apostrophes and long TLDs, because o'brien+news@example.marketing is a real address and rejecting it is a bug.
Lowercase the domain always — domains are case-insensitive. Do not lowercase or strip tags from the local part before sending, because the standard says the local part is case-sensitive and the mailbox owner decides. Keep a separate normalised column (lowercased, plus-tag stripped, Gmail dots removed) purely for duplicate detection, and send to the original string.
Roughly all of the addresses that never receive mail are simple domain typos: gmial.com, hotmail.co, yahoo.con. A domain-suggestion pass — mailcheck-style Levenshtein against a list of the top few hundred mail domains — recovers those with a "Did you mean gmail.com?" prompt. This single step converts more sign-ups than any blocklist ever will.
dig MX example.com +short tells you whether the domain can receive mail at all. No MX and no A record means the address is undeliverable and you can reject with confidence. Cache the answer per domain for a day — you are looking up the same twenty domains over and over. Do not treat a missing MX with a valid A record as invalid; SMTP falls back to the A record.
Connecting and issuing RCPT TO without sending data is technically possible and practically unreliable. Large providers accept everything and bounce later, catch-all domains accept everything by design, greylisting returns a temporary failure on first contact, and hammering port 25 from your app server is a fast route onto a blocklist. Use a paid verification API if you need this, and treat the answer as a probability rather than a fact.
A confirmation link proves the address exists, that a human reads it, and that they want your mail. Nothing upstream proves all three. Send the confirmation from your production sending domain with SPF, DKIM and DMARC aligned, so the confirmation itself is not the message that lands in spam.
Wire your ESP's bounce webhook to a suppression table. Hard bounces get suppressed immediately and never retried; soft bounces get a few attempts before suppression. Most providers start warning when hard bounces exceed a couple of percent of a send, and the fix is always the same — stop mailing addresses that already bounced. A validator that runs once at sign-up and never again is only half a workflow.