Real-time email validation on sign-up forms: how it works and what it catches
Real-time email validation checks an address as it is typed: syntax, typos, disposable domains, role accounts, MX and an optional mailbox check. Here is how it works.
Forty email deliverability terms defined in one or two sentences each: bounces, SPF, DKIM, DMARC, spam traps, greylisting, sender reputation, inbox placement and verification.
This email deliverability glossary defines the 40 terms that come up most often when a team tries to work out why mail is bouncing, landing in spam or going unopened. Each entry is one or two sentences, grouped by topic and alphabetical within each group, with links to the longer guides where they exist. Deliverability is the share of sent mail that reaches the inbox, and nearly every term below moves that number.
A domain whose mail server accepts mail for every address, real or not, so a verifier cannot confirm a specific mailbox and marks it risky. See catch-all domains explained.
A temporary address from a throwaway provider that expires within minutes or hours, used to get past a signup without giving a real inbox. Check one with the disposable email checker.
A signup flow in which the subscriber must click a confirmation link before being added, proving they control the address. Compared in double opt-in vs single opt-in.
A consumer mailbox service such as gmail.com, outlook.com or yahoo.com whose domain says nothing about the owner's employer. B2B teams often segment these; see free providers vs business domains.
The rate at which addresses on a list stop working, typically around 22% a year through job changes, abandoned mailboxes and lapsed domains. How fast lists go bad breaks it down.
An address for a function rather than a person, such as info@, sales@ or support@, usually read by several people and more likely to bounce or complain. Covered in role-based addresses and deliverability.
A set of test addresses you control at many providers, included in a send to observe where the message lands. Used to measure inbox placement.
A signup flow that adds the address immediately with no confirmation step. Faster growth, but typos and fake addresses enter the list unless real-time verification catches them.
An address that never signs up for anything, maintained by a provider or blocklist operator to identify senders with poor list hygiene. Hitting one damages reputation; see what is a spam trap.
A rule for removing or pausing subscribers who have not opened or clicked for a set period, often 90 to 180 days, before their inactivity drags down reputation.
A list of addresses that must never be mailed again: unsubscribes, hard bounces, complainers and legal opt-outs. Checked against before every send.
Authenticated Received Chain, a header that preserves authentication results when a message passes through forwarders or mailing lists that would otherwise break SPF and DKIM.
Brand Indicators for Message Identification, a standard that displays your logo beside messages in supporting inboxes once DMARC is enforced and a logo record is published.
A sending IP address used only by your organisation, so your reputation is entirely your own. Only worth it above roughly 100,000 messages a month.
DomainKeys Identified Mail, a cryptographic signature added to each message that lets the receiver confirm it was not altered in transit and was authorised by the signing domain.
A DNS policy that tells receivers what to do with mail failing SPF or DKIM alignment (none, quarantine or reject) and where to send reports. Required for bulk senders to Gmail and Yahoo.
Gradually increasing volume from a new IP or domain over two to six weeks so receivers can build a reputation history before full volume arrives.
The DNS record naming the servers that accept mail for a domain. No MX record usually means nothing can be delivered there; explained in MX records explained.
The SMTP command that names the recipient of a message. The server's reply to it is what verification reads to learn whether a mailbox exists.
A sending IP used by many customers of the same provider, pooling their reputation. One bad neighbour can affect everyone.
Simple Mail Transfer Protocol, the conversation mail servers hold to hand over a message: greeting, EHLO, MAIL FROM, RCPT TO, DATA, QUIT. Verification uses the first four steps and never sends DATA.
Sender Policy Framework, a DNS record listing the servers allowed to send mail for your domain. Setup for all three protocols is in SPF, DKIM and DMARC setup.
SMTP reply codes where 4xx means a temporary failure (try again later) and 5xx means a permanent one (do not retry). 550 5.1.1 is the classic "user unknown".
The share of sent messages returned as undeliverable. Providers begin throttling senders around 2% hard bounces; the bounce rate calculator shows where you stand.
A receiving server's practice of rejecting the first attempt from an unfamiliar sender with a 4xx and accepting a retry minutes later. Harmless for mail, confusing for verification; see greylisting explained.
A permanent delivery failure, usually because the address or domain does not exist. The address should be suppressed immediately; compared in hard bounce vs soft bounce.
A temporary delivery failure such as a full mailbox or a server that is down. Retry, and suppress the address if it keeps soft bouncing.
A published list of IPs or domains observed sending spam or hitting traps, consulted by receivers when deciding whether to accept mail.
The share of delivered messages in which a recipient clicked a link. A more reliable engagement signal than opens.
The share of delivered messages recipients reported as spam. The Gmail and Yahoo bulk sender rules set a 0.3% ceiling and a 0.1% target.
The collective signals receivers use to judge whether recipients want your mail: opens, clicks, replies and moves out of spam, against deletes without reading and complaints.
A mechanism by which a mailbox provider reports spam complaints back to the sender so the complainer can be unsubscribed.
The share of delivered mail that lands in the inbox rather than the spam folder. Delivery rate counts acceptance; inbox placement counts where it went.
The share of delivered messages that were opened, measured by a tracking pixel. Inflated by privacy features that load images automatically.
Google's free dashboard showing your domain's reputation, spam rate, authentication results and delivery errors at Gmail.
A receiver's running assessment of a sending domain and IP, built from bounces, complaints, trap hits, authentication and engagement. It decides whether mail is accepted, throttled or filtered.
Checking whether an address can receive mail by validating syntax, resolving MX records and asking the mail server over SMTP whether the mailbox exists, without sending a message. The full process is in how SMTP verification works.
A 0 to 100 number summarising every verification signal: 90 to 100 deliverable, 60 to 89 risky or unknown, 30 to 59 unknown or risky, 0 to 29 undeliverable.
The first stage of verification, checking the address against RFC 5321 and 5322 rules: one @ sign, a valid local part and domain, no illegal characters.
A misspelling of a real provider's domain such as gmial.com or hotmal.com. Verification returns a did_you_mean suggestion so forms can offer the correction.
Delivery rate is the share of messages the receiving server accepted. Deliverability, or inbox placement, is the share that reached the inbox rather than spam.
Authentication (SPF, DKIM, DMARC), IP warm-up, bounce rate and complaint rate. Get those four right and most other problems do not arise.
No. A spam trap is an address used to detect bad senders; a blocklist is the published result of that detection, which receivers consult.
Only positively. It never sends a message, so receivers see nothing, and removing undeliverable addresses prevents the bounces that would have hurt reputation.
Related reading
@Real-time email validation checks an address as it is typed: syntax, typos, disposable domains, role accounts, MX and an optional mailbox check. Here is how it works.
@Gmail, Outlook and Yahoo addresses carry no company signal, so B2B teams segment them. When free addresses are legitimate, how the free and role flags route them, and bulk detection.
@Role accounts like info@ and sales@ belong to a function, not a person. Why ESPs distrust them, the consent problem, when B2B senders can still use them and how to detect them.
Photos: Freepik