iCloud+ SPF, DKIM and DMARC setup, step by step

Quick answer: For an existing domain being moved to iCloud Mail, use Apple's custom-domain DNS packet, preserve other legitimate senders, finish Apple's verification, then prove that a fresh message has passing, aligned DKIM. MX migration affects incoming mail; it is not merely an authentication adjustment.

This guide starts when your existing domain has been entered in iCloud+ and its DNS instructions are available. It covers manual DNS completion and acceptance testing, not buying a domain, undocumented enrollment screens, Hide My Email, Sign in with Apple relay, or mail sent by other applications. No customer account, DNS or message tests were performed.

1. Confirm eligibility and approve the mail migration

You need iCloud+, an Apple Account with two-factor authentication, and iCloud Mail enabled. Managed accounts are excluded. Apple also excludes domains registered as Organization Domains in Apple Business. Address eligibility matters: an address associated with another Apple Account cannot simply be reassigned by deleting that account. Resolve eligibility through Apple's current instructions before touching DNS. Apple: Custom Email Domain requirements

Record the exact domain, authorized account owner, DNS administrator, current inbound provider and every existing address that must keep receiving mail. Apple directs you to enter existing addresses before changing DNS. Prepare mailbox continuity, any shared addresses, forwarding arrangements, archived mail access, and a rollback decision with the owner. Do not assume that changing MX transfers historical mail or reproduces another provider's mailbox features.

Stop if incoming mail must stay elsewhere. This is a mailbox-hosting migration, not a recipe for adding iCloud as a marketing sender while retaining an unrelated inbound arrangement. Obtain explicit approval for the destination and affected addresses before replacing MX. Never add Apple and the old provider's MX records as a guessed coexistence design. Different priorities do not provide a supported mailbox-splitting scheme.

Export the existing DNS records and keep the old provider available through the agreed transition. Preserve unrelated website records, other senders' DKIM selectors, delegations and security settings. Do not change parent nameservers, DNSSEC or credentials to make this example fit.

2. Separate account-issued values from documented constants

Apple's manual packet has these purposes. Compare the live setup packet before publishing; example.com below is a reserved example, not your domain.

Apple documents TTL 3600 and a final Verify action, followed by checking Custom Email Domain → Manage at iCloud+. The personal TXT must come from your account; the DKIM example substitutes your domain into Apple's documented pattern. Apple's existing-domain DNS procedure

This distinction is important: do not generate a private key yourself, borrow another customer's ownership token, or replace the CNAME with a copied public TXT key. Apple operates the signing side. A DNS administrator publishes only the required public information.

3. Publish at the authoritative DNS owner

The registrar and active DNS host may differ. Identify the authoritative nameservers and the zone responsible for each full name before editing. In the example.com zone, the relative DKIM owner is sig1._domainkey; entering the full name into an interface that automatically adds the zone can accidentally create sig1._domainkey.example.com.example.com.

For a separately delegated child domain, make changes in its authoritative child zone. If _domainkey.example.com is delegated, the selector belongs in that namespace, not a disconnected parent-zone copy. Preserve the existing NS delegation. If a DNS-provider setup cannot represent the required CNAME at the delegated owner, stop and arrange a supported configuration rather than removing the delegation.

These are DNS naming examples, not a claim that Apple accepts every possible enrollment domain. Use the exact domain accepted in your setup packet:

The ownership TXT and SPF TXT can coexist at the apex because they have different purposes. Only one TXT record at a given owner may begin with v=spf1. At the DKIM CNAME owner, however, do not add a conflicting TXT, A, AAAA, MX or second CNAME. Identify the system using any existing sig1 record before replacing it. An active selector collision requires a coordinated migration, not an overwrite.

Use DNS-only, not an HTTP proxy, for the authentication alias. Where Cloudflare's per-record Flatten control is available, leave it off for the required CNAME. Also ensure that the zone's all-CNAME flattening setting does not suppress this alias; a per-record exception cannot override that setting. Review dependencies before changing a zone-wide control. Cloudflare also flattens apex CNAMEs and same-zone targets in specific cases. If those mandatory behaviors prevent the necessary literal answer, stop for a supported arrangement rather than inventing a switch. Cloudflare CNAME flattening behavior and controls

DNS interfaces differ in whether they accept a trailing dot or surrounding TXT quotation marks. Inspect the stored value rather than repeatedly appending punctuation. The DNS value must not acquire smart quotes, spaces inside a hostname, a second suffix, or the literal placeholder domain.

4. Merge SPF without weakening existing senders

SPF checks the actual SMTP MAIL FROM domain, or the HELO identity in applicable cases. It does not automatically check the visible From address. Record the real envelope identity from a received test rather than promising a universal iCloud Return-Path or inventing a custom bounce-domain control.

Apple's setup packet places SPF at @ for the enrolled custom domain. Publish or merge that required authorization there; do not move the packet's SPF record to a different owner merely because a test exposes a different envelope domain. Separately, investigate the policy actually evaluated for the observed MAIL FROM with the responsible provider. You cannot edit an Apple-owned envelope domain.

Before editing the applicable policy, inventory all legitimate sending services. Add Apple's authorization to the single policy only where appropriate, retain the other approved mechanisms, and preserve the existing qualifier and routing design. Do not replace a working policy with a tutorial's standalone ~all example. If the domain uses redirect, review that design: redirect is ignored when an all mechanism is present. Do not add all accidentally and disable the intended redirect.

The SPF limit is ten evaluated DNS-dependent terms, including nested processing, not simply ten visible include strings. Count the whole applicable evaluation path before publishing. Do not manually flatten service IPs into a permanent snapshot or assume authorizing SPF guarantees acceptance. SPF evaluation and processing limits, RFC 7208

5. Complete verification, then test the actual sending route

After the approved DNS changes propagate, complete Apple's Verify step and confirm the domain's state in Manage. A successful account check is one checkpoint, not the final authentication result. If Apple's packet or account state differs from this documented route, pause and resolve it with Apple rather than guessing an extra activation control.

Use read-only DNS checks before sending. Replace example.com with your actual domain; these commands show the questions to ask, not fabricated successful output:

dig +short TXT example.com
dig +short MX example.com
dig +short CNAME sig1._domainkey.example.com
dig +short TXT sig1.dkim.example.com.at.icloudmailadmin.com
dig +short TXT _dmarc.example.com

Compare authoritative answers and an independent recursive resolver. Expect the authorized ownership value, one coherent SPF policy, the approved MX pair, and the exact DKIM alias leading to public key data. NXDOMAIN, a missing answer, an unexpected target or SERVFAIL needs investigation. DNS caching can delay visibility, but waiting does not repair an incorrect name or broken delegation.

Next, send a new message from the intended custom-domain address through iCloud Mail to a controlled external mailbox whose receiving infrastructure you trust. Do not test on customers. Check both the webmail path and any device/client path you actually intend to use, since a client can select a different From identity or outgoing account. Separately test incoming delivery and replies for the addresses affected by the migration.

Inspect the receiver's original message and keep these acceptance checks together:

• The visible From is the intended custom-domain address, not a rewritten icloud.com identity.
• The intended provider signature passes DKIM, with the observed d= signing domain and s= selector recorded.
• That passing signature aligns with the visible From under the current adkim policy.
• The trusted receiving service reports dmarc=pass for that From domain.
• SPF has been evaluated using the observed envelope identity, with any fail or error investigated independently.

Only use Authentication-Results produced inside the actual recipient service's known processing boundary. Consult its documented handling of externally supplied Authentication-Results and identify its own results through the service's original-message view or trusted administrator tooling. Header position and a familiar authserv-id string alone are not proof: an attacker can insert lookalike fields. Ignore untrusted results. Authentication-Results trust boundary, RFC 8601

A generic DMARC pass through SPF does not establish that the intended DKIM route works. Nor does another service's valid signature prove iCloud is signing correctly. Record each signature separately. For the distinction, see EmailAuth's raw DKIM versus DMARC-aligned DKIM results.

6. Retain the domain's DMARC protection

Under relaxed alignment, authenticated and visible-From domains share an Organizational Domain; strict alignment requires exact domain equality. A child envelope domain does not automatically satisfy strict SPF alignment. Check the actual d=, MAIL FROM and visible From values against the active adkim and aspf settings. DMARC identifiers and alignment, RFC 9989

Keep existing direct and applicable inherited DMARC policies and approved reporting destinations. Do not downgrade an enforced policy to p=none just because a new mailbox host is being added. Correct the sending route instead. If no direct or applicable inherited policy exists, the owner approves monitoring, and there is an appropriate review plan, this is a conditional first-record shape, not an instruction to paste it:

Type: TXT
Full owner: _dmarc.example.com
Relative owner in example.com zone: _dmarc
Value: v=DMARC1; p=none; rua=mailto:OWNER_APPROVED_REPORT_MAILBOX

Replace only OWNER_APPROVED_REPORT_MAILBOX with the approved mailbox address, such as the owner-approved address in your reporting plan; keep the existing mailto: prefix exactly once. Do not insert a full URI after it and create mailto:mailto:. Alternatively, omit rua until reporting has been deliberately arranged. Do not create a second DMARC record at the same owner. For a first policy specifically approved for mail.example.com, the full TXT owner is _dmarc.mail.example.com: enter relative _dmarc.mail in the parent example.com zone, or relative _dmarc in a separately delegated mail.example.com zone. These owner examples do not authorize overriding an applicable inherited policy.

When the report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted. Follow the reporting service's exact authorization instructions; protocol authorization is separate from the owner's consent to disclose report data. External report authorization and its exception, RFC 9990 section 4

Review approved aggregate reports alongside controlled message evidence. Do not raise enforcement until all legitimate senders, not only iCloud, have been assessed. Do not use obsolete percentage-rollout assumptions or treat missing reports as proof of failure or success.

Troubleshooting

When escalating, retain the change time, DNS answers, provider status and a minimally necessary message/header sample. Remove unrelated recipients and personal content. Never share Apple passwords, recovery secrets or private keys in a support attachment.