A clear, technical walkthrough of how email verification actually works — syntax checks, MX lookups, SMTP probing, catch-all and disposable detection, and confidence scoring.
Every email you send is a small bet on an address being real. When that bet is wrong, the message bounces — and bounces are not free. Mailbox providers like Gmail and Outlook watch how many of your sends hit dead addresses, and a high failure rate tells them you are mailing a list you do not maintain. That quietly erodes your sender reputation, which is the trust score that decides whether your future mail lands in the inbox or the spam folder.
Email verification is the practice of checking an address before you send to it, so you can keep the deliverable ones and quarantine the rest. This guide walks through how a verification engine actually works, layer by layer — from a quick syntax glance all the way to a live conversation with the receiving mail server — and why an honest engine sometimes answers "I'm not sure" instead of pretending to know.
A hard bounce is a permanent delivery failure: the address does not exist, the domain has no mail server, or the mailbox has been shut down. Unlike a soft bounce (a temporary issue like a full mailbox), a hard bounce will never succeed no matter how many times you retry. As a rule of thumb, a healthy hard-bounce rate is generally under 2 percent; sustained rates above that are a strong signal to providers that your data is stale.
The cost compounds. A bad address can also be a spam trap — an address that exists only to catch senders who do not practice good list hygiene — and hitting one can land you on a blocklist. Verification is the cheapest insurance against all of this. BounceShift's job is to tell you whether an address is real, deliverable, and safe to send to, before a single message goes out.
A verification engine runs a series of checks in order, from cheap and instant to expensive and network-bound. The principle is simple: the first layer that can decide an address wins, and there is no reason to open a network connection if the address is already disqualified by its spelling. Here is how BounceShift moves through that pipeline.
Syntax validation is the first gate. The engine confirms the address conforms to the email standards (RFC 5321 and RFC 5322) — it has exactly one @, a sensible local part, a domain with a valid structure, and a length within spec. An address like jane.doe@ or jane@@example.com fails here instantly and is marked invalid.
Syntax is also where typo correction lives. Many "bad" addresses are not fake — they are fat-fingered. If someone types gmial.com or gnail.com, the engine recognizes the near-miss and suggests gmail.com. That single correction can rescue a real subscriber who would otherwise have been dropped, which is why typo handling is part of verification rather than an afterthought.
Two more cheap, decisive checks run early in the pipeline. Disposable email addresses come from throwaway services designed to self-destruct after a few minutes — useful for signing up once, useless for an ongoing relationship. The engine matches the domain against a maintained list and flags these as disposable.
Role-based addresses are tied to a function rather than a person: [email protected], [email protected], [email protected]. They often route to several people or to a shared queue, are more likely to generate spam complaints, and rarely represent an engaged subscriber. The engine flags them so you can decide whether they belong in a given campaign, rather than blocking them outright.
Before there is any point in probing a mailbox, the domain has to be able to receive mail at all. An MX record (Mail Exchange record) is the DNS entry that names the server responsible for accepting email for a domain. The engine queries DNS for the domain's MX records; if there are none — and no usable fallback — then no mail can ever be delivered there, and the address is invalid regardless of how the local part is spelled.
If MX records do exist, the engine also reads them to detect the underlying provider. The MX hostnames for Google Workspace, Microsoft 365, or a forwarding service look distinct, and knowing the provider shapes how the next steps behave.
SMTP (Simple Mail Transfer Protocol) is the language mail servers speak to hand messages to one another. SMTP verification takes advantage of that conversation: the engine connects to the receiving server and begins the handshake exactly as a real sender would, but stops short of delivering anything.
The key step is the RCPT TO command, which names the recipient. A correctly behaving server answers with a status code: a 250 means "I would accept mail for this recipient," while a 550 typically means "no such user here." The engine reads that reply to decide whether the mailbox exists — and then it ends the session. No message is ever sent. The recipient sees nothing; the probe is a question, not an email.
This is the most powerful signal in the pipeline and also the most fragile. Servers can be slow, can defer with greylisting (a temporary "try again later" used to discourage spammers), can rate-limit, or can sit behind a network where the outbound port needed for SMTP is blocked. When the conversation is inconclusive, the engine does not invent an answer — more on that below.
Some domains are configured to accept mail for every possible address, valid or not, and to sort it out internally afterward. These are catch-all domains. When the engine sends RCPT TO for a catch-all domain, the server says 250 — "accepted" — even for an address that does not actually have a mailbox behind it. The probe cannot distinguish a real inbox from a fictional one.
This is an honest dead end for the SMTP layer, and BounceShift labels it catch_all rather than forcing a valid or invalid verdict. To add information, the engine enriches the result with other signals: the reputation history of that exact address and per-domain patterns it has observed over time. Sometimes that enrichment is enough to raise confidence; often it is not, and the honest answer stays catch_all.
The checks above reason about an address in isolation. The strongest evidence, though, comes from what has actually happened when mail was sent to it. BounceShift operates a crowdsourced reputation network: when customers connect their email service provider webhooks — Mailgun, SendGrid, Postmark, Amazon SES — real bounce, delivery, and complaint outcomes flow back into scoring.
If an address has hard-bounced repeatedly across the network, that is far better proof it is dead than any single probe. If it has reliably delivered, that strengthens the case it is live. Privacy is built into the design: addresses in the reputation layer are stored only as one-way cryptographic hashes, so the system can recognize a repeat address without ever holding the raw text of it.
Every address that passes through the pipeline comes out with three things: a status, a more granular sub-status, and a confidence score from 0 to 100. The status is the headline verdict; the sub-status explains the reason; the confidence tells you how much weight to put on it.
| Status | What it means |
|---|---|
valid | The mailbox exists and is safe to send to. |
invalid | The address is not deliverable (bad syntax, no MX, or no mailbox). |
catch_all | The domain accepts everything; existence cannot be confirmed. |
risky | Deliverable but carries elevated risk. |
unknown | The probe was inconclusive; no confident verdict. |
disposable | A throwaway address from a temporary-mail service. |
spamtrap / abuse / do_not_mail | Addresses you should not send to. |
For sending decisions, "safe to send" means a status of valid or catch_all. Everything else deserves a closer look before it enters a campaign.
The most important design choice sits behind the unknown status. When a probe is genuinely inconclusive — greylisting, rate-limiting, a blocked outbound port, or a catch-all wall — many tools quietly round up to valid because it looks better. BounceShift does not. A false valid is treated as worse than an honest abstention, because a false positive is the one outcome that puts a real bounce on your record and damages your reputation. When the engine cannot confirm an address, it reports unknown or catch_all with low confidence and lets you decide, rather than guessing on your behalf.
How you verify depends on where the addresses come from. BounceShift exposes the same engine through three surfaces.
POST /v1/validate/single from your signup or checkout form and get a verdict back in roughly 200 to 500 milliseconds. This catches typos and bad addresses at the exact moment a person enters them, when you can still ask them to fix it.Used together, these three surfaces form a loop: verify addresses as they arrive, clean the list you already hold, and learn from what actually happens when you send. That loop is what keeps your bounce rate low and your deliverability healthy over time.
Get 100 free validations to test our service. No credit card required.
Start Free Trial