An iCloud+ custom domain takes only a few records, one of which deserves attention: Apple’s assistant offers an SPF record using redirect=, a mechanism that behaves nothing like an include.
MX
@ MX 10 mx01.mail.icloud.com
@ MX 10 mx02.mail.icloud.comSPF, and the redirect trap
Apple suggests: v=spf1 redirect=icloud.com. That works — if iCloud is your only sender. Because redirect= does not add to the other mechanisms: it replaces the whole evaluation with that of the target domain. Anything else you listed is ignored, and your other sending services fall.
As soon as a second sender exists — billing, newsletter, a website form — switch to the additive form:
v=spf1 include:icloud.com ~allDKIM
One CNAME, whose value contains your own domain:
sig1._domainkey CNAME sig1.dkim.yourdomain.com.at.icloudmailadmin.comDMARC
Publish the monitoring policy on _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:your-address@yourdomain.comOnly tighten once every sender is identified. The progression, step by step.
Common mistakes with iCloud Mail
- Keeping
redirect=while another service sends. The mistake is invisible in the record — it is syntactically perfect — and only shows up in the reports. - A TTL other than 3600. Apple requires exactly one hour on its records; any other value fails validation, with no explicit message.
- The Cloudflare proxy left on for the DKIM CNAME. The orange cloud must be off, otherwise the returned target is not Apple’s.
- Confusing aliases with the custom domain. iCloud’s hidden addresses do not use your domain and fall outside your DMARC.
Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge.