Appleは2026年8月24日、iCloud+の「メールを非公開（Hide My Email）」で使うメールドメインについて、従来の icloud.com を維持すると発表した。6月15日の時点では「Appleでサインイン」とHide My Emailの両方を private.icloud.com へ移す予定だったので、Hide My Emailについては約2か月で方針が戻ったことになる。
私はWebサービスや開発ツールへ登録するとき、普段使っているメールアドレスをそのまま渡さず、Hide My Emailで作ったアドレスを使うことが多い。サービスごとに別のアドレスを持てて、不要になればそのアドレスだけ止められるので、かなり重宝している。
そのため、6月に @private.icloud.com へ変わるという発表を見たときは困った。メール転送の機能がなくなるわけではないが、専用ドメインになれば登録先から「Appleの非公開用アドレス」と簡単に分類できる。私の使い方では、その時点でHide My Emailを使い続ける理由がかなり薄くなるため、SimpleLoginやaddy.io、FastmailのMasked Emailなどへの移行を考えていた。
今回 @icloud.com のまま残るのはiCloud+のHide My Emailであり、「Appleでサインイン」のプライベートEメールリレーは別の話だ。こちらは新規アドレスを @private.icloud.com へ移す予定が維持されている。
アップデート：「Appleでサインイン」の新しいドメイン - 最新ニュース - Apple Developer
「Appleでサインイン」で生成されるアドレスはこれまで「privaterelay.appleid.com」で発行されていましたが、年内より「private.icloud.com」で発行されるようになります。「privaterelay.appleid.com」を含む既存のアドレスは引き続き機能し、中断なくユーザーにメールが転送されます。検討を重ね、コミュニティからのフィードバックを考慮した結果、iCloud+の「メールを非公開」で生成されるアドレスは引き続き「icloud.com」で発行されます。 必要な対応 アプリやWebサイトに「Appleでサインイン」を導入しているデベロッパは、アカウントシステム、Eメール検証ロジック、許可リストにおいて、既存のドメイン「privaterelay.appleid.com」に加えて、新しいドメイン「private.icloud.com」を含むアドレスを受け入れるように設定する必要があります。「Appleでサインイン」についてさらに詳しく プライベートEメールリレーサービスを使用したコミュニケーション（英語）
https://developer.apple.com/jp/news/?id=1ptvdtcm
6月15日の発表から、8月24日に方針が変わった
2026年6月15日のApple Developer向け告知では、「Appleでサインイン」で使われてきた privaterelay.appleid.com と、iCloud+のHide My Emailで使われている icloud.com を、新しい private.icloud.com にまとめる予定だと案内されていた。
その後、8月24日にAppleが内容を更新し、Hide My Emailについては icloud.com を維持すると発表した。Appleはコミュニティからのフィードバックを確認したうえで方針を見直したとしており、6月の古い告知にも現在は情報が更新されたことを示す注記が付いている。
| 機能 | これまで | 6月15日時点の予定 | 8月24日の更新後 |
|---|---|---|---|
| Appleでサインイン | @privaterelay.appleid.com | @private.icloud.com | 新規は @private.icloud.com へ移行。既存は維持 |
| iCloud+ メールを非公開 | @icloud.com | @private.icloud.com | @icloud.com を維持 |
「Appleでサインイン」およびiCloud+の「メールを非公開」の新しいドメイン - 最新ニュース - Apple Developer
Appleは今年の夏、「Appleでサインイン」とiCloud+の「メールを非公開」で使用されているEメールドメインを「private.icloud.com」という単一の共有ドメインに統合する予定です。
https://developer.apple.com/jp/news/?id=sus6t6ab
@privaterelay.appleid.com はそのまま使える
今回の発表で少し紛らわしいのが、「Appleでサインイン」のアドレスだ。Hide My Emailは @icloud.com を維持する一方で、「Appleでサインイン」で新しく作られるプライベートEメールリレーのアドレスは @private.icloud.com へ移行する。
私も [email protected] のようなアドレスを持っているが、既存のアドレスが今回の変更で置き換えられたり無効になったりするわけではない。Appleは既存の privaterelay.appleid.com アドレスについて、引き続き機能し、メール転送も中断なく継続すると案内している。
privaterelay.appleid.com は2026年6月から8月の間だけ使われた一時的なドメインでもなく、「Appleでサインイン」でメールアドレスを非公開にしたときに以前から使われてきた専用ドメインだ。
「Appleでサインイン」はもともとrelay専用ドメインを使っていたので、private.icloud.com へ変わっても、サービス側からrelay用のアドレスだと分かる点は大きく変わらない。私が今回気にしていたのは、通常のiCloud Mailと同じ icloud.com を使っていたHide My Emailまで専用ドメインへ移ることだった。
私が専用ドメイン化を嫌だった理由
Hide My Emailでは、Appleが作ったランダムなメールアドレスをWebサイトやアプリへ渡し、そこに届いたメールを自分の受信先へ転送できる。私が便利だと感じているのは、本来のメールアドレスを渡さずに済むことだけではない。
現在のHide My Emailは [email protected] のようなアドレスになる。通常のiCloud Mailも同じ icloud.com を使うため、少なくともドメインだけを見てHide My Emailなのか通常のiCloud Mailなのかを判別することはできない。
もし6月の予定どおり private.icloud.com に移っていたら、その状況が変わる。
[email protected]
[email protected]
[email protected]
[email protected]本来のメールアドレスまでは分からなくても、@private.icloud.com を見ればAppleの非公開用アドレスだと判断しやすい。私はこの状態でWebサービスへの登録に使い続けるのは厳しいと感じていた。
Webサービス側で特定ドメインを条件にする処理は簡単に書ける。たとえば、サービス側が非公開メールを受け付けたくないと判断すれば、次のような条件だけで対象にできる。
const domain = email.split("@").pop()?.toLowerCase();
if (domain === "private.icloud.com") {
// 登録不可や追加確認など、サービス側のルールを適用できる
}実際にどれだけのサービスが拒否するかは分からない。ただ、私は登録するたびに「このサービスでは使えるだろうか」と気にしながらHide My Emailを使いたくない。専用ドメイン一つでまとめて判定できる状態になった時点で、登録用アドレスとしての使い勝手はかなり落ちると考えていた。
Apple自身も6月の告知で、メールサービス事業者に対してドメインベースのフィルタリングやsuppression list、routing ruleへ private.icloud.com を追加するよう案内していた。メールシステムがドメイン単位で処理すること自体は珍しくないので、私にとっては単なる想像上の心配として片付けにくかった。
私がHide My Emailをよく使う場面
私はSaaSや開発ツールを試すとき、検証用アカウントを作るとき、しばらく使うか分からないサービスへ登録するときにHide My Emailをよく使う。普段のメールアドレスを渡す必要がない場面では、登録先ごとにアドレスを分けておく方が都合がいい。
iCloud+ではHide My Emailのアドレスごとにラベルやメモを付けられるので、どこへ渡したものか後から確認できる。不要になったサービスがあれば、そのアドレスだけ転送を止められる。
Create and edit Hide My Email addresses on iCloud.com
On iCloud.com, create unique, random email addresses with Hide My Email to hide your personal email address. You can also edit ones you created.
https://support.apple.com/guide/icloud/create-and-edit-addresses-mm1a876f7aed/icloud
たとえば私の使い方を単純化すると、次のような形になる。
開発ツールA [email protected]
SaaS B [email protected]
検証用サービスC [email protected]短期間だけ使って止めることもあるし、そのサービスを使い続けるなら同じアドレスを残しておけばいい。一般的な捨てアドレスより長く使いやすく、管理もiCloudの中で完結する。この手軽さがあるので、私は単なるプライバシー機能というより、用途別の受信用メールアドレスとして使っている。
独自ドメインでもできるが、私はメール運用を増やしたくない
用途別にアドレスを分けるだけなら、独自ドメインでaliasやcatch-allを使う方法もある。私自身も独自ドメインは持っているので、技術的にはそちらへ寄せることもできる。
ただ、Webサイトのためにドメインを管理することと、メールを継続して運用することは少し違う。マネージドなメールサービスを使えばメールサーバーを自分で保守する必要はないものの、ドメインの更新、DNSやMXレコード、転送先、aliasなど管理する項目は増える。自分のドメインから送信するならSPF、DKIM、DMARCも関係してくるし、メールは相手側へ安定して届くことまで気にしたい。
私は、開発ツールを一つ試すために受信用アドレスを増やしたいだけなら、そこまでメール環境の管理を増やしたくない。Hide My EmailならiCloud+の中でアドレスを作り、転送はAppleに任せ、不要になったものだけ止められる。その程度の手軽さで使えるところが自分には合っている。
private.icloud.com のままなら、代替サービスへ移るつもりだった
6月の発表を見たあと、Hide My Emailの代わりになりそうなサービスも調べた。私が欲しいのは、サービスごとにアドレスを作れて、不要になれば個別に止められるものだ。そのうえで、エイリアスを使っていることをドメインだけで簡単に判別されない方がいい。
候補をその条件で見ると、次のようになる。
| サービス | エイリアス作成 | 個別に無効化 | 独自ドメイン | 私が気にした点 |
|---|---|---|---|---|
| SimpleLogin / Proton Pass | ○ | ○ | ○ | 共用ドメインではエイリアス利用を判別されやすい。独自ドメインなら避けやすい |
| addy.io | ○ | ○ | ○ | 独自ドメインを使えばサービス固有ドメインを避けられる |
| DuckDuckGo Email Protection | ○ | ○ | × | @duck.com なので今回と同じように専用ドメインだと分かる |
| Firefox Relay | ○ | ○ | ×（*.mozmail.com の専用サブドメインは利用可） | @mozmail.com 系なのでrelay用アドレスと判別されやすい |
| Fastmail Masked Email | ○ | ○ | ○ | 通常メールにも使われる @fastmail.com をMasked Emailに利用できる |
SimpleLogin | Open source anonymous email service
With email aliases , you can be anonymous online and protect your inbox against spams and phishing.
https://simplelogin.io/
Free, Open-source Anonymous Email Forwarding | addy.io
Create unlimited email aliases for free. Protect your real email from spam by using a different address for each service. Privacy friendly, anonymous replies.
https://addy.io/
Masked Email
A Masked Email address is a unique, automatically generated email address that can be used in place of your real email address.Masked Email addresses are especially useful when you need to sign up ...
https://www.fastmail.help/hc/en-us/articles/4406536368911-Masked-Email
DuckDuckGo Email ProtectionやFirefox Relayでも、サービスごとに別アドレスを作って転送するという目的は満たせる。ただ、私がHide My Emailから移行しようとしていた理由は、専用ドメインで簡単に判別されることだった。@duck.com や @mozmail.com 系へ移ると、その点では同じ問題が残る。
SimpleLoginやaddy.ioなら独自ドメインを持ち込めるため、サービス固有のドメインを避けられる。ただ、その場合は自分でドメインとDNSを管理することになるので、Hide My Emailで気に入っていた手軽さからは少し離れる。
FastmailのMasked Emailは候補としてかなり気になった。通常メールにも使われる @fastmail.com をMasked Emailに使えるので、Hide My Emailが @icloud.com を使う状態に比較的近い。独自ドメインにも対応しているため、Appleが方針を戻さなければ、このあたりを中心に移行先を選んでいたと思う。
移行しなくて済んだのが一番嬉しい
8月24日の発表を見て、まず安心したのは代替サービスへの移行を考えなくてよくなったことだった。
もし @private.icloud.com への移行がそのまま実施されていたら、私はHide My Emailを今までのようには使わず、別のサービスへ移るつもりだった。代替候補はあるものの、独自ドメインを管理するのか、Fastmailのようにメール環境ごと移すのか、といった別の判断も必要になる。
今回の撤回で、今後も必要なときに @icloud.com のアドレスを作り、登録先ごとに分けて使える。私がHide My Emailを使っていた理由がそのまま残ったので、今回は素直に嬉しい変更だった。
