Sign up and contact support to get 100 free checks.Sign up free
EmailCheckPro workflow illustration for How to Check If an Email Address Exists and Can Receive Mail
A visual overview of the workflow discussed in this EmailCheckPro article.

A practical guide to checking whether an email address exists: the four outcomes a check can return, how common methods compare, and how to act on each result.

Before that, confirm the input is a complete address with a local part, an @ sign and a domain, because a malformed entry is a format problem rather than an undeliverable result. Some addresses, such as those on catch-all domains, cannot be settled either way and should be stored as undetermined.

What "check if email address exists" can realistically tell you

A check made before any message is sent can answer the first two. The last two belong to other processes, such as a confirmation link or your own consent records.

It helps to treat the answer as one of four outcomes rather than a simple yes or no:

Outcome What it means Next step
Invalid format The input is not a complete address with a local part, @ and domain Ask for a correction; do not record it as undeliverable
Deliverable The address could receive mail at check time Keep it and store the check date
Undeliverable The address could not receive mail at check time Stop sending to it and look for a current address
Undetermined No outcome could be settled, as with catch-all domains Keep it in a separate group and decide case by case

Keeping these four apart is the main thing most existence checkers skip. Folding invalid or undetermined rows into undeliverable throws away addresses that may be fine and hides typos that could be fixed.

Common ways to check if an email address exists, compared

Several methods circulate in guides and forums. They differ a lot in what they show and what they cost you.

Method What it shows Main drawback
Send a test message A bounce, or silence Silence is not proof of anything, and mailing unknown addresses adds bounces to your sending history
Probe a sign-in or password-recovery page Sometimes whether an account exists Recovery flows are designed not to reveal this, and probing them can look like an attack
Look up the domain's mail records Whether the domain is set up to receive mail Says nothing about the individual mailbox
Talk to the mail server yourself Sometimes whether a recipient is accepted Many servers accept every recipient or refuse unknown callers, and your own IP can be blocked
Use a deliverability check service Deliverable or undeliverable at check time, with nothing sent Some addresses remain undetermined

The test-message route is the most common mistake. Google's email sender guidelines expect bulk senders to mail people who asked for it, and repeated bounces from guessed addresses work against that. Recovery-page probing has a similar problem: the OWASP guidance on email verification tells applications not to disclose whether an account exists, so well-run services give the same answer either way. Server conversations follow the commands defined in RFC 5321, but the standard lets servers decide how much they reveal, which is why do-it-yourself scripts return so many inconclusive answers.

How to check if an email address exists with EmailCheckPro

EmailCheckPro's Email Deliverability Check accepts addresses on virtually any domain and returns deliverable or undeliverable for each completed check. The workflow depends on how many addresses you have.

  1. Clean the input first. Trim spaces, remove trailing punctuation copied from documents, and confirm each entry has a local part, an @ sign and a domain. Lowercasing the domain is safe; leave the local part as entered.
  2. Check one address. Paste it into the dashboard for a realtime result, or call POST /api/v1/check from your server with the Email Deliverability Check product. Keep the API key on the server rather than in browser code.
  3. Check a short list. The dashboard handles realtime checks of up to 500 addresses. Through the API, POST /api/v1/batch-check accepts 1–100 addresses per request and returns results in the same order as the input. An item with no completed result is reported as such and should not be read as undeliverable.
  4. Check a prepared file. Upload a TXT or CSV file with one complete address per line as an asynchronous bulk task. Invalid and duplicate lines are removed during preparation. Poll GET /api/v1/bulk-tasks/{id} no more often than every 30 seconds and download the single result CSV when the task succeeds.
  5. Record the outcome with a date. A result describes the address at check time, so the date matters as much as the verdict.

No message is sent to the address at any stage, and the address owner receives nothing. For Gmail, Yandex and Mail.ru addresses, Email Avatar Check can add a public avatar signal alongside deliverability.

What to do with each outcome

A check is only useful if each outcome leads to a clear action. A simple routing plan looks like this:

  • Invalid format. At a signup form, show the address back and ask the person to correct it. In an imported list, fix obvious domain typos only when the source record confirms the intended address; otherwise move the row to a review group. Invalid input is not charged.
  • Deliverable. Keep the address and save the check date next to it. A deliverable address is still subject to your normal permission rules, so the result does not replace your consent records.
  • Undeliverable. Stop routine sending to the address. Mark the record rather than deleting it, so the same address is not re-imported later, and ask for a current address at the next natural touchpoint, such as a login or a renewal.
  • Undetermined. Keep these rows in their own group. Catch-all addresses, for example, are undetermined rather than guessed, and a realtime check that cannot be settled returns no result and is not charged. Re-check later, or contact these addresses only where an existing relationship already supports it.

Teams that send from several tools should agree on one place where outcomes are stored. Otherwise a marketing platform may keep mailing an address the CRM already flagged as undeliverable.

Limits to keep in mind before acting on a result

An existence check is a snapshot, and a few limits shape how far it should be trusted.

  • Results age. Mailboxes are closed, abandoned and recreated. Google, for example, publishes an inactive account policy under which personal accounts unused for two years may be deleted. Re-check older segments before an important send or after a long gap.
  • Deliverable is not a person. Shared and role addresses such as a team inbox can be deliverable while no single person is responsible for them.
  • Deliverable is about the recipient address only. It says the address could receive mail; how a particular message is filtered is a separate question about the sending side.
  • Undetermined is not a failure of your data. It reflects how some domains are configured, so it should not count against the contact by default.

Writing these limits into the team's data rules keeps people from over-reading a single result in either direction.

FAQ

How can teams check whether a whole list of email addresses exists?

Export the email column, remove obvious blanks, and save it as a TXT or CSV file with one complete address per line. Submit it as a bulk task, which runs asynchronously, and poll the task status no more often than every 30 seconds. The single result CSV lists each address with its outcome. Download links last 12 hours; querying the same task again refreshes the link if it expires.

Why does a catch-all domain make an existence check inconclusive?

EmailCheckPro reports these addresses as undetermined instead of guessing, and undetermined checks are not charged. Treat them as a separate group with their own sending rules.

What is the difference between an invalid email address and an undeliverable one?

An invalid address fails the basic shape of an email address, for example a missing @, a space in the middle, or a missing domain. An undeliverable address is complete and well formed, but the check found that it could not receive mail at that moment. The fixes differ: invalid entries need correcting, undeliverable ones need replacing.

How long does a deliverable result stay useful?

A practical approach is to tie re-checks to events: before a large campaign, when a contact returns after a long silence, and when records are imported from an older system. Store the check date with each result so the team can see how old the evidence is.

Learn More

Choose the product information that fits the next step in your workflow.

Sources