How to Verify an Email Domain (And Why It's the First Thing Verification Tools Check)

When an email bounces, most people blame the address. The real culprit is usually the domain. A bad domain means every address on it is undeliverable — no matter how well-formatted the local part looks. This guide explains how email domain verification works, what it catches, how to do it manually and with a tool, and why getting it right is the foundation of everything else in email deliverability.

---

What does it mean to verify an email domain?

Email domain verification is the process of confirming that the domain portion of an email address — everything after the @ — is real, properly configured, and capable of receiving mail.

Take the address sarah@acmecorp.com. The local part is sarah. The domain is acmecorp.com. Domain verification checks whether acmecorp.com actually exists in DNS, whether it has mail exchange (MX) records that tell the internet where to deliver email, and in some cases whether the domain is configured to accept all incoming mail regardless of the recipient.

A valid-looking address on a broken domain is completely undeliverable. sarah@acmecorp.com hard bounces if:

• acmecorp.com doesn't exist in DNS
• acmecorp.com exists but has no MX records
• acmecorp.com's mail server is permanently offline

Domain verification is the check that catches all of these — before you send a single message.

---

What checks does domain verification run?

Domain verification isn't one check. It's a sequence of lookups that progressively confirm the domain's mail-readiness.

1. DNS existence check

The first question is whether the domain exists at all. A DNS lookup queries the global domain name system to see if acmecorp.com is registered and resolving. If the domain has expired, been abandoned, or never existed, the lookup returns no result and the verification fails immediately. Every address on that domain is undeliverable.

2. MX record lookup

If the domain exists, the next check queries for MX records. An MX record is a DNS entry that specifies which mail server handles incoming email for a domain. Without MX records, there is no configured path for email to reach the domain, even if the domain itself is live.

Some domains exist on the web but have never been configured to receive email — they serve websites or other services but have no mail infrastructure. MX record verification catches these.

3. MX record validity

Having an MX record isn't enough if what it points to doesn't exist or doesn't respond. A thorough domain check confirms that the hostname specified in the MX record actually resolves — that there's a real mail server at the other end, not just a pointer to nothing.

4. Catch-all detection

Once a valid, active mail server is confirmed, there's one more domain-level behavior to check: whether the domain is configured as a catch-all. A catch-all domain accepts all email sent to any address at that domain, regardless of whether the specific mailbox exists. This matters because it makes SMTP-level mailbox verification unreliable — the server says "yes" to everything, so you can't confirm whether sarah@acmecorp.com is a real mailbox or not.

Catch-all detection probes the mail server with a known-nonexistent address (something like zzz_not_real_12345@acmecorp.com). If the server accepts it, the domain is flagged as catch-all.

---

What is an MX record and why does it matter?

An MX (mail exchange) record is a type of DNS record that tells the internet's mail routing infrastructure where to deliver email for a given domain. When you send an email to sarah@acmecorp.com, your mail server queries DNS for acmecorp.com's MX records, finds the hostname of the receiving mail server (like mail.acmecorp.com), and delivers the message there.

MX records have a priority value attached to them, which allows domains to specify multiple mail servers in order of preference. If the primary server is unavailable, delivery retries against the secondary.

From an email verification standpoint, the absence of MX records is definitive: no MX record means no mail delivery path means the address cannot receive email, period. You can verify this in seconds without even touching an inbox.

Common reasons a domain has no MX records:

• The domain is used only for a website, not for email
• The company has migrated to a new domain and the old one is being wound down
• The domain was registered speculatively and never configured
• The email infrastructure was shut down but the domain registration is still active

All of these scenarios produce hard bounces. Domain verification catches them before you send.

---

What is a catch-all domain?

A catch-all domain (also called an accept-all domain) is a domain whose mail server is configured to accept email addressed to any local part — valid or not. If acmecorp.com is catch-all, both sarah@acmecorp.com and doesnotexist@acmecorp.com will appear to accept delivery at the server level.

This creates a problem for verification. Standard SMTP verification works by connecting to the mail server and asking "does this mailbox exist?" On a catch-all domain, the answer is always yes, even when the mailbox doesn't exist. The actual bounce happens silently later — often after the message has already damaged your sender metrics.

Catch-all domains are common in:

• Small and mid-size businesses that configure a catch-all to avoid missing any email sent to their domain, even if the recipient's name is misspelled
• Older corporate infrastructure set up before modern spam considerations made catch-alls problematic
• Domains used for testing or internal routing that were never intended for external use

From a sending perspective, catch-all addresses carry real risk. They look verifiable, they accept the message at the SMTP handshake, but a significant portion of the underlying mailboxes don't exist. Sending to a list with a high proportion of catch-all addresses often results in silent delivery failures — the kind that degrade sender reputation without clear attribution.

The right approach is to segment catch-all addresses separately and either suppress them, test with a small controlled send first, or accept the tradeoff of reaching some while losing others.

---

How to verify an email domain manually

You can run domain-level checks yourself without any tool. Here's how.

Check if the domain exists

On Mac or Linux, open Terminal. On Windows, open Command Prompt or PowerShell.

nslookup acmecorp.com

If the domain exists and resolves, you'll see an IP address in the response. If the domain doesn't exist, you'll see a "Non-existent domain" or similar error.

Look up MX records

nslookup -type=MX acmecorp.com

A domain with mail configured will return one or more MX entries with hostnames and priority values, like:

acmecorp.com    MX preference = 10, mail exchanger = mail.acmecorp.com

No MX records returned means the domain can't receive email.

On Linux/Mac you can also use:

dig MX acmecorp.com

Check for catch-all behavior

This one requires a basic SMTP session. You're simulating the start of an email delivery to test how the server responds to a nonsense address. Most developers use telnet for this:

telnet mail.acmecorp.com 25
EHLO test.com
MAIL FROM:<test@test.com>
RCPT TO:<zzz_not_real_99999@acmecorp.com>

If the server responds with 250 OK to that obviously fake address, the domain is catch-all. If it responds with 550 User unknown or similar, the domain verifies at the mailbox level.

This works for individual checks, but it doesn't scale. For lists of any meaningful size, you need a tool.

---

How domain verification fits into full email verification

Domain verification is one layer in a multi-step process. Understanding where it sits helps clarify what it catches and what it doesn't.

Verification layer	What it checks	What it catches
Syntax check	Address format	Typos, malformed addresses
Domain existence	DNS registration	Expired, abandoned, or nonexistent domains
MX record check	Mail routing configuration	Domains not set up to receive email
Catch-all detection	Server-level accept behavior	Domains that mask invalid mailboxes
SMTP mailbox check	Specific mailbox existence	Addresses that don't exist on a real domain
Disposable detection	Known throwaway providers	Temporary inboxes
Role-based detection	Generic local parts	Team inboxes with high complaint rates
Spam trap detection	Seeded trap addresses	ISP-planted addresses that damage sender reputation

Domain verification covers the middle chunk — steps 2 through 4. It's the foundation everything else builds on. A clean domain result is a prerequisite for meaningful mailbox-level verification. A failed domain check means the entire address is undeliverable regardless of what the local part looks like.

---

Why domain verification alone isn't enough

Knowing that a domain exists and has MX records tells you the domain can receive email. It doesn't tell you whether a specific address at that domain does.

sarah@acmecorp.com might be a real, active inbox. saaah@acmecorp.com — a one-letter typo — might not exist at all. Both would pass domain verification. Only mailbox-level SMTP verification can distinguish between them.

This is why thorough email verification runs domain checks first (to eliminate the obvious failures) and then moves to mailbox-level checks for the addresses that survive. Doing it in sequence is efficient: there's no point in running an SMTP check against an address whose domain has no MX records.

The practical implication: if you're trying to verify email addresses, domain verification is necessary but not sufficient. A tool that only checks domains is leaving meaningful risk on the table.

EmailsConfirmed runs the full sequence — format, domain, MX records, catch-all detection, and SMTP mailbox verification — and returns a clear valid, invalid, or risky result for each address. Domain verification is included as part of every check, not sold as a separate feature.

---

The fastest way to verify email domains at scale

Manual nslookup and dig commands work fine for checking a handful of addresses. For lists of any real size, you need something that runs these checks in parallel across thousands of addresses and gives you structured output you can act on.

EmailsConfirmed is built for exactly this. Upload a CSV or TXT file, and it runs every domain and mailbox-level check automatically — no manual column editing, no setup, no configuration. Results come back classified as valid, invalid, or risky, and you download a clean export ready to load back into your ESP or CRM.

The pricing model is what separates it from the alternatives. Every other major verification tool — ZeroBounce, NeverBounce, Kickbox, Hunter — charges per email verified, either as credits or a subscription that resets monthly. That means every time you re-verify a list, you pay again. For teams that run campaigns regularly or maintain large databases, those costs compound fast.

EmailsConfirmed charges a single flat fee of $149.99, once, for unlimited verifications. Run your list monthly. Re-verify before every campaign. Verify the same list ten times in a year. The price doesn't change.

For anyone verifying at scale, that math is hard to argue with.

---

Key takeaway

Domain verification is the first real gate in email deliverability. Before you can know whether a specific mailbox is reachable, you need to know whether the domain it lives on exists, has mail infrastructure configured, and isn't masking bad addresses behind a catch-all configuration.

Getting domain verification right — along with the full suite of mailbox-level checks — is what keeps bounce rates low, sender reputation intact, and campaigns landing in the inbox instead of the spam folder or the void.

Start with 100 free verifications at EmailsConfirmed — no credit card required — and see exactly which addresses and domains in your list are putting your deliverability at risk.

---

FAQ

What is email domain verification?

Email domain verification is the process of confirming that the domain portion of an email address (everything after the @) exists in DNS, has properly configured mail exchange (MX) records, and is capable of receiving email. It's the foundation layer of full email address verification.

What's the difference between domain verification and email verification?

Domain verification checks that the domain itself is valid and mail-capable. Email verification goes further and checks whether the specific mailbox at that domain exists and can receive messages. Domain verification is a subset of full email verification — necessary but not sufficient on its own.

What is an MX record?

An MX (mail exchange) record is a DNS entry that specifies which mail server handles incoming email for a domain. Without MX records, a domain has no configured path for receiving email, and any address on that domain is undeliverable. Checking for MX records is one of the first and most reliable domain-level checks.

What is a catch-all domain and is it safe to send to?

A catch-all domain accepts email addressed to any local part at that domain, even if the specific mailbox doesn't exist. This makes it impossible to confirm individual mailboxes through standard SMTP verification. Catch-all addresses carry higher delivery risk — some mailboxes are real, others aren't, and there's no reliable way to tell. The safest approach is to segment them separately and either suppress them or test carefully before including them in large sends.

Can I verify an email domain without a tool?

Yes. You can use nslookup -type=MX yourdomain.com or dig MX yourdomain.com to check MX records manually, and a basic SMTP session via telnet to test catch-all behavior. This works for individual checks but doesn't scale to lists of any meaningful size.

Does EmailsConfirmed verify email domains as part of its checks?

Yes. Domain verification — including DNS existence, MX record lookup, and catch-all detection — is included in every verification EmailsConfirmed runs. It's part of the full multi-layer process, not a separate feature or add-on.

Why does my list have domains that pass verification but still bounce?

Most likely because of catch-all domains. A catch-all domain's mail server accepts everything at the SMTP handshake, making individual mailboxes appear valid even when they don't exist. The bounce happens after delivery, silently. Catch-all detection flags these domains so you can handle them separately rather than treating them as confirmed-valid sends.

How often should I re-verify domains on my list?

Domain configurations change. Companies shut down, migrate to new domains, or change their mail infrastructure. A domain that was valid six months ago may have no MX records today. Before any major campaign — and at minimum quarterly for active lists — re-verification catches these changes before they produce bounce spikes.

What happens to my sender reputation if I send to invalid domains?

Sending to addresses on nonexistent or mail-incapable domains generates hard bounces. ISPs track hard bounce rates at the sender domain level. Rates above 2% start triggering deliverability penalties — reduced inbox placement, promotions tab filtering, and in severe cases, blocks. A single send to a poorly verified list can cause a bounce spike that takes weeks of clean sending to recover from.