Gmail Compliance status dashboardは送信ドメインの要件確認に使い、個々のテストメールの受信証明には使わないでください。今週のリリース判定では、ドメインの適合状況と、管理された受信先での実メール確認を別々の証拠として記録します。
対象は、自社製品から個人用Gmailアカウントへメールを送る独立開発者、QAエンジニア、メール基盤担当者、リリース責任者です。
第三者サービスへの一括登録ではなく、自社製品または許可を得た環境の検証を前提にします。
Gmail Compliance status dashboardで確認する範囲
このダッシュボードが示すのは、対象ドメインに関連する送信要件の適合状況です。Googleは、Compliance status dashboardの用途を、送信者が要件への適合状況を確認するためのものとして案内しています。これは、特定のメールが送信された、相手側に受け入れられた、あるいは受信箱に表示されたことを証明する機能ではありません。
まず、受信先が個人用GmailアカウントかGoogle Workspaceアカウントかを区別します。Googleの送信要件の適用範囲は個人用Gmailアカウント向けとして説明されており、Workspaceの受信結果まで同じ範囲で示すものではありません。
| 確認対象 | わかること | わからないこと | 判定上の評価 |
|---|---|---|---|
| Compliance status dashboard | 対象ドメインの関連要件の状態 | 個別メールの送信、受け入れ、受信箱への表示 | ドメイン確認に有効 |
| 受信先での実メール確認 | 対象メールがその受信先で読めるか | 他の受信者や別の送信条件での結果 | 個別テストの証拠として有効 |
| アプリケーションの送信記録 | アプリが送信処理を行った記録 | 受信側での受け入れや表示 | 送信処理の補助証拠 |
ダッシュボードでテストメールを受け取ったと証明できますか？
できません。ダッシュボードの結果はドメインの要件確認に使い、実際の受信については受信先を確認します。送信処理の記録だけで受信完了と判定しないことが重要です。
独立開発者の確認記録
個人用Gmail宛ての送信とWorkspace宛ての送信を同じ試験結果にまとめると、結論の適用範囲が曖昧になります。確認前に、送信ドメイン、メールの種類、受信先の種類を記録してください。
Googleの送信者向けガイドラインでは、送信者に適用される要件が示されています。一方で、すべてのテストケースに同じ条件を機械的に当てはめるのではなく、宛先と送信規模に応じて該当項目を読み分けます。
| 確認項目 | 実施内容 | 公開判定に残すもの |
|---|---|---|
| 宛先の範囲 | 個人用GmailかWorkspaceかを特定 | 試験対象の種類 |
| 送信主体 | 自社製品の送信ドメインとメール種別を記録 | ドメイン、通知・確認メールなどの区分 |
| 要件状況 | 対象ドメインの状態と該当する公式要件を確認 | 確認日、参照先、判定 |
| 実メール | 管理された受信先で内容と表示を確認 | 対象アドレス、受信結果、確認内容 |
| 適用範囲 | その結果が何を証明するか明記 | 対象環境と未確認事項 |
Googleのガイドラインでは、個人用Gmail宛てに1日あたり5,000件以上を送る送信者を一括送信者として扱う条件が示されています。また、迷惑メール率は0.10%未満を保ち、0.30%に達しないようにすることが案内されています。これらは対象範囲や送信者の条件を踏まえて読むべき値であり、少数のQAメールの受信可否を直接判定するしきい値ではありません。公式ガイドラインの一括送信者と迷惑メール率の説明
メール基盤担当者の要件照合
基盤担当者は、ダッシュボードの表示だけで合格とせず、送信ドメインに関係する認証やその他の適用要件を公式ガイドラインと照らし合わせます。要件がどの送信者に適用されるかを確認し、対象外の条件をテストケースへ無理に持ち込まないでください。
Googleの送信要件に関するよくある質問も参照し、状態の意味や適用範囲が曖昧な場合は、推測で原因や合格条件を追加せず、公式説明に沿って記録します。送信ドメインの登録・確認に関する作業では、ドメイン設定の案内も確認先になります。
QAの受信確認
Gmailの送信要件を満たしているのに、テスト用アドレスでメールを確認できない場合はどうしますか？
まず、対象アドレス、送信したメールの種類、アプリ側の送信記録を確認します。そのうえで、管理された受信先で受信箱だけでなく迷惑メールなども調べ、メール本文が想定どおりか確認してください。要件の適合状態だけから、送信処理の失敗や受信側の振り分けを断定することはできません。
登録確認メールや通知メールの検証では、アプリが作ったメール、送信処理の記録、受信先に届いた実メールを結び付けます。受信先の用意や検証後の扱いを選ぶ際は、一時メールとメールエイリアスの違いも確認できます。実際の登録確認の流れを整理する場合は、登録後もメール確認が未完了になるケースも参考になります。
QAはドメイン適合と個別メールの受信をどう区別しますか？
前者は公式の状態表示と該当要件、後者は管理された受信先で確認したメールを証拠にします。宛先と本文、確認結果をひとまとまりで保存し、ダッシュボードの状態を個別メールの到達記録として扱わないでください。
リリース責任者の判定とチーム引き継ぎ
リリース責任者は「ドメイン要件の確認」と「アプリのメール機能確認」を別々の判定項目にします。片方の合格をもう片方の代わりにせず、公開記録には担当者、対象ドメイン、受信先の種類、確認した証拠、結論の適用範囲を記載します。
実務では、次の順に進めると証拠が混ざりません。
- テストが自社製品または許可を得た環境に限られていることを確認します。
- 送信ドメイン、メールの種類、受信先が個人用GmailかWorkspaceかを記録します。
- ダッシュボードで対象ドメインの状態を確認し、該当する公式要件と照合します。
- 自社アプリから対象メールを送信し、アプリ側の送信記録を保存します。
- 管理された受信先で実メールを探し、本文と宛先が試験内容に一致するか確認します。
- ドメインの確認結果と受信結果を別々に判定し、担当者と参照資料を記録します。
- 公式ガイドラインやダッシュボードの説明が更新された場合、適用要件を再確認します。
公開時の一文は、「この試験では、記録した送信ドメインの状態と、指定した受信先でのメール確認を別個に実施した」といった形にします。一度の受信結果を、すべての利用者や送信条件で届くという保証へ広げないことが、正確な引き継ぎにつながります。
まだ単一メールの受信証拠が不足しているなら、まずは管理されたテスト受信先で確認手順を整えます。公開用の個人アドレスを試験データに使いたくない場合、Fwdskyの一時メールも検証方法の候補です。ただし、受信結果は送信内容や受信側の条件に左右されるため、ドメイン状態の確認と実際のメール確認は分けて記録してください。