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

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. [email protected] and [email protected] 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 (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 (apple.email), Amazon, Facebook, Instagram, Netflix, Spotify, LinkedIn and X. There are also per-provider checks, such as the Gmail 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?

The runtime list of e-mail services, their modes and prices comes from GET /v1/services. See e-mail checks.

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

The mail protocol was designed with a command for this. RFC 5321 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:

Deliverability is also a reputation question. Google's e-mail sender guidelines 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.
• 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.
• Lead verification for B2C leads where a made-up address wastes sales time. See 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 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:

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

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

{
  "kind": "email",
  "input": "[email protected]",
  "email": "[email protected]",
  "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 [email protected] 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.

#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, 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. 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 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 and test every branch for free with the addresses in test mode.