How do I set up and use custom email domains with iCloud, and what are common issues with it?
Updated on 19 Oct 2026: We updated the iCloud address limits and setup checks, and added steps for sorting custom domain mail into folders.
To set up a custom email domain with iCloud, you need iCloud+, an Apple Account with two-factor authentication, a primary iCloud Mail address, a domain you own or purchase during setup, and access to its DNS records. In iCloud.com, add the domain, add and verify the addresses you already use, publish Apple's DNS records, verify the setup, choose the default sending address, then test both inbound and outbound mail.
iCloud custom domains are part of your existing Apple Account and iCloud Mail, rather than a separate mailbox system. Incoming mail goes to Apple's MX servers, and outbound mail can use your custom address after Apple verifies the domain. Apple allows up to five custom domains. Apple's current overview lists up to ten personalized addresses per person per domain, and a domain can be shared with up to five other people. Use Apple's setup page for the account-level requirements, then use DNS checks to confirm the domain is ready.
- Mailbox model: Mail lands in iCloud Mail under your Apple Account, not a separate provider login.
- DNS change: Your domain's MX records must point to Apple's mail servers.
- Sending identity: You can choose the default From address after setup, but every mail client still needs testing.
- Eligibility: Custom Email Domain is unavailable in some countries and regions, and managed Apple Accounts are unsupported.
- Main risks: DNS propagation, duplicate SPF records, missing DKIM CNAMEs, full iCloud storage, old Apple Account ties, and rushed MX cutovers cause most failures.
How iCloud custom domains work
iCloud custom domains fit personal and light business mailboxes. They work well for people who want me@example.com in Apple Mail, iCloud.com, Messages, Calendar, FaceTime, and other Apple Account uses. They are less suited to newsletters, CRM mail, transactional systems, or operations that need role-based administration and detailed deliverability controls.
The setup changes where your domain receives mail. It does not simply forward messages to an @icloud.com address. Once MX records point at Apple, Apple becomes the receiving mail provider for that domain. For sending, publish the exact SPF and DKIM records Apple provides, then confirm that a real message passes DMARC through an SPF or DKIM domain match.
iCloud custom domain
- Login: You sign in with the Apple Account that owns or accepts the domain.
- Inbox: Mail appears in iCloud Mail and Apple Mail, alongside normal iCloud mail.
- DNS: MX, TXT, SPF, and DKIM CNAME records must match Apple's values.
Basic forwarding
- Login: You keep the original mailbox provider and forward copies elsewhere.
- Inbox: Forwarded messages can lose authentication context or arrive as relayed mail.
- DNS: MX records stay with the original mail host unless forwarding is provider-managed.
iCloud custom email domain setup with DNS verification and mail testing.
Set up the domain in iCloud
Before touching DNS, write down the current provider, every active address, the existing MX values, the existing SPF record, and the current TTL. That rollback note matters. When you change MX records, new mail starts going to Apple as soon as resolvers see the update. If the address list is incomplete or verification stalls, people can miss mail.
- Prepare: Confirm iCloud+ is active, iCloud Mail has a primary address, and two-factor authentication is on.
- Add: Open iCloud.com, go to iCloud+, choose Custom Email Domain, then add a domain you own.
- Assign: Add existing addresses and complete the verification email for each one at your current provider before changing MX records. Choose Only You or You and Other People as appropriate.
- Publish: Add Apple's verification TXT record, SPF include, two MX records, and DKIM CNAME.
- Verify: Return to iCloud and select Finish Setup after DNS has had time to propagate.
- Test: Send and receive with the final app, then inspect headers with an email tester.
On iPhone, open Settings > [your name] > iCloud > Mail, enable Use on this iPhone, then select Custom Email Domain > Use a Domain You Own. On iCloud.com, use the Custom Email Domain app or the iCloud+ settings.
Typical iCloud DNS recordsdns
@ TXT apple-domain=YOUR_PERSONAL_VERIFICATION_VALUE @ TXT "v=spf1 include:icloud.com ~all" @ MX 10 mx01.mail.icloud.com. @ MX 10 mx02.mail.icloud.com. sig1._domainkey CNAME sig1.dkim.example.com.at.icloudmailadmin.com.
Use the verification value Apple gives your account and replace example.com in the DKIM target with your own domain. The SPF example assumes iCloud is your only sender; merge it with an existing policy when other services also send mail.
After choosing the default sending address, iCloud.com can import messages from a supported previous provider. Check the mailbox size and available iCloud storage first. Imported messages appear in a folder named after the previous address, with its mailbox folders nested inside.
Do not publish two SPF records at the root. If your domain already has SPF for another sender, merge Apple's include into the existing record. Two separate SPF TXT records create a permanent SPF error, even if each record looks valid by itself.
Verify DNS before moving live mail
The most common iCloud setup complaint is simple: the records look right, but iCloud still says they are wrong. Check for cached DNS, a host field mismatch, or old MX records still present. Some DNS hosts append your domain automatically, so confirm that sig1._domainkey resolves under the correct name and that its CNAME target matches Apple's value. Quotes and trailing dots are DNS-editor conventions; omit them when the host requires it. Check public DNS first, then retry Apple's verifier.
For a broad check, Suped's domain health checker checks published email authentication records. Use it to find DNS configuration problems, then inspect a real message's headers to confirm that SPF or DKIM passes with a domain match.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
Lower TTL before a planned migration when the DNS host allows it, then wait for the previous TTL to expire before changing MX records. After the domain verifies, real mail passes, and rollback is no longer needed, restore a normal TTL. Apple recommends a TTL of 3600 seconds, or 1 hour, for these records.
Use the domain after setup
After iCloud verifies the domain, choose which address sends by default. On Apple devices, use the same Apple Account and enable iCloud Mail so the custom addresses appear. Test iCloud.com, Apple Mail on macOS, Mail on iPhone, and every third-party client that connects to iCloud Mail. Default address settings and client-side account caches can disagree for a while, so the only proof is a message sent from each real client.
iCloud.com custom email domain settings with verified DNS.
|
|
|
|---|---|---|
Inbound | Mail reaches iCloud | Bounce or delay |
Outbound | From uses domain | Shows iCloud address |
SPF | Apple is allowed | Permerror |
DKIM | Apple signs | No signature |
DMARC | Domain match passes | Fail result |
What to test after iCloud verifies the domain.
If you share the domain, every person needs to accept the invitation and create or verify their addresses. Family Sharing does not mean every old mailbox has moved. Check each address individually, including short aliases, role addresses, and any address used for account recovery.
For a manually configured client, iCloud Mail uses IMAP on imap.mail.me.com with port 993 and SMTP on smtp.mail.me.com with port 587. Use SSL/TLS for IMAP and STARTTLS for SMTP, with SMTP authentication enabled and an app-specific password. iCloud Mail does not support POP. For SMTP, use your full primary iCloud Mail address as the username, while selecting the custom address in From. For IMAP, use the primary address's username or its full address if needed.
An address already used with a different Apple Account cannot be added to the domain until that account stops using it. Deleting the other Apple Account does not release the address. Resolve this conflict before migration; Apple's current overview allows personalized addresses for signing in to your own device.
Separate custom domain mail into folders
Custom domain addresses assigned to your Apple Account share your iCloud Mail inbox. They do not create separate mail accounts. Use a recipient-based iCloud Mail rule to keep domain mail in its own folder across devices.
- Create an iCloud Mail folder, such as "Domain mail".
- On iCloud.com, open Mail > Settings > Rules, select Add, and name the rule.
- Set the recipient condition to your custom address, such as me@example.com, and choose the action that moves matching messages to the folder.
- Save the rule, allow up to 15 minutes for it to take effect, then send a new test message and check the folder on your devices.
Repeat for other addresses as needed. Update the rule if you rename or delete its destination folder. The folder organizes mail within the same account; check the From address when replying.
Use catch-all mail carefully
iCloud supports catch-all delivery through a setting called Allow All. The domain owner can open iCloud.com, select iCloud+, choose Custom Email Domain, select the domain, then turn on Allow All. Mail sent to an address that has not been created goes to the domain owner's inbox.
- Ownership: Only the domain owner can enable Allow All.
- Destination: Unmatched messages go to the domain owner's iCloud Mail inbox.
- Shared addresses: Mail for an address previously created by another member does not become catch-all mail for the owner.
- Deleted addresses: Messages sent to deleted addresses are returned to the sender.
Catch-all delivery recovers mail sent to misspelled or unlisted addresses, but it also accepts more unwanted mail. Create explicit addresses for important identities and test both an unused address and a deleted address before relying on the setting.
Common iCloud custom domain issues
Most problems fall into repeatable groups. Separate setup problems from sending problems because the fix path differs. A domain can receive mail through iCloud while outbound mail still shows the wrong From address, fails DMARC, or lands in spam because the sending path differs from the one you tested.
|
|
|
|---|---|---|
MX rejected | Propagation or old MX | Check both priority-10 Apple MX records, remove old MX records, then allow cached DNS to expire |
Address verification pending | Verification email not completed | Check the old inbox and junk folder; use Resend Verification Emails and retry in another mail client if the button is missing |
SPF error | Duplicate TXT records | Merge senders into one record |
No DKIM | Bad CNAME | Fix host and target values |
Wrong From | Default or client cache | Reset default and refresh |
Address unavailable | Used by another Apple Account | Remove the address from the other account before adding it; deleting that account does not release it |
Cannot send or receive | iCloud storage is full | Free space or add storage |
Feature missing | Region or managed account | Check account eligibility |
Sending limit exceeded | iCloud Mail account sending quota | Maximum 1,000 messages and 1,000 recipients daily, with 500 recipients per message; resume after the quota resets |
Unreliable open rates | Mail Privacy Protection | Measure clicks and replies |
Common issues and practical fixes.
The SPF mistake is especially common. Apple's value must be added to the existing SPF policy if you already send mail through another system. A focused SPF checker helps catch duplicate records, syntax errors, and lookup problems before they affect real recipients.
Merged SPF exampledns
@ TXT "v=spf1 include:_spf.example.net include:icloud.com ~all"
Test the process with a low-risk separate domain before moving a live business domain. Changing MX redirects new mail for the entire domain, so a secondary address on that domain does not isolate the migration. Prepare every active address and keep account recovery accessible during the change.
If mail to Apple domains starts bouncing after the change, separate custom domain setup from recipient-side delivery. Authentication issues, content filtering, user over-quota responses, and temporary Apple server behavior need different fixes. For a deeper path, use the iCloud delivery issues checklist.
Authentication and DMARC choices
A custom domain on iCloud should have a DMARC record. SPF and DKIM show whether Apple is authorized to send and whether the message has a valid signature. DMARC checks whether an authenticated domain matches the visible From domain. For personal mail, start at p=none, confirm passing mail with a domain match, then tighten the policy only when reports show that every legitimate sender is accounted for. Replace the example rua address with a working reporting mailbox or the reporting address supplied by Suped; create the mailbox first if you receive reports yourself.
Starter DMARC recorddns
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
DMARC policy staging
A simple way to move from visibility to enforcement after iCloud sends cleanly.
Observe
p=none
Use reports to see every service sending as the domain.
Limit risk
p=quarantine
Apply only after legitimate sources consistently pass.
Enforce
p=reject
Use when approved sources pass through an SPF or DKIM domain match.
Suped's DMARC monitoring is relevant when the domain has more than iCloud sending mail. Suped's product groups aggregate reports by sending source and shows whether SPF or DKIM matches the visible From domain. This helps identify an unaccounted sender before moving from p=none to enforcement. It can also alert on authentication changes after the migration.
Infographic showing MX, SPF, DKIM, DMARC, and reporting for iCloud domains.
Privacy and tracking quirks
Apple privacy protections affect reporting expectations around iCloud users. When recipients read mail in Apple Mail with Mail Privacy Protection enabled, opens are less reliable because remote content loading no longer maps cleanly to a human open. That applies to the mail client behavior, not only to the spelling of the recipient's domain.
For custom domains hosted at iCloud, rely less on opens and more on replies, clicks, bounces, complaint patterns, and authentication results. Use message headers and delivery errors to investigate a specific sending problem.
The cleanest operating model is simple: use iCloud for human mailbox mail, use dedicated sending infrastructure for product or marketing mail, and monitor the whole domain so DMARC reports show every legitimate source.
Views from the trenches
The community comments below describe early testing in 2021. They are historical experiences, not current address-format restrictions; use Apple's present setup checks when adding an address.
Best practices
Stage the move on a low-risk domain before changing MX for a primary business address.
Keep the old mailbox active until iCloud has verified every MX, TXT, SPF, and DKIM record.
Send test mail through the final client, not only iCloud.com, before telling users it works.
Document the previous DNS records so rollback has exact values, priorities, and TTL settings.
Common pitfalls
Moving MX before every address is ready interrupts delivery, even if old mail is still accessible.
Replacing the whole SPF record instead of merging Apple's include breaks other senders.
Assuming open-rate data stays normal after Apple privacy protections causes bad reporting.
Using a custom domain address tied to another Apple Account stops the address from being added.
Expert tips
Check sender authentication after setup, because a green receive test does not prove DMARC passes.
Use a separate sending subdomain for marketing systems instead of routing them through iCloud.
Lower TTL before migration, then restore it after Apple verifies and real mail has passed.
Keep verification email access at the old host until every existing address has been confirmed.
Marketer view
Marketer from Email Geeks says iCloud custom domains use Apple's MX records, not a separate IMAP or POP login.
2021-08-26 - Email Geeks
Marketer view
Marketer from Email Geeks says the setup checker can reject valid DNS until propagation finishes, then clear without another DNS change.
2021-08-26 - Email Geeks
Keep iCloud custom domain mail working
For a live domain, avoid rushing the MX change. Keep the old provider available, test with a low-risk address, check DNS externally, and inspect message headers after sending. If the domain has multiple senders, use DMARC reports to check every legitimate sending source. Without reports, fixing iCloud can break another sender without an obvious warning.
In Suped's DMARC reporting platform, review iCloud and other sending sources after the cutover. Investigate new failures before tightening the domain's DMARC policy.
