# Domain Check vs Mailbox Check: MX vs SMTP Verification

URL: https://leadraft.co/blog/domain-check-vs-mailbox-check
Summary: An MX (domain) check proves a domain takes mail. An SMTP (mailbox) check asks about the address. What each proves, why some verifiers skip SMTP, how to tell.

[ All articles](https://leadraft.co/blog)

# Domain check vs mailbox check: what email verification actually proves

An MX (domain) check proves a domain takes mail. An SMTP (mailbox) check asks about the address. What each proves, why some verifiers skip SMTP, how to tell.

The Leadraft teamLeadraft

Published

November 3, 2026

Read time

6 min

Category

Deliverability

A domain check (MX lookup) proves only that a domain can receive email; it says nothing about whether the mailbox you want exists. A mailbox check (SMTP check) asks the domain's mail server about that exact address and is the only common test that can catch "no such user", except on catch-all servers, which accept every address.

Many tools labeled "email verification" do only the domain check. That's fine for catching typos and dead domains, but not for cold email, where each address that doesn't exist becomes a bounce.

## What does each check prove?[#](#what-does-each-check-prove)

The two checks answer different questions. A verifier that does both runs them in order: syntax, then the domain's MX records, then the SMTP conversation with the mail server.

A verifier does the first half of a delivery and stops before anything is sent. Accept-all (catch-all) servers say yes to every address, so they get their own grade: a maybe, never a yes.

Scroll horizontally if needed →

|  | Domain check (MX) | Mailbox check (SMTP) |
| --- | --- | --- |
| Question it answers | Can this domain receive email? | Will this server accept mail for this address? |
| How it works | DNS lookup of MX records (and A/AAAA as a fallback) | Connects to the mail server, names the address with `RCPT TO`, hangs up before sending |
| Catches | Typo domains, expired domains, domains with a null MX | Those, plus mailboxes that don't exist at a working domain |
| Misses | Every made-up or departed mailbox at a working domain | Certainty on catch-all servers; bounces after acceptance |
| Detects catch-all? | No | Yes, by testing a made-up address |
| Speed | Milliseconds | Seconds per address, with retries |
| Runs from | Anywhere, including a browser | A server with port 25 open and a clean IP |
| Sends an email? | No | No |

So `jane@acmeplumbing.com` and `zzqx81@acmeplumbing.com` look identical to a domain check if `acmeplumbing.com` has mail servers. A mailbox check tells them apart, unless the server accepts both.

## What exactly does a domain check look at?[#](#what-exactly-does-a-domain-check-look-at)

It queries DNS for the domain's MX records, which name its mail servers. Under RFC 5321, if a domain has no MX records but has an address record, the domain itself is treated as the mail server. A "null MX" record (RFC 7505) says the domain accepts no mail at all, so any address there is invalid.

DNS checks can show more than MX. Our free [email domain checker](https://leadraft.co/tools/email-domain-checker) also reads SPF and DMARC records and shows who hosts the mail (Google Workspace, Microsoft 365 and others). Those tell you the domain is maintained and how it's set up. None of them reaches a mailbox.

## Why do some verifiers only check the domain?[#](#why-do-some-verifiers-only-check-the-domain)

Because a domain check is easy and a mailbox check is hard to do well.

-   **Port 25 is blocked on common platforms.** Amazon EC2 blocks outbound port 25 to public addresses by default, and Google Compute Engine blocks connections to destination port 25 outside your network. A tool built on serverless or standard cloud hosting often can't talk to mail servers at all.
-   **IP reputation decides the answer.** Mail servers refuse or mislead connections from IPs they distrust, such as end-user ranges on Spamhaus's Policy Blocklist. A careless checker gets blocked and returns garbage.
-   **It's slow.** Each check is a network conversation with retries for greylisting (RFC 6647), which deliberately delays unknown senders with temporary `4xx` replies.
-   **Some providers discourage it.** Microsoft's Outlook.com sender policy prohibits "namespace mining," checking addresses without sending to them. Large providers often give answers that make every address look the same.

None of that makes a domain check dishonest. It becomes a problem when it's sold as verification and the result is shown as "valid."

## How do I tell which check a tool runs?[#](#how-do-i-tell-which-check-a-tool-runs)

Run three quick tests on any verifier, including ours:

1.  **The fake-mailbox test.** Verify an address you know doesn't exist at a domain you control, such as `no-such-person-8137@yourcompany.com`. A mailbox check marks it invalid. A domain check marks it valid. (Make sure your own domain isn't catch-all first, or both will say yes.)
2.  **The catch-all test.** Does the tool ever return "catch-all", "accept-all" or "risky"? A domain-only check can't detect catch-all, so it never shows that result.
3.  **The unknown test.** Does the tool sometimes return "unknown" or "retry later"? Real SMTP checks hit timeouts and greylisting. A tool that always answers instantly with valid or invalid is probably not talking to mail servers.

Scroll horizontally if needed →

| Result you see | Likely check |
| --- | --- |
| Fake mailbox at a real domain marked valid | Domain only |
| Never returns catch-all | Domain only |
| Returns catch-all, invalid mailbox, and some unknowns | Mailbox (SMTP) |

Then read how the tool grades catch-all. Folding catch-all into "valid" is the commonest way a verifier inflates its numbers. See [how to check if an email is catch-all](https://leadraft.co/blog/how-to-check-if-email-is-catch-all).

## When is a domain check enough?[#](#when-is-a-domain-check-enough)

A domain check is enough when you only need to catch typos and dead domains: a sign-up form, a CRM cleanup before a mailing to people who opted in, or a first pass before a paid verifier so you don't pay to check addresses at domains that can't receive mail. For cold email, use a mailbox check, because a bounce rate built from nonexistent mailboxes hurts the reputation of every mailbox you send from. [What's a good cold email bounce rate](https://leadraft.co/blog/cold-email-bounce-rate) covers the thresholds.

## FAQ[#](#faq)

### What is the difference between an MX check and an SMTP check?[#](#what-is-the-difference-between-an-mx-check-and-an-smtp-check)

An MX check looks up DNS to see whether a domain publishes mail servers, so it proves the domain can receive email. An SMTP check connects to that mail server and asks whether it would accept mail for the specific address, so it can catch mailboxes that don't exist. Only the SMTP check says anything about the person's address.

### Is an MX check enough to verify an email list?[#](#is-an-mx-check-enough-to-verify-an-email-list)

No. It removes addresses at domains that can't receive mail, such as expired domains and typos, but every made-up or departed mailbox at a working domain passes. For cold email, where bounces hurt sender reputation, you need a mailbox-level check.

### Why do some email verifiers only check the domain?[#](#why-do-some-email-verifiers-only-check-the-domain)

Because SMTP checks are hard to run well. They need outbound port 25, which major cloud platforms block by default, a sending IP with a clean reputation, careful pacing and retries. A DNS lookup is instant and works from anywhere, so some tools stop there and still call it verification.

### How can I tell if a verifier does a real mailbox check?[#](#how-can-i-tell-if-a-verifier-does-a-real-mailbox-check)

Test it with an address you know doesn't exist at a domain you control (and that isn't catch-all). A mailbox check marks it invalid; a domain-only check marks it valid. Also look for a catch-all or accept-all result: a tool that never returns one isn't asking the mail server.

### Does a mailbox check guarantee an email won't bounce?[#](#does-a-mailbox-check-guarantee-an-email-wont-bounce)

No. It shows the server accepted the address at the moment of the check. Catch-all servers accept every address, some servers bounce after accepting, and mailboxes close later. A mailbox check lowers bounce risk; it doesn't remove it.

## Sources[#](#sources)

1.  IETF, [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321) (`RCPT TO`, reply codes, implicit MX in section 5.1).
2.  IETF, [RFC 7505: A "Null MX" No Service Resource Record](https://www.rfc-editor.org/rfc/rfc7505).
3.  IETF, [RFC 6647: Email Greylisting](https://www.rfc-editor.org/rfc/rfc6647).
4.  Amazon Web Services, [Amazon EC2 service quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) (port 25 restricted by default).
5.  Google Cloud, [Sending email from an instance](https://docs.cloud.google.com/compute/docs/tutorials/sending-mail).
6.  Spamhaus, [Policy Blocklist (PBL)](https://www.spamhaus.org/blocklists/policy-blocklist/).
7.  Microsoft, [Outlook.com Postmaster: Policies, Practices, and Guidelines](https://substrate.office.com/ip-domain-management-snds/postmaster/Policies) (namespace mining).

## Keep reading

-   [
    
    November 3, 2026Deliverability
    
    ### How to check if an email domain is catch-all
    
    To check if an email is catch-all, ask the mail server about an address that can't exist. How the test works, why a verifier should run it, and which tools do.
    
    Read article
    
    ](https://leadraft.co/blog/how-to-check-if-email-is-catch-all)
-   [
    
    October 31, 2026Deliverability
    
    ### What's a good cold email bounce rate? (And how to get yours under it)
    
    Aim for a cold email bounce rate under 2%. What Gmail, Yahoo, Outlook and sending tools actually publish, what causes bounces, and how to fix a high rate.
    
    Read article
    
    ](https://leadraft.co/blog/cold-email-bounce-rate)
-   [
    
    October 31, 2026Deliverability
    
    ### How email verification works: syntax, MX, SMTP and catch-all, explained
    
    How email verifiers check an address without sending mail: syntax, MX records, the SMTP RCPT TO test, catch-all detection, their limits, and when to re-verify.
    
    Read article
    
    ](https://leadraft.co/blog/how-email-verification-works)

Last built: 2026-11-09