Email deliverability glossary: 40 terms every sender should know
Forty email deliverability terms defined in one or two sentences each: bounces, SPF, DKIM, DMARC, spam traps, greylisting, sender reputation, inbox placement and verification.
What is email verification and how does SMTP verification work?
Email verification checks whether an address can really receive mail. We walk through syntax, MX, reputation lists, the SMTP handshake, catch-all probes and scoring.
Email verification is the process of checking whether an address can actually receive mail before you send to it. Proper verification goes well beyond checking the spelling: it looks up the domain's mail servers, then opens a real SMTP conversation with the receiving server and asks whether the mailbox exists, all without sending a message. The result is a verdict you can act on: deliverable, undeliverable, risky or unknown.
Why "looks valid" is not the same as "exists"
An address can be perfectly well formed and still be dead. The person left the company, the domain lapsed, the mailbox was never created, or the user typed gmial.com. None of that shows up in a regular expression.
Around 22% of addresses on a typical list decay every year, and roughly 15% of addresses collected through forms are invalid at the moment they are captured. Sending to those addresses produces hard bounces, and mailbox providers start throttling senders once bounce rates creep towards 2%. Verification exists to catch those addresses first.
The six stages of a real verification
We run every address through the same pipeline. Each stage can end the check early with a firm verdict, or pass the address along for a deeper look.
1. Syntax
The address is parsed against the rules of RFC 5321 and 5322: one @ sign, a local part no longer than 64 characters, a domain with valid labels, no stray spaces or unbalanced quotes. We also apply practical rules that the RFCs allow but no real mailbox uses, such as rejecting comments in the local part. Our email syntax checker runs this stage on its own if you want to see it in isolation.
Syntax failures are the cheapest to catch and they are surprisingly common in form data: double @ signs, trailing full stops, pasted text with a name attached.
2. DNS and MX records
Next we ask DNS whether the domain exists and whether it publishes MX records. An MX record names the servers that accept mail for the domain. No MX record and no A record fallback means nothing can deliver there, so the address is undeliverable.
This is also where typos surface. A domain like outlok.com may resolve, but it does not belong to Microsoft, and its mail servers will not know your contact. You can see exactly what we see with the MX lookup tool.
3. Reputation lists
Before we spend an SMTP connection, we compare the domain and the local part against our lists: more than 10,000 disposable providers, the major free mailbox providers, and the role prefixes such as info, sales and support. A match does not necessarily make the address undeliverable, but it changes how the result is scored. A disposable domain is almost always a dead end for marketing; a role account may be fine for B2B but carries consent problems, which we cover in our post on role-based addresses.
4. The SMTP handshake
This is the stage most lightweight checkers skip, and it is the one that produces the answer. We connect to the highest priority MX server on port 25 and hold a short, standard conversation:
- The server greets us with a 220 banner.
- We send EHLO with our hostname, and the server lists what it supports.
- We send MAIL FROM with a sender address, so the server knows who is asking.
- We send RCPT TO with the address we are checking.
- We send QUIT.
Nothing else happens. We never send the DATA command, so no message body is transmitted and no email lands in anyone's inbox. The recipient sees nothing, and there is nothing to unsubscribe from. The whole exchange usually takes less than a second.
The reply to RCPT TO is what we are after, and we show you the full transcript so you can read it yourself.
Reading the reply codes
| Reply | Meaning | Our verdict |
|---|---|---|
| 250 | Recipient accepted | Deliverable, subject to the catch-all probe |
| 550 5.1.1 | User unknown, mailbox does not exist | Undeliverable |
| 550 5.7.x | Policy rejection, sender blocked or relay denied | Unknown, retried from another route |
| 450 / 451 | Temporary failure, usually greylisting | Unknown, retried later |
| 452 / 552 | Mailbox full or over quota | Risky |
Greylisting deserves a note. Some servers reject the first attempt from an unfamiliar sender with a 450 and expect a retry a few minutes later. We retry on a schedule rather than marking the address bad, because a greylisted mailbox is often perfectly healthy.
A full mailbox is a different story. The address exists, but mail to it is currently bouncing, and a mailbox that stays full for months usually belongs to someone who has stopped reading. We mark it risky so you can decide.
5. The catch-all probe
A 250 is not always proof. Some domains are configured to accept every address, real or not, and sort it out afterwards. To detect this we send a second RCPT TO with a random, impossible local part. If the server accepts that too, the domain is a catch-all and the original 250 tells us nothing about the specific mailbox. The address is scored as risky rather than deliverable. The catch-all checker runs this probe on any domain, and we explain the behaviour in depth in catch-all domains explained.
6. Scoring
Finally every signal is combined into a score from 0 to 100 and one of four verdicts:
- Deliverable: the mailbox was confirmed and nothing counts against it.
- Undeliverable: syntax, DNS or the server itself said no.
- Risky: the address may work, but it is catch-all, full, role-based or otherwise unreliable.
- Unknown: the server would not give an answer, usually a timeout or a persistent greylist.
The score lets you set your own line. A conservative sender might mail anything above 80; a cold outreach team might accept catch-alls at 50 and watch the bounces.
Why database-only verifiers are a guess
Some services never talk to a mail server at all. They check syntax, look up MX, and then compare the address against a database of addresses that have been seen before. If the address is in the database it is "valid"; if not, it is "unknown" or quietly marked valid anyway.
That approach has two problems. First, the database is a snapshot of the past, and addresses decay at over a fifth per year. Second, most of the addresses on your list were never in anyone's database to begin with, because they belong to ordinary people at ordinary companies. The only way to know whether sara.khan@example.com exists today is to ask example.com's mail server today. That is what the SMTP handshake does, and it is why we show the transcript: you should not have to take our word for it.
What to do next
Paste any address into the free email checker to watch all six stages run and read the SMTP transcript line by line. For a whole list, upload it to the bulk email verifier, and if you want every signup checked before it reaches your database, look at real-time verification through the API or the form widget.
