Validating an email address means confirming three things: that the address is written correctly, that its domain is configured to receive mail, and that the specific mailbox behind it actually exists. The first two take seconds, and a script can do them. The third is where most validation stops returning answers, and it is the layer that decides whether your next campaign bounces.
That third layer matters more in B2B than anywhere else. Corporate mail servers are routinely configured in ways that withhold the answer: catch-all configurations accept every address you hand them, security gateways answer on the mailbox's behalf, and anti-harvesting rules refuse to answer at all. A list can pass every syntax and DNS check you run and still be full of addresses nobody reads, which you find out after the bounces have already reached your sending reputation.
This guide works through the checks themselves: what each layer tests, how to run them without sending anything to the address, how tools and APIs do it at scale, and what to do with each result you get back. It also covers the two operational questions that decide whether any of it holds up, which are how to clean a list in bulk without damaging deliverability and how often to check again.
Key takeaways
- Email validation is a layered check: that an address is correctly formed, that its domain can receive mail, and that the mailbox behind it exists.
- Validation and verification are not the same job. Validation screens an address at the point of entry. Verification confirms a specific mailbox is live before you commit a send to it.
- A test send is the wrong way to check an address. Enterprise servers are commonly configured to drop invalid mail silently without sending non-delivery reports, so nothing bounces back.
- Catch-all and gateway-fronted domains are where standard checks stop returning answers. In our study of the Fortune 500 email infrastructure setups, 344 of 500 domains (69%) were one, the other, or both.
- Validate continuously at the point of entry and re-check your existing list quarterly, plus immediately after a data import, a bounce spike, an ESP switch, or before reactivating dormant contacts.
What is Email Validation?
Email validation is the process of checking that an email address is correctly formed, that its domain is configured to receive mail, and that the mailbox behind it exists. It runs in layers, from a format check through a DNS lookup to a mailbox-level test, and each layer only matters because the one before it passed.
Validation and verification get used interchangeably, and the difference is worth holding onto. Validation is about the input: is this string structured correctly, and does the domain behind it exist. Verification is about the mailbox: is there something on the other end to receive mail.
In practice that maps to two moments. Validation belongs at the point of entry, on a signup form or a CRM import, where the job is to stop typos and throwaway addresses before they land in the database. Verification belongs immediately before a send, where the job is to confirm the addresses you are about to email are still live.
What are the safest ways to validate an email address without sending an email?
The safest ways to validate an email address without sending one are all out-of-band, meaning they never put a message in front of the recipient. A syntax check tests the format, a DNS lookup confirms the domain accepts mail, and a disposable and role-based screen flags addresses that resolve but are not worth much. An SMTP handshake then asks the receiving server about the specific mailbox and disconnects before any message is sent.
The alternative, and the most common mistake in list management, is the test send: mailing a blank or "hello" message to an address to see whether it bounces. The bounces it produces land on your sending domain like any other campaign's, and an unusual ratio of invalid recipients is exactly what receivers throttle on.
In B2B, it is also technically unreliable. Enterprise environments sit behind Secure Email Gateways and catch-all configurations built to obscure the true status of a mailbox. As Microsoft Exchange documentation outlines, servers are frequently configured to discard mail addressed to a recipient that does not exist rather than return a non-delivery report, which prevents backscatter, the flood of bounce messages a server generates when it replies to a forged sender. Your test send therefore disappears without a bounce, and you file the address as fine because nothing came back.
If you only need to check one or a few addresses right now, Allegrow's free email verifier runs these checks for you without sending anything to the address. The rest of this section covers the first three, and the handshake gets its own section below, so you can run these yourself or judge a tool that runs them for you.
How do you check email address syntax correctly?
Syntax validation compares an address against the formal specification in RFC 5322. A robust check goes past the @ symbol: it validates the local part before the @, the domain part after it, and the total length, which a companion specification, RFC 5321, caps at 254 characters.
What it catches is fat-finger data, name@gmial.com or user@domain..com, and special characters used where they are not allowed. What it cannot do is tell you whether the address exists. An address can be perfectly formed and entirely fictional, which is why syntax is the first layer and never the answer.
How do you check whether the email domain can receive mail?
Once the format is clean, the next question is whether the domain handles email at all. That is a DNS query for the domain's MX (Mail Exchange) records, which name the servers responsible for accepting its mail. If no MX record exists, the domain is dark to email, and anything you send will hard bounce.
An MX record tells you the building exists and has a mail room. It says nothing about whether anyone lives in the apartment you are writing to, so a domain-level pass tells you mail will arrive somewhere, not that anyone will read it.
One gotcha is worth knowing. MX is not the only signal of life: some legacy configurations publish no MX record but still accept mail through the domain's A record, its primary IP address. A process that checks only MX will reject perfectly reachable addresses on older enterprise infrastructure, so check both.
How do you detect disposable and role-based email addresses?
An address can pass syntax and DNS and still be worth nothing to you. Disposable email addresses are temporary inboxes people use to get past a gated form without giving up a real address. Many expire within hours, so a lead captured this morning is often a hard bounce by tomorrow.
Role-based addresses (admin@, info@, sales@) are a different problem. They reach a group, not a person, which generally means low engagement and a higher chance of a spam complaint from whoever happens to be checking it that week. Detection on both is a lookup: the address gets compared against maintained data on disposable providers and known role prefixes. What you do with a match is a routing decision, not automatically a block.
How do you validate a single address manually?
For one high-value address, a manual pass catches most of what tends to be wrong with it. Start with the domain and look for near-miss spellings, conpany.com for company.com, and for homoglyphs, characters that look alike, where a zero stands in for an o or an uppercase I for a lowercase l. Then check the edges of the string, since trailing spaces and doubled dots (john..doe@domain.com) survive a copy and paste and fail on delivery.
Next, confirm the domain is the one the company actually uses. A look at their website settles the TLD. If their site is brand.io and your record says brand.com, the address is probably a legacy entry or somebody's guess, and it will bounce.
There is one case where sending is the right move, and it is not a test send. In a double opt-in flow, a newsletter signup or an account activation, the confirmation email is expected by the person receiving it and serves a purpose beyond checking that the address works. That is consent, and mail servers treat it very differently from probing.
How does email validation work?
Email validation works in three layers, each asking a narrower question than the last. Syntax checks whether the address is written correctly, a DNS lookup checks whether its domain is configured to receive mail, and an SMTP handshake asks the receiving server whether that specific mailbox exists. The layers run in that order because each costs more than the last, so the cheap checks clear the obvious failures first.
The first two are settled questions. Syntax normalizes the address, stripping hidden whitespace and lowercasing where that is safe, then tests it against the format rules. DNS asks whether the domain exists and publishes mail servers, and a failure there is conclusive, because a domain with no mail servers cannot receive mail whatever the address looks like. The third layer is the mailbox itself, and that is the one people mean when they ask how validation works.
What happens during an SMTP handshake?
To check a specific mailbox without sending anything, a validator opens a connection to the receiving mail server and starts the same conversation a real sending server would. It identifies itself with EHLO, names a return address with MAIL FROM, then issues RCPT TO, the command that names the recipient. We cover this exchange in more depth in our guide to the SMTP handshake. RCPT TO is the question being asked: is this an address you will accept mail for?
In plain terms, the validator is calling the company's front desk to ask whether a particular person works there, then hanging up before leaving a message. The conversation happens, the answer comes back, and nothing lands on anyone's desk.
The server answers with a numeric response code. A 250 means accepted, and a 550 usually means the mailbox does not exist, though a server may also return 550 for policy reasons rather than for the address itself. A 4xx code is temporary, typically greylisting, where a server deliberately refuses an unfamiliar sender the first time to see whether it tries again, or simple congestion, and it means try again later rather than that the address is dead. The validator then disconnects without issuing DATA, the command that would transmit a message body, so nothing reaches anyone's inbox.
Because the conversation stops before DATA, the check costs the recipient nothing. What it cannot control is the answer, so the result is only as good as the server's willingness to distinguish one address from another.
Why is the mailbox layer the hard one?
Three configurations stop the handshake from producing an answer. Catch-all domains accept mail for every address at the domain, so RCPT TO returns 250 whether the mailbox exists or not; the response is real, it just carries no information. Secure Email Gateways such as Proofpoint answer before the mail server does, so the code you get describes the gateway's policy rather than the mailbox behind it. Anti-harvesting measures return the same code for every address, so the response carries no information about any individual mailbox.
This is not a rare edge case. In a point-in-time study of Fortune 500 domains, 344 of 500 (69%) were catch-all, gateway-fronted, or both, meaning that on a list of enterprise contacts, the layer that answers the actual question is the layer most likely to stay silent.
How do spam traps get past validation?
Spam traps are addresses maintained by ISPs and blocklist operators to catch senders mailing lists they did not build. They exist, they resolve, and they accept mail, so every layer above returns a clean result on them. Nothing in a syntax check, a DNS lookup, or an SMTP handshake will tell you that you are holding one.
They come in a few recognizable shapes: pristine traps that were never real addresses and were published only to be scraped, recycled traps that are abandoned mailboxes an ISP has reactivated for the purpose, and typo-domain traps sitting on near-miss domains like gmial.com to collect whatever is misaddressed to them. Screening for them relies on different signals entirely, mainly where the record came from, how old it is, and reputation data on the address and its domain. That is why spam trap detection is a separate discipline rather than a stricter version of validation.
How do email validation tools and APIs validate an email address?
Validation tools and APIs run the same three layers at volume, then add the work a script cannot do on its own: secondary diagnostics on servers that accept every address, and cross-references against maintained data on disposable providers, role prefixes, and recently deactivated domains. None of that is visible in the handshake, and all of it changes what you should do with an address the handshake called valid.
Tools are sold in two shapes and most teams need both. Real-time validation runs through an API at the point of entry, one address at a time, synchronously, inside the few hundred milliseconds a form submission can tolerate, which protects the database going forward. Bulk validation, sometimes sold as list cleaning, runs against a list you already hold, asynchronously, with no latency budget and therefore room for the slower checks, which repairs what is already in it. The same address can get a different depth of scrutiny depending on which path it came through, so results are not directly comparable across the two.
What checks does a good validator run behind the scenes?
Past the layers already covered, what separates validators is what happens after the handshake stops being informative. A basic tool typically reports the server's response and stops, which is why catch-all comes back looking like a final answer, meaning the record is unresolved rather than decided. A tool built for B2B runs secondary diagnostics against the configuration to work out whether a specific mailbox is real behind a server that accepts everything.
What that difference affects is coverage, meaning how much of your list a tool is willing to return a decision on at all. Two tools can report identical accuracy on the addresses they resolved and still be very different purchases, because one of them resolved most of your enterprise contacts and the other declined to rule on them.
What results should you expect, and what should you do with each one?
Most tools return the same five statuses. A practical way to read them is by what each one lets you do next, since two of the five settle nothing until you resolve them.
Catch-all is the result where tools diverge most, and the reason is what they do after the server accepts. Most stop there, which leaves you holding a segment you can neither send to nor safely delete, and on B2B data that segment is rarely small. In our 11-tool benchmark, run in August 2026 across 500 real professionals on 251 all-catch-all domains plus 5,000 fictional controls, Allegrow found 98.2% of the real contacts (491 of 500) at a 0.22% false-positive rate (11 of 5,000). Those figures describe that test, on those domains, at that time, and the point they make is that catch-all is a resolvable state where a tool keeps working after the handshake stops helping.
How do you validate an email address in real-time on signup forms?
Real-time validation on a signup form runs a syntax check, a domain lookup, and an API call before the submit button unlocks, then sorts the answer into three actions: (1) block what is clearly invalid or disposable, (2) suggest a correction when the address is a near miss on a common domain, and (3) accept but flag anything ambiguous for a slower check. The job here is narrower than full validation, because you have a few hundred milliseconds and a real person waiting.
Blocking covers the first case. An invalid result or a known disposable domain should keep the form locked, with a message asking for a working address instead of a generic error, since the person can usually fix it in two seconds if you tell them what is wrong.
Correction is the case most forms skip. A common shape of bad form data is a near miss on a common domain, and a "did you mean gmail.com?" suggestion recovers the signup rather than losing it. A correction recovers the signup; a rejection loses it.
The third case is the one where a form should neither block nor wave through. A catch-all or unknown status is not grounds to reject someone, and it is not grounds to wave them through either. Accept the submission, mark the record, and resolve it out of band before the lead reaches a sequence. Where the asset justifies it, a demo booking or a gated report, a double opt-in does the same job by asking the person to confirm, which produces a definitive signal instead of a guess.
How do you validate email addresses in bulk without damaging deliverability?
To validate a list in bulk without damaging deliverability, run the full pass 24 to 48 hours before you send, remove everything that came back invalid, and put the risky and catch-all segments on a metered track you send to in small batches while watching the bounce rate. The sequence matters more than the tool, because the damage comes from sending an unchecked list, not from checking it.
The reason to be careful is that high-volume sending is a privilege resting on your history. ESPs commonly suspend an account that uploads a list and immediately produces a wall of hard bounces, because your reputation is attached to their IPs as well as your domain, and a damaged one is why good emails start landing in spam.
How do you clean a list safely before campaigns?
The gap before launch is what lets you act on the results instead of just reading them, and bulk jobs on large lists do not finish instantly. Invalid records come off the list and do not go back on. The real work is in what you do with risky and catch-all.
Treating those two as a yes or a no is where lists get damaged. Put them on a metered track instead: send to them in small batches, ahead of the main send, and watch the bounce rate as it comes in. If bounces on that track pass 2%, stop and re-check the remainder before you continue. Two percent is an operational ceiling rather than a published standard, and it is deliberately conservative, because a re-check costs credits and a damaged sending reputation costs weeks.
How do you run bulk validation operationally?
Run bulk jobs asynchronously. Submit the list, take a job ID, and collect results when they are ready. A connection held open through a large job will time out halfway. Whether you work through a dashboard or an API, plan for rate limits and build retries, because a share of every large list comes back unknown for reasons that have nothing to do with the addresses: greylisting, congestion, a server having a bad minute.
Store a last-checked timestamp on every record, as a queryable field rather than a note in a description. It turns re-validation into a filter, where anything older than your chosen window gets picked up automatically before it enters a send. Without it you cannot tell a record confirmed last week from one confirmed eighteen months ago, and those two carry very different risk.
How do you decide what to suppress versus keep?
Suppression should be permanent and narrow. A global suppression list is for addresses that returned a clean invalid and for anything identified as a spam trap, and once an address is on it, it stays. Unknowns do not belong there. They failed to produce an answer, which is not the same as producing a bad one, so hold them for re-validation and check again.
Catch-all addresses need a decision rather than a rule, because in B2B they are frequently your best accounts. Suppressing them on principle cuts enterprise targets out of your TAM on the grounds that a tool could not see inside the server, which reduces your reachable market without reducing your risk. Resolve them instead, then suppress only what comes back invalid.
How often should you validate email addresses?
Validate continuously at the point of entry, and re-check the list you already hold once a quarter. Tighten that if you send at high volume or your data comes from sources you do not control, since both raise how fast the list drifts and lower how much bounce you can absorb. Beyond the calendar, four events should trigger a pass immediately whenever they happen.
The reason a schedule is needed at all is that B2B contact data goes stale on its own, with nothing happening to your list. People change jobs, companies get acquired and retire the old domain, and mailboxes get deactivated weeks before anyone updates a CRM. A record marked valid is a statement about the day it was checked, not a permanent property of the address. Volume-based cadence tiers, on the other hand, generally claim more precision than the underlying data supports, so a quarterly floor with event triggers on top is easier to run and easier to defend.
The triggers:
- A data import. Any list you acquire or sync from a partner gets validated before it touches your primary CRM, not after. Inherited bad data is indistinguishable from your own once it is in the database.
- A bounce spike. The same 2% ceiling applies mid-campaign: stop the send and re-check the remaining segment before resuming.
- An ESP switch. New providers typically run probationary periods on new accounts, and the first send is the one that sets your standing with them.
- A reactivation campaign. Contacts you have not mailed in six months or more are the likeliest to have gone dark, and dormant lists are where recycled spam traps collect.
Conclusion
Almost all of this is something you can run yourself. Syntax against RFC 5322, an MX lookup, a disposable and role-based screen, and an SMTP handshake that stops at RCPT TO are public standards, and a competent script will give you accurate answers on most of a normal list. The layer that does not yield to a script is mailbox existence on catch-all and gateway-fronted domains, which is where the majority of enterprise contacts live and where a clean-looking result usually means the server declined to answer rather than that the person is real.
Start a 14-day free trial and run Allegrow against up to 1,000 of your own contacts, ideally the catch-all and gateway-fronted ones your current tool hands back as unresolved, and see how much of that segment comes back with an answer.
FAQs
Is there a way to validate an email address without sending an email?
Yes. Syntax checks, a DNS lookup for MX records, and an SMTP handshake that stops at the RCPT TO command all test an address without delivering anything to it. The handshake asks the receiving server whether it will accept mail for that address, then disconnects before any message body is sent.
What is the difference between validation and verification?
Validation checks the input: that the address follows the format rules and that its domain is configured to receive mail. Verification goes further and confirms the specific mailbox is live and reachable. Validation keeps bad data out of your CRM at the point of entry, and verification is what protects an actual send.
Do MX checks guarantee the inbox exists?
No. An MX record only proves the domain has designated a server to handle its mail. It says nothing about whether a specific mailbox behind that server is active. Mailbox-level checks are a separate layer, and on catch-all domains they are the hard one.
How should you handle catch-all domains?
Flag them rather than guessing, then resolve them with a tool built for it. Catch-all servers accept every address, so a standard check returns catch-all for real and fictional mailboxes alike. In our August 2026 benchmark across 251 all-catch-all domains, Allegrow found 98.2% of real contacts (491 of 500) at a 0.22% false-positive rate.
