iCloud Mail SPF and DKIM setup

The five records Apple asks you to publish for a custom email domain on iCloud Mail, why the DKIM record is one CNAME with your own domain in the middle of the target, and why the MX step is the one that moves your mail.

What you are setting up

Custom Email Domain is the iCloud+ feature that lets iCloud Mail receive and send the mail for a domain you own, so the setup covers MX as well as SPF and DKIM. You add the domain on iCloud.com, publish the records Apple shows you, and Apple signs outgoing mail as your domain so it aligns. Apple hands you five values: a personal TXT record that proves you own the domain, an SPF TXT, two MX records, and one DKIM CNAME. The CNAME means Apple hosts the actual key and you never paste a p= value. You need an iCloud+ subscription (yours, or one in your Family Sharing group) and a primary iCloud Mail address; you can run up to five custom domains, with up to three active addresses per person on each. The feature is not available in every country or region.

Publish SPF and DKIM

Sign in at icloud.com/icloudplus, select Custom Email Domain, then Add a domain you own. Choose Only You or You and Other People, enter the domain, and add any addresses people already use at it. At the records step, Apple may offer to sign in to your registrar and update the records for you; otherwise select View and add them yourself at your DNS host. Apple lists them in this shape, all with a TTL of 3600 (one hour):

Type:  TXT     (domain verification)
Host:  @
Value: (the personal TXT record Apple shows you during setup)

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:icloud.com ~all

Type:  MX
Host:  @
Value: mx01.mail.icloud.com   (priority 10)
Value: mx02.mail.icloud.com   (priority 10)

Type:  CNAME   (DKIM)
Host:  sig1._domainkey
Value: sig1.dkim.yourdomain.com.at.icloudmailadmin.com

The DKIM target contains your domain in the middle, so sig1._domainkey.example.com points at sig1.dkim.example.com.at.icloudmailadmin.com. Copy the value Apple shows rather than building it by hand. If your domain already has an SPF record, Apple's instruction is to add include:icloud.com to it just before ~all instead of publishing a second record; two SPF records fail everywhere. If your DNS editor does not accept @ as the host, enter your domain name instead. Apple tells you to delete your existing MX records before adding its two, then go back to the iCloud Mail setup page and click Verify. It can take a few minutes for the saved changes to be seen; if verification fails, Apple's only advice is to check the records for errors and try again, so read them character by character.

Apple documents a single sig1 selector and no custom Return-Path or bounce domain for the custom domain feature. If the setup screen shows you anything beyond these five values, publish what it shows; the article is the floor, not the ceiling.

Add DMARC

Apple's setup article does not mention DMARC at all, and its own postmaster page says iCloud Mail honors whatever DMARC policy your domain publishes. Publish the standard _dmarc TXT record, start in monitor-only mode, and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean. Your iCloud Mail messages pass on aligned DKIM, so the SPF ~all qualifier is not what protects them.

The iCloud Mail gotcha

The DKIM CNAME is the record people get wrong. Three ways, all seen in Apple's own support forums. First, leaving Apple's placeholder in place, so the target still reads sig1.dkim.example.com.at.icloudmailadmin.com with a literal example.com; the target must carry your domain. Second, a DNS host that appends your domain to the target, giving sig1.dkim.yourdomain.com.at.icloudmailadmin.com.yourdomain.com; add a trailing dot or check the resolved name afterwards. Third, publishing it as a TXT because the editor defaulted to that type; it is a CNAME, and a TXT at sig1._domainkey will never verify. Until the CNAME resolves, Apple cannot sign as your domain, and your mail authenticates only as far as SPF takes it.

Deleting the MX records is the cutover. The moment the old MX entries go and Apple's two take over, inbound mail for every address at the domain lands in iCloud Mail, including addresses you have not created there yet. Add the addresses people already use in the setup flow before you swap, and if the domain currently receives mail at another provider, import what you want to keep first and make sure your iCloud storage can hold it. Apple does not document a way to keep MX pointed elsewhere and still send from the domain, so this is an all-or-nothing move for the domain's mailboxes.

Confirm it worked

  • Check the domain in iCloud. At icloud.com/icloudplus, open the Custom Email Domain widget and click Manage. The domain should show as set up, with each address's verification status listed beneath it; re-open the records view if anything is still pending.
  • Send a test and read the headers. Send from your custom address in iCloud Mail, open the message at the other end, and confirm the DKIM signature shows d=yourdomain.com with s=sig1, and the result is dmarc=pass. Our header analyzer reads it back plainly.
  • Watch the reports. iCloud Mail should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.
Let trustyourinbox publish iCloud Mail for you

Connect your DNS once and we publish the iCloud Mail records above in a single click, with a five-minute window to undo. Then we keep watching this sender in your DMARC reports and tell you the moment iCloud Mail mail starts failing, so a typo in a record never quietly costs you the inbox.

Keep reading

Last verified 2026-09-06 against the official iCloud Mail documentation.

Was this page helpful?

Stop guessing. Start monitoring.

Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.