iCloud+ · Custom domain · Setup & limits
iCloud+ custom email domain: better aligned than you feared, smaller than you hoped
Most cheap sending puts your brand on someone else's authentication. Apple's design does the opposite: the SPF record sits at your root and the DKIM key is served from your _domainkey — alignment most ESPs can't offer. What Apple withholds isn't authentication. It's control, tooling and scale.
The record set (exactly as Apple specifies it)
| Record | Name | Value | Apple's notes |
|---|---|---|---|
| TXT | @ | Your personal verification value (issued during setup) | Proves the domain is yours |
| TXT (SPF) | @ | v=spf1 include:icloud.com ~all | Merge the include into an existing SPF instead of adding a second record |
| MX | @ | mx01.mail.icloud.com and mx02.mail.icloud.com, both priority 10 | Delete your existing MX first |
| CNAME (DKIM) | sig1._domainkey | sig1.dkim.<yourdomain>.at.icloudmailadmin.com | Apple prints the pattern with “example.com” and tells you to substitute your domain |
| Apple suggests TTL 3600 and warns a registrar lock blocks setup until removed. Two doors in: buy the domain through Apple (its partner flow pre-configures DNS) or bring your own domain and enter records yourself (some registrars support Apple's sign-in auto-update; Apple names none of them — Cloudflare is confirmed only for purchases). | |||
What Apple never does: DMARC
Nowhere in Apple's flow does a _dmarc record appear — confirmed both in Apple's guide and in first-person setup accounts. So the standard move is yours: publish v=DMARC1; p=none; rua=mailto:you@yourdomain at your DNS host, read the aggregate reports (Article #36 — they'll show Apple's sources passing), and climb per Article #4. Apple's mail will carry it fine; Apple simply has no DMARC tooling, dashboard or postmaster service for domain owners on the other side.
§3 — the alignment reality (labelled inference)
Apple publishes no MAIL FROM/envelope specification. But its mandated DNS only functions one way: SPF is evaluated on the envelope domain, so a root-level SPF record is purposeless unless the envelope sits at your domain — and a DKIM CNAME under your _domainkey can only serve signatures with d= your domain, selector sig1. Read together (this guide's mechanism inference, marked as such): both SPF and DKIM align, relaxed and strict — iCloud custom domain is better aligned than the shared-ESP setups in Articles #31/#34/#35. If your DMARC fails on iCloud-sent mail, look at record errors (Article #20), not at Apple's architecture.
The honest limits table
| Apple states | What it means for a business |
|---|---|
| 5 domains per account · 10 addresses per domain | Family-scale, not staff-scale. (Apple's own guide contradicts itself — one page still says three addresses per person; Apple's newer support text says 10 per domain. We print the newer figure and flag the stale one) |
| Share with up to 5 people (Family Sharing) | “Employees” are family members in Apple's model. There are no business-owned mailboxes: addresses live in a person's Apple Account |
| An address, once used, can never be reused — even after the owning Apple Account is deleted | The burned-address rule. A departed person's info@ is gone forever. Choose addresses like they're permanent — they are |
| Catch-all exists (“Allow All”, owner-only, owner's inbox) | Third-party claims of “no catch-all” are wrong — Apple's guide documents it. It all lands on the owner, though |
| Sending: 1,000 messages/day · 1,000 recipients/day · 500/message · 20 MB (5 GB Mail Drop) | Fits correspondence, not campaigns — and there is no bulk-sending program to graduate into |
| IMAP only, no POP; third-party clients via app-specific passwords | Client flexibility exists, managed-device control doesn't |
Absent, not prohibited (framed as absence — Apple simply offers none): admin console, DKIM key choices or rotation (one fixed selector sig1, keys held by Apple), DMARC/postmaster/feedback tooling for owners, audit/eDiscovery/retention controls, programmatic sending beyond client SMTP.
When to graduate
- Stay if: it's you (plus family-scale help), correspondence volume, Apple devices everywhere, and the burned-address rule doesn't scare you because addresses are personal anyway.
- Graduate to Workspace/M365 when any of these become true: mailboxes must belong to the business (staff turnover), you need an admin console/audit trail, sending approaches the daily caps, or a second sending service (invoicing, helpdesk) needs its own authentication story alongside yours. The migration is a standard MX/SPF/DKIM changeover — Articles #41–#44 are the receiving guides; your iCloud records delete cleanly, but remember: addresses you created stay burned only inside Apple's system — the same addresses can be recreated fresh at the new provider.
Traps
| Trap | Reality |
|---|---|
| Moving registrars casually | The records ARE the setup. A transfer that drops the four records takes mail down until they're rebuilt — export them first (the drift-breaks-mail claims from third parties are plausible practice, not Apple-documented) |
| Treating an employee's address as a company asset | It lives in their Apple Account, under the burned rule. Front-door addresses (info@, sales@) deserve a real provider from day one if staff will rotate |
| Expecting Apple Business tooling | There is none at this tier. iCloud+ custom domain is a consumer feature that happens to fit tiny businesses — evaluate it as that, and it's genuinely good at it |
FAQ
Do I need the “Apple Branded Mail” program too?
Different thing: Branded Mail (Business Connect) puts your logo in Apple Mail (Article #37 covers the split) and is separate from custom-domain mail hosting. Owning one doesn't grant the other.
Can I send from a subdomain of my iCloud domain?
Apple's guide doesn't document subdomain sending setups — treat it as unsupported territory and use the domain itself (or a real provider for subdomain streams, Article #40's model).
Will my DMARC at p=reject break iCloud mail?
Not when the four records are exactly as tabled — both legs align (§3). Errors in the records, not enforcement, are the risk; climb with reports as usual.
Sources
Apple Support — HT212524 (custom domain setup: the record set, TTL, registrar lock, catch-all “Allow All”) · Apple iCloud Mail limits documentation (1,000/day figures as quoted verbatim in research; the legacy Apple article could not be re-read directly this pass — older 200/day figures exist in print and are flagged here rather than silently replaced) · Apple support text on address counts (Sept 2026 update) · First-person 2025 setup account (DMARC absence corroboration).
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.