How to Verify Email Address Accuracy Before You Send

If you searched for how to verify email address accuracy before you send, start with one rule: no single check is enough. A valid-looking address can still bounce, belong to a burner domain, sit behind a catch-all server, or fail because the mailbox does not exist.

What it means to verify an email address: how to verify email address accuracy

To verify an email address, you check whether it is correctly formatted, belongs to a real mail-capable domain, and is likely to receive mail without bouncing.

People often use validation, verification, and deliverability scoring interchangeably. They are related, but they are not the same.

Check type	What it answers	Example	Limitation
Validation	“Does this look like an email address?”	alex@example.com has a local part, @, and domain	Cannot prove the mailbox exists
Verification	“Can this address likely receive mail?”	Domain has MX records and mailbox probe looks valid	Some servers hide mailbox status
Deliverability scoring	“How risky is it to send?”	Catch-all, disposable, role account, or unknown SMTP result	It gives a decision signal, not a guarantee

A basic regex can catch obvious mistakes like missing @ signs or invalid domain characters. It cannot check if alex@company.com maps to a real mailbox. It also cannot detect disposable domains, catch-all behavior, greylisting, or mailbox-level rejections.

A practical verification result usually falls into four verdicts:

• Deliverable: The address passed format, domain, mail record, and mailbox checks. You can usually send.
• Risky: The address may accept mail, but has risk signals. Examples include catch-all domains, role accounts, or temporary SMTP uncertainty.
• Undeliverable: The address is malformed, uses a dead domain, has no mail records, or appears rejected by the mail server.
• Unknown: The check could not reach a confident answer. This can happen because of throttling, privacy protections, greylisting, or temporary DNS/SMTP failures.

Step 1: Check syntax and obvious typos

Start by checking whether the address has a valid structure and whether the domain looks like a common typo.

A standard email address has two main parts:

local-part@domain

For example:

jane.santos@example.com

You should check:

• The address has exactly one @ symbol.
• The local part is not empty.
• The domain is not empty.
• The domain contains valid labels separated by dots.
• The top-level domain exists in a valid format.
• The address does not contain spaces or invalid control characters.
• The full address length stays within accepted email limits.

Do not make your regex too clever. Email syntax has edge cases that most real-world systems do not support well. A practical validator should reject obvious bad input without blocking normal addresses like:

• first.last@example.com
• first+tag@gmail.com
• first_last@company.co.uk

Catch typo domains

Many bad addresses come from simple typing mistakes. You should flag common provider typos such as:

• gmial.com → gmail.com
• gmai.com → gmail.com
• hotmial.com → hotmail.com
• outlok.com → outlook.com
• yaho.com → yahoo.com

Typo correction works best when you ask the user to confirm the fix.

For example, if someone enters:

maya@gmial.com

Your form can say:

Did you mean maya@gmail.com?

Do not silently rewrite the address unless the user confirms it. Some domains look like typos but are real company domains. Silent correction can lock users out of accounts, misroute receipts, or send personal data to the wrong inbox.

Keep syntax feedback immediate

Syntax and typo checks belong in the form. Give feedback before submission when possible. This reduces friction and prevents bad data from entering your CRM, product database, or email platform.

Good form behavior:

• Show a clear error for malformed input.
• Suggest a likely typo fix.
• Preserve what the user typed.
• Let the user confirm or override a suggestion.

Bad form behavior:

• Accept anything with an @.
• Block valid plus-addressing.
• Rewrite domains automatically.
• Show vague errors like “Invalid input.”

Step 2: Verify the domain and mail records

After syntax, check whether the domain exists and can receive email.

This means performing DNS checks. DNS tells you whether the domain is real and which mail servers handle email for it.

Check domain resolution

First, check whether the domain resolves in DNS. If the domain does not exist, the address cannot receive mail.

For:

sam@example-company-123.com

You check:

example-company-123.com

If DNS returns NXDOMAIN, the domain does not exist. The address is undeliverable.

Run an MX record check

Next, run an MX record check. MX records identify the servers that receive mail for a domain.

A healthy domain might return records like:

example.com.  MX 10 mail1.example.com.
example.com.  MX 20 mail2.example.com.

If the domain has MX records, you can move to deeper verification.

If it has no MX records, check whether it has an A or AAAA record. Some domains can receive mail through fallback A records, although most modern mail setups use MX records. Treat fallback-only domains with more caution.

Flag parked, expired, and suspicious domains

Some domains technically resolve but should still raise risk.

Watch for:

• Parked domains with no real mail setup.
• Expired domains that recently changed ownership.
• Domains with suspicious random strings.
• Domains used by disposable email services.
• Domains that resolve but refuse all mail connections.
• Domains with misconfigured DNS.

A domain-level check helps you answer a basic question: “Is there a real mail system behind this address?” If the answer is no, do not send.

Step 3: Detect disposable, role, and free provider addresses

Disposable, role, and free provider addresses need different treatment because they create different types of risk.

Disposable email detection

Disposable email addresses come from temporary inbox providers. People use them to avoid giving a permanent address.

Examples include burner inboxes created for:

• One-time downloads.
• Coupon abuse.
• Spam complaints avoidance.
• Fake trial signups.
• Low-quality lead submissions.

Disposable email detection checks the address domain against known burner and throwaway providers. This list needs constant updates because new disposable domains appear all the time.

For many signup forms, you should block disposable addresses or ask for a business or permanent email. They often create poor activation, poor retention, and higher abuse rates.

That said, your policy should match your product. A free tool may allow disposable addresses for low-risk access. A paid trial, marketplace, community, or fintech product may block them.

Role account detection

Role accounts represent a function, not a person.

Common examples:

• info@company.com
• support@company.com
• sales@company.com
• admin@company.com
• billing@company.com
• privacy@company.com

Role accounts are not always bad. They are often correct for invoices, support requests, vendor notices, and business inquiries.

They become risky when you need a specific person to receive and engage with the email. For example, cold outreach to info@ usually performs worse than outreach to a named contact. It can also reach multiple people, which may increase complaint risk if your message is not expected.

Use role detection as a routing signal:

Use case	Role account action
Billing receipt	Allow
Support conversation	Allow
Product signup	Allow or review, depending on abuse risk
Newsletter opt-in	Allow if confirmed
Cold outreach	Treat as risky
Account owner email	Prefer a person-specific address

Free provider detection

Free providers like Gmail, Outlook, Yahoo, and iCloud are not automatically disposable. Do not block them just because they are free.

A Gmail address can be a real customer, buyer, applicant, or newsletter subscriber. In B2B workflows, you may prefer a work email for lead qualification. But that is a business rule, not a deliverability rule.

Separate these concepts:

• Disposable means temporary or burner.
• Free provider means consumer mailbox provider.
• Role account means shared function address.
• Business domain means custom organizational domain.

Each one should feed your decision differently.

Step 4: Use SMTP checks carefully

An SMTP email check asks the receiving mail server whether it appears willing to accept mail for a mailbox.

At a high level, the verifier connects to the mail server listed in DNS and performs part of an SMTP conversation. It does not need to send an actual message. It checks how the server responds when asked about a recipient.

A simplified flow looks like this:

Connect to mail server
Say hello
Specify sender
Ask about recipient
Read server response
Quit

If the server clearly says the mailbox does not exist, you can mark the address undeliverable. If it accepts the recipient, the address may be deliverable.

But SMTP checks have limits.

SMTP checks are not always definitive

Mail servers use many defenses that make verification harder:

• Greylisting: The server temporarily rejects unfamiliar senders.
• Throttling: The server limits repeated checks.
• Tarpitting: The server intentionally slows connections.
• Privacy protections: The server hides whether a mailbox exists.
• Temporary failures: DNS, network, or mail server issues affect the result.
• Security gateways: A gateway accepts mail first and filters later.

Because of this, SMTP verification should not be a blunt yes/no gate. It should contribute to a risk score.

Understand catch-all domains

A catch-all domain accepts mail for any local part, whether the mailbox exists or not.

For example, all of these may appear accepted:

alice@company.com
random-string-9283@company.com
notarealperson@company.com

That does not mean every mailbox is real. It means the domain accepts all recipients at the SMTP level.

This is where catch-all email verification matters. A verifier should detect catch-all behavior and return a risk-based verdict instead of pretending the address is confirmed.

Catch-all addresses can still be useful. Many companies run catch-all configurations. You should not automatically block them. You should treat them as uncertain and combine the signal with other data.

Good supporting signals include:

• The domain is established.
• The address came from a trusted source.
• The user confirmed ownership.
• The contact engaged before.
• The local part looks person-specific.
• The domain has normal business mail records.

Riskier signals include:

• The address came from a purchased list.
• The local part looks random.
• The domain is new or suspicious.
• The same domain appears in many low-quality signups.
• The campaign is cold outreach.

Step 5: Decide whether to send, block, or review

The goal of email address verification is a better sending decision, not a prettier report.

Use the verdict to choose one of four actions:

Verdict	Meaning	Typical action
Deliverable	Low bounce risk	Accept and send
Risky	Some signals suggest caution	Allow with safeguards, review, or confirm
Undeliverable	High confidence the address will bounce	Block, suppress, or ask for correction
Unknown	Not enough signal	Retry later, confirm ownership, or review

Signup forms

For signup forms, verify in real time before you create the account or send the first email.

Recommended actions:

• Deliverable: Accept.
• Risky: Allow with email confirmation, CAPTCHA, rate limits, or manual review.
• Undeliverable: Ask the user to correct the address.
• Unknown: Allow only if the product flow can handle confirmation or delayed activation.

A real-time API check works well here because it catches bad input while the user can still fix it. Bounceable, for example, can return deliverability verdicts, typo suggestions, disposable flags, role account signals, and catch-all risk before you send.

An illustrative verification response might look like:

{
  "email": "maya@gmial.com",
  "verdict": "undeliverable",
  "reason": "domain_typo",
  "suggestion": "maya@gmail.com",
  "checks": {
    "syntax": "pass",
    "mx": "fail",
    "disposable": false,
    "role": false,
    "catch_all": false
  }
}

Newsletters

For newsletters, protect consent and engagement.

Recommended actions:

• Use email address verification at signup.
• Use confirmed opt-in for higher-risk sources.
• Suppress undeliverable addresses before import.
• Segment risky or unknown addresses into a lower-volume path.
• Remove addresses that hard bounce.

Do not rely on confirmation emails alone. A confirmation email sent to a bad address still bounces. Verification reduces that waste before you send.

Cold outreach

Cold outreach has less margin for error. Recipients did not ask for your message, so bounces and complaints hurt faster.

Recommended actions:

• Verify every address before loading it into a sequence.
• Suppress undeliverable results.
• Limit catch-all sends and monitor outcomes by domain.
• Avoid role accounts unless the message truly belongs there.
• Start with small batches for risky or unknown results.

Keep bounce rates low. Many teams aim to stay well under 2% for campaigns, especially on cold lists.

Transactional email

Transactional email needs a different policy because the user may need the message to complete an action.

Recommended actions:

• Check syntax and typo suggestions before submission.
• Block clearly undeliverable addresses.
• Allow some unknown results if the user can retry.
• Use confirmation or backup contact methods for critical flows.
• Log verification results for support teams.

For password resets, receipts, and security alerts, accuracy matters. But overblocking can also hurt users. Balance risk with account recovery needs.

Common mistakes when verifying email addresses

Most verification problems come from treating one signal as the whole truth.

Relying only on regex

Regex is useful, but it only answers one question: “Does this look like an email address?”

It does not answer:

• Does the domain exist?
• Does the domain receive mail?
• Is the mailbox real?
• Is the domain disposable?
• Is the server catch-all?
• Is the address likely to bounce?

Use regex as the first check, not the final check.

Relying only on confirmation emails

Confirmation emails prove ownership when the user clicks. They do not prevent the first bounce.

If someone enters a typo, your confirmation email still goes to the typo address. That bounce can hurt list quality and sender reputation over time.

Best practice:

1. Validate and verify the address.
2. Suggest corrections before submission.
3. Send confirmation only to addresses that are not clearly undeliverable.
4. Suppress hard bounces immediately.

Sending test emails to unknown addresses

Do not “verify” by sending test messages to see what bounces. That creates the exact problem you are trying to avoid.

Test sends can:

• Increase bounce rate.
• Hit spam traps.
• Trigger complaints.
• Pollute engagement metrics.
• Damage domain and IP reputation.

Run an email deliverability check before sending. Then send only when the risk fits the use case.

Treating catch-all addresses as automatically bad

Catch-all does not mean fake. It means SMTP cannot confirm the mailbox at the recipient level.

For a warm inbound lead from a known company, you may accept a catch-all address. For a purchased cold list, you may suppress or heavily limit it.

Use context.

Treating free addresses as automatically bad

A free provider address can be valid and engaged. Many buyers use personal email for newsletters, communities, receipts, and trials.

Block free providers only when your business process requires a work email. Do not call them disposable unless they come from an actual disposable domain.

Treating unknown as automatically safe

Unknown means the verifier could not reach a confident result. It does not mean deliverable.

Handle unknown results based on risk:

• Low-risk newsletter signup: allow with confirmation.
• Expensive free trial: review or require confirmation first.
• Cold outreach list: retry later or suppress.
• Transactional account flow: allow with safeguards if needed.

Skipping ongoing list hygiene

Verification is not a one-time task. Addresses decay. People leave jobs. Domains expire. Mail systems change. A deliverable address today can bounce later.

Build hygiene into your process:

• Verify at collection.
• Recheck old or inactive lists before campaigns.
• Remove hard bounces immediately.
• Suppress repeated soft bounces after a reasonable threshold.
• Watch bounce rate by source.
• Treat list purchases and scraped data as high risk.
• Reconfirm stale subscribers before sending large campaigns.

If you want a practical workflow, keep it simple:

1. Check syntax and typos at the form.
2. Verify DNS and MX records.
3. Detect disposable, role, and free provider addresses.
4. Run careful SMTP and catch-all checks.
5. Return a clear verdict.
6. Apply a decision rule by use case.
7. Recheck lists before important sends.

That gives you a reliable way to check if email address is valid before it reaches your sending platform. It also keeps your decisions explainable when sales, marketing, product, or support asks why an address was blocked or allowed.