Gmailの迷惑メール判定：送信者が制御できる範囲

よくある原因

認証やアライメントがストリームと一致しない

SPFがバウンス用ドメインで合格しても、DKIMは別のドメインで署名していることがあります。DMARCが合格するのは、認証済みの識別子の少なくとも1つが表示上のFromドメインとアライメントしている場合だけです。これはRFC 9989の4.4節（識別子のアライメント）と4.1節（DMARCの合格条件）に規定されています（RFC 9989）。転送経路によってSPFの挙動が変わることもあります。公開レコードが送信内容どおりだと決めつけず、実際に届いたメッセージを診断してください。

受信者が迷惑メールとして報告する

Googleの現在のガイダンスは、迷惑メール率を0.10%未満に保つよう推奨し、0.30%以上に達しないよう求めています。FAQでは、24時間に個人用Gmailアカウントへ約5,000件以上のメッセージを送る主要ドメインを一括送信者と定義し、一度その分類になると期限切れにならないとしています（Googleの送信者ガイドラインFAQ）。これらはGoogleの基準で、インターネット共通の上限ではありません。

レピュテーションや送信量が急に変わる

新しいドメイン、新しいIP、休眠リスト、送信量の急増、想定外のトラフィック発生源は、Gmailが見る証拠を変えます。認証情報の漏えいでも同じパターンが生じます。誰が、どのシステムから、どんな権限で送ったかを確認する前に、送信量を減らすことを修正と見なさないでください。

同意、登録解除、ターゲティングが不十分

メッセージを予期していなかった受信者ほど、迷惑メールとして報告しがちです。Googleは現行のガイドラインで、一括送信者のマーケティングメールと登録型メールにワンクリックでの登録解除を求め、登録解除の依頼に速やかに応じることを求めています。ストリームを使い回すためだけに、トランザクションメールへ無関係な宣伝内容を詰め込むべきではありません。

内容やリンク先が送信者の身元と矛盾する

誤解を招く表示名、表示上の送信者と無関係なリンク先ドメイン、短縮URL、添付ファイルの多い一斉送信、他組織を装うメッセージは、認証に合格していてもリスクになります。禁止ワードの信頼できるリストはありません。依頼内容とリンク先の全体を評価してください。

原因の診断方法

再現できる証拠から始めます。

何かを変える前に、手順を順番に実行します。

1. 影響を受けた範囲を特定する

表示上のFromドメイン、キャンペーンまたはメッセージの種類、送信システム、期間、Gmail宛てのおおよその送信量、観察された結果を記録します。公開されている一括送信者の基準は個人用Gmailアカウントが対象なので、個人用Gmailの受信者とGoogle Workspaceの受信者を分けます。共有メモでは、受信者のアドレスと本文を伏せてください。

2. 代表的な受信メッセージを一通調べる

迷惑メールに入ったメッセージの生のヘッダーを取得します。受信側が付加したAuthentication-Results、DKIM-Signature、Return-Path、関連するReceivedフィールドを読みます。RFC 8601の1.2節は、認証ヘッダーが意味を持つのは受信側の信頼境界の内側だけだと警告しています。送信者が挿入した似たフィールドを信用しないでください（RFC 8601、1.2節）。Palisadeのメールヘッダー解析ツールで、入手したヘッダーを解析できます。ただし、Gmailの非公開スコアは表示できません。

3. Google Postmasterの証拠を比較する

十分なトラフィックがあるドメインについて、Googleは迷惑メール率、IPとドメインのレピュテーション、認証、暗号化、配信エラーのダッシュボードを公開しています（Postmaster Toolsのダッシュボードの定義）。問題の期間を通常時の基準と比べます。データがない場合、ドメインがダッシュボードのデータしきい値に達していない可能性があります。問題なしという結果とは限りません。

4. 変更と未承認の送信元をたどる

デプロイ、リストの入手元、送信ドメイン、IP、認証、送信量の変更を、最初に影響が出た時刻と照らし合わせます。DMARC集計レポートのデータで、Fromドメインを使う想定外の送信元を探します。認証情報のローテーションやDNSの編集の前に、時系列を記録しておきます。

5. 原因を一文にまとめる

反証できる文を書きます。例：「news.exampleストリームのGmail受信者は8月19日に8,000人から42,000人に増え、Postmasterの迷惑メール率は0.04%から0.20%に上がった」。ダッシュボードの期間に、配信された48,000通に対してユーザー報告が96件あれば、具体的な計算は96 / 48,000 x 100 = 0.20%です。ダッシュボードが公開していない件数を作り出さず、ダッシュボード自身の定義を使ってください。

修正方法

実際の送信元で認証を修正する

届いたメッセージの認証が失敗している、またはアライメントしていない場合は、承認済みの送信元、Return-Path、DKIM署名の設定を修正します。DNSと署名の手順はGmail向けのメール認証をご覧ください。無関係な識別子を合格させるためだけに、DMARCポリシーを緩めないでください。

不要・不明なトラフィックを止める

侵害された送信元や未承認の送信元を停止し、該当する認証情報を正規の管理者を通じてローテーションし、同意を証明できない受信者を削除します。本番システムを変更する前に、ログを保全し、ロールバックの手段を用意します。

予測可能な配信登録の運用に戻す

トランザクションとマーケティングの目的を分け、送信者の身元を明確にし、登録解除に応じます。根本にあるリストと権限の問題を直す間は、送信量の急な変化を抑えます。送信量を減らしても、有効な同意の代わりにはなりません。

誤解を招く内容やリンク先を正す

受信者が認識し確認できるドメインとリンクを使います。不当に急がせる表現をなくし、実際のリンク先を隠さないでください。侵害された送信元やアライメントの不一致を残したまま、文面をやみくもに書き換えないでください。

修正の検証方法

影響を受けた送信経路を、同じFromドメイン、メッセージの種類、認証経路、比較可能なGmailの受信者層で再現します。まず新しいヘッダーの結果を確認します。次に、適切な送信量と期間で、Postmasterの認証、迷惑メール率、レピュテーション、配信エラーの証拠を見ます。Googleは共通の回復期間を公開していないため、日数を約束せず、観察結果と日付を報告します。

公正な再テストでは、診断した原因を1つだけ変えます。SPFやDKIMがアライメントしても振り分けが改善しない場合は、認証の修正を残したまま、同意、レピュテーション、トラフィック発生源、内容の証拠を調べ続けます。別の層にまだ作業が必要だからといって、有効なセキュリティ対策を元に戻さないでください。

修正の過程で、承認済みの送信元と不明な送信元がいくつもドメインを使っているとわかった場合、PalisadeのDMARC Agentは、それらのストリームにわたるDMARC集計レポートの証拠を整理できます。Smart DNS Deploymentが書き込めるのは、人が承認したDNS変更だけです。Gmailの非公開の分類器を明らかにしたり、受信トレイへの到達を保証したりはできません。同一経路での再テストで、残る課題が送信元をまたいだ監視だとわかったら、Palisadeを始めましょう。

この手順が当てはまらない場合

この手順は、一般ユーザーが自分の受信トレイを学習させる場合、送信者側にアクセスできないまま一通のメッセージが見つからない場合、プロモーションへの振り分けには当てはまりません。Gmailの非公開モデルの説明や、特定のフォルダへの振り分けの保証もできません。SMTPで明確に拒否された場合は、迷惑メール振り分けの手順を使う前に、その拡張ステータスコードから診断してください。

根拠

出典と参考資料

• Googleのメール送信者のガイドライン
• Googleの送信者ガイドラインFAQ
• Google Postmaster Toolsダッシュボード
• RFC 9989、DMARC
• RFC 8601、Authentication-Results