# iCloud Mail: MX records and email verification

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

Updated: 2026-09-03

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.

Reference: https://spaw.co/email-providers/icloud