iCloud Mail: MX records and email verification

updated · September 3, 2026

How iCloud Mail and iCloud custom domains look in DNS, how Apple's servers answer a verification handshake, and which verdicts to expect.

iCloud Mail serves Apple's consumer accounts on icloud.com, together with the legacy me.com and mac.com addresses that still deliver to the same mailboxes, and since 2021 it also hosts custom domains for iCloud+ subscribers. Spaw reports all of them as mx_provider: "icloud".

How iCloud shows up in DNS

Every iCloud-hosted domain publishes the same pair of MX records, mx01.mail.icloud.com and mx02.mail.icloud.com, both at priority 10. Apple's setup guide for custom domains uses exactly these two hosts. Spaw matches the .mail.icloud.com suffix. iCloud is a mailbox host: the MX target is Apple's own inbound server, mx_found is true and mx_implicit is false.

How iCloud answers a verification handshake

Apple's inbound servers typically reject unknown recipients at RCPT TO, so a missing icloud.com mailbox is confirmed in the session. They are also strict about sender reputation and will defer or drop connections from sources they distrust, which occasionally leaves a probe unverified with smtp_reason: greylisted or no_connect. Custom domains on iCloud+ can enable a catch-all address from the iCloud settings, and those domains then answer as catch-all.

What that means for your verdicts

For icloud.com, me.com and mac.com, Apple's username rules apply before any probe: letters, digits, dots, underscores and hyphens. Anything else is undeliverable with reason: invalid_local_part without a handshake. Valid addresses are probed and mostly come back deliverable with mailbox_exists: true or undeliverable with reason: mailbox_not_found and smtp_reason: no_mailbox.

Hide My Email, Apple's relay feature, generates single-purpose addresses on privaterelay.appleid.com rather than on icloud.com, so they classify under a different provider; they exist until the user deactivates them, after which they bounce. Custom domains with catch-all enabled answer risky with reason: catch_all and a mailbox_confidence estimate; iCloud is not on the established-provider list, so the estimate relies on the domain's own records, its age and the shape of the username.

SPF and DMARC at iCloud

For custom domains, Apple's guide publishes v=spf1 include:icloud.com ~all for SPF, a DKIM CNAME with the selector shown during setup, and a DMARC record. icloud.com itself publishes SPF and a DMARC policy, so From addresses at icloud.com sent through other services fail alignment. Spaw reports the live state of any domain in has_spf and dmarc_policy.

Practical notes for sending to iCloud users

Apple's Mail Privacy Protection loads remote content through Apple's proxies, which makes open rates for iCloud users unreliable and makes engagement data a poor substitute for verification. Legacy me.com and mac.com addresses are still live for the accounts that had them, so do not discard them on age alone; verify them. iCloud does not use Gmail-style plus-addressing for consumer accounts, and role-style usernames on icloud.com are individual accounts rather than shared inboxes, though Spaw still applies its role-word list to them.

For a live look at any iCloud-hosted domain, run it through the free MX lookup and the SPF and DMARC checker.

Live examples

Current DNS for domains hosted here, from the free tools.

Related

markdown version: /email-providers/icloud.md

Verify addresses the same way

The Spaw API runs every check described here on each lookup, with an SMTP handshake that never sends mail. 10 free lookups a month, no card required.

Get your API key

More email providers