trustyourinbox

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.

Verified 2026-09-06 against the official iCloud Mail documentation.

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 and a primary iCloud Mail address; you can run up to five custom domains and share each with up to five people (your Family Sharing group, or others). The feature is not available in every country or region, and a domain with a registrar lock on it cannot be set up.

Publish SPF and DKIM

Sign in at icloud.com/icloudplus, select Custom Email Domain, then Add a domain you own. Choose whether the domain is just for you or shared with other people, enter the domain, and add any addresses people already use at it. At the records step, Apple shows the records to add at your DNS host. It 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 carries them.

The iCloud Mail gotcha

The DKIM CNAME is the record people get wrong. Three common ways. 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; if verification failed, check each record for errors and try again.
  • 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 Cloudflare or AWS Route 53 once and the iCloud Mail records are one click. We email you the exact record, wait five minutes, write it, and read it back from public DNS. Then we keep watching this sender in your DMARC reports and alert you when iCloud Mail mail starts failing.

Was this page helpful?

Keep reading.

Start with one domain. See it with your own data.

Free for one domain, no card. Add one DNS record and the first reports usually arrive within a day.

  1. Monitoring
  2. Quarantine
  3. Reject