Running Business Email on an iCloud+ Custom Domain: MX Records, Limits, and a Realistic Exit Plan

The failure usually looks like this: you change the MX records on a Friday, mail stops arriving by Monday, and nobody wrote down what the old records were. The domain still resolves. The website still loads. Only the mail is gone, and the person who set up the previous provider is no longer answering.

That is not an Apple problem. It is a change-management problem, and it is entirely avoidable. Moving a small business onto iCloud+ Custom Email Domain is a DNS project with an email migration attached, not the other way around. Treat it that way and the cutover is boring. Treat it as an email migration and you will spend a weekend on the phone with a registrar.

What follows is the record set Apple actually specifies, the registrar edge cases that break verification, the documented capacity limits that matter for a 3–20 device shop, the security reality that Apple’s own documentation is unusually candid about, and the exit plan you should write before you touch a single record.

Why this is a DNS project, not a Mail app project

Apple’s setup instructions are explicit about the scope: to use your own domain with iCloud Mail, you change three types of DNS records at your registrar — MX, TXT, and CNAME (Apple Support, “Set up an existing domain with iCloud Mail”). Each does a different job:

• MX records specify where email sent to your domain is delivered. A domain can have multiple MX records, each with its own priority level.
• TXT records store text-based information about your domain, including information that helps prevent email spoofing.
• CNAME records point traffic to the same IP address when you have different variations of the same domain name.

Nothing in that list lives in the Mail app. Nothing in that list is fixed by signing out and back in on a Mac. If mail is not arriving, the answer is almost always in the DNS zone, and the fastest diagnostic is to look at the records rather than the client.

Pre-flight: inventory addresses before you touch records

Apple’s instructions include a step that is easy to skip and expensive to skip: before changing your domain records, enter the email addresses you already use with that domain name. Once the domain is set up with iCloud Mail, you can create any new addresses you want.

In practice, that means you walk into the cutover with a written list of every address currently receiving mail on the domain — including the ones nobody remembers, like accounts@, invoices@, or the address a former contractor set up for a vendor portal. If an address is not on the list before the MX change, it will not exist after it.

Two prerequisites are also worth confirming before you schedule anything:

• An Apple Account with two-factor authentication turned on.
• iCloud Mail already set up on your devices.

Both are documented requirements for using a custom domain with iCloud Mail (Apple Support, “Use Custom Email Domain with iCloud Mail”). If two-factor authentication is not on, turn it on first. Do not try to do both in the same window.

The record set, verbatim

Apple’s published values are below. The TXT value is not a fixed public string — it is a personal record provided to you during setup, so copy it from the setup page rather than from any article, including this one.

Type	Host	Value	Priority
TXT	@	[personal TXT record provided during setup]	—
TXT (SPF)	@	“v=spf1 include:icloud.com ~all”	—
MX	@	mx01.mail.icloud.com.	10
MX	@	mx02.mail.icloud.com.	10
CNAME (DKIM)	sig1._domainkey	sig1.dkim.example.com.at.icloudmailadmin.com.	—

Two details in that table are worth reading twice.

First, the SPF record. If you already have an SPF record, Apple’s instruction is not to replace it but to add include:icloud.com to the value before ~all. That matters if you send transactional mail through a third-party service from the same domain — dropping the existing include would break it.

Second, the DKIM entry. It is a CNAME at host sig1._domainkey pointing to sig1.dkim.example.com.at.icloudmailadmin.com., with your own domain name substituted where it says example.com. It is not a TXT record, and it is not a fixed string.

Apple’s instructions also begin with a step that should make anyone nervous: delete your existing MX records. That is the point at which rollback stops being free unless you have already recorded what was there.

Registrar edge cases that break verification

Apple documents three registrar-level conditions that will stop the setup cold, and one formatting exception that trips people up more often than it should:

• Domain lock. If your registrar has a lock on your domain, you cannot set up a domain with iCloud Mail. Unlock it before the change window, not during it.
• No @ support. If your registrar does not support @ as a host, enter your domain name as the host instead.
• No quotes or trailing periods. If your registrar does not support quotes or trailing periods in record values, enter the value without quotes or trailing periods.
• TTL. Apple states TTL should be set to 3600 seconds, or 1 hour.

This works, but the TTL guidance is a floor, not a promise. Apple’s own note is that it might take a few minutes before saved changes can be verified. That is a statement about verification, not about how long every resolver on the internet will hold a cached record. Plan the window accordingly and do not schedule the cutover for the hour before a client deadline.

Verifying, and what to do when it fails

Verification happens on the iCloud Mail setup page: click Verify to confirm setup. To check that the domain and addresses are set up, sign in to icloud.com/icloudplus, select the Custom Email Domain widget, and click Manage.

If verification fails, Apple’s guidance is direct: check the updated DNS records for errors and try again. In practice, the errors that matter are the ones listed above — a locked domain, an @ host the registrar rejected, quotes or trailing periods that were stripped, or a personal TXT value that was transcribed incorrectly. Re-read the record against the setup page character by character before you change anything else.

Capacity planning for a small team

The documented limits shape how you assign addresses, and they are different from a per-seat mailbox model. With iCloud+, you can use up to five custom domains, with up to 10 personalized email addresses per domain.

Sharing is the lever that matters for a shop with contractors or part-time staff:

• If you share iCloud+ with a Family Sharing group, you can share your custom domain with the group and let them create personalized addresses.
• In iOS 16 or later, you can also share your custom domain with people outside your family, up to five other people.
• Someone added who is not part of your Family Sharing group must accept the invitation before being added to the domain.
• Each person you share the domain with can create up to 10 personalized email addresses on the custom email domain.

That is a different planning shape than “one mailbox per employee.” It means a contractor can hold their own address on your domain without you provisioning a seat for them, and it means the address count is governed by who you share with rather than by a per-user license.

One constraint to design around: a personalized address cannot already be in use with a different Apple Account, and deleting that other account does not free the address for use. If a departing employee used their work address as their Apple Account sign-in, that address is effectively stuck. Decide before you assign addresses whether staff should sign in with the work address or keep a personal Apple Account and add the work address as a secondary.

Also worth knowing: Custom Email Domain does not support managed accounts. If you were expecting admin-console-style control over user accounts, that is not the model here.

The alias ceiling is a design constraint

Separate from custom-domain addresses, iCloud Mail aliases have their own limits, and they behave in ways that matter if you were planning to use them as disposable per-vendor addresses.

After you set up a primary iCloud Mail address, you can create up to nine @icloud.com email aliases on iCloud.com. When an alias is turned off or deleted, email sent to that alias is returned to the sender. And if you have nine aliases and delete one, you must wait 7 days before you can create a new one.

Aliases also cannot be changed, transferred, or converted to primary accounts, and by default, emails sent to an alias appear in your primary inbox.

Read together, those constraints argue against treating aliases as throwaway addresses for every newsletter and vendor signup. The 7-day wait at the cap is the part that bites: if you churn aliases casually, you will eventually hit the ceiling at the moment you need a new one. Plan alias use deliberately, or use a dedicated service for disposable addresses and keep the iCloud aliases for stable, long-lived purposes.

Security reality check: iCloud Mail is not end-to-end encrypted

This is the part of the setup that deserves a plain sentence rather than a footnote. Apple’s own iCloud data security documentation states that iCloud Mail does not use end-to-end encryption because of the need to interoperate with the global email system.

More specifically, iCloud Mail remains under standard data protection even when Advanced Data Protection is enabled, with encryption keys stored by Apple. Turning on Advanced Data Protection does not change the encryption status of your mail. It changes the status of many other categories — iCloud Backup, Photos, Notes, and more — but not Mail.

This works, but it means account-level encryption settings are not a substitute for a decision about what belongs in this mailbox. If your business handles client-confidential correspondence, the realistic move is a decision rule about which material never lives in iCloud Mail at all, rather than an assumption that a security setting covers it.

For the correspondence that does belong there, Apple notes that all native Apple email clients support optional S/MIME for message encryption. That is a per-message, per-certificate setup, not a switch, and it is worth treating as a separate project rather than a checkbox in the migration.

Designing the exit before you migrate

The exit plan is mostly a documentation exercise, and it costs an hour before the cutover. The reason to do it is that Apple’s instructions start with deleting your existing MX records, and the documented behavior of removing a domain is unambiguous: after you remove it, you will not be able to send or receive email from addresses at that domain in iCloud Mail.

That is not a soft off-ramp. It is a stop. Which means the exit must be sequenced as a migration — new provider first, records changed second, domain removed last — rather than as a deletion.

The pre-cutover checklist that makes rollback cheap:

1. Record the current records. Screenshot or export the exact MX, TXT, and CNAME values in place before you delete anything. This is the single most valuable artifact in the whole project.
2. Confirm registrar access is under your own account. If a contractor or former employee controls the registrar login, fix that before the change window, not after.
3. Unlock the domain. A locked domain cannot be set up with iCloud Mail, and it will also complicate any future move.
4. Export existing mail. Whatever is in the old mailbox should be exported to a local archive before the MX change, because the old provider’s retention policy is not your problem until it is.
5. Write down the exit sequence. New provider’s records ready, TTL lowered in advance if your registrar allows it, and a named person responsible for the change.
6. Decide the address policy. Which addresses are staff sign-ins, which are shared, and which are aliases. This determines what is painful to move later.

None of that is exotic. It is the difference between a cutover you can reverse in twenty minutes and one that consumes a weekend.

A labeled walkthrough: two-person studio, existing domain

The following is a hypothetical sequence, not a report of a specific migration. It is written out because the decision points are easier to see in order than in a checklist.

Setup. A two-person studio runs mail on an existing domain through a legacy provider. They have four addresses in active use: two personal, one hello@, one invoices@. They have an iCloud+ subscription and two Macs, two iPhones, and an iPad.

Decision point 1: prerequisites. Both Apple Accounts have two-factor authentication on, and iCloud Mail is already set up on their devices. If either were not true, that would be the first task, not the DNS change.

Decision point 2: inventory. They list all four addresses and check the legacy provider’s admin panel for any forwarding rules or aliases they forgot. They find one: a support@ address that forwards to hello@. It goes on the list.

Decision point 3: record capture. They screenshot the current MX, TXT, and CNAME records. This is the rollback artifact.

Decision point 4: registrar check. They confirm the domain is unlocked, that the registrar accepts @ as a host, and that it accepts quotes and trailing periods. If any of those were false, they would use Apple’s fallback formatting before scheduling the window.

Decision point 5: the change. They delete the old MX records, enter the two iCloud MX records at priority 10, add the personal TXT value, add or amend the SPF record, and add the DKIM CNAME. TTL is set to 3600.

Decision point 6: verification. They click Verify on the setup page. If it fails, they re-read the records against the setup page before changing anything else.

Decision point 7: address creation. They recreate the four addresses plus support@ on the custom domain. They decide that invoices@ will be a shared address rather than a personal one, and they note that neither partner will use a work address as their Apple Account sign-in, so a future move is not blocked.

Decision point 8: the exit plan, filed. They write down the sequence for leaving iCloud Mail later: stand up the new provider, change MX and TXT records, verify delivery, then remove the domain from iCloud. They note that removing the domain stops send and receive at that domain in iCloud Mail, so it is the last step, not the first.

The whole sequence is a DNS change window with a rollback, not an email migration. That is the point.

Catch-all behavior: Apple documents an option

Apple’s iCloud User Guide includes a page titled “Allow all incoming emails” for Custom Email Domain (iCloud User Guide, “Allow all incoming emails to a custom email domain on iCloud.com”). The documented behavior is specific:

• You can use your iCloud Mail email address as a catch-all address, receiving all emails sent to your custom domain even if the exact address has not been created.
• You must be the domain owner to use this feature.
• You will not receive emails sent to addresses that have been previously created for other members of the domain.
• If the domain owner turns on “Allow All,” any emails not sent to an active email address go to the domain owner’s inbox.
• If the setting is not turned on, those emails are returned to the sender.
• Emails sent to deleted email addresses are automatically returned to the sender.

That is a real catch-all option, but it is not a routing rule. It is a binary switch that sends unlisted mail to the domain owner’s inbox or bounces it. If your workflow depends on catching mail sent to addresses you have not explicitly created, turn this on deliberately and understand that the domain owner’s inbox becomes the destination for all of it.

What Apple’s documentation does not cover

One gap is worth naming plainly, because it affects planning and because pretending otherwise leads to bad assumptions.

Business-oriented controls. Apple’s documentation does not describe shared mailboxes, delegation, retention policies, or eDiscovery for Custom Email Domain, and it states that Custom Email Domain does not support managed accounts. If your requirements include those controls, iCloud Mail is the wrong tool for that part of the job, and the honest move is to say so before the cutover rather than after.

That gap is not a reason to avoid iCloud Mail. It is a reason to write down what you actually need from a mail system before you point MX records at it.

FAQ

Can I keep my existing SPF record?
Yes. Apple’s instruction is to add include:icloud.com to the value before ~all rather than replacing the record. If you send mail through another service from the same domain, keep that include.

What TTL should I use?
Apple states TTL should be set to 3600 seconds, or 1 hour.

Why did verification fail?
Apple’s guidance is to check the updated DNS records for errors and try again. The documented blockers are a locked domain, a registrar that does not support @, and registrars that do not support quotes or trailing periods in record values.

How many addresses can I create?
Up to 10 personalized email addresses per domain, with up to five custom domains on iCloud+. If you share the domain with others, each person you share with can create up to 10 personalized addresses on that domain.

Does Advanced Data Protection encrypt my mail?
No. Apple’s documentation states that iCloud Mail does not use end-to-end encryption because of the need to interoperate with the global email system, and that iCloud Mail remains under standard data protection even when Advanced Data Protection is enabled.

What happens if I remove the domain?
After you remove it, you will not be able to send or receive email from addresses at that domain in iCloud Mail. Sequence the exit as a migration: new provider first, records changed second, domain removed last.

Can I use a work address as my Apple Account sign-in?
You can, but a personalized address cannot already be in use with a different Apple Account, and deleting that other account does not free the address. If you plan to move providers later, keeping work addresses separate from Apple Account sign-ins makes the move cheaper.

Does iCloud+ support a catch-all address?
Yes. Apple’s iCloud User Guide documents an “Allow all incoming emails” option for Custom Email Domain. When enabled by the domain owner, emails sent to addresses that have not been created go to the domain owner’s inbox. When disabled, those emails are returned to the sender.

The short version

Point MX records at iCloud, add the personal TXT value, amend SPF rather than replacing it, add the DKIM CNAME, set TTL to 3600, and verify from the setup page. Unlock the domain first and confirm your registrar’s formatting rules. Record the old records before you delete them. Decide which addresses are sign-ins and which are shared. Decide whether the domain owner wants the documented catch-all option turned on. And write the exit sequence before the cutover, because removing the domain stops mail at that domain in iCloud Mail — it is the last step, not the first.

Do that, and the cutover is a Tuesday afternoon. Skip it, and it is the failure scenario at the top of this article.