To verify an email address without sending a message, run five checks in order: syntax, domain, MX records, a mailbox check over SMTP, and a catch-all test. The first three catch typos and dead domains in milliseconds. Only the SMTP check asks the mail server whether the mailbox exists, and a catch-all domain can hide even that answer.
Verification is the last step of finding business contact information. Below you will learn how to verify an email address by hand, what each check proves, where manual checks break, and what to do with each result before you hit send.
How do you check if an email is valid?
You check if an email is valid by confirming three things without sending anything: the address is written correctly, its domain has a working mail server, and that server accepts the mailbox. A verifier does this with a syntax check, a DNS lookup of the domain’s MX records, and a short SMTP conversation that stops before any message goes out.
The answer comes back in one of three shapes. The mailbox exists and is safe to send to. The server accepts every address, so the mailbox cannot be confirmed (a catch-all, which tools label Risky). Or the address fails a check and should come off your list before it becomes a hard bounce.
How to verify an email address in 5 checks
Each check answers one question, and each is only worth running if the one before it passed. Here is the order a verification tool follows, and how to do each one yourself.
1. Check the syntax
A syntax check confirms the address has exactly one @, a local part before it, and a domain with a dot after it, with no spaces. It catches dana whitfield@northwindfab.com (a space) and dana.whitfield@northwindfab (no top-level domain).
Keep the rule loose, for example ^[^\s@]+@[^\s@]+\.[^\s@]+$. Strict patterns reject real addresses such as sean.o'brien@ or dana+events@. If you built the address from a naming pattern, check it against the company email format first.
What it misses: everything else. dana.whitfield@northwindfb.com, with one letter missing from the domain, passes syntax and goes nowhere.
2. Confirm the domain exists
Look the domain up in DNS. If it returns no record at all, nobody can receive mail there: the company rebranded, let the domain expire, or the domain was mistyped.
At this step, also compare the domain against a list of disposable inbox services. Those addresses are real for an hour and dead the next day, so they do not belong in a B2B list.
3. Look up the MX records
MX (mail exchanger) records tell the internet which server takes mail for a domain. One command shows them:
Windows: nslookup -type=mx northwindfab.com
Two edge cases matter. A domain with no MX record is not automatically dead: under RFC 5321, senders then try the domain’s own address record. A “null MX”, a single MX record pointing to “.”, is the domain saying it accepts no mail at all (RFC 7505).
4. Ask the mail server if the mailbox exists
The SMTP check is the only step that looks at the mailbox itself. Connect to the MX host on port 25, introduce yourself with EHLO and MAIL FROM, then send RCPT TO with the address you are testing. The reply to RCPT TO is your answer. Then send QUIT instead of DATA, so no message is ever delivered.
Read the reply by its first digit. 250 means accepted. A 5xx reply such as 550 5.1.1 means the mailbox does not exist. A 4xx reply means “try again later” and tells you nothing yet.
The older VRFY command was built for this question, but most servers switch it off. RFC 5321 tells servers that disable it to answer 252, which confirms nothing either way.
5. Test for catch-all
Repeat the RCPT TO with an address that cannot exist, such as x7q2k9-test@northwindfab.com. If the server rejects it, its earlier 250 for Dana’s address means something: the mailbox is real. If it accepts the fake address too, the domain is catch-all and a 250 proves nothing.
Catch-all addresses are not bad, just unconfirmed. Treat them as Risky and send to them separately. Our guide to catch-all emails covers how.
What to do with each verification result
Every result maps to one action. The table below covers the answers you will see, including the two that are not about the mailbox: disposable domains and role inboxes such as info@ or sales@.
The labels differ from tool to tool. Scalelist uses Valid and Risky for emails it returns, and Not found when it finds no address; our page on reading email verification statuses maps the common labels to these actions.
Example: checking four prospects before a sequence
Maya Chen, an SDR at a payroll software company in Denver, has four operations leaders to add to Monday’s sequence. She runs each address through the five checks first.
| Address | What the checks returned | Result | Maya’s move |
|---|---|---|---|
| dana.whitfield@northwindfab.com | MX found, 250 for Dana, 550 for a fake address | Deliverable | Sends from her main domain |
| tom.keller@brightlineplastics.com | 250 for Tom and 250 for a fake address | Risky (catch-all) | Calls first, emails from a secondary domain |
| luis.ortega@cedarvalleytooling.com | 550 5.1.1: mailbox does not exist | Remove | Looks up Luis’s current address |
| jen.park@harborlinelogistics.com | 451: try again later (greylisting) | No answer yet | Rechecks in an hour |
Without the checks, Luis’s address would have hard bounced on Monday, and Tom’s would have gone out from her main domain with no way to know if anyone reads it.
Common challenges when you verify emails yourself
Manual checks work for one address. At list scale, five problems show up, and each has a fix.
The server says yes to every address
Catch-all domains return 250 for any mailbox. Fix: run the fake-address test from step 5 on every domain, and keep catch-all contacts in a separate, smaller send.
The server answers “try again later”
Some servers answer an unfamiliar sender with a 4xx on purpose. This is greylisting, and RFC 6647 describes it as a deliberate “transient (soft) fail”. Fix: retry after a few minutes, and never mark a 4xx as a bad address.
Your IP gets throttled or blocked
Probing looks like address harvesting to the receiving server. Fix: never verify from the IP or domain you send from. Use a verification tool or an email verification API that paces the checks.
Spam traps pass every check
A spam trap is an address used to catch senders who mail people without permission. Spamhaus, which runs one of the best-known blocklists, notes that “Spamtraps are never revealed by their owners”. Recycled traps are old addresses that went dead and were switched back on to catch stale lists.
No syntax, MX or SMTP check can tell a trap from a real inbox. Fix: build lists from sources you trust, remove contacts who have never engaged, and never buy an old list and mail it.
A good address goes bad after you check it
People change jobs and their mailboxes are deleted. ZeroBounce, a verification vendor, reports that at least 23% of an email list degrades in a year, based on more than 11 billion addresses it checked in 2025 (lists its customers chose to clean). Fix: verify again right before each campaign. More on the pace of B2B data decay.
Best practices for email address verification
Good verification is a habit at three moments: when an address enters your system, right before you send, and right after a bounce.
Two more habits work at the campaign level rather than the address level:
- Track bounce rate per campaign. A jump on one campaign points straight at the list behind it. See our email bounce rate benchmarks for what to aim for.
- Fix the sender side too. Google asks senders to keep reported spam below 0.10% in its sender guidelines. A clean list helps, but authentication and content matter as well: see email deliverability best practices.
What to look for in an email verification tool
A good tool runs every check above for you, at volume, without touching your sending reputation. Before you pick one, confirm it:
- Runs a real SMTP mailbox check, not only syntax and MX.
- Gives catch-all addresses their own status instead of calling them safe.
- Flags disposable domains and role inboxes.
- Retries greylisted domains instead of marking them bad.
- Handles one address, a CSV and an API call.
- Does not keep or reuse the list you upload.
How Scalelist helps you send only to verified emails
Scalelist, an AI Lead Finder, verifies every email before it returns it and labels it Valid or Risky. Scalelist finds and verifies contact details on demand rather than serving a pre-compiled list, so the check happens when you ask, not months earlier.
- Emails you find: the Scalelist Email Finder returns a work email with its status. You pay 1 credit per email found, Valid or Risky; Not found costs nothing.
- Emails you already have: the Scalelist Email Verifier runs syntax, domain, MX, SMTP, catch-all, disposable and spam-trap checks on one address or a list. Verification is included in every plan.
- Risky emails: Scalelist’s help center puts it at about 20 to 30% of Risky emails being deliverable, and recommends sending them from a secondary domain.
- Your data: contact data you submit is never added to Scalelist’s database.
Plans start at 29 USD a month for 500 credits, and new accounts get 20 free credits with no credit card required (see Scalelist pricing).
Find a prospect’s work email and see its status before you send.
Get 20 credits to test itFAQ
Can you verify an email address without sending an email?
Yes. Verification uses DNS lookups and a short SMTP conversation with the recipient’s mail server. The verifier asks about the mailbox with the RCPT TO command, reads the reply, and disconnects with QUIT before the DATA step, so no message is created or delivered. The person you are checking never sees anything.
How do I check if an email is valid from the command line?
Run dig +short MX domain.com (or nslookup -type=mx domain.com on Windows) to find the mail server, then open an SMTP session to it on port 25 and send EHLO, MAIL FROM and RCPT TO. Many internet providers and cloud hosts block outbound port 25, and servers throttle repeated probes, so this works for one address, not a list.
Why did an email that passed verification still bounce?
Usually because something changed after the check or the check could not see the mailbox. The person may have left the company, the domain may be catch-all and bounce the message later, or a server may accept at the SMTP stage and reject after reading the message. Verify again right before each send and keep Risky addresses separate.
What does a Risky or catch-all result mean?
It means the domain’s mail server accepts every address, real or not, so no verifier can confirm the specific mailbox. Scalelist labels these emails Risky. Its help center estimates that about 20 to 30% of Risky emails are deliverable and recommends sending them from a secondary domain, never from your main one.
Is email verification 100% accurate?
No. Verification can confirm that a server accepts a mailbox today, but it cannot see inside catch-all domains, detect spam traps, or predict a mailbox being deleted next month. Treat a clean result as strong evidence, not a promise. Re-verify before each campaign and remove every hard bounce the same day.
How often should you verify your email list?
Verify every list right before you send it, and verify new addresses the moment they enter your CRM. People change jobs and companies change domains all year: ZeroBounce reports at least 23% of addresses degrading within a year in its 2025 data. A list checked more than a few weeks before a campaign should be checked again.
Can email verification detect spam traps?
Not reliably. A spam trap is a real, working mailbox, so it passes syntax, MX and SMTP checks. Spamhaus notes that trap owners never reveal them. Tools can flag some known trap signals, but the real protection is list sourcing: only email people who match your market, remove long-silent contacts, and never mail an old purchased list.
Is it legal to verify email addresses?
Checking whether a mailbox exists does not send anyone a message, but the address of a person is still personal data under laws such as the GDPR, so you need a lawful basis to hold and use it. This is not legal advice. See our guide to B2B data and GDPR for the basics.
Sources
- RFC 5321: Simple Mail Transfer Protocol (reply codes, implicit MX, VRFY)
- RFC 3463: Enhanced Mail System Status Codes
- RFC 7505: A “Null MX” No Service Resource Record
- RFC 6647: Email Greylisting
- Google Workspace: Gmail SMTP errors and codes
- Microsoft Learn: Fix NDR error 550 5.1.10 in Exchange Online
- Google: Email sender guidelines
- Spamhaus: Spamtraps, fix the problem, not the symptom
- ZeroBounce: The Email List Decay Report for 2026
- Scalelist help center: Can we use the risky emails found by Scalelist?
