Apple's iCloud+ Custom Email Domain lets you send and receive mail at your own domain through iCloud Mail. It supports SPF, but does not currently support outbound DKIM signing for custom domains. This guide gives you the three DNS records you need to publish for Apple iCloud Mail to authenticate cleanly: SPF, DKIM, and a safe DMARC starter.
1. SPF — authorize Apple iCloud Mail to send
Publish (or update) a single TXT record at the root of your domain (host @) that includes Apple iCloud Mail's SPF token:
v=spf1 include:icloud.com ~all
If you already have an SPF record, do not replace it — merge. Add include:icloud.com alongside your existing mechanisms, keeping every other sender that's already authorized. A domain may only have one SPF record; publishing two breaks SPF entirely. Use the SPF checker to verify the merged record once published.
2. DKIM — sign messages from Apple iCloud Mail
Apple iCloud limitation: iCloud+ Custom Email Domain currently does not support outbound DKIM signing for custom domains. You can publish SPF and DMARC, but DKIM will be missing. If DKIM is critical to your deliverability, consider Google Workspace, Microsoft 365, or Fastmail instead.
3. DMARC — tell receivers what to do on failure
DMARC is sender-agnostic — the starter record is the same regardless of who hosts your mail. Publish it as a single TXT record at _dmarc:
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; fo=1
This is monitor-only: it doesn't change how mail is delivered. Instead, it tells receivers to send you aggregate reports about every server sending as your domain. Watch those reports for a few weeks, confirm only your legitimate senders pass, then tighten the policy to p=quarantine and eventually p=reject. Jumping straight to p=reject without checking reports is the most common way to block your own legitimate email. The DMARC checker can generate a tailored record for you.
Where do these records actually go?
All three records live at your DNS provider, not at Apple iCloud Mail. Your mail provider tells you what to publish; your DNS host is where you publish it. If you're not sure where to add them, see the step-by-step guides for every common DNS provider — Cloudflare, GoDaddy, Namecheap, AWS Route 53, Google Cloud DNS, Hover, Porkbun, IONOS and OVH are all covered.
Verify what you published
Once everything is live, run the full diagnostic on your domain. It checks all three records, detects Apple iCloud Mail as your mail host, and flags any mismatches between what you should have published and what's actually in DNS.
Frequently asked questions
Do I need SPF, DKIM and DMARC?
For sending email from a custom domain, yes. SPF lists which servers may send as you, DKIM cryptographically signs each message so receivers can verify it wasn't altered, and DMARC tells receivers what to do when SPF or DKIM fails. Together they're the modern standard — most major mailbox providers (Gmail, Yahoo) now require all three for reliable delivery to consumer inboxes.
Should DMARC start at p=none, p=quarantine or p=reject?
Start at p=none with a rua= address. That's monitor-only — it doesn't change how your mail is delivered, but it tells you who's sending as your domain via aggregate reports. Once you've watched reports for a few weeks and confirmed only your legitimate senders pass, move to p=quarantine, then to p=reject. Jumping straight to reject without checking reports is the most common way to block your own legitimate email.
Where do I actually publish these records?
All three records live at your DNS provider — not at your mail provider. Your mail provider tells you what value to publish; your DNS provider is where you publish it. See our guide for adding TXT records at each common DNS provider if you're unsure where to add them.