How to Verify an Email Address Before You Send

Email verification is not a checkbox. It is a short conversation your software has with a mail server, and the whole art is knowing how to read the answers, including the ones that mean "I honestly cannot tell."

Most people treat "verify this email" as a single yes-or-no operation: the address is either good or it is junk. That mental model is the source of nearly every deliverability disaster in outreach. Real verification is a sequence of increasingly expensive checks, each of which can pass, fail, or come back ambiguous, and the ambiguous cases are not a bug. They are the mail system working exactly as designed, protecting mailboxes from exactly the kind of probing that verification does. A tool that never returns "unknown" is not more accurate than one that does. It is lying to you.

This guide is the technical one. It covers what each layer of verification actually inspects, down to the SMTP commands on the wire, why the four confidence tiers exist and what "risky" and "unknown" really mean, why an unverified address is one of the most expensive things you can send, and how to run verification as part of a pre-send workflow rather than a panicked afterthought. It is written for recruiters, founders, and sales teams who already have an address in hand and need to know, before they send, whether a real person is on the other end.

Contents

1. What "verify" actually promises (and what it cannot)
2. The layers, from cheapest to most expensive
3. The SMTP handshake in detail
4. The four risk flags that change everything
5. The four confidence tiers, and why "unknown" is honest
6. Why an unverified address is expensive
7. Single verification versus bulk
8. A practical pre-send workflow
9. Where verification meets finding people
10. The bottom line

1. What "verify" actually promises (and what it cannot)

Start with the honest boundary of the whole exercise, because everything downstream depends on it. Verification predicts deliverability. It does not prove receipt, and it never proves a reply. The most a verifier can tell you is that, at the moment it checked, a mail server was willing to accept a message addressed to that mailbox. That is a strong and useful signal, but it is a prediction about the mail system, not a fact about the human behind it.

Three things verification genuinely establishes: that the address is syntactically legal, that the domain is configured to receive mail, and that the specific mailbox is likely to accept a message rather than reject it outright. Those three together are what stand between you and a bounce. When all three line up cleanly, you have a deliverable address, and deliverable is the whole point: a message you send has a real inbox to land in.

Now the limits, stated plainly, because a tool that hides them is selling confidence it has not earned. Verification cannot tell you the mailbox is monitored (people abandon inboxes and leave auto-forwarding on for years). It cannot detect a spam trap, an address that looks live and exists only to catch senders who mail without permission. It cannot promise the person still works there, only that the address still accepts mail. And on a large and growing share of domains, it cannot even confirm the mailbox exists, because the mail server is deliberately built not to tell. Holding both of these ideas at once, the real signal and its real ceiling, is what separates someone who uses verification well from someone who trusts a green checkmark and burns their domain.

2. The layers, from cheapest to most expensive

Verification runs as a pipeline, ordered so that the cheapest checks fail first. There is no reason to open a network connection to a mail server if the address does not even contain an @, and no reason to probe a mailbox if the domain has no mail servers at all. Each layer is a gate, and most bad addresses are caught at the first two before any real work happens. Understanding the order tells you exactly how much a "valid" verdict is worth, because it tells you which gates it actually passed.

Syntax: does it even look like an address

The first gate is format validation against the rules for an email address, which are defined by RFC 5322 (the Internet Message Format) and, for the transport envelope, RFC 5321. A verifier checks that there is exactly one @ separator, that the local part and domain use permitted characters, and that the domain looks like a real hostname rather than a fragment. This catches the enormous category of typos and paste errors: a trailing space, a missing dot, gmial.com, a name where an address should be.

Two honest caveats keep this layer from being oversold. First, the real syntax rules are far more permissive than most people expect: quoted local parts, plus-addressing, and unusual but legal characters are all valid, so a naive regex that rejects them produces false negatives, marking good addresses as bad. Second, and more important, passing syntax proves almost nothing. asdfghjkl@stripe.com is perfectly legal syntax and almost certainly not a real mailbox. Syntax is a filter for garbage, not a signal of deliverability, and any tool that stops here and calls the result "valid" is misusing the word.

Domain and MX: can the domain receive mail at all

The second gate is a DNS lookup for the domain's mail servers. To receive email, a domain must publish MX records (Mail Exchanger records), the prioritized list of hostnames authorized to accept mail on its behalf, a mechanism defined in RFC 5321. The verifier queries DNS, and the answer is decisive in one direction: no MX records means the domain cannot receive mail, full stop, and the address is undeliverable no matter how plausible it looks.

This layer is still cheap and deterministic: it is a DNS query, not a mail conversation, and it either returns mail servers or it does not. A subtlety worth knowing: a domain with no MX record but a valid A record can technically still receive mail at that host under the old fallback rules, so a careful verifier checks for that case rather than declaring a hard fail. But the common outcome is clean: MX present, proceed to the real test; MX absent, stop here. Passing this gate tells you the domain is a live mail destination. It still tells you nothing about the specific person's mailbox, which is what the next, and by far the most interesting, layer is for.

3. The SMTP handshake in detail

This is where verification earns its name, and where the mechanics get genuinely subtle. To test a specific mailbox without sending anything, the verifier does something clever: it begins the exact conversation a real mail server would begin to deliver a message, and then stops one step before actually sending it. The protocol for that conversation is SMTP (Simple Mail Transfer Protocol), specified in RFC 5321, and every step is a plain-text command with a numeric reply.

Here is the sequence, on the wire:

1. Connect. The verifier opens a TCP connection to the domain's highest-priority MX host on port 25, the standard port for server-to-server mail. The server answers with a 220 greeting if it is ready.
2. EHLO. The verifier introduces itself with the EHLO command (Extended HELO) and its own hostname. The server replies 250 and lists the extensions it supports. This is the handshake that establishes the session.
3. MAIL FROM. The verifier declares an envelope sender with MAIL FROM. Well-behaved verifiers use a real, reputable sending identity here, because the receiving server judges everything that follows partly on who is asking.
4. RCPT TO. The decisive step. The verifier issues RCPT TO:<person@domain.com>, which asks the server a single question: will you accept mail for this recipient? The server's numeric reply is the actual verification result.
5. QUIT. The verifier sends QUIT (or RSET) and closes the connection. Critically, it never issues the DATA command, the step that would transmit an actual message body. No email is ever delivered. The mailbox owner sees nothing.

That last point is worth dwelling on because it is widely misunderstood: SMTP verification does not send a test email. It conducts the delivery negotiation and hangs up before the payload, so a correctly built verifier is invisible to the recipient. The information lives entirely in the RCPT TO reply code, and reading those codes correctly is the heart of the craft:

• 250 (accepted). The server says it will accept mail for that recipient. On a normal domain this is the strongest positive signal there is: the mailbox very likely exists.
• 550, 551, 553 (rejected). A permanent negative reply, usually meaning no such user. This is a confident "undeliverable."
• 450, 451, 452 (temporary). A soft failure. The server is not saying no, it is saying not right now: greylisting, rate limiting, or a temporary block. This is the classic source of an unknown result, and it deserves a retry rather than a verdict.
• 252 (cannot verify, will accept). An explicitly ambiguous reply defined by the standard reply codes in RFC 3463: the server will not confirm the mailbox but will attempt delivery. That is a shrug, not a yes.

Two realities make this layer harder than the clean list suggests, and an honest guide names both. First, the historic verification command, VRFY, is dead in practice. RFC 5321 defines a VRFY command whose entire job is to confirm a user exists, but nearly every mail server disables it precisely because it leaks whether accounts exist to anyone who asks. So verifiers use RCPT TO instead, inferring existence from delivery behavior rather than asking directly.

Second, and this is the single most important operational fact in modern verification: major providers deliberately defeat the RCPT TO probe. Microsoft 365, which hosts a large share of corporate email, frequently accepts every recipient with a 250 and bounces the invalid ones asynchronously minutes later, which means the live probe cannot distinguish a real mailbox from a fake one on those domains. Some providers greylist unfamiliar probing IPs with a 4xx, and some throttle or block connections from IP addresses with no sending history. The consequence is unavoidable and worth internalizing: on a meaningful and growing slice of the internet, the most a verifier can honestly return is unknown, and the tools that pretend otherwise are guessing.

4. The four risk flags that change everything

Even a clean 250 is not automatically a green light. On top of the core existence check, a competent verifier runs a set of risk classifications that can turn an apparently valid address into one you should treat with caution, or one that is technically live but a bad idea to email. These flags are where the difference between a serious verifier and a cheap one is most visible.

Catch-all (accept-all) domains

This is the big one, the single largest source of false confidence in the entire field. A catch-all domain is configured to accept mail for every possible address at the domain, even ones that were never created, and forward or hold it. On such a domain, the RCPT TO probe is worthless: the server returns 250 for ceo@company.com and 250 for xq7z9k@company.com with equal enthusiasm, because it accepts everything. A verifier that reports that 250 as "valid" is reporting the domain's configuration, not the mailbox's existence.

The detection method is elegant and every good verifier uses it: probe a random, obviously fake local part first. Send RCPT TO for something like verify-probe-8f3a2@company.com. If the server rejects it, the domain is honest and its 250s mean something. If the server accepts the nonsense address, the domain is catch-all, and every result from it, including the real address you care about, has to be downgraded to risky rather than deliverable. This is not pessimism, it is accuracy: on a catch-all domain the address might be a real, monitored inbox or it might be a void that silently swallows mail, and the SMTP layer genuinely cannot tell you which.

Role accounts

A role account is an address tied to a function rather than a person: info@, sales@, support@, admin@, hello@, careers@. These addresses almost always exist and accept mail, so they pass the existence check cleanly, but they carry two problems for outreach. They are often distribution lists read by several people or none, and unsolicited mail to them draws complaints at a much higher rate than mail to a named individual. A verifier flags them not because they are undeliverable but because sending cold outreach to info@ is a deliverability and reputation risk dressed up as a valid address. If you are trying to reach a specific human, a role account is usually the wrong target, and a tool like PeopleSearch.im that returns a named individual's professional email exists precisely so you are not stuck emailing a shared inbox.

Disposable domains

A disposable (or temporary) email domain provides throwaway addresses that self-destruct after minutes or hours: the services people use to get past a signup wall. These addresses verify as deliverable in the moment because the mailbox really does exist right now, which is exactly why they are dangerous to trust. A verifier maintains a list of known disposable providers and flags any address on one, because a "deliverable" verdict on a disposable domain has a shelf life measured in minutes. For any real business relationship, a disposable address is a red flag regardless of what the SMTP probe says.

Greylisting

Greylisting is a spam-defense technique, described as an applicability statement in RFC 6647, in which a server temporarily rejects mail from any sender-recipient-IP combination it has not seen before, replying with a 4xx and expecting a legitimate mail server to retry after a delay. Real mail servers retry and get through; most spam does not bother. For a verifier that connects once and leaves, greylisting looks identical to a temporary failure, so it produces an unknown rather than a false verdict. Good verifiers handle this by retrying after a delay, which is one reason serious verification is not always instantaneous and why an honest "unknown, checking again" beats a hasty wrong answer.

5. The four confidence tiers, and why "unknown" is honest

All of the mechanics above collapse into a small set of verdicts, and the vocabulary matters because it is where tools quietly mislead. The four tiers that actually describe reality are deliverable, risky, undeliverable, and unknown. A verifier that only offers "valid" and "invalid" is hiding the two middle cases that carry the most important information.

• Deliverable. Syntax passed, MX present, the mailbox accepted the RCPT TO probe, the domain is not catch-all, and no disposable or role flag applies. This is a genuine green light: send with confidence.
• Risky. The address is live or plausibly live, but something reduces certainty: a catch-all domain where existence cannot be confirmed, a role account with high complaint risk, or an accept-all provider. Risky does not mean do not send, it means send with awareness: a small, warmed sending reputation can absorb the occasional risky address, a cold domain cannot.
• Undeliverable. A hard, permanent negative: no MX, a 550 no-such-user, or a malformed address. Do not send. Full stop. These are the addresses that would bounce, and bounces are the thing you are verifying to avoid.
• Unknown. The verifier could not get a definitive answer: greylisting, a provider that accepts-then-bounces, a temporary block, or a probe rate-limited by the receiving server. Unknown is not failure. It is the mail system refusing to leak information, and the correct response is to retry later or make a judgment call on the specific domain, not to force it into "valid" or "invalid."

The reason to insist on this four-way vocabulary is that the middle tiers are where the money and the risk both live. Collapsing "risky" into "valid" is how senders discover, one blown campaign later, that half their "verified" list was catch-all noise. Collapsing "unknown" into "invalid" is how they throw away perfectly good addresses on Microsoft-hosted domains. This is exactly why every professional email surfaced through PeopleSearch.im carries a confidence level instead of a blanket "verified" stamp, and why a reveal that genuinely cannot resolve a deliverable address refunds the credit rather than charging you for a shrug. Honest uncertainty, priced honestly, is worth more than a confident guess.

6. Why an unverified address is expensive

It is tempting to treat verification as optional polish. It is not, and the reason is sender reputation, the score that mailbox providers assign to your sending domain and IP based on how your mail behaves over time. The cost of skipping verification is almost never paid by the one bad email. It is paid by every email you send afterward, because a bounce is one of the highest-leverage negative signals in that score.

The mechanism is simple and unforgiving. When you send to an address that does not exist, the receiving server returns a hard bounce, and providers read a pattern of hard bounces as the signature of someone mailing a stale or purchased list, exactly the behavior their filters exist to punish. Deliverability practitioners generally hold that hard bounces should stay below 0.5% and total bounces under 1% to remain in good standing, and that a rate above 2% is dangerous while above 5% can trigger automatic filtering or blocklisting - Mailshake. A single send to an unverified list can blow through that entire budget at once.

The providers have made this concrete. Google's own Email sender guidelines instruct senders to authenticate their mail with SPF, DKIM, and DMARC, to make unsubscribing one-click, and, crucially, to keep spam complaint rates low, with a stated ceiling that senders should stay under and ideally well below. Since the joint Gmail and Yahoo bulk-sender requirements took effect in 2024, those expectations are enforced, not suggested: senders who cross the thresholds see their mail throttled or filtered. Underneath all of it sits authentication, the domain-level trust layer standardized by SPF (RFC 7208), DKIM (RFC 6376), and DMARC (documented at dmarc.org). Verification protects the reputation that authentication vouches for: you can prove a message came from you, but if what you send bounces, the proof works against you.

There is a second-order cost that is easy to miss. Reputation damage is portfolio-wide, not per-campaign. If you send from a shared domain or run mail for several accounts, one bad list can drag down deliverability for everything, and rebuilding a burned domain takes weeks of careful, low-volume sending. Set against that, verification is the cheapest insurance in outreach. It is also why the strongest tools resolve the address through a live lookup at the moment you need it rather than serving a cached row that may already be dead. If you want the full picture of how discovery, verification, and compliance fit together, the companion guide on how to find anyone's professional email address walks the whole chain end to end.

7. Single verification versus bulk

Verification comes in two shapes, and choosing the right one is mostly about what you already have and how fast you need it.

Single verification is the interactive case: you have one address, you paste it in, and you want an answer now. This is the right tool when you are about to reply to an inbound lead, confirm a contact before an introduction, or check the one executive you are trying to reach this week. A standalone email verifier runs the full pipeline (syntax, MX, SMTP probe, risk flags) on a single address and returns a tier in seconds. The tradeoff is that a lone probe is more exposed to greylisting and rate limits, since there is no batch window to retry within, so a single-check "unknown" is common and usually means "try again shortly."

Bulk verification processes a list, and it is a genuinely different engineering problem, not just the single flow in a loop. Probing thousands of mailboxes means respecting each receiving server's rate limits, spreading connections so you do not get your probing IP blocked, rotating sending identities, and retrying the greylisted and temporary results on a schedule. Done crudely, bulk verification gets your infrastructure blocklisted halfway through the list and returns garbage for the rest. Done well, it returns a clean breakdown across the four tiers with the unknowns honestly separated out rather than force-fitted. The important discipline with any bulk result is to re-verify close to send time: a list verified last quarter has already started to decay, and the whole point was to catch that decay before it becomes a bounce.

For programmatic needs, verification belongs inside your own systems: gate a signup form, clean a CRM import, or check an address at the moment a user types it. That is what an API is for, and PeopleSearch.im exposes these lookups to developers so verification can run where the data actually enters your business rather than as a manual chore after the fact.

8. A practical pre-send workflow

Verification is not a standalone task, it is a gate in a sending process. Run it at the wrong time (last quarter, on a list you then let sit) and it protects nothing. Run it in the right place, immediately before you commit to sending, and it catches decay before a provider ever sees it. Here is the sequence that keeps you in the inbox.

Reading the flow as an operating procedure:

1. Verify at send time, not before. Run verification as close as possible to the moment you actually send, because an address verified weeks ago has been decaying ever since. The goal is to catch a mailbox that went dead after you sourced it and before you mail it.
2. Act on the tier, not the label. Send freely to deliverable. Suppress undeliverable outright. Treat risky with a small, warmed reputation and a lighter touch. Hold unknown for a retry rather than gambling on it.
3. Suppress, do not delete. Keep a running suppression list of hard bounces and complaints, and check every send against it. An address that bounced once should never get a second attempt, because a second bounce doubles the reputational cost.
4. Warm before you scale. A brand-new sending domain has no reputation to spend, so it cannot absorb even a few risky addresses. Ramp volume gradually and keep early sends to clean, deliverable addresses only.
5. Watch the pattern, not the send. Track your bounce rate and complaint rate over time. A single bounce is noise, a climbing bounce rate is a warning that your sourcing has gone stale, and it is the earliest signal you will get before placement drops.

Notice what this workflow is not: it is not "buy a list, verify it once, and blast it." Every step narrows toward fewer, fresher, verified addresses, which is the only version of outreach that compounds instead of decaying. The teams that win at this send less mail to more accurate addresses, and both their reply rates and their sender reputation benefit.

9. Where verification meets finding people

Verification is most powerful when it is not a separate chore. If you find an address and verify it in one motion, resolved live at the moment you need it, the whole "is this real?" question disappears into the act of getting the address in the first place. That is the design principle behind PeopleSearch.im: describe the person you are looking for in plain English, get real masked profiles back, and spend a credit to reveal the individual and their professional email with a confidence level already attached. The verification is not a second tool you run afterward, it is baked into the result.

That matters differently depending on your starting point, which is why the individual lookups exist as focused tools. When you have a name and a company but no address, the email finder resolves the likely mailbox against the live server and returns what is actually deliverable rather than a guessed pattern. When you have an address but no name, a reverse email lookup maps it back to the person and their public profile, which is how you confirm you are talking to the right individual before you reply. When you are working from a LinkedIn profile, tools like find LinkedIn profile and company lookup connect the professional identity to the contact detail. Each is a different door into the same verified result.

And because most people know the kind of person they need long before they know a single name, the search itself works by description. Whether you are trying to reach recruiters, founders and CEOs, sales leaders, or software engineers, you can describe the role, industry, and company size, get real matches, and reveal only the specific people worth contacting, each arriving with a verified, confidence-scored email. You can see exactly how that prices out on the pricing page: search and preview are free, you start with free credits, and you spend only on the people you actually reveal, with the email credit refunded when no deliverable address exists. Verification stops being a step you remember to do and becomes the default state of every contact you keep.

10. The bottom line

Email verification is a conversation with a mail server, and fluency in that conversation is the difference between outreach that lands and outreach that quietly destroys your sender reputation. Everything in this guide reduces to a few durable truths. Syntax and MX catch the obvious garbage cheaply. The SMTP RCPT TO probe is the real test, and it works by starting a delivery and stopping before the send. The risk flags, catch-all above all, are where false confidence hides. And the four tiers, especially the honest "risky" and "unknown," carry more decision-making value than any green checkmark.

The single most important habit is to treat an address as a live fact to be proven, not a static record to be trusted. Verify at send time, respect what "unknown" is telling you, suppress your bounces, and send less mail to better targets. Do that and email stays the most direct channel there is. Skip it and you will spend 2026 wondering why your carefully written messages stopped landing, with no idea that a stale list three campaigns ago is the reason.

That conviction is the reason we built PeopleSearch.im the way we did: resolve the address live, attach an honest confidence level, and refund the credit when there is no deliverable email to find rather than charge for a guess. It is a small company in a field of much larger incumbents, and that honesty is the deliberate bet, because the mailbox providers are getting stricter about signal quality every year, and the future belongs to precision, not volume. That thesis comes from years on the recruiting side of this problem: our team came up building AI recruitment tools (including HeroHunt.ai), where the daily cost of stale, unverified data made the value of proving an address before you send impossible to ignore.

This guide reflects email verification mechanics and provider deliverability standards as of August 2026. SMTP behavior varies by receiving provider, and provider thresholds change, so verify current requirements before you launch a campaign.