# E-mail verification vs account existence checks: what's the difference?

> Mailbox validation says an address can receive mail. An account check says it is registered on a service. When to use each, and the privacy rules.

Canonical: https://mobilevalidate.com/blog/email-verification-vs-account-existence-checks · Last updated: 2026-09-25

![Cover: E-mail verification vs account existence checks: what's the difference?](https://mobilevalidate.com/og/blog/email-verification-vs-account-existence-checks.png)


By MobileValidate team (https://mobilevalidate.com/about) · Published: 2026-09-25 · Category: Guides · Tags: Email verification, Account security, Fraud prevention, Privacy, Deliverability

E-mail verification and account existence checks answer different questions. Mailbox validation asks: *can this address receive mail?* An account existence check asks: *is this address registered on a particular service?* The first protects deliverability and catches typos. The second is a fraud and account-security signal, and it is more sensitive, so it needs a clearer purpose.

## What does e-mail verification (mailbox validation) answer?

It answers whether the mailbox behind an address exists at the provider that hosts it. A syntax check only proves an address is well formed. `jane.doe@gmail.com` and `jane.dooe@gmail.com` both pass syntax, but only one of them may have a mailbox.

Mailbox validation matters when you are about to send mail: a sign-up confirmation, a receipt, a password-reset link. Mail to a mailbox that doesn't exist bounces, and a high share of bounces damages your sending reputation with mailbox providers.

MobileValidate's [mailbox check](/services/email-verification) (`email.valid`, alias `email`) returns:

- `registered: true`: the provider has a mailbox at this address.
- `registered: false`: a conclusive answer, and there is no such mailbox.
- `registered: null`: no conclusive answer, and `reason` explains why. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate).

It never sends mail to the address and never reads the mailbox.

## What does an account existence check answer?

It answers whether a specific online service has an account registered with the address. Examples in our catalog are [Apple ID](/services/apple-id-email-check) (`apple.email`), Amazon, Facebook, Instagram, Netflix, Spotify, LinkedIn and X. There are also per-provider checks, such as the [Gmail check](/services/gmail-email-check) (`gmail`), that answer whether an account exists at one mail provider.

This is a different kind of fact. A mailbox tells you mail can arrive. An account tells you the address was used to sign up somewhere, which says something about how real and how established the address is:

- A sign-up address with no accounts on the services you check can be one sign of a throwaway address. On its own it proves nothing, so combine it with other signals.
- A recovery address added during a suspicious session that has no mailbox at all can't receive a reset link.

Account checks return yes/no/unknown only. **They never return names, photos, profiles or any inference about the person.**

## How do the two compare side by side?

| | Mailbox validation | Account existence check |
|---|---|---|
| Question | Can the address receive mail? | Is the address registered on service X? |
| Main use | Deliverability, typo capture at sign-up | Fraud and account-security signals |
| Codes | `email.valid` (`email`) | `apple.email`, `amazon.email`, `facebook.email`, `instagram.email`, `netflix.email`, `spotify.email`, `linkedin.email`, `x.email`; per-provider `gmail`, `outlook`, `yahoo`, `yandex`, `mailru` |
| Modes | Real time + bulk | Service accounts: real time + bulk, except `linkedin.email` and `x.email` (bulk only). Per-provider checks: bulk only |
| Coverage | Major webmail providers; other domains → `unknown`, `UNSUPPORTED_PROVIDER`, free | The named service |
| Sensitivity | Lower: says the address works | Higher: says the person uses a service |
| Typical retention | Result + date on the contact record | Only the decision (allow, step up, review) |

The runtime list of e-mail services, their modes and prices comes from `GET /v1/services`. See [e-mail checks](/docs/emails).

## Why can't I just ask the mail server?

The mail protocol was designed with a command for this. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) defines `VRFY` to verify a user name (section 3.5). The same RFC also notes, in section 7.3, that these commands can reveal information about users, and that sites may disable or restrict them. In practice most large providers don't give useful answers to them.

Other do-it-yourself methods have their own problems. Starting an SMTP delivery and stopping before the message body gives different answers depending on the provider. Some domains accept mail for any address ("catch-all") and bounce later. Repeated probing from your own servers can also get your IP addresses rate-limited or listed, which hurts the mail you actually want to deliver.

That is why our mailbox check covers **major webmail providers only**, where most consumer sign-ups come from and where we can give conclusive answers. For company domains it answers `unknown` with `UNSUPPORTED_PROVIDER` rather than guessing, and you pay nothing for those rows.

## When should I use mailbox validation?

Use it whenever an address is about to receive mail you care about, ideally at the moment it enters your system:

| Moment | Why | Action on `false` |
|---|---|---|
| Sign-up form | Catch typos while the person is still on the page | "Please check your e-mail address" |
| Checkout / receipt address | Make sure the receipt arrives | Ask for a correction before payment |
| Lead form | Stop sales from chasing addresses that bounce | Ask for a correction or send to review |
| List import | Remove dead addresses before a send | Suppress the address |

Deliverability is also a reputation question. Google's [e-mail sender guidelines](https://support.google.com/a/answer/81126) ask senders to keep the spam rate reported in Postmaster Tools below 0.3%. That rate counts spam complaints, not bounces, but both come from the same habit: mailing addresses that never asked for your mail or no longer work. Cleaning addresses at entry and mailing only people who opted in addresses both.

## When is an account existence check appropriate?

Use account checks when a decision about fraud or account security benefits from knowing whether the address is established, and when you have a lawful reason to process it. Good fits:

- **Sign-up risk scoring.** An address with a mailbox and accounts on well-known services is less likely to be throwaway. Combine it with phone signals; see [OTP and sign-up fraud](/use-cases/otp-and-signup-fraud).
- **Contact-detail changes.** When a user replaces the recovery address, a new address with no mailbox or no history is a reason to step up verification. See [account security](/use-cases/account-security).
- **Lead verification** for B2C leads where a made-up address wastes sales time. See [lead verification](/use-cases/lead-verification).

Poor fits: deciding whether someone gets credit, a job, housing or insurance; building marketing segments ("people who use service X"); checking addresses you didn't collect. The [acceptable use policy](/legal/acceptable-use) forbids these.

## What does a request look like?

Put addresses in `emails` and at least one e-mail check in `checks`. This test-mode request checks the mailbox and an Apple account for three addresses on the reserved test domain:

```bash
curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["Registered@Test.MobileValidate.com", "unsupported@test.mobilevalidate.com", "not-an-address"],
       "checks": ["email", "apple.email"], "wait": 5}'
```

The first result row (real test-mode output, trimmed):

```json
{
  "kind": "email",
  "input": "Registered@Test.MobileValidate.com",
  "email": "registered@test.mobilevalidate.com",
  "email_status": "valid",
  "e164": null, "country": null,
  "checks": {
    "email.valid": {"service": "email.valid", "status": "completed", "registered": true,
                    "confidence": "high", "checked_at": "2026-09-25T16:15:27.672Z", "billed": false, "reason": null},
    "apple.email": {"service": "apple.email", "status": "completed", "registered": true,
                    "confidence": "high", "checked_at": "2026-09-25T16:15:27.672Z", "billed": false, "reason": null}
  },
  "test": true
}
```

The address was normalized by trimming and lowercasing (no dot or plus rewriting). The second address answers `"status": "unknown", "reason": "UNSUPPORTED_PROVIDER"`, which is how a company domain looks in live mode. The third row has `"email_status": "invalid_email"` and no checks at all, so nothing is billed. Per-provider checks such as `gmail` are bulk only: on `POST /v1/lookup` they return `403 service_disabled` with "available in bulk jobs only (POST /v1/jobs)".

## What limits protect people whose addresses are checked?

E-mail checks have their own anti-enumeration rules, because generated address lists are how people try to discover who uses a service:

- **Per request:** 20 or more distinct addresses on one domain whose local parts differ only by digits or separators (`jane1@`, `jane.2@`, `jane_3@`…) are refused with `403 suspected_enumeration`. `gmail.com` and `googlemail.com` count as one domain. We tested it: twenty `janeN@example.org` addresses were rejected with "The request looks like a generated list of e-mail addresses".
- **Per day (live keys):** 50 or more distinct addresses of one such pattern from one account in a UTC day are refused, however they are split across requests.
- **Size limits:** 100 identifiers per lookup, 50,000 per job, 20 checks per request, and at most 2,000 identifier × check combinations per lookup (100,000 per job).

See [rate limits and abuse](/docs/rate-limits-and-abuse).

## What privacy rules apply?

An e-mail address is usually personal data, and the answer to "does this person have an account on service X" can be more revealing than the address itself. Under the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj), the following points typically apply (ask your counsel what applies to your case):

- **Have a lawful basis** (Article 6) for each purpose. Fraud prevention and securing accounts are commonly argued under legitimate interests. Document your assessment.
- **Minimise** (Article 5(1)(c)). Store the mailbox result and its date on the contact record. For account checks, store the decision (allow, step up, review) rather than a list of services.
- **Honour objections** (Article 21). People can object to checks through our [opt-out form](/opt-out). Suppressed addresses come back as `email_status: "suppressed"`, are never checked and never charged.

Tell users in your privacy notice that you verify contact details to prevent fraud and keep accounts secure.

## What are the key takeaways?

- **Mailbox validation** answers "can this address receive mail?" Use it at sign-up, checkout and list import to protect deliverability.
- **Account existence checks** answer "is this address registered on service X?" Use them as fraud and account-security signals, not for marketing or eligibility decisions.
- The mailbox check covers **major webmail providers**. Other domains answer `unknown` (`UNSUPPORTED_PROVIDER`) and **aren't charged**.
- DIY SMTP probing is unreliable: [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) lets servers disable `VRFY`, and catch-all domains accept everything.
- Generated address lists are refused. Check only addresses people gave you, keep only the decision, and respect objections.
- Start with the [mailbox check](/services/email-verification) and test every branch for free with the addresses in [test mode](/docs/test-mode).

## Sources

1. [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) — IETF, 2008
2. [Email sender guidelines](https://support.google.com/a/answer/81126) — Google, 2026
3. [General Data Protection Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj) — European Union, 2016

## Frequently asked questions

### What is the difference between e-mail verification and an account existence check?

E-mail verification (mailbox validation) answers whether the address has a working mailbox at its provider, so mail will not bounce. An account existence check answers whether an account on a specific service, such as Apple or Amazon, is registered with that address.

### Why does the mailbox check return unknown for my company domain?

The mailbox check covers major webmail providers only. Company and custom domains run their own mail servers with their own rules, so they answer unknown with reason UNSUPPORTED_PROVIDER. That result is not charged.

### Is an account existence check more sensitive than mailbox validation?

Yes. Knowing that an address is registered on a particular service reveals more about a person than knowing their mailbox exists. Use account checks only with a clear purpose such as fraud prevention or account security, and store only the decision.

### Can I verify a list of addresses like name1@, name2@, name3@?

No. Twenty or more addresses on one domain that differ only by digits or separators are refused as suspected enumeration, and live keys have a daily limit per pattern. Check only addresses people gave you.