How to set up DMARC/DKIM/SPF for iCloud Mail
Updated on 11 Oct 2026: We updated the iCloud Mail setup instructions for current DMARC enforcement rules, SMTP settings, and report verification.
To authenticate a custom domain in iCloud Mail, add the domain to iCloud+, publish one SPF TXT record that authorizes include:icloud.com, publish every personalized DKIM CNAME Apple displays, and publish a DMARC TXT record at _dmarc. Apple then signs outgoing custom-domain mail. DMARC passes when SPF or DKIM passes and that authenticated domain meets the matching rule for the visible From domain.
This setup applies to a domain you own, such as example.com. It does not apply to an @icloud.com, @me.com, or @mac.com address because Apple controls DNS and authentication for those domains. Copy personalized values from Apple's setup screen for the domain being configured.
Add your custom domain
An iCloud+ subscription, two-factor authentication on the Apple Account, a primary iCloud Mail address, and control of the domain's DNS are required. List every existing mailbox before changing MX records because the MX cutover redirects new inbound mail to iCloud.
A custom address cannot already be used with a different Apple Account, and Custom Email Domain does not support Managed Apple Accounts. Check these eligibility restrictions in Apple's Custom Email Domain requirements before the MX cutover.
- Open iCloud+. Sign in at iCloud.com, open iCloud+, select Custom Email Domain, and choose Add a domain you own.
- Choose users. Select Only You or You and Other People, then enter the bare domain without www or an email address.
- Add mailboxes. Enter every existing address that must keep working, assign each one to its user, and complete the verification emails before the old provider stops receiving mail.
- Open DNS setup. Select View when Apple offers automatic or manual DNS setup. Use the automatic connection when the DNS host supports it, then inspect the created records.
The web path is the clearest for DNS work. On iPhone, the equivalent path is Settings, your name, iCloud, Mail, Custom Email Domain, then Use a Domain You Own. The web and device flows both end at the same DNS requirements.
Apple iCloud+ screen for adding a custom email domain
Apple displays a personal ownership TXT value plus MX, SPF, and DKIM records. The ownership token proves control of the domain. The two MX records route inbound mail, so replace old MX records when every required existing address has been added and verified in iCloud and the cutover is ready.
Protect the inbound cutover
Changing MX records affects receiving mail, not only authentication. Schedule the change when the old mailboxes, forwarding rules, and iCloud addresses have been accounted for.
- Preserve addresses. Add and verify each existing active address in iCloud before replacing the old provider's MX records. Finish setup after the DNS change.
- Copy exact values. Use the ownership token and DKIM target shown for this domain, including every selector Apple supplies.
A typical manual setup has the records below. The personal token and DKIM target are examples of structure, not reusable values. Some DNS panels add the domain name automatically, and some remove a final dot from a target. For manual entry, Apple's DNS instructions specify a TTL of 3600 seconds (one hour). A root host is usually @, blank, or the bare domain, depending on the DNS panel.
Apple iCloud manual DNS records for a custom domain
Enter these as separate DNS records at the authoritative DNS host. Each record has its own type, host, and value.
Typical iCloud Mail DNS structureDNS
@ IN TXT "apple-domain=PERSONAL_TOKEN_FROM_ICLOUD" @ IN MX 10 mx01.mail.icloud.com. @ IN MX 10 mx02.mail.icloud.com. @ IN TXT "v=spf1 include:icloud.com ~all" sig1._domainkey IN CNAME sig1.dkim.example.com.at.icloudmailadmin.com.
After saving DNS, return to the iCloud setup page and select Verify or Finish Setup. DNS publication often completes within minutes, but a high previous TTL can delay Apple's lookup. DNS changes do not move existing messages; import them separately after setup. Keep the setup page open or return to Custom Email Domain to retry verification.
Set up SPF
iCloud Mail supports a custom-domain return-path that can match the visible From domain, so SPF can satisfy DMARC for mail sent through Apple. Publish one SPF record at the root and add Apple's documented include to that record. Multiple SPF records at the same hostname cause a permanent SPF error.
- Find the root TXT. Check the bare domain for an existing value beginning v=spf1.
- Create or merge. If no SPF record exists, publish Apple's value. If one exists, add include:icloud.com before its final all mechanism.
- Keep other senders. Retain mechanisms for every other approved sender, using only values documented by those senders.
- Save as TXT. Use host @ or the DNS host's blank-root convention. Do not create the obsolete SPF record type.
- Remove duplicates. Confirm that the root publishes exactly one SPF TXT record beginning v=spf1. Other TXT records, such as the Apple ownership token, stay in place.
For a domain that sends only through iCloud Mail, Apple's standard SPF value is concise. The DNS provider usually adds display quotes automatically, so enter the value without literal extra quote characters unless its documentation says otherwise.
iCloud-only SPF TXT valueDNS
v=spf1 include:icloud.com ~all
Check the public DNS result after saving the record. The checker below exposes duplicate records, syntax errors, void lookups, and lookup-count problems that Apple's setup screen does not fully explain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A passing SPF result alone is insufficient when its return-path belongs to another domain. DMARC needs the authenticated SPF domain to match the visible From domain. iCloud custom-domain sending supports that match, but an additional platform that uses its own return-path can show an SPF domain-match error. That result is acceptable only when DKIM passes with the custom domain and DMARC passes.
Treat SPF as one shared policy
Every approved platform that sends with this return-path shares the same SPF record. Merge authorized mechanisms into one record. RFC 7208 permits at most ten DNS-querying mechanisms and modifiers during evaluation, including nested includes. Exceeding the limit causes permerror.
Do not add an SPF include because an IP name merely looks related to Apple. The iCloud setup screen and Apple's published guidance are the authority for include:icloud.com, while each additional sender must supply its own supported value.
Set up DKIM
Apple hosts the DKIM public key and manages the signing key; no locally generated DKIM key is required. The custom domain delegates each selector to Apple with a CNAME. Copy every host and target shown in iCloud because the target contains the real domain and cannot be reused across domains.
- Copy the selector. In iCloud Custom Email Domain, open the domain's DNS details and copy each DKIM host, commonly sig1._domainkey.
- Create a CNAME. Add the selector as the host and Apple's full domain-specific name as the target.
- Avoid doubled names. If the DNS panel appends example.com automatically, enter only sig1._domainkey in the host field.
- Clear conflicts. Check records at the exact selector hostname. A CNAME cannot coexist with other record data; replace conflicting records only after confirming they are no longer needed.
- Repeat selectors. Add every DKIM CNAME Apple lists. A later selector can support key rotation without changing the From address.
The sample below shows the common sig1 structure. The actual target displayed by Apple is authoritative. A DNS provider that treats names as fully qualified can accept the final dot, while another provider removes it when saving.
Apple iCloud DKIM CNAME values for a custom domain
Publish the CNAME at the authoritative DNS host, then query the complete selector hostname. A valid response resolves to Apple's target and ultimately exposes a DKIM public key.
Typical iCloud DKIM CNAMEDNS
sig1._domainkey.example.com. IN CNAME sig1.dkim.example.com.at.icloudmailadmin.com.
A copied sample does not activate DKIM
Replacing only the visible example.com text can still produce the wrong target. Copy the selector and target from the iCloud setup for the exact domain.
DKIM success is confirmed on a sent message, not by CNAME existence alone. The receiving mailbox's Authentication-Results header should show dkim=pass. With default relaxed matching, header.d and the visible From domain must share the same organizational domain. With adkim=s, they must match exactly.
Set up DMARC
DMARC belongs at _dmarc.example.com and is separate from Apple's ownership TXT, SPF, MX, and DKIM records. For a new deployment, start with p=none and aggregate reporting. If the domain already has p=quarantine or p=reject, keep that enforcement policy and repair authentication without weakening it.
- Create the mailbox. Make sure dmarc@example.com can receive aggregate reports, or replace it with a reporting address that can.
- Check for DMARC. Query _dmarc.example.com before publishing. Edit an existing record rather than creating a duplicate.
- Publish one TXT. Use host _dmarc for a domain with no current policy. Replace the example reporting address with a working address for the real domain.
- Keep enforcement. Leave p=quarantine or p=reject in place when it already protects the domain. Do not reset it to p=none for convenience.
The DMARC record generator builds the TXT value when the reporting address, subdomain policy, or strict domain matching needs to change. For the starting policy, replace dmarc@example.com with your reporting address and publish this value:
Initial DMARC TXT valueDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
If rua points to a different organizational domain, the report receiver must authorize that destination in DNS. RFC 9990 defines this external reporting check. With Suped's product, use the reporting address supplied for your domain and verify external destination authorization during onboarding.
Verify the public result after saving. The host must resolve to one DMARC record, the version tag must come first, and the reporting address must be able to accept compressed aggregate report attachments.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker confirms syntax and publication. It cannot prove that iCloud is signing every real message or that every other sending source has been identified. Those answers come from sent-message headers and aggregate DMARC reports.
Do not lower an existing policy
A working p=quarantine or p=reject policy already blocks some impersonation. Keep it, confirm iCloud's DKIM and SPF results, and fix only the failing source.
DMARC passes when at least one method passes and its authenticated domain matches the From domain. Aim for both SPF and DKIM to pass on direct delivery. Relaxed matching is the default; aspf=s or adkim=s requires an exact domain match for that method. Forwarding often breaks SPF because the forwarding server has a different IP, while DKIM survives when the signed content stays intact.
Verify and troubleshoot iCloud Mail authentication
Verification has two layers. DNS must publish the intended records, and a real message must show passing authentication with the custom domain. Complete both checks after Apple's Finish Setup succeeds.
- Finish in iCloud. Open iCloud+, Custom Email Domain, select the domain, and choose Verify or Finish Setup.
- Check public DNS. Query the root SPF TXT, both MX records, each DKIM CNAME and its public key, and the _dmarc TXT from outside the DNS provider.
- Send from iCloud. Compose in iCloud Mail or Apple Mail using the iCloud account, select the custom address in From, and send to a mailbox where full headers are available.
- Read the results. Inspect the receiving mailbox's Authentication-Results header. For direct iCloud delivery, expect spf=pass, dkim=pass with the custom signing domain, and dmarc=pass. Compare smtp.mailfrom and header.d with header.from.
- Test every route. Repeat for iCloud.com, each device, and any application that sends using the custom From address.
These commands query the records directly. Replace example.com with the real domain and repeat the CNAME query for every selector Apple supplied.
DNS verification commandsBASH
dig +short TXT example.com dig +short MX example.com dig +short CNAME sig1._domainkey.example.com dig +short TXT sig1._domainkey.example.com dig +short TXT _dmarc.example.com
When DNS looks correct but Apple's screen still fails, compare the saved host with the fully qualified name. A common mistake is a doubled domain, such as sig1._domainkey.example.com.example.com. Confirm that the record is enabled and saved in the DNS zone used by the domain's authoritative nameservers.
Expected results
- SPF result. One root record and spf=pass for direct iCloud delivery.
- DKIM result. The selector resolves and dkim=pass uses the custom domain.
- DMARC result. One _dmarc TXT record and dmarc=pass in the message header.
- Mail flow. Both Apple MX hosts publish at priority 10 and the mailbox receives mail.
Targeted fixes
- SPF permerror. Merge duplicate SPF records and recount DNS lookups.
- DKIM missing. Correct the selector host, remove conflicts, and copy Apple's target again.
- DMARC fail. Compare header.d and the SPF return-path domain with the visible From domain.
- No inbound mail. Correct MX records and create the exact recipient address in iCloud.
A clean DNS response still needs a sent-message test. In iCloud Mail, the custom address must be selected in the From menu. Sending with the primary @icloud.com address tests Apple's domain, not the custom domain.
Selecting a custom domain address in Apple iCloud Mail
Send a real iCloud message into Suped's email tester for an end-to-end check. It evaluates the message path and authentication results together, which catches a wrong From address, missing DKIM signature, or domain mismatch that a DNS-only check misses.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If direct iCloud messages pass but mail sent by an application fails, check its outgoing SMTP server. An app sending through iCloud uses Apple's authentication. An app sending through its own platform is a separate source and needs that platform's custom-domain DKIM. A nonmatching SPF return-path still permits DMARC to pass when matching DKIM passes.
For delivery errors at Apple-hosted recipients, compare the SMTP response and sending practice with Apple postmaster guidance. Apple states that iCloud Mail signs outbound mail with DKIM, publishes SPF for its own domains, and honors a sender domain's DMARC policy.
Send through iCloud's SMTP server
Selecting a custom From address in a mail app does not choose the outgoing server. Use the iCloud account for that address. For a client that needs manual configuration, Apple documents these outgoing settings:
iCloud outgoing SMTP settingsTEXT
Server: smtp.mail.me.com Port: 587 Encryption: TLS/STARTTLS SMTP authentication: required Username: your full primary iCloud Mail address Password: an app-specific password
Use an app-specific password for manual SMTP authentication, rather than the normal Apple Account password. Set From to an address added to your custom domain, then repeat the message-header test. Follow Apple's mail server settings for the client configuration.
If the app uses another outgoing server, adding include:icloud.com does not authorize that server. Configure that sending platform separately and keep its legitimate mechanisms in the shared SPF record.
Monitor iCloud Mail authentication
DNS verification is a point-in-time check. A later DNS edit, expired sending integration, new application, or Apple selector change can break authentication after setup. Suped's DMARC monitoring product turns aggregate reports into source-level issues and notifies the responsible person when authentication failures cross a configured threshold.
- Watch pass rates. Alert when iCloud SPF, DKIM, or DMARC results fall below the established baseline.
- Identify new sources. Separate approved iCloud traffic from an unknown service using the same From domain.
- Catch DNS drift. Recheck DNS and the reporting destination after unexpected failures for a missing DKIM selector, duplicate SPF record, changed policy, or disabled report address.
- Track reputation. Review blocklist and blacklist status alongside authentication and deliverability signals.
Keep aggregate reporting enabled after every record passes. Daily source data provides the evidence needed to distinguish a temporary forwarding effect from a broad configuration failure. Reports usually cover a daily period and arrive after the receiver processes that period, so report-based alerts depend on report arrival. Recheck DNS and sent-message headers immediately after a change.
Connect reports to Suped
Add the custom domain to Suped and use its assigned rua destination in your existing DMARC policy. Confirm that reports arrive, mark approved iCloud traffic, and investigate unexpected sources before changing enforcement.
An alert should identify the affected domain, source, authentication method, failure rate, and first observed time. That context makes the response actionable and avoids changing a healthy iCloud record because an unrelated application failed.
Secure your domain with p=reject
p=reject instructs participating receivers to refuse messages that use the domain in From and fail DMARC. Move to it only after reports show that iCloud and every approved source pass through at least one matching authentication path.
RFC 9989 makes pct historic and removes percentage-based enforcement. Use p=none, then p=quarantine, then p=reject after reviewing legitimate traffic; treat each enforcement change as applying to all DMARC-failing messages.
DMARC enforcement gates
Each gate has an observable condition before the policy becomes stricter.
Observe
p=none
Collect aggregate reports and label all legitimate senders.
Confirm
Approved sources verified
Require a valid SPF or DKIM domain match for approved mail.
Quarantine
p=quarantine
Request quarantine for DMARC-failing messages and inspect affected legitimate mail.
Reject
p=reject
Request rejection of DMARC-failing use of the domain.
The observation period must include normal billing, support, account, and device-generated mail cycles. A quiet day is not enough evidence for a domain used by applications that send weekly or monthly. Test forwarding and mailing-list delivery before enforcement; a list that changes signed content can also break DKIM.
- Inventory sources. Label iCloud Mail, forms, applications, devices, and any service that uses the domain in From.
- Fix DKIM first. Require the custom domain in the DKIM signing result wherever the sender supports it.
- Test quarantine. Publish p=quarantine only after approved senders pass DMARC, then inspect legitimate delivery before moving to reject.
- Reach full reject. Publish p=reject after quarantine data has no unexplained legitimate failures.
- Review subdomains. Without sp, subdomains without their own DMARC record inherit p. Check legitimate subdomain senders before choosing an explicit sp policy.
- Keep monitoring. Continue reports and alerts after enforcement because authorized systems still change.
The quarantine and reject examples use the same aggregate reporting address. They are alternative values: replace example.com and publish only the selected policy as one DMARC TXT record.
Alternative quarantine and reject DMARC policiesDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC product lets you manage the policy after publishing the assigned DNS delegation. Pair policy changes with aggregate-report review before selecting quarantine or reject.
Do not remove reporting at p=reject
Enforcement blocks impersonation attempts, but it also makes an unnoticed sender change more disruptive. Keep rua reporting and authentication alerts active after full enforcement.
After p=reject is live, retest mail sent through iCloud.com, each Apple device, and every approved application. A DMARC pass with the intended From address is the release criterion for each route.
Frequently asked questions
Yes. Apple provides an SPF include and domain-specific DKIM CNAME values during custom-domain setup. You publish DMARC separately at _dmarc. A real message should show SPF and DKIM passing, with DMARC passing because at least one authenticated domain matches the From domain. A DMARC pass does not guarantee inbox placement; receivers also apply spam filtering.
Confirm that rua uses a working report address and that an external destination is authorized. Send real mail to receivers that issue aggregate reports and allow their reporting cycle to complete. Reports usually cover a daily period, and not every receiver sends them. A successful iCloud setup check does not confirm report delivery.
iCloud Mail uses include:icloud.com for custom-domain SPF authorization. Publish it because Apple's setup instructions for the real domain require it, not because it appears in an unrelated domain or report. Merge it into the existing SPF record instead of publishing a second SPF record.
Yes, when DKIM passes and its signing domain meets the matching rule for the visible From domain. This is common after forwarding breaks SPF. For direct iCloud custom-domain mail, expect both SPF and DKIM to pass. A passing SPF result for an unrelated return-path does not satisfy DMARC.
No. Start a new DMARC deployment with p=none and aggregate reporting, identify every legitimate sender, review delivery under p=quarantine, then move to p=reject. Keep an existing p=quarantine or p=reject policy in place rather than lowering protection during iCloud setup.
