Apple iCloud+ Custom Email Domainの​SPF・DKIM・DMARC設定。

Apple iCloud+ Custom Email Domainを認証すべき理由

iCloudでは、純粋な送信サービスを使う場合よりも、これらのレコードを正しく設定する重要性が高くなります。Custom Email DomainはiCloudを単なる送信リレーではなくメールボックスサービスにするものであり、送信を可能にするMXの変更によって、そのドメイン宛ての受信メールもすべてAppleに向かうようになるからです。設定を誤ると、迷惑メールに振り分けられるだけでなく、メールを受信できなくなります。到達率の面では、最新のルールも引き続き適用されます。2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMでの成功を義務付けており、大量送信者にはアライメントが一致したDMARCの公開も求めています。Microsoftも2025年に、大量送信者に同様のチェックの適用を始めました。この点でiCloudは条件の良いケースです。実際のメールボックスサービスであるため、送信メールはyourdomain.comとしてDKIM署名され、SPFはAppleが許可したIPを通じて解決されます。そのため、どちらのメカニズムでもyourdomain.comとのアライメントを一致させられ、DMARCの成功につながります。ただし、Appleが公開するのはSPFとDKIMだけです。DMARCレコードを自分で追加するまで、受信側には適用すべきポリシーがなく、ドメインはなりすましが可能な状態のままです。なお、iCloud+ Custom Email Domainは個人や少人数チーム向けのメールボックス（有料のiCloud+ストレージプランならどれにも含まれます）であり、マーケティングやトランザクションメールのプラットフォームではありません。人が使うメールボックスとして認証し、一括送信は専用のメール配信サービス（ESP）で行ってください。

Apple iCloud+ Custom Email DomainにおけるSPFの実情

iCloudは、実際に「include」で設定する方式のサービスです。共有メカニズムのinclude:icloud.comを1つ、ルートドメインの単一のSPF TXTレコードに追加します。Appleのセットアップウィザードはこれをv=spf1 include:icloud.com ~allとして書き出します。ここまでは標準的な手順です。ほとんどのガイドが誤っているのはコストです。include:icloud.comはルックアップ1回で済む安価なincludeではなく、広く使われている共有includeの中でも特に消費の多いものの1つです。解決すると、icloud.comのSPFレコードとしてv=spf1 redirect=_spf.icloud.comが返ります。このredirectの先は_spf.icloud.comで、そのレコードはv=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~allです（各_netsレコードにはip4/ip6の範囲しかないため、連鎖はここで止まります）。RFC 7208に基づいて数えると、include自体（1回）、redirect（1回）、ネストされた3つの_netsのinclude（3回）で合計5回となり、許容される10回のSPF DNSルックアップのうち5回をiCloudだけで消費します。Google Workspace、Microsoft 365、SendGridのいずれかからも送信している場合は、すぐに10回の上限によるPermErrorに達する可能性があります。iCloudのincludeは消費の大きい項目として扱い、SPFの他の部分は最小限に抑えてください。ルールはあと2つあります。まず、ドメインのSPFレコードは1つだけにします。2つ目のTXTを公開せず、include:icloud.comを既存のv=spf1の行にまとめてください。SPFレコードが2つあると自動的にPermErrorになります。次に、include形式を、古いチュートリアルに見られるredirect=icloud.com形式と混同しないでください。redirect=icloud.comはSPFポリシー全体をAppleのものに置き換え、他の送信元をすべて気づかないうちに除外します（ルックアップも同じ5回を消費するため、利点はありません）。したがって、そのドメインとして送信するのがiCloudだけの場合に限り正しい設定です。Appleのレコードは~all（softfail）で終わります。これは、すべての送信者が網羅されていることを確認する間の適切なデフォルトです。

2つの設定方法

設定手順

追加するレコード

正確な値はApple iCloud+ Custom Email Domainのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Apple iCloud+ Custom Email Domainの設定がこの上限のうち何回を消費するかは、次のとおりです。

正しく設定できたか確認する

Appleの「Finish Setup」の緑のチェックだけで判断せず、実際のメールで認証を確認してください。新しいiCloudアドレスからGmailアカウントに送信し、メールを開いて⋮ → Show originalを選びます。SPF: PASS、signed-by: yourdomain.comとセレクターsig1を伴うDKIM: PASS、DMARC: PASSと表示され、すべてicloud.comではなく自社ドメインを指していれば成功です。iCloudは受信ホストにもなっているため、そのアドレス宛てにもメールを送り、届くことを確認してください。これでMXの変更が反映されたことを確かめられます。レコードを直接確認する場合、dig TXT yourdomain.comでは単一のv=spf1 include:icloud.com ~allが表示され、dig CNAME sig1._domainkey.yourdomain.comはsig1.dkim.yourdomain.com.at.icloudmailadmin.comに解決され、dig TXT _dmarc.yourdomain.comではポリシーが返されるはずです。次に、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決されることを確認します。include:icloud.comが5回のルックアップを消費するため、SPFが10回の上限内に収まっていることの確認はiCloudでは特に重要です。集計レポートが届いたら、DMARCレポート解析にレポートをドロップし、iCloudがアライメント一致ですべて成功している送信元として表示されることを確認します。

よくある注意点

• 認証失敗の原因

  include:icloud.comは消費が大きいincludeです。10回のSPF DNSルックアップのうち、1回ではなく5回を消費します。icloud.comは_spf.icloud.comにリダイレクトし、そこに_nets0/_nets1/_nets2.icloud.comがネストされています。Google WorkspaceやMicrosoft 365と併用すると10回の上限によるPermErrorに達する可能性があるため、SPFの他の部分は最小限にし、回数を確認してください。

• 適用範囲

  これは送信時の署名だけでなく、メールボックスの完全な移行です。mx01/mx02.mail.icloud.comのレコードは、そのドメイン宛ての受信メールをすべてiCloudに向けます。同じアドレスをiCloudと他のサービスに分けてホストすることはできません。iCloudで受信する準備が整ってからMXを追加してください。

• DNS設定

  redirect=icloud.comではなくinclude形式を使ってください。redirectはSPFポリシー全体をAppleのものに置き換え、他の送信元をすべて気づかないうちに除外します。ルックアップも同じ5回を消費するため、利点はありません。iCloudがそのドメインの唯一の送信者である場合にのみ正しい設定で、それ以外ではフォーム、ニュースレター、CRMがSPFに失敗し始めます。

• DNS設定

  DKIMレコードはCNAMEで、プロキシやフラット化を適用してはいけません。Cloudflareではsig1._domainkeyを「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドのプロキシやCNAMEフラット化はターゲットを書き換え、DKIMの署名が止まります。鍵はAppleが保持するため、公開鍵の貼り付けやローテーションは不要です。

• DNS設定

  Appleが公開するのはSPFとDKIMだけで、DMARCは公開しません。自分で_dmarcレコードを設定しない限り、適用すべきポリシーがなく、ドメインはなりすましが可能な状態のままです。まずv=DMARC1; p=noneを追加し、その後引き上げてください。

• DNS設定

  iCloudが用意するDKIMセレクターは1つ（sig1）だけです。sig2も追加するよう案内するガイドがあっても、Appleの現在の手順ではありません。sig1のCNAMEが1つあれば正しい設定です。

• 認証失敗の原因

  SPF TXTレコードは1つだけにしてください。include:icloud.comは既存のv=spf1の行にまとめます。SPFレコードが別々に2つあると自動的にPermErrorになり、SPFが完全に失敗します。

• 適用範囲

  iCloud+ Custom Email Domainは個人や少人数チーム向けのメールボックスであり、ESPではありません。Appleは送信量に上限を設け、大量送信や商用の一斉送信を禁止しています。マーケティングキャンペーンや大量のトランザクションメールはこれを経由させず、専用の送信プラットフォームを使ってください。

• DNS設定

  セットアップ後もapple-domainのTXTを削除しないでください。Appleはこれを使ってドメインの所有権を定期的に再確認します。削除するとドメインが無効になり、メールが使えなくなる可能性があります。

SPFレコードを作成

以下ではApple iCloud+ Custom Email Domainがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。

Apple iCloud+ Custom Email DomainのSPFに関するよくある質問

関連記事

ワークスペース・メールボックスの他のサービス

• Fastmail
• Google Workspace
• mailbox.org
• Microsoft 365
• Microsoft 365 (GoDaddy / IONOS)
• Migadu
• Namecheap Private Email
• Proton Mail

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。