Short answer: iCloud addresses come back as unknown, not invalid. We are not saying the address is bad — we are saying we could not obtain a reliable signal to confirm it either way. There is no setting that changes this, and we do not charge credits for these results.
Why this happens
Apple's mail infrastructure (icloud.com, me.com, mac.com, including Hide-My-Email aliases) is deliberately built to defeat mailbox verification. During the SMTP conversation, Apple's servers do not reveal whether a specific mailbox exists — they typically accept the address (returning "250 OK") and only bounce it later, after the message body is sent. They also rate-limit and block verification probes at the network level.
Because of this, there is no point in the exchange where any verification provider can deterministically prove an iCloud address is deliverable. Rather than guess, we intentionally skip live probing for Apple domains and return an honest unknown.
This is consistent with how the major verification services (ZeroBounce, NeverBounce, Kickbox, Hunter) treat these same domains — the limitation is on Apple's side, not unique to us.
Is there a configuration to fix it?
No. There is no setting that will turn these results into valid. We would rather return an honest unknown than a fabricated valid we cannot stand behind.
What we recommend
Treat unknown iCloud addresses as "unconfirmed but likely fine to send." If they came from a legitimate signup or transaction, they are usually deliverable. The safest way to confirm is a real send with normal bounce monitoring — the only test Apple's servers actually respond to. Do not discard unknown iCloud addresses on the assumption they are invalid.