How to Check if an Email Is Valid: SMTP 250 vs 550

How to Check if an Email Is Valid: Quick Answer

To validate an email address, check three layers: syntax, a resolvable domain, and a mailbox that accepts mail. That 250/550 split goes back to RFC 821, and RFC 5321 still uses 550 for the same 'mailbox unavailable' condition.

The syntax layer follows RFC 5322, and the domain layer needs MX records under RFC 1035.

I cross-check 550 handling against Google's bulk sender guidelines and Microsoft's SMTP error reference; both treat a 550 recipient-not-found response as a hard bounce.

See RFC 5322: Internet Message Format. You can check the first two manually. You can't confirm the third without an SMTP conversation: a 250 means the receiving server accepted the address, and a 550 means the mailbox does not exist. Here's the side-by-side I use:

• 250: '250 2.1.5 OK <[email protected]>' - the mailbox exists and the server will accept mail.
• 550: '550 5.1.1 <[email protected]>... User unknown' - the mailbox does not exist and the server refuses delivery.

That's the trap. A lead list's addresses look fine because each one contains an @ and a.com. You import them. Then the bounces start, and your next campaign lands in spam before it reaches a single inbox.

I worked a B2B list from a third-party data reseller that was too big to check by hand and every address passed the visual check. The first send bounced hard enough to push the campaign into spam. After I ran SMTP verification and pulled the catch-all and invalid rows, the next send reached the inbox without that bounce spike. So what actually works?

The real answer isn't a binary yes or no.

This post covers manual syntax checks, DNS and SMTP verification, API-based validation like Verifox's status-per-address endpoint, status semantics, and catch-all domain limits.

TL;DR:

• Check all three layers: syntax, resolvable MX, and mailbox acceptance.
• Manual checks work for one-off addresses, but they don’t scale and silence on a catch-all domain proves nothing.
• For production signups, I call an SMTP-based API inline and treat a 550 as a hard reject, a 250 as accept, and a catch-all or risky result as a quarantined maybe instead of deleting them.

What Does It Mean to Check if an Email Is Valid?

I use the Three-Layer Email Validity Stack whenever I need to know how to check if an email is valid. The 250/550 reply contract dates back to the original 1982 SMTP spec; I still rely on that contract now because most receiving servers still signal invalid recipients the same way.

Syntax: RFC 5322 defines the legal address format, and RFC 5321 sets SMTP limits for the local part and domain. See IETF RFC 5322 - Internet. Domain: the domain must publish an MX record or an A record that can receive mail.

Mailbox: the server must return a 250 to RCPT TO, or the domain must run a catch-all that accepts every address. For syntax, '[email protected]' passes while 'alice@@example.com' fails. For domain, 'example.com' has an MX record while 'no-such-domain.invalid' has none.

For example, '[email protected]' returns a 250, while '[email protected]' returns a 550.

Skip any layer and you're guessing; I rely on RFC 5321 to define the 250 and 550 reply codes, and RFC 5322 to define the legal address format. When I validate a client list, I call an address valid only after all three clear. I count a 250 as valid only when received in the same SMTP session, and flag catch-all domains as risky.

How Email Validation Works: Syntax, Domain, and SMTP Checks

My first check is which validation layers actually ran. A label that says "validated" without an SMTP attempt proves syntax only, and syntax is the weakest signal in the stack.

Stage 1: Syntax. Every validator parses the address against RFC 5322. This catches the obvious junk: a missing @, spaces, double dots, illegal characters. It's necessary. It's absolutely not sufficient. Regex alone misses real-world edge cases like quoted local parts, internationalized domain names, and plus-addressing. I've seen a regex reject a legitimate address with a plus sign and accept a typo like [email protected]. Syntax is the cheapest filter, not the decision.

Stage 2: Domain and MX lookup. After syntax passes, the validator resolves the domain and checks for a mail exchanger (MX) record under RFC 1035. If no MX record exists, the validator can fall back to the domain's A record, but that's already a weak signal. See RFC 5321. The MX lookup proves the domain can accept email at all. It doesn't prove the specific mailbox exists. A domain can publish MX records and still bounce every RCPT TO with a 550.

Stage 3: SMTP handshake. The strongest signal is a live conversation with the receiving mail server. The validator connects, issues MAIL FROM, then RCPT TO, and reads the reply code defined in RFC 5321. A 450 or 451 means temporary failure, usually greylisting.

The MAIL FROM address should be a syntactically valid sender at your domain; a malformed sender gets rejected before RCPT TO. A server can also accept RCPT TO and then reject at the DATA stage once it sees the full message, which means SMTP checks are strong but still not a guarantee. I've reproduced this exact failure on a client's shared host: RCPT TO returned 250, then the DATA stage returned 550 for the same mailbox. That handshake is the only check that verifies the mailbox itself.

So why would a validator skip it?

Because it's slow. Each SMTP conversation has to wait for the remote server's reply, and mail providers rate-limit connections. Google and Microsoft throttle or block a validator that opens too many sessions from one IP. I've had to spread RCPT TO probes across sessions because a single IP started receiving 421 connection-limit replies from one provider's MX pool. A receiving server under high connection load also treats automated probes as abuse. Cheap validators do the safe thing: they check syntax and DNS, return "valid," and never touch SMTP.

A validator that skips SMTP is a syntax checker wearing a validator costume. When I'm cleaning a list for a client, I treat any domain that greylists as "unverified" rather than "invalid" - a 450 means retry later and keep the address in the queue.

That rate limiting is the speed-versus-signal tradeoff. MX lookups are cheap and parallel; SMTP sessions are sequential and connection-bound. A validator hammering SMTP ends up blocked. A validator ignoring SMTP ends up wrong.

This pipeline matters because a bounce only needs one weak link. A syntactically perfect address on a catch-all domain will pass SMTP and still bounce later, but that's a catch-all problem, not a syntax problem. Validation is a stack of signals, and the cheapest bounce is the one you never send.

For a client's newsletter list after a rebrand, I ran syntax and MX checks and kept the records that only cleared syntax in a separate review queue. I keep the full start-to-finish walkthrough in how to check if an email is valid so you can see each layer in action.

Email Validation Results: Valid, Invalid, Risky, and Everything Between

Most dashboards imply two states: valid and invalid. That binary is how senders get hurt.

When I triage a client's suppression file, the statuses between green and red are the ones that actually decide whether a campaign lands in inboxes or burns the domain. Seven statuses matter, and each one carries an action.

Treat catch-all and risky as action items, not green lights. A validator that hands you nothing but "valid" and "invalid" is hiding the two statuses that prevent most bounces.

• I clear Valid addresses without a second look.
• A 550 or an unresolvable mail route means Invalid, so I suppress it immediately.
• Risky addresses hold until I can match a recent open or click, because past engagement is the only signal that outweighs the bounce pattern.
• Catch-all domains accept every RCPT TO, so I only release those addresses after opens or replies from the exact address; otherwise they stay quarantined.
• Disposable addresses register temporary inboxes that inflate vanity metrics and vanish, so I remove them before the next campaign.
• I keep role-based addresses like sales@, info@, and support@ for transactional mail only; anything promotional goes to a named contact.
• Unknown stops the SMTP check through timeouts, greylisting, or provider blocks, so I retry once before adding a suppression tag.

How to Check if an Email Is Valid Without Third-Party Tools

For how to check if an email is valid, run these four manual checks for one-off address verification only. When I need to check if an email is valid without a third-party tool, I work through this exact four-step sequence and treat the result as a tentative verdict only. They don't scale, and they can make a dead lead look alive.

1. Send a test email and watch the bounce. Compose a short message, send it, and watch for a non-delivery report. A hard bounce with a 550 code usually means no mailbox. No bounce tells you only that the receiving domain didn't reject the address during the SMTP stage. With a catch-all domain, silence proves nothing because the receiving server accepts every address. You'll get a bounce later when the catch-all eventually drops the message or a human replies "wrong address." This check is cheap, but it's the slowest and least conclusive method on catch-all domains.

2. Try the password recovery page (skip this one for bulk work). On Gmail, Yahoo, or Outlook, start the account recovery flow and enter the address. As of this writing, Gmail returns "Couldn't find your Google Account" for nonexistent addresses; Yahoo and Outlook show similar account-not-found messages, but these flows can change or return false signals. That's the entire trick. The failure mode: providers throttle repeated lookups, throw CAPTCHAs, and sometimes hide whether an address exists by always showing a password field to block address enumeration. Use it only for a handful of individual leads when you have a legitimate reason. Never automate it, and stop the moment the provider challenges you. Probing addresses without a business relationship crosses into enumeration, and providers treat it that way.

3. Check the MX record from the command line. Run dig example.com MX +short or nslookup -type=MX example.com. An answer with a mail exchanger means the domain can receive mail. No answer, or a null MX record (0. under RFC 7505), means the domain has no inbound mail route and every address on that domain is invalid. An online DNS tool like Google Admin Toolbox Dig or MXToolbox shows the same record. An MX lookup verifies only the domain, not the mailbox; the server can still reply with a 550 for a specific local part.

4. Search the address in quotes. Type "[email protected]" into Google. If the address appears on a public profile, a conference page, or a company directory, that's a weak signal in favor of existence. If nothing appears, that absence proves nothing. Plenty of valid addresses never appear in any indexed page, and plenty of indexed addresses are long dead.

Field note: When I hand-clean a short list of founder addresses, I verify the MX record and run the quote search side by side, then send the test email only to the leads that clear both. I set anything ambiguous aside instead of trusting it.

That sequence works for ten addresses. It collapses at a hundred, and at a thousand it's a full-time job with no audit trail. The real danger is the false confidence. A manual check that returns no bounce can push you to trust an address on a catch-all domain, only for the message to bounce later, or to trust a typo that a catch-all server accepts.

For a growing list, a manual verdict is a guess wearing a green checkmark.

I ran the manual MX lookup and quote search side by side on a short founder list before I sent any test message.

How to Check if an Email Is Valid With a Single API Call

For production signups, call the validation API before you write the user record.

That's the direct answer I use for how to check if an email is valid. You need a status reply inline, not a batch cleanup after the fact. Here's the exact call.

Expected response:

The status field is the verdict. mx_record tells you the domain can receive mail at all. role flags group inboxes like sales@ or info@. disposable flags throwaway addresses. If any of those booleans flips, treat the address differently before sending.

The API does what a manual check can't. It runs syntax, DNS, and an SMTP handshake in one round trip, without ever sending an email.

Finally, the server closes the connection. No message is queued or delivered. That's the inline check that catches bounces before a user record gets written.

For a B2B signup flow, this is the cheapest bounce you never send. In practice, I key my signup handling off the 'status' value instead of treating every non-'valid' result the same way.

• 'valid' means the syntax, domain, and mailbox all passed. I write the record and continue.
• 'invalid' means the address failed syntax or the mailbox does not exist. I block the signup and ask the user to re-enter the address.
• 'catch_all' means the domain accepts mail for any mailbox, so the SMTP handshake returns a false positive. I allow the signup but flag the lead for a slower confirmation email.
• 'unknown' means the receiving server did not answer definitively, usually because of a timeout or greylisting. I keep the record as pending rather than valid.

For error handling, I wrap the call in a small retry block. A '401' means the API key is wrong or missing, so I stop retrying and surface that to the engineer.

A '429' means the rate limit is hit, so I back off and retry after the 'Retry-After' header. A network timeout or '5xx' response is a temporary failure, so I retry once before falling back to a basic syntax-only check.

Here is the decision table I use for a B2B signup flow:

That keeps the single-API-call path from being a toy example: the response stays inline, but the handling around it is explicit enough to ship.

Email Verification Tool Comparison: What Actually Matters

In the lists I clean, the first question I ask about a verification vendor is not price per 1,000 lookups. It's whether the tool returns unverified or valid for a catch-all address. That single question separates tools that reduce bounces from tools that just relabel a list.

I work through this numbered check:

1. Match the tool to the list size: a free single-check tool for one founder address, an SMTP-based API for bulk developer work, and a data-enriched API only when the vendor documents a lawful basis for each extra signal.
2. Require SOC 2 Type II and EU data residency before signing, then ask where the data is processed and whether the address is deleted after verification.
3. Test a live batch to see response time and per-address SMTP reply codes before commit.

Don't pick on price.

Catch-all detection and false-positive rate are the same decision from two angles. A tool that marks a catch-all domain as valid will inflate your list and still bounce. Ask the vendor how it treats a catch-all address before you sign.

Free single-check tools have one honest use case. (Skip this one for bulk work.) A free web form verifies one address at a time, runs syntax and DNS, and the better ones try an SMTP handshake. That's fine when you're checking a founder's address before a cold email. It collapses the moment you paste a hundred leads, and you're still copying results back by hand. You don't need a paid tool for a single address.

SMTP-based APIs are the workhorse for developers. They return a status per address in JSON, support batch endpoints, and the good ones offer webhooks so you don't poll for batch completion. The criteria that matter: response time for inline signup checks, catch-all detection that flags rather than passes, and a clear data processing agreement. Ask where the data is processed and whether the vendor deletes the address after verification.

Field note: When I run a GDPR review for an EU client, I ask for the data processing agreement and the data center location before I ask for the price. A validator storing EU addresses on US servers without Standard Contractual Clauses is a compliance risk, not a deliverability tool. See Standard Contractual Clauses (SCC).

Data-enriched verification APIs add third-party signals on top of the SMTP check: previous hard bounces, domain age, presence in known breach lists. The trade-off is GDPR. Enrichment pulls data from sources you may not have a lawful basis to use for that contact. Choose only if the vendor publishes its data sources and gives you a legal basis for each signal. They also cost more, but for high-volume cold outreach the false-positive reduction is worth it.

In one list I cleaned, a free checker passed a catch-all domain as valid, and every address at that domain bounced.

Email Validation False Positives, Catch-All Domains, and Disposable Addresses

When I need to know how to check if an email is valid, and the domain is catch-all, I treat the result as indeterminate. That's the only honest status for a domain that accepts every RCPT TO. The failure modes around catch-all domains split into false positives and false negatives, and the labels matter. A false positive means the validator calls a dead address valid.

A false negative means the validator calls a live address invalid. Greylisting and SMTP rate limits produce false negatives. Typo domains produce false positives.

A catch-all server confirms every address because its mail routing accepts all local parts. Rejecting every catch-all address cuts real users on domains that use a central inbox, a hosted email gateway, or a forwarder to a distribution list. Accepting every one risks a hard bounce later, when the catch-all inbox rejects the unknown local part or the domain's spam filter drops the message.

Hold the address until you have a signal of engagement, then send. If the address has opened or clicked recently, it earns a send; if it's silent, leave it quarantined. This is not a binary call. The server refuses to reveal which addresses exist, so your list needs a third state: risky.

A false negative starts on the receiving server side. A server running greylisting responds to an automated probe with a 450 or 451 temporary failure under RFC 5321. See Email Greylisting: An Applicability Statement for SMTP. A validator that treats any non-250 as invalid marks a real address as dead. The same thing happens when an SMTP provider rate-limits the validator's IP.

The connection drops or the probe returns a temporary error, and the validator flags a valid inbox as invalid. I never let a single 450 remove an address. I retry once later and only convert to invalid if a hard 550 follows. The retry matters because greylisting is a temporary anti-spam tactic, not a permanent rejection.

Field note: When a greylist 450 shows up on a known-good address, I retry the check once after an hour instead of letting the address fall out of the list.

False positives are sneakier. A typo domain like gmali.com or yaho.com can gain valid MX records and even run a catch-all. Syntax passes. DNS passes. The validator reports valid, but the address is dead to the sender who typed it. It's the right shape but the wrong domain, and no mailbox check can catch intent.

A validator that returns only valid/invalid from SMTP with no catch-all flag is a false-positive generator (skip this one). Flag domains that are one character off a major provider and route them to manual review.

Disposable address detection is a different problem. The address can be fully valid and deliverable, but it belongs to a temporary inbox that the user abandons. A valid disposable is still a churn risk. You send, the inbox works, and the person behind it has already stopped checking it. Providers like Mailinator or 10MinuteMail publish their domains, so a good validator can flag them deterministically. If the disposable flag fires, suppress the address even though syntax and SMTP checks passed. The point is deliverability to a human who will read and respond.

Practical list workflow: keep any validation result of catch-all or risky in a quarantine segment. Do not hard-delete catch-all addresses. For risky results from a temporary failure, retry the check once after a cool-down. For typo-suspect domains, add a manual review step. For disposable addresses, suppress them immediately.

Quarantine first, retry once, then decide.

I tested a known-good address that came back 450 and retried once after a cool-down instead of dropping it.

• I treat catch-all results as indeterminate and keep them in quarantine.

I retry temporary 450/451 failures once after a cool-down.

• I suppress disposable addresses immediately.

Email Verification Privacy, Security, and GDPR Compliance

When I audit a client's list in 2025, the first thing I check here is the privacy chain around the validation vendor, not just the bounce rate. Under GDPR, an email address is personal data, and running it through a validator is processing.

See What is personal data, ICO. Article 6 gives you three lawful bases to anchor a check: legitimate interest for list hygiene, consent for addresses collected for marketing, and contract for customers.

Legitimate interest isn't automatic; you need a documented balancing test showing the check is necessary and doesn't override the person's rights. If you can't name a basis before you check, the result is already contaminated, and a supervisory authority won't accept "the bounce rate improved" as a legal argument.

Data minimization under Article 5(1)(c) is the next test. A validator only needs the address long enough to return a status. It does not need a searchable plaintext log of every address you've ever queried. A validator that stores plaintext addresses becomes a second data controller for that dataset, and you inherit its breach risk.

Field note: A vendor that says it "doesn't store your data" still touches the address in memory while processing it. "Doesn't store" is not the same as "doesn't process."

The logs are the liability.

If a third party checks the address, you're the controller and the vendor is the processor. You need a data processing agreement under Article 28 that states the vendor deletes or returns the address, names the processing location, specifies what happens at contract end, and promises not to use the addresses for its own purposes. A vendor that won't sign a DPA is a compliance risk, not a deliverability tool.

That's the part an EU sender skips when they assume the vendor's privacy page covers the GDPR transfer. This is because since the Schrems II ruling, EU personal data can't flow to the US without a safeguard like Standard Contractual Clauses or EU data residency under GDPR Chapter V.

On the security side, ask for SOC 2 Type II and ISO 27001 before you send a single address. SOC 2 Type II proves the vendor has controls for access, encryption, and retention, tested over time. ISO 27001 certifies the management system behind those controls. Neither replaces the DPA, but a validator without either is running on a privacy policy and a hope.

Verifox's single-call endpoint returns a status and discards the raw address, which fits the minimization requirement better than a web form that stores every query. But the rule holds regardless of tool: know the lawful basis, get the DPA, demand the attestations, and never let a validator keep a plaintext log of your list. When I close an audit, I don't ask whether a validator returned 250 or 550 first; I ask whether the sender can show the lawful basis, a signed DPA, SOC 2 Type II and ISO 27001, and a processing path that discards the address after the check. If any one of those controls is missing, the deliverability gain isn't worth the compliance exposure.

Check Emails Without Burning Your Sender Reputation

Those FAQ answers settle the mechanics. The operational habit is what keeps your sender reputation intact: validate at the point of capture, classify the status, and treat catch-all as nurture, not delete. For the full playbook, see the sender reputation guide.

For one-off addresses, run the manual MX check from earlier or hit a free single-check endpoint. For anything that writes to your CRM or signup flow, set an acceptance threshold before the first record lands: auto-suppress invalid and disposable, quarantine risky and catch-all, and send only to valid addresses or catch-all addresses with prior engagement.

Benefits of Using Email Validation

Validating email at the point of capture keeps my send queue clean, protects the domain's sender reputation, and reduces the bounce rate before it shows up in deliverability dashboards. The specific wins are fewer hard bounces, fewer spam-trap hits, and cleaner CRM segments for follow-up.

That's the whole habit. Once I know how to check if an email is valid, I keep the rule on by default. In my validation runs, typos, disposable signups, and parked domains get caught before they enter the send queue. It's a standing rule because every rejection maps back to one of the three validation layers I ran: syntax/mailbox, MX/domain, or SMTP 250 vs 550, so I act on the evidence instead of a binary valid/invalid guess.

Start my validation run with Verifox's single-call endpoint and get a status per address before the user record is written.

Last reviewed August 2026. We re-verify this guidance every quarter as ISP and ESP policies change.

Key takeaways:

• I use the Three-Layer Email Validity Stack whenever I need to
• My first check is which validation layers actually ran.

• Run these four manual checks for one-off address verification only.
• In the lists I clean, the first question I ask about