受信メールに別名を示す手掛かりが見当たらず、対応済みか判断できないことがあります。
結論：$maskedemailはRFC 9979が定める提示用のマークとして扱い、サーバーの対応、マークの有無、画面表示を分けて検証してください。
メールクライアントの開発者は、IMAP・JMAPでマークをどう読み取り表示するかを確認したい方に向いています。
QA担当者は複数の受信条件を使った試験設計に、長期のメール利用者はマークが示す範囲の理解に役立ちます。
最終更新：2026年11月13日。RFC 9979の原文とIANAのIMAP・JMAPキーワード登録を確認しています。
RFC 9979の$maskedemailに対するクライアント互換性を設計する
RFC 9979の定義では、$maskedemailはメールが特定の相手向けに用意された非公開アドレスを経由して受信されたことを示すヒントです。標準が定めるマークの意味と、個々のサーバーやクライアントが実際に対応しているかは別の確認事項です。
このマークだけから、別名が作成された、送信者が認証された、あるいは利用者の匿名性が保証されたとは判断できません。マークがある場合に説明できるのは、別名経由で受信したことを示す手掛かりがメールに付いている、という範囲です。
開発担当は、プロトコルごとの読み取り地点を確認する
IMAPでは、サーバーがメッセージに付けるキーワードやフラグの扱いを確認します。RFC 9051のIMAP仕様とIANAの登録情報を参照し、クライアントがキーワードを取得しても、独自に意味を拡張していないかを確認してください。
JMAPでは、メールのキーワードを扱う処理と画面表示を切り分けます。RFC 8621のJMAP Email仕様を確認し、試験環境で取得できた値が、対象メールの表示まで正しく結び付いているかを記録します。プロトコルの仕様に値が存在することだけでは、利用中のサーバーがその値を提供する証拠にはなりません。
実装の見通しを立てる際は、次の対照表で「何を確かめるか」と「そこから何を判断できるか」を分けます。
| 選択肢・試験対象 | 確認すること | 判断できる範囲 |
|---|---|---|
| IMAPクライアント | 取得したキーワード、メールとの対応、画面表示 | マークの読取と提示の動作 |
| JMAPクライアント | Emailのキーワード値、対象メールとの対応、表示 | JMAP経路での読取と提示の動作 |
| マークのないメール | サーバーの対応状況と試験条件 | 欠落の理由。受信アドレスの有効性ではありません |
| 通常アドレス宛てのメール | 対象アドレスと実際の試験データ | 表示が別名経由の手掛かりを誤って付けていないか |
サーバー担当は、付与条件を試験環境ごとに記録する
RFCの定義と、各サーバーの実装・設定は同じではありません。メールサービスが関連するメッセージにマークを付けるかは、対象の環境と設定を使って確かめます。別の環境でマークが見つかったという結果を、すべてのサーバーに当てはめないことが大切です。
記録には、サーバーとクライアントの識別情報、利用プロトコル、試験に使ったアドレスの用途、受信メールのマークの有無を含めます。特定サービスの実装について確認できる資料や試験結果がない場合は、「未対応」ではなく「未確認」とします。
QA担当は、受信条件を分けて互換性を検証する
一つのメールだけで判定せず、入力条件を分けて試験します。次の順序なら、サーバー側の付与とクライアント側の表示を切り分けやすくなります。
- 環境を固定する： クライアント、サーバー、プロトコル、利用アドレスを記録します。
- マーク付きメールを用意する：
$maskedemailが実際に付いたメールを受信し、画面上の対象メールと一致するか確認します。 - マークのないメールを用意する： 同じ経路で値がないメールを受信し、別名利用を示す表示が誤って出ないか確認します。
- 通常アドレス宛てを確認する： 受信先の用途と表示が食い違わないかを調べます。
- プロトコル上の値を照合する： IMAPまたはJMAPで取得した内容と、画面の表示を比べます。
- 結果を分類する： 「サーバーが付与」「クライアントが読取」「画面が表示」の各段階を分け、欠けた段階を記録します。
マークが見つからない場合は、サーバーの提供状況と試験条件を確認してから、クライアントの不具合かどうかを判断します。認証情報やアドレスの実在性が疑われる場合も、このマーク単独では裏付けになりません。
製品担当は、利用者に伝える意味を限定する
画面に表示する場合は、「別名経由のメールを示す手掛かり」のように、観測できた情報だけを伝えます。「漏えいした」「安全が保証されている」といった、マークから導けない説明は避けます。RFCが定める提示用マークを、すべてのクライアントで必ず同じ場所に表示する要件として扱う必要もありません。
製品に別名の停止機能がある場合は、その操作がマークの読取とは独立して動くかを別途検証します。$maskedemailが見えたことを理由に自動でアドレスを停止する設計は、標準の意味からは導けません。
リリース担当は、判定記録を残して再試験する
リリース前の記録には、クライアント、プロトコル、サーバーの対応状況、マークの読取結果、画面の結果を残します。また、「標準で定義されていること」「製品が実装していること」「試験で確認できたこと」を別々に書けば、後から対応範囲を誤解しにくくなります。
プロトコルやサーバーの実装、クライアントの表示処理に変更があった場合は、同じ受信条件を使って再試験します。ひとつの環境でマークが見えた、または見えなかったという結果だけで、互換性全体を判定しないようにします。
FAQ：表示と試験の境界を確認する
RFC 9979の$maskedemailは、何を示しますか？
特定の相手向けに用意された非公開アドレスを経由してメールを受信したことを示すヒントです。別名の作成、送信者認証、匿名性の保証とは区別します。
クライアントは必ず表示しなければなりませんか？
一律の画面表示を前提にせず、読取の可否と製品の表示方針を別々に確認します。表示文言も、マークの意味を超える断定を避けます。
サーバーがマークを提供しない場合はどうしますか？
欠落を受信先の無効と決めつけず、サーバーの対応状況と試験条件を確認します。判断できない段階は「未確認」として記録します。
IMAP・JMAPクライアントの検証では何を比べますか？
マーク付き、マークなし、通常アドレス宛てのメールを使い、プロトコル上の値、対象メール、画面表示を照合します。利用環境と結果も残します。
長期の別名運用は、マークとは別の機能として選ぶ
$maskedemailは別名経由を示すヒントであり、別名の作成・転送・停止を提供する機能ではありません。まずメール別名と使い捨てアドレスの違いを確認し、長期利用では別名を終了・整理する際の確認事項も参考にしてください。
一時的な登録や確認メールの受信先を探している場合は、InboxCloakの案内で現在の提供内容を確認できます。RFC 9979への対応や特定の受信機能を前提にせず、長く受信を続けたい用途と、その場限りの用途を分けて選ぶのが確実です。
よくある質問
RFC 9979の$maskedemailは、メールについて何を示しますか？
$maskedemailは、そのメールが特定の相手向けに用意された非公開アドレスを経由して受信されたことを示すヒントです。RFC 9979では提示用のマークとして登録されています。別名を作成したり、送信者を認証したり、匿名性や安全性を保証したりする機能ではありません。
メールクライアントは$maskedemailを必ず画面に表示する必要がありますか？
必ず同じ場所や形式で表示する、という一律の画面要件として扱うべきではありません。クライアントはマークを読み取れるか、利用者に役立つ表示にするかを製品の設計に沿って決めます。表示する場合も、別名経由の手掛かりであることを超えて、漏えいや安全性を断定しない文言にします。
サーバーから$maskedemailが届かない場合、クライアントはどう扱えばよいですか？
マークが見えないだけで、受信アドレスが無効だと結論づけないでください。サーバーやプロトコル経路がマークを提供しているかを先に調べ、通常の受信とマーク付き受信を分けて記録します。対応状況が不明なら未確認として扱い、画面上でも別名利用の有無を断定しない設計にします。
IMAPやJMAPのクライアントで別名マークをどう検証しますか？
同じ試験環境で、マーク付きメール、マークなしメール、通常アドレス宛てのメールをそれぞれ用意し、プロトコル上の値と画面表示を照合します。利用したクライアント、サーバー、プロトコル、マークの読取結果も記録します。試験環境がマークを提供しない場合は、その結果を未対応の証拠と混同しないことが重要です。
必要な手がかりだけを持って、ツールに戻る
受信トレイに戻って実際のメールを確認してください。まだ届いていない場合は、個別の診断チェックリストを順に確認すれば十分です。画面全体を再び撮影する必要はありません。