会員登録やログインに「Appleでサインイン（Sign in with Apple）」を使っているWebサイトやアプリでは、利用者が本当のメールアドレスを隠す「メールを非公開」を選ぶと、Appleが作った転送用のアドレスが届きます。これまでそのアドレスは @privaterelay.appleid.com で終わっていました。登録処理のどこかでこのドメインを決め打ちしていると、新しいドメインのアドレスを持つ利用者だけが登録できない、メールが届かない、といった問い合わせにつながります。
Appleは2026年8月24日の開発者向けの告知で、Sign in with Appleで新しく発行するアドレスのドメインを変えると案内しました。
Starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com. Existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without interruption.
この記事では、Appleの告知と開発者向けのドキュメントをもとに、Webサイトや業務システムの保守担当者が確かめることを整理します。
何が変わり、何が変わらないか
告知の要点は次の3つです。
- 新しく発行されるアドレス：
@private.icloud.comになる（「later this year」＝今年中の予定。公開前に確認した2026年10月27日時点でも、開始日は書かれていない） - すでに発行されたアドレス：
@privaterelay.appleid.comのまま使え、転送も続く - iCloud+の「メールを非公開」：
@icloud.comのまま変わらない
最後の点は、6月15日の最初の告知から変わりました。6月の告知では「メールを非公開」も private.icloud.com にまとめるとしていましたが、8月の告知で取り下げられ、6月の告知のページには「古い情報を含む」という注記が付いています。調べものの途中で6月のページを読んだ場合は、8月の告知を正としてください。
告知が開発者に求めていることは1つです。
Developers with apps or websites that use Sign in with Apple should ensure that their account systems, email validation logic, and allowlists accept addresses on the new private.icloud.com domain in addition to the existing privaterelay.appleid.com domain.
つまり、会員の登録・更新の処理、メールアドレスの入力チェック、許可リストの3か所が、新しいドメインを受け付けるかどうかです。
決め打ちがないか確かめる場所
ここからは、告知の3か所を具体的なコードや設定に置き換えた編集部の整理です。
- 会員登録・ログインの処理：Appleから受け取ったメールアドレスのドメインを見て「転送用のアドレスか」を判定し、扱いを分けている処理（例：メールアドレスの再入力を求める、別の確認画面に送る）
- メールアドレスの入力チェック：フォームのバリデーションや、使い捨てメールを弾くための「許可するドメイン」「拒否するドメイン」の一覧
- 許可リスト・社内の連携先：会員のメールアドレスを受け取る外部のサービス（メール配信、CRM、決済など）の側にある、ドメインでの絞り込みやブロックの設定
6月の告知（現在は古い情報を含むと注記されたもの）は、メール配信の事業者に対しても、転送用のドメインを列挙しているフィルターや配信停止の一覧、振り分けのルールを更新するよう求めていました。8月の告知ではこの段落はなくなっていますが、外部のメール配信サービスにドメインでの設定がある場合は、同じように見直しておくのが安全です。
ドメインで判定するときの落とし穴
古い書き方の例と、新しいドメインを加えた例を、編集部の検証環境（Node.js 22.22.0）で比べました。テスト用のアドレスは架空のものです。
// 古い書き方：privaterelay.appleid.com だけを見ている
const legacy = /@privaterelay\.appleid\.com$/i;
// Appleのドキュメントが挙げる、転送用アドレスのドメイン
const APPLE_RELAY_DOMAINS = new Set(['private.icloud.com', 'privaterelay.appleid.com', 'icloud.com']);
function emailDomain(email) {
const at = email.lastIndexOf('@');
return at < 0 ? '' : email.slice(at + 1).trim().toLowerCase();
}
const isAppleRelayDomain = (email) => APPLE_RELAY_DOMAINS.has(emailDomain(email));結果は次のとおりです。
| テストのアドレス | 古い書き方 | ドメインの一覧で判定 |
|---|---|---|
ep9ks2tnph@privaterelay.appleid.com | 一致 | 一致 |
ab12cd34ef@private.icloud.com | 一致しない | 一致 |
AB12CD34EF@Private.iCloud.com | 一致しない | 一致 |
taro@icloud.com | 一致しない | 一致 |
x@private.icloud.com.evil.example | 一致しない | 一致しない |
古い書き方では、新しいドメインのアドレスを転送用と見なせません。一方で、icloud.com を一覧に入れると、icloud.com で終わるアドレスはすべて「Sign in with Appleの転送用」と判定されます。Appleのドキュメントは、転送用のアドレスの特徴として「@private.icloud.com、@privaterelay.appleid.com、@icloud.com のいずれかで終わる」と書いていますが、icloud.com で終わるアドレスがすべて転送用だとは書いていません。8月の告知によれば icloud.com はiCloud+の「メールを非公開」のアドレスにも使われ続けます。ドメインだけでは、こうした別の用途のアドレスと区別できません。
そこで編集部としては、次の使い分けを提案します。
- 受け付けるかどうか（入力チェック・許可リスト）：3つのドメインのどれも拒否しない。新しい
private.icloud.comを加える - 転送用かどうかを判定したい場合：ドメインで推測せず、Appleから届く情報を使う。Appleのサーバー間通知（メールの転送の有効化・無効化の通知）の例には、
is_private_emailという項目が含まれています
ドメインの比較は、上の例のように @ より後ろを小文字にしてから完全一致で行います。前方一致や「含む」で比べると、private.icloud.com.evil.example のような別のドメインを通してしまいます。
転送用のアドレスにメールを送る側の確認
転送用のアドレスに会員向けのメールを送っている場合は、ドメインの変更とは別に、Appleの転送サービスの設定も確かめておきます。Appleのドキュメントによると、転送サービスを通すには、送信元のドメインやメールアドレスをAppleの開発者アカウント（Certificates, Identifiers & Profiles）に登録し、SPFまたはDKIMで認証する必要があります。
- 登録していない送信元から送ったメールは、転送されずに戻ってくる（バウンスする）
- 登録できる送信元は、組織で登録している場合は100件まで、個人の場合は32件まで
- 1つの転送用アドレスで扱えるメールは1日100通まで（開発者からのメールと利用者の返信の合計）
新しいドメインのアドレスに送るときも、この仕組みは同じです。送信元を増やしたのに登録を忘れている、メール配信サービスを変えたのにSPF・DKIMの設定が追いついていない、といった状態は、ドメインの変更をきっかけに見直しておくと安心です。SPF・DKIM・DMARCの設定の考え方は中小企業のSPF/DKIM/DMARC設定で解説しています。
外注先に確認するときの聞き方
自社でコードを書いていない場合は、制作会社や開発会社に次の点を確認すると、話が早く進みます。
- Sign in with Appleで受け取ったメールアドレスを、ドメインで判定している処理はあるか
- メールアドレスの入力チェックや、外部のサービスの許可リストに
privaterelay.appleid.comを書いている箇所はあるか - ある場合、
private.icloud.comを加える対応と、テストの予定はどうなっているか
「Googleでログイン」などのソーシャルログインを含めた検収の見方は、「Googleでログイン」を実装してもらった — 検収で見るのはどこかでまとめています。
確認した範囲
2026年10月26日に、Apple Developerのニュース「Update: New domain for Sign in with Apple」（2026年8月24日）と「New domain for Sign in with Apple and iCloud+ Hide My Email」（2026年6月15日、古い情報を含むと注記されたもの）、ドキュメント「Communicating using the private email relay service」「Processing changes for Sign in with Apple accounts」、ヘルプ「Configure private email relay service」を確認し、公開前の10月27日に同じ資料で内容を確かめ直しました。8月の告知より後に、このドメインの変更についての新しい告知は出ていません（資料調査）。ドメインの判定のコードは編集部の検証環境（Linux、Node.js 22.22.0）で実行し、上の表の結果を確認しました。公開前にmacOS（Node.js 22.23.4）でも実行し、同じ結果になりました（実機検証）。実際のApple Accountでのサインイン、新しいドメインのアドレスの発行の開始、転送サービスでのメールの送受信は確認していません。
会員サイトや業務アプリのログインまわりの改修は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Update: New domain for Sign in with Apple（Apple Developer、2026-08-24）
- New domain for Sign in with Apple and iCloud+ Hide My Email（Apple Developer、2026-06-15）
- Communicating using the private email relay service（Apple Developer Documentation）
- Processing changes for Sign in with Apple accounts（Apple Developer Documentation）
- Configure private email relay service（Apple Developer Help）
