How to verify an iCloud email address

That three-domains-one-mailbox quirk is the whole story of iCloud verification. If your list has john@me.com and john@icloud.com, they may be the same person's inbox reached two ways. Verifying one address tells you that route works; it doesn't prove the user actually reads the other two. Below is how iCloud behaves over SMTP and how to check a list without sending anything.

How iCloud responds to a verification attempt

iCloud's mail servers sit behind MX records on *.icloud.com and *.mail.me.com. When a verifier connects and asks — at the RCPT TO stage — whether the server will accept mail for an address, iCloud gives a comparatively straight answer: a clean 250 for a real mailbox, a 550 for one that doesn't exist. That's better than Gmail, which accepts almost everything and bounces later, or Outlook, which greylists first attempts.

Consumer iCloud domains are not catch-all, so you rarely get an ambiguous "unknown" on a plain @icloud.com address the way you would on a custom Google Workspace domain. The result is that iCloud verification is usually decisive: valid or invalid, with fewer of the in-between "risky" verdicts other providers force.

The wrinkle is Hide-My-Email. Apple lets users generate random relay addresses — a pattern of a few words plus digits at @icloud.com — that forward to the real inbox. These are fully deliverable and will verify as valid, because they are real routing addresses; they just don't tell you who's behind them. Our validator recognizes the Hide-My-Email shape rather than treating those addresses as ordinary iCloud accounts.

The three-domain trap when you deduplicate

Because @icloud.com, @me.com and @mac.com can share an inbox, a naive dedupe by exact string will keep what are effectively duplicate contacts. If you're cleaning a list, treat all three as the same provider before counting unique recipients — otherwise you may mail the same person twice and inflate your list size on paper. This isn't a deliverability bug; it's a counting one, and it only bites teams that assume one address string equals one person.

A related subtlety: the @me.com and @mac.com domains are older. Apple has handed them out for well over a decade, so addresses on them skew toward long-standing accounts — some very active, some long abandoned. The domain alone doesn't tell you which; only an SMTP check does. That's the difference between "this address is formatted like iCloud" and "this iCloud mailbox will actually accept mail," and it's why the syntax pass and the deep check answer different questions.

How to verify an iCloud address without sending an email

For a single address you can do it by hand. Look up the domain's MX records with dig MX icloud.com — you'll see Apple's mail hosts. Then open an SMTP session to one of them, say HELO, give a MAIL FROM, and issue RCPT TO for the address you're checking. Read the response code — 250 means the server will accept mail, a 550 means the mailbox doesn't exist — then disconnect before the DATA step. No message is ever sent. That works cleanly for one or two addresses, precisely because iCloud gives honest answers.

It stops scaling fast, though. From a single IP, repeated probes look like abuse, and while iCloud is less aggressive than Yahoo about rate-limiting, Apple still throttles. You also lose the provider-aware handling — the three-domain grouping, the Hide-My-Email detection — that a manual telnet session simply doesn't do. For anything past a handful of addresses, automate it.

It stops working the moment you have a list. Probing many addresses from one IP gets throttled, and stitching together the three iCloud domains, Hide-My-Email relays and rate limits by hand is error-prone. The reliable path is two-pass:

1. Cheap first pass — syntax, MX lookup, provider detection and scoring across the whole list at $0.00049 per address. This already flags malformed addresses and identifies which are iCloud.
2. Deep SMTP check — run the mailbox-level verification only on the addresses you choose, so you don't spend the premium rate on entries the first pass already ruled out.

You never send a message to the recipient at any step — verification reads the server's answer, not the mailbox's contents.

Reading the result

Because iCloud is informative, most addresses come back as a firm valid or invalid, and you can act on those directly: mail the valid ones, drop the invalid ones. The addresses worth a second look are the few marked risky — usually Hide-My-Email relays or accounts on a custom domain that happens to route through Apple. A relay is safe to mail; it forwards. A genuine unknown you can hold back from a first campaign and re-check later, rather than risk a bounce on your most important send.

One thing not to do: don't treat "didn't bounce a test email" as verification. Sending a real message to probe an address burns your sender reputation if the address turns out dead, and it tips spam traps — the exact addresses you most want to avoid. An SMTP check reaches the same conclusion without ever putting a message in the recipient's server, which is why verifying before you send is strictly safer than testing by sending.

Common questions