Should I add include:icloud.com or redirect=icloud.com to my SPF?

Use the include form — v=spf1 include:icloud.com ~all — which is what Apple's setup wizard generates and which lets iCloud coexist with your other senders. redirect=icloud.com replaces your whole SPF policy with Apple's and silently drops anything else that sends as your domain (and resolves the same 5-lookup chain, so it saves you nothing), so only use it if iCloud is the ONLY sender for the domain.

How many SPF lookups does iCloud use?

Five. include:icloud.com resolves to a redirect to _spf.icloud.com, which in turn includes _nets0, _nets1, and _nets2.icloud.com — so it consumes the include plus the redirect plus three nested includes, totaling 5 of your 10 permitted SPF DNS lookups. Budget the rest of your record carefully if you also send through Google Workspace, Microsoft 365, or an ESP.

Where's the DKIM public key I'm supposed to paste?

There isn't one. iCloud DKIM is a CNAME (sig1._domainkey → sig1.dkim.yourdomain.com.at.icloudmailadmin.com), not a TXT key. Apple holds the private key behind that hostname, signs your mail as your domain with the sig1 selector, and rotates the key on its side. You just publish the CNAME and leave it — no key to copy, no rotation to manage, and no sig2 to add.

Will setting this up stop my current email from working?

Yes, for the addresses on that domain. The mx01/mx02.mail.icloud.com records move ALL inbound mail for the domain to iCloud, so it's a full mailbox migration, not just outbound authentication. Create your addresses in iCloud first, plan any mailbox migration off your old provider, and only add the MX records when you're ready for Apple to become the receiving host — once they propagate, mail for the domain is delivered to iCloud, not your previous provider.

Can I use iCloud+ Custom Email Domain for marketing or bulk email?

No. It's a personal / small-team mailbox with sending caps, and Apple's terms prohibit bulk and commercial mass mail. Authenticate it as your human mailbox for one-to-one correspondence, and route newsletters or transactional volume through a dedicated ESP (SendGrid, Postmark, and the like) on its own authenticated domain or subdomain.

Do I still need DMARC if iCloud already sets up SPF and DKIM?

Yes. Apple publishes SPF and DKIM but never a DMARC record, and without one receivers have no policy to enforce and your domain stays spoofable — Gmail and Yahoo also expect bulk senders to publish it. Add a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:you@yourdomain.com, watch the aggregate reports until iCloud and any other senders show aligned passes, then tighten to p=quarantine and p=reject.

SPF setup guide

SPF, DKIM & DMARC for Apple iCloud+ Custom Email Domain.

Apple's iCloud+ Custom Email Domain lets you send and receive at your own domain (you@yourdomain.com) through iCloud Mail, and it authenticates that mail with a set of DNS records Apple generates for you during setup: two MX records that hand your whole mailbox to iCloud, an apple-domain TXT that proves you own the domain, an SPF record that adds Apple's shared include:icloud.com, and a single DKIM CNAME (sig1._domainkey) that delegates signing to Apple. There is no DKIM public key to paste and nothing to rotate — Apple holds the private key behind that CNAME. The one record Apple does NOT generate is DMARC; that is the piece you add yourself to turn SPF and DKIM into real spoofing protection.

SPF include

Your DNSAdd the CNAME / TXT records

Apple iCloud+ Custom Email DomainSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Apple iCloud+ Custom Email Domain?

Getting these records right on iCloud is higher-stakes than on a pure sending service, because Custom Email Domain makes iCloud your mailbox host, not just an outbound relay — the same MX change that lets you send also reroutes every inbound message for the domain to Apple. Misconfigure it and you don't merely land in spam, you stop receiving mail. On the deliverability side the modern rules still apply: since February 2024 Gmail and Yahoo require every sender to pass SPF or DKIM (and bulk senders to also publish DMARC with alignment), and Microsoft began enforcing similar checks for high-volume senders in 2025. iCloud is one of the good cases here — because it is your real mailbox host, outbound mail is DKIM-signed as your domain and SPF resolves through Apple's authorized IPs, so both mechanisms can align to yourdomain.com and feed a DMARC pass. But Apple only ever publishes SPF and DKIM; until you add the DMARC record yourself, receivers have no policy to enforce and your domain stays spoofable. Note too that iCloud+ Custom Email Domain is a personal / small-team mailbox (any paid iCloud+ storage tier includes it), not a marketing or transactional platform — authenticate it as your human mailbox, and keep bulk sending on a dedicated ESP.

The SPF reality for Apple iCloud+ Custom Email Domain

iCloud is a genuine "include" provider: you add one shared mechanism, include:icloud.com, to the single SPF TXT record on your root domain, and Apple's setup wizard writes it as v=spf1 include:icloud.com ~all. That part is standard. What almost every guide gets wrong is the cost. include:icloud.com is NOT a cheap one-lookup include — it is one of the most expensive shared includes in common use. Resolve it and icloud.com's SPF record is v=spf1 redirect=_spf.icloud.com; that redirect points at _spf.icloud.com, whose record is v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all (each _nets record holds only ip4/ip6 ranges, so the chain stops there). Counting under RFC 7208, that is the include itself (1) + the redirect (1) + three nested _nets includes (3) = FIVE of your 10 permitted SPF DNS lookups, spent on iCloud alone. If you also send through Google Workspace, Microsoft 365, or SendGrid, you can trip the 10-lookup PermError fast, so treat iCloud's include as a heavy line item and keep the rest of your SPF lean. Two more rules: keep exactly one SPF record on the domain (merge include:icloud.com into your existing v=spf1 line rather than publishing a second TXT — two SPF records is an automatic PermError), and don't confuse the include form with the redirect=icloud.com form some older tutorials show. redirect=icloud.com replaces your entire SPF policy with Apple's and silently drops every other sender (and costs the same 5 lookups, so it buys you nothing), so it is only correct if iCloud is the ONLY thing that sends as your domain. Apple ends with ~all (softfail), which is the right default while you confirm every sender is covered.

Two ways to set it up

Recommended

include:icloud.com (Apple's default — keep other senders)

What Apple's setup wizard actually generates: v=spf1 include:icloud.com ~all
Coexists with other senders — you can merge Google Workspace, M365, SendGrid, etc. into the same line
Costs 5 of your 10 SPF DNS lookups (redirect + three nested _nets includes), so budget accordingly
Ends in ~all softfail, the safe default while you confirm every sender is authorized

Legacy

redirect=icloud.com (only if iCloud is your ONLY sender)

Replaces your ENTIRE SPF policy with Apple's — anything not in icloud.com's record hard-fails
Silently breaks any other service that sends as your domain (newsletters, forms, CRM)
No lookup savings — it resolves the same 5-lookup icloud.com chain, just with none of the flexibility
Use only on a domain where iCloud Mail is the single, exclusive sending source

Step by step

In iCloud settings

1
Confirm you have iCloud+
Custom Email Domain is an iCloud+ feature, so you need any paid iCloud+ tier (any storage plan qualifies). The account organizer can share a domain with Family Sharing members, or you can set it up for yourself only.
2
Open Custom Email Domain
On the web, sign in at icloud.com, open Account/Mail settings, and choose Custom Email Domain (icloud.com/settings lists it directly). On an iPhone/iPad: Settings → tap your name → iCloud → scroll to Custom Email Domain under iCloud+ Features.
3
Add your domain
Choose whether the domain is for "Only you" or "You and other people" (Family Sharing), then type your domain, e.g. yourdomain.com. iCloud+ allows up to 5 domains, with up to 3 addresses per person per domain.
4
Create the email addresses you'll use
Add the mailboxes you want on the domain (you@yourdomain.com, hello@yourdomain.com, …). Apple won't publish the DNS instructions until you've defined at least one address — this is a mailbox migration, not just outbound signing, so decide your addresses up front.
5
Get your DNS records
Apple shows the records to add — two MX, an apple-domain TXT verification value, the SPF line, and the sig1._domainkey DKIM CNAME. Use "Email instructions" to send them to yourself, or copy each value. Apple's instructions list a TTL of 3600 (1 hour); any standard TTL is fine.

In your DNS

6
Repoint MX to iCloud
At your DNS host, REMOVE any existing MX records and add mx01.mail.icloud.com and mx02.mail.icloud.com, both at priority 10. This is the big one: it moves ALL inbound mail for the domain to iCloud, so only do it when you're ready to make iCloud the mailbox for these addresses.
7
Add the verification TXT and SPF record
On the root (host @): add a TXT record with Apple's apple-domain=… verification value, and add or MERGE the SPF record v=spf1 include:icloud.com ~all. If a v=spf1 record already exists, fold include:icloud.com into that one line — never publish a second SPF TXT.
8
Add the DKIM CNAME
Create a CNAME with host sig1._domainkey and target sig1.dkim.yourdomain.com.at.icloudmailadmin.com (Apple substitutes your real domain into the target). If your DNS is on Cloudflare, set it to DNS only (grey cloud) — a proxied/orange-cloud record or CNAME flattening breaks DKIM resolution.
9
Publish your own DMARC record
Apple does not create DMARC. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so nothing is blocked while you confirm iCloud mail passes aligned SPF and DKIM.

Verify

10
Finish setup and test a real message
Back in iCloud, click Finish Setup so Apple verifies the records (propagation can take minutes to a few hours). Then send a message from your new address to a Gmail account, open ⋮ → Show original, and confirm SPF: PASS, DKIM: PASS (signed-by yourdomain.com, selector sig1), and DMARC: PASS. Also send a message TO the address to confirm iCloud is now receiving.

Records to add

Apple iCloud+ Custom Email Domain generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
MX	@	mx01.mail.icloud.comPriority 10 — reroutes all inbound mail to iCloud (remove existing MX first)
MX	@	mx02.mail.icloud.comPriority 10 — second iCloud mail exchanger
TXT	@	apple-domain=Ab12Cd34Ef56Gh78Illustrative — Apple generates a unique verification value per domain; keep it published, Apple re-checks it
TXT	@	v=spf1 include:icloud.com ~allMerge into your single SPF line if one exists. include:icloud.com costs 5 DNS lookups (redirect + 3 nested _nets includes)
CNAME	sig1._domainkey	sig1.dkim.yourdomain.com.at.icloudmailadmin.comIllustrative — Apple inserts your real domain. DKIM key is held/rotated by Apple; keep DNS-only (no Cloudflare proxy)
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this — Apple does not. One DMARC record per domain; start at p=none, then tighten

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Apple iCloud+ Custom Email Domain's setup costs against that budget.

SPF 10-lookup budget5 used · 5 free

Apple iCloud+ Custom Email Domain adds 5 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

DKIM for iCloud is delegated, not pasted. Apple has you publish a single CNAME — host sig1._domainkey.yourdomain.com pointing to sig1.dkim.yourdomain.com.at.icloudmailadmin.com (Apple substitutes your real domain into that target during setup). There is no v=DKIM1; p=… public key for you to copy and no selector to invent: Apple holds the private key behind that CNAME, signs your outbound iCloud mail with d=yourdomain.com using the sig1 selector, and can rotate the published key on its side without you ever editing DNS again. Two practical points. First, iCloud provisions exactly ONE selector, sig1 — if a tutorial tells you to also add sig2, that's not part of Apple's current flow; a lone sig1 CNAME is correct and complete. Second, because it's a CNAME to Apple's hostname, it must resolve as a normal delegated record: if your DNS is on Cloudflare set it to DNS only (grey cloud), and avoid CNAME flattening or any proxy that would rewrite the target, since that breaks the delegation and DKIM silently fails to sign. DKIM is the mechanism that most reliably aligns to your domain here (the d= is yourdomain.com), so it's what carries a DMARC pass even when a message is forwarded and SPF breaks — get this CNAME right.

DMARC

DMARC is the record Apple never creates for you, and without it the SPF and DKIM you just published don't add up to any enforceable policy. Add a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only — it changes nothing about delivery but asks receivers to email you aggregate (rua) reports so you can watch iCloud mail authenticate. Because iCloud signs with DKIM as your own domain and sends through Apple's SPF-authorized IPs, you should see clean, aligned passes quickly. Let the reports run for a week or two, confirm that iCloud plus any other legitimate senders (a newsletter tool, a contact form, another mailbox provider) are all passing aligned, then tighten to p=quarantine and finally p=reject to actually stop spoofing. Keep exactly one _dmarc record for the whole domain regardless of how many services you use — never add a second DMARC record specifically for iCloud. If you host DNS somewhere that also lets you receive the reports, point rua at a mailbox you'll actually read, or feed them into a DMARC analyzer.

Check it actually worked

Don't trust Apple's "Finish Setup" green check alone — confirm authentication on a real message. Send from your new iCloud address to a Gmail account, open the message, and choose ⋮ → Show original: you want SPF: PASS, DKIM: PASS with signed-by: yourdomain.com and selector sig1, and DMARC: PASS — all pointing at your domain, not icloud.com. Because iCloud is now also your receiving host, send a message TO the address as well and make sure it arrives, which proves the MX change took. For a raw check, dig TXT yourdomain.com should show your single v=spf1 include:icloud.com ~all, dig CNAME sig1._domainkey.yourdomain.com should resolve to sig1.dkim.yourdomain.com.at.icloudmailadmin.com, and dig TXT _dmarc.yourdomain.com should return your policy. Then run the domain through Qualisend's domain health check to confirm every record resolves and — importantly for iCloud — that your SPF stays under the 10-lookup limit given the 5 lookups include:icloud.com consumes. Once aggregate reports arrive, drop one into the DMARC report analyzer to confirm iCloud shows up as an aligned, fully-passing source.

Domain health check DMARC report analyzer

Common gotchas

Breaks auth
include:icloud.com is expensive: it costs 5 of your 10 SPF DNS lookups, not 1. icloud.com redirects to _spf.icloud.com, which nests _nets0/_nets1/_nets2.icloud.com. Stack it with Google Workspace or Microsoft 365 and you can trip the 10-lookup PermError — keep the rest of your SPF lean and check the meter.
Coverage
This is a full mailbox migration, not just outbound signing. The mx01/mx02.mail.icloud.com records reroute ALL inbound mail for the domain to iCloud. You cannot split-host the same addresses across iCloud and another provider — only add the MX when you're ready for iCloud to receive that mail.
DNS setup
Use the include form, not redirect=icloud.com. redirect replaces your entire SPF policy with Apple's and silently drops every other sender — and it costs the same 5 lookups, so there's no upside. It's only correct when iCloud is the single, exclusive sender for the domain; otherwise your forms, newsletters, and CRM start failing SPF.
DNS setup
The DKIM record is a CNAME you must not proxy or flatten. On Cloudflare set sig1._domainkey to DNS only (grey cloud); an orange-cloud proxy or CNAME flattening rewrites the target and DKIM stops signing. Apple holds the key — you never paste or rotate a public key.
DNS setup
Apple publishes SPF and DKIM but never DMARC. Without your own _dmarc record there's no policy to enforce and the domain stays spoofable — add v=DMARC1; p=none to start, then tighten.
DNS setup
iCloud provisions a single DKIM selector (sig1). If a guide says to also add sig2, that's not Apple's current flow — a lone sig1 CNAME is correct.
Breaks auth
Keep exactly one SPF TXT record. Merge include:icloud.com into your existing v=spf1 line; two separate SPF records is an automatic PermError that fails SPF entirely.
Coverage
iCloud+ Custom Email Domain is a personal / small-team mailbox, not an ESP. Apple caps sending volume and prohibits bulk and commercial mass mail, so don't route marketing or high-volume transactional campaigns through it — use a dedicated sending platform for that.
DNS setup
Don't delete the apple-domain TXT after setup. Apple re-verifies domain ownership against it periodically; removing it can deactivate the domain and knock out your mail.

Build your SPF record

Apple iCloud+ Custom Email Domain is pre-selected below. Add any other platforms you send through, then publish the single merged record.

Sending sources

Search for each platform you send email through and tick it.

Selected

Apple iCloud+ Custom Email Domaininclude:icloud.comGuide →

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record1/10 DNS lookups

v=spf1 include:icloud.com ~all

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list