Email verification by provider
Every mailbox provider answers a verification attempt differently, so the same check can return a clean "valid" on one domain and an honest "risky" on another.
When a verifier checks an address without sending mail, it opens an SMTP conversation with the
receiving server and asks whether it will accept mail for that mailbox. The catch is that
providers don't answer the same way. Gmail and Outlook are evasive — they accept almost
anything at the RCPT TO stage and sort out delivery later, so a raw check looks
positive even for addresses that will bounce. Yahoo and iCloud are stricter and more
informative, giving a clearer signal at connection time.
That's why a single flat "valid / invalid" verdict, applied the same way to every domain, is an oversimplification. A verifier worth using has to read each provider on its own terms — which is exactly what the table below breaks down, provider by provider.
How the four major providers respond
| Provider | MX pattern | Catch-all typical? | SMTP informative? | What to watch for |
|---|---|---|---|---|
| Gmail / Google Workspace | *.google.com, aspmx.l.google.com |
Rare on @gmail.com, common on Workspace domains |
Limited — accepts, then bounces | Dots and +tags are ignored: j.doe+x@gmail.com = jdoe@gmail.com |
| Yahoo | *.yahoodns.net |
Rare | Moderate | Aggressive rate limiting on bulk probing |
| Outlook / Hotmail / Live | *.outlook.com, *.hotmail.com |
Common on custom domains | Limited | Greylisting — a first attempt may look like a soft failure |
| iCloud | *.icloud.com, *.mail.me.com |
Rare | Good | Three domains for one mailbox: @icloud.com, @me.com, @mac.com |
These patterns come straight from how our own validator classifies traffic: it detects the provider from the MX host, normalizes Gmail dots and tags, flags catch-all domains as risky rather than valid, and reads iCloud's Hide-My-Email aliases by their distinctive shape. The per-provider pages below go deeper on each.
Why the provider changes the result
To verify a Gmail address without sending an email — or a Yahoo, Outlook or iCloud one — a tool
opens an SMTP session with the provider's mail server and asks, in effect, "will you accept mail
for this mailbox?" On a cooperative server the answer is a clean 250 for yes or
550 for no. The problem is that the big providers don't all cooperate the same way,
and each has its own reason.
Gmail and Outlook optimize for accepting mail, not for answering probes. Their servers say
yes at the RCPT TO step to almost anything, then decide whether the mailbox exists
after the connection closes. That's good for deliverability and bad for verification: a raw check
reads as valid even when the address is dead. On Google Workspace domains it's worse — many
are configured as catch-all, so the server accepts every address by policy. An honest tool marks
those risky instead of pretending it confirmed them.
Yahoo and iCloud give straighter answers, but each adds a twist. Yahoo rate-limits
aggressively: probe too many addresses on the same domain too fast and it starts throttling by IP,
which is why bulk verification has to be paced rather than hammered. iCloud answers cleanly, but a
single account spans three domains — @icloud.com, @me.com and
@mac.com — and Apple's Hide-My-Email produces relay aliases that look like random
addresses but forward to a real inbox. Reading those correctly needs provider-specific logic, not
a one-size check.
The practical takeaway: a manual dig MX plus telnet works for one or two
addresses, but the moment you check a list at scale the providers' defenses — greylisting, rate
limits, catch-all acceptance — turn a naive script into a source of false positives. That's the
gap a real verifier fills.
Verify a specific provider
Verify any provider at once
You don't need to sort your list by provider first. Upload a mixed CSV and charlymail detects each address's provider automatically, applies the right logic per domain, and returns a result broken down by valid, risky and invalid. Catch-all and unknown addresses are flagged honestly, not passed off as verified.
Verification runs at $0.00049 per address — $0.49 per 1,000, with no subscription and payment in crypto, no card required.
Start with 200 free tokensCommon questions
Does Gmail tell you if an email address exists?
Not reliably. Gmail accepts mail for an address at the RCPT stage and decides
later, so a check can look like a yes even for an address that will bounce. Gmail also ignores
dots and +tags — j.doe+news@gmail.com and jdoe@gmail.com
reach the same mailbox — so those never mark a separate account.
Can you verify an Outlook address without sending an email?
Partly. You can confirm the MX records and run an SMTP check, but Outlook uses greylisting: a first attempt can look like a soft failure even for a real mailbox. A good verifier retries and reads the pattern instead of trusting one response — that's how you verify an Outlook address without sending anything.
Why do Gmail addresses come back as risky?
Because Gmail's SMTP layer isn't fully informative. When the server won't confirm a mailbox either way — common on Workspace domains set up as catch-all — an honest verifier marks the address risky rather than claiming a certainty it doesn't have.
Do @me.com and @icloud.com mean the same mailbox?
Often yes. Apple gives one iCloud account up to three address domains — @icloud.com,
@me.com and @mac.com — that can all deliver to the same inbox. Their
MX records point to the same Apple infrastructure.
How much does it cost to verify a list across providers?
charlymail detects each address's provider automatically and verifies mixed lists at $0.00049 per address — $0.49 per 1,000. New accounts get 200 free tokens, there's no subscription, and payment is in crypto with no card required.