Googleの2024年2月1日からの新しいメールセキュリティポリシーについて

Googleが段階的に上げてきたメールセキュリティポリシー

2023年11月10日作成
2024年1月25日更新
著者: 竹洞 陽一郎

Googleは2024年2月1日から、Gmailアカウントへのメール送信者に対して新しいセキュリティ要件を導入します。
これらの変更は、メールの送信者が従うべき特定のガイドラインを含んでおり、メールの安全と透明性を高めることを目的としています。

対象

Gmailが対象です。
Gmailは個人が幅広く利用しています。
ですから、B2Cのビジネスをされていると影響があります。

Gmail

Gmailは、個人のメールアドレスとして、現在幅広く多くの人々に利用されています。
B2Cのビジネスをされているのであれば、今回の新しいメールセキュリティポリシーを理解して、しっかりと対応する必要があります。

Google Workspace(※)

Google Workspaceは、Microsoft365と並んで、企業や大学などで幅広く使われているサービスです。
B2Bのビジネスをされているのであれば、今回の新しいメールセキュリティポリシーを理解して、しっかりと対応する必要があります。

※ 2023年12月に更新されたEmail sender guidelines FAQで、Google Workspaceが除外となりました。

ポリシー基準引き上げの背景

最近のGoogleのメールセキュリティポリシーの強化に対する疑問の声がある中、この動きの背景を理解することが不可欠です。

全てのサイバー攻撃の91%はメールから始まる

全てのサイバー攻撃の91%は、メールを起点としていることが調査によって判明しています。
91% of all cyber attacks begin with a phishing email to an unexpected victim

攻撃は、セキュリティ知識をあまり持っていない、対策していない個人や中小企業からスタートする

攻撃の対象は、手っ取り早く利益が得られる個人を対象としたものから、大規模な企業を対象としたものまで、様々にあります。
攻撃者は、最終的な攻撃対象が大企業であっても、最初から大企業に対して攻撃するわけではありません。
セキュリティの知識があまりない個人や、対策に費用が欠けられない中小企業から開始し、人間関係やサプライチェーンを辿っていきます。
したがって、個人ユーザー向けのGmailなどのセキュリティを強化することは、社会全体にとって有益です。

攻撃そのものが検知できなくなりつつある

従来のマルウェア感染のような「外部からのファイルの持ち込みを検知できる」侵害から、Living off the Land攻撃のように、「外部からファイルを持ち込まず、既にシステム内にあるツールを駆使して活動を行う」攻撃へとシフトしつつあります。
これは、攻撃者側がOPSEC(Operation Security: 作戦保全)対策を行うようになってきており、企業のセキュリティ担当者に自身の意図や活動を推測するのを防ぐようになってきていることも影響しています。
メール経由の攻撃をSPF、DKIM、DMARCなどの認証システムで防ぐことは、これらの進化する脅威から社会を守る上で重要です。

新しいメールセキュリティポリシーにおける対応のポイント

新しいメールセキュリティポリシーは、全てのメール送信者に適用されます。
Gmail/Google Workspaceのアカウントに対して1日に5,000通以上のメールを送信する場合、このポリシーに基づき、追加的な対応措置を講じる必要があります。

大量送信者とは？

大量送信者とは、24時間以内に個人のGmailアカウントへ5,000件近く、またはそれ以上のメッセージを送信するメール送信者のことを指します。
同じ主ドメインから送信されるメッセージは、5,000件の制限に含まれます。

送信ドメインとは？

5,000件のメッセージ制限を計算する際には、同じ主ドメインから送信された全てのメッセージをカウントします。
例えば、毎日solarmora.comから2,500件のメッセージとpromotions.solarmora.comから2,500件のメッセージを個人のGmailアカウントに送信する場合、全ての5,000件のメッセージが同じ主ドメインsolarmora.comから送信されたため、あなたは大量送信者とみなされます。

上記の基準を少なくとも一度満たした送信者は、永久に大量送信者と見なされます。

1日あたり5,000通を計算する方法

1日あたりの以下のメール通数の総計です。

結構見逃しているのが、なりすましメールの総数と、転送メールの総数、なりすましメールの転送総数です。

転送メール

計算する際に、見落としてしまいそうなのが、転送メールです。
転送メールは、Fromアドレスは、御社のメールアドレスです。
ですから、DMARCレポートでは、転送メールは、きちんとレポートされ、そしてメール通数としてカウントされます。
転送メールを合格させるために、DKIMやARCが必要なのです。

なりすましメール

SPFの仕様上、同じ環境のMTA(GmailやMicrosoft365、各種SaaS、同居しているレンタルサーバ)からなりすましメールを出されると、正規のメールと見なされます。
これを防ぐには、DKIMも実装し、DMARCのアライメントをSPF、DKIM、双方一致させて、DMARCに合格させて、p=rejectで排除する必要があります。
p=quarantineだと、なりすましメールの送信数は大して減りません。

勝手につくられたサブドメインでのなりすましメール

SPF、DKIMの単体仕様での運用の場合、これらは、APEXに設定したものが、サブドメインに自動継承されません。
ですから、DMARCを設定していないドメインは、結構な確率で、勝手にサブドメインをつけたなりすましメールを出されています。
(安心して下さい、PowerDMARCなら自動検出して、一覧表に出してくれます！)
これを防ぐには、DMARCを実装し、存在しないサブドメインについてSPFやDKIMが無い場合に明確に不合格・不一致にする必要があります。

なりすましメールの転送

なりすましメールの転送数も、1日あたりのメールの通数にカウントされます。
Fromアドレスは、御社のドメインですから。

DKIMリプレイ攻撃

DKIMリプレイ攻撃は、なりすましメールの転送を応用した攻撃です。
多くの企業でDKIMリプレイ攻撃を検出しており、正規のDKIM署名がついているため、DMARC検査では合格になります。
RUAレポートを定常的に分析し、ダークWebで自社のメールアドレスなどが売買されていないか、監視する必要があります。

転職エージェントやショッピングモールなどの転送メール

転職エージェント会社が、御社のメールを転送、もしくはメールアドレスをそのまま使ってメールを送っているのを多数検出しています。
ショッピングモールも、御社のメールを転送、もしくはメールアドレスをそのまま使ってメールを送っているのを多数検出しています。
そういう、なりすましではないけど、なりすましに近い、もしくは転送されているメールについて、送っている企業とその総数を把握する必要があります。

これら全てをDMARCを設定してRUAレポートを受信することで把握可能です。
ただし、全てのMTAがRUAレポートを送ってくるわけではありません。
B2Cの場合、RUAレポートで把握できるメール通数は、実際のメール送信数の1/4～1/2程度になるでしょう。

Gmail宛てメール送信者に求められる要件の概要表

全てのメール送信者に適応される要件

送信するメールの通数に関係なく、全てのメール送信者に求められる要件について解説します。

ドメイン用のSPFまたはDKIMメール認証を設定する

SPFとDKIMの基本

SPF（Sender Policy Framework）は、自ドメイン名義のメールを送信するメールサーバのIPやホスト名をDNSに登録する仕様です。
一方、DKIM（DomainKeys Identified Mail）は、自ドメイン名義のメールの真正性を電子署名によって確認できる仕様です。
これらにより、メールが正規の送信者から来ていることが確認されます。

SPF、DKIM、DMARCの組み合わせの重要性

要件としては、「SPFまたはDKIM」と書いてありますが、実際の運用では、SPF/DKIM/DMARCまで実装することをお勧めします。
理由は、スパム率0.3%の制限に影響があるからです。

DKIMをすぐに実装できない場合の対策

現在利用しているMTA（Mail Transfer Agent）やメールサービス、レンタルサーバなどがDKIMにすぐに対応できない場合、セキュアメールゲートウェイ（SMTPリレーサーバ）を利用することで対応が可能です。
後述するSTARTTLSに対応できない場合にも利用できます。

推奨されるセキュアメールゲートウェイは、SPFのReturn-Path、DKIMの対応サービス一覧をご確認下さい。

送信ドメインやIPアドレスの有効なフォワードおよびリバースDNSレコード（PTRレコードとも呼ばれる）の確保

PTRレコードとは

PTRレコード、またはポインターレコードは、IPアドレスからホスト名への逆引き（逆引きDNS）を可能にするDNS（ドメインネームシステム）の一部です。
これは、特定のIPアドレスがどのホスト名に関連しているかを示します。逆引きによる検証プロセスはFCrDNS(Forward-confirmed reverse DNS)と呼ばれます。

PTRレコードの重要性

PTRレコードは特にメールサーバの信頼性を確認する際に重要で、メールが正当なソースから送信されたことを保証するのに役立ちます。
逆引きDNSレコードが不在または不正確である場合、メールがスパムと見なされるリスクが高まります。

FCrDNS検証と現代の課題

SPF仕様化前は、FCrDNS検証が一般的でした。
この検証は、ドメイン名の所有者とIPアドレスの所有者間の有効な関係を示す弱い認証形式を提供します。
スパマーやフィッシング攻撃者がこれを回避することは難しく、ホワイトリストの目的には十分な効果があります。

しかし、現代のクラウドやSaaS主体の環境ではFCrDNS検証はしばしば不適切です。
IPアドレスから導き出されるホスト名が異なるドメインに属しているか、PTRレコード自体が設定されていないことが多いためです。
このため、SPF/DKIM/DMARCによるドメイン認証の重要性が増しています。

Googleの指摘と現実的な解決策

Googleは、「送信IPアドレスは、PTRレコードで指定されたホスト名のIPアドレスと一致する必要がある」と指摘していますが、実際にはこの条件を満たす環境は限られています。そのため、SPF/DKIM/DMARCによる現代的なドメイン認証を活用することが現実的な解決策となります。

共有IPアドレスの問題点

共有IPアドレスは、複数のメール送信者によって利用されるIPアドレスです。これらの送信者の行動は、その共有IPアドレスの評判に影響を与え、配信率にも影響を及ぼす可能性があります。共有IPアドレスを使用する際は、そのIPがインターネットのブロックリストに載っていないかを確認する必要があります。

Googleは、共有IPアドレスの評判をPostmaster Toolsを通じて監視することを推奨しています。

TLS接続を使う

※2023年12月のEmail sender guidelinesの更新で追加されました。

STARTTLSとは

SMTPでの通信の暗号化には、STARTTLSというプロトコル拡張が使用されます。
これは、非暗号化の通信プロトコルにセキュリティ層を追加するものです。
SMTPにおけるSTARTTLSの詳細は、2002年に公開されたRFC3207に記載されています。

STARTTLSの基本的な動作

1. 接続の開始

クライアントはサーバに対して通常の非暗号化接続を開始します。

2. STARTTLSコマンドの使用

クライアントは、サーバにSTARTTLSコマンドを送信してセキュアな通信への移行を要求します。

3. TLSハンドシェイク

サーバがSTARTTLSをサポートしている場合、TLSハンドシェイクが開始されます。
この過程で、サーバはクライアントに対して証明書を提示し、両者は共有鍵を確立します。

4. 暗号化された通信

TLSハンドシェイクが完了すると、クライアントとサーバ間の通信は暗号化されます。
この段階から、データは盗聴や改竄から保護されます。

STARTTLSの利点と欠点

利点

• 既存プロトコルの拡張: 既存の非暗号化プロトコルを変更することなく、セキュリティを強化できます。
• 柔軟性: クライアントとサーバが暗号化をサポートしていない場合、通信は非暗号化のまま継続できます。

欠点

• ダウングレード攻撃のリスク: 攻撃者が通信中にSTARTTLSコマンドを削除または変更することで、通信を非暗号化の状態に強制することが可能です。
• 暗号化されない初期通信: 最初の接続とSTARTTLSコマンドの発行までは、通信は暗号化されていません。

STARTTLSのテスト

STARTTLSに対応済みかどうかのテストはコマンドラインやオンラインツールで出来ます。
オンラインツールであれば、SSL ToolsのSTARTTLS Testがお勧めです。
コマンドラインであれば、以下のように実行します。

openssl s_client -connect [ホスト名もしくはIPアドレス]:25 -starttls smtp

MTA-STSとの関連性

上述のように、STARTTLSは20年以上前の仕様で広く普及していますが、メール配送サービスやメルマガサービスの中には、実装していないMTAも存在します。
ダウングレード攻撃や初期通信の平文といった欠点を補うために、TLS通信を受信側MTAから強制化するMTA-STSという仕様があります。
GmailはMTA-STSに対応しており、このポリシーは、1月29日時点でenforce(強制)になっていることを確認済みです。

Postmaster Toolsで報告されるスパム率を0.3%以下に保つ

Google Postmaster Toolsにおけるスパム率の定義

SNSなどではDMARCの要件に注目が集まっていますが、より厳格な要件はPostmaster Toolsでのスパム率の維持です。Googleによると、「スパム率」とは、アクティブユーザの受信箱に届いたメールの中で、ユーザが手動でスパムとしてマークしたメールの割合を指します。

スパム率とは、アクティブユーザの受信箱に送信されたメールに対して、ユーザによってスパムとしてマークされたメールの割合です。 多くのメールが直接スパムフォルダーに配信される場合、ユーザが受信箱のメールをスパムとしてマークしていても、低いスパム率が示されることがあります。

スパム率の計算は、1日単位で計算されます。
2023年12月に更新されたEmail sender guidelines FAQで、以下のように記載されています。

スパム率は毎日計算されます。
メッセージが予想通りに配信されるように、送信者はスパム率を0.1%以下に保つべきであり、私たちのメール送信者ガイドラインで説明されているように、スパム率が0.3%以上になることを防ぐべきです。

この率がユーザの手動マーキングに基づくため、その維持は非常に重要です。

スパム率を低く保つための戦略

たとえば、1日にGmail/Google Workspaceへ10通のメールを送信して、そのうち1通が迷惑メールとしてマークされた場合、スパム率は10%になります。
300通送信し、1通がマークされると0.33%になります。
以下に、スパム率を低く保つための主要な対策を挙げます。

SPF/DKIM/DMARCの設定

これらを設定し、DMARCでp=quarantineかrejectにすることで、なりすましメールやスパムの送信を防ぎ、受信者に届かないようにします。

価値のあるメールを送信する

ユーザの判断が重要で、適切な宛先選定や内容の正確さが求められます。メールの誤送信による迷惑メールのマークを避けるため、内容は慎重に作成する必要があります。

不適切なメールアドレス宛に送信しない

クローリングで集めたアドレスや購入したアドレスなど、関係が構築されていない宛先へのメール送信は避けるべきです。営業メールの誤送信は迷惑メールとしてマークされる可能性が高いです。

これらの対策を講じることで、スパム率を低く保ち、効果的なメールマーケティングを実施することが可能です。

スパムと認定されないための推奨されるメール送信の実践

Googleは、「推奨されるメール送信の実践」と題して、以下の事項を推奨します。

SPFとDKIMを用いたメール認証

SPFとDKIMを用いてメールを認証し、これらが一致していることを確認します。
メール配信サービスやメルマガ配信サービスを使用する場合は、SPFとDKIMをサポートしているかを確認することが重要です。

同じIPアドレスの使用

理想的には、すべてのメッセージを同じIPアドレスから送信するようにします。
複数のIPアドレスから送信する必要がある場合は、メッセージの種類ごとに異なるIPアドレスを使用します。
例えば、アカウント通知の送信には一つのIPアドレスを、プロモーションメッセージの送信には別のIPアドレスを使用します。

「From:」メールアドレスの一貫性

同じカテゴリーのメッセージは、同じ「From:」メールアドレスを持つべきです。
例えば、solarmora.comというドメインからのメッセージは次のような「From:」アドレスを使うようにします。

• 販売受領メッセージ：sales@solarmora.com
• プロモーションメッセージ：deals@solarmora.com
• アカウント通知メッセージ：alert@solarmora.com

受信者のアドレス帳にメールアドレスを登録してもらう

受信者の連絡先にあるアドレスから送信されたメッセージは、スパムとしてマークされる可能性が低いです。
Gmailの場合、メールアドレスにマウスオーバーすると「連絡先に追加」というボタンがあるので、それで登録してもらうことで、スパムメールとマークされる可能性が下がります。

送信量を徐々に増やす

2000年頃には、SMTPで送信するメールの通数は徐々に増やすというベストプラクティスが確立していました。
これをSMTP Warmup(IP Warmup)と云います。
徐々にメール送信数を増やす理由は、迷惑メールを送ってくるIPアドレスは、いきなり大量のメールを送ってくるので、1時間とか1日あたりのメールの送信数で閾値を設けてブロックすることが主流だったからです。
もし、新規のIPアドレスから、大量配信を行う場合は、SMTP Warmupを行った方が無難でしょう。
メール送信数の増やし方は、50～100通/日からスタートして、7～10日かけて1,000通ぐらいまで増加させることが多いです。
MailReachのような商用サービスを利用するのも手です。
メール配信では、確実にバウンス処理ができるようにしましょう。
バウンスメールを受信するMXのMTAの設定を適切に設定できていなくて、バウンスメールを受信できない場合には、ドメインのレピュテーションが下がりメールが到達できなくなります。

メールをインターネットメッセージフォーマット標準（RFC5322）に従ってフォーマットする

インターネットメッセージフォーマット標準（RFC5322）は、メールのフォーマットを定義する規格です。
この標準はメールヘッダと本文の構造を規定し、メールの正しい解釈と送信のためのルールを設けています。

ヘッダフィールド

これには送信者、受信者、件名などの情報が含まれます。
各フィールドは特定の形式で書かれ、メールの配信や処理に重要な役割を果たします。

日付と時刻のフォーマット

メールが送信された日時が正確に記録されます。

メッセージID

各メールにはユニークな識別子が割り当てられ、追跡や参照が容易になります。

MIME（多目的インターネットメール拡張）

これにより、テキスト以外のコンテンツ（画像、音声、ビデオなど）をメールに含めることができます。

RFC 5322に準拠したメールフォーマットを使用することで、メールシステム間の互換性が保たれ、メールの配信がスムーズになります。
また、スパムフィルターや他の自動化されたメール処理システムによってメールが適切に処理される可能性が高まります。
なりすましメールやスパムメールは、RFC5322に準拠したフォーマットになっていないことが多いので、判定として使います。

正規のメールであっても、RFC5322に準拠していない場合があります。
自動返信システムや問い合わせフォームからの返信メールなど、メールヘッダの中身を確認し、規格に準拠していることを確認することが重要です。

Gmailの「From:」ヘッダを偽装しない

Gmailは、DMARC（Domain-based Message Authentication, Reporting, and Conformance）の隔離ポリシー（quarantine）の使用を計画しています。
これにより、「From:」ヘッダを偽装するとメール配信に影響が生じる可能性が高まります。
個人やフリーランスの方々、また企業も含め、Gmailのドメインのアドレスを使用してメールを送信する際には、実際に使用するメールアドレスを「From:」フィールドに正確に記載することが重要です。

DMARCとは

DMARCでは、「From:」アドレスのドメインがメールヘッダ内の「Return-Path」やDKIM署名のd=パラメータに指定されたドメイン名と異なる場合、これを「From:」アドレスの詐称と判断します。
この一致を「DMARC Alignment」と呼びます。

DMARCの影響

GmailがDMARCの隔離ポリシー（p=quarantine）を採用するということは、Fromアドレスの偽装がメールの配信を妨げる主要な要因になることを意味しています。
したがって、メール配信の信頼性を保つためには、「From:」ヘッダの正確な使用が不可欠です。

定期的にメールを転送する場合（メーリングリストやインバウンドゲートウェイを含む）、送信メールにARCヘッダを追加する

メールが定期的に転送される場合（メーリングリストやインバウンドゲートウェイを含む）、送信メールにARC (Authenticated Received Chain) ヘッダを追加することは非常に重要です。
ARCヘッダは、メッセージが転送されたことと転送者の身元を明確に示します。特にメーリングリストを運用する際は、「List-id:」ヘッダの追加も必要です。

ARCヘッダの重要性

• ARCヘッダは、メールの転送経路と認証情報を記録します。
• Google Groupsなどのサービスでは自動的にARCヘッダが付与されますが、自社で運用するメールサーバでは設定が必要です。
• ARCヘッダの追加は、特にスパムフィルタリングでの誤ブロックを防ぐのに役立ちます。

メール転送時のSPFとDKIMの検証問題

メール転送プロセスにおけるSPFやDKIMの検証問題を理解し、適切に対応することが重要です。

• メーリングリストのサーバがSPFレコードに含まれていない場合、SPF検証は通常失敗します。
• メール本文に変更がある場合、DKIMのハッシュ値が元のメッセージと一致しなくなり、DKIM検証も失敗します。

これらの問題を適切に理解し、メール転送時の信頼性と追跡可能性を高めるために対応することがメーリングリストの運用において重要です。

メーリングリストの送信者は、List-id:ヘッダを付与する

メーリングリストの運用者は、メーリングリストからの送信であることを明確にするために、List-id:ヘッダを付与しなくてはいけません。

1日あたり5,000通以上メールをGmail/Google Workspaceに送信する場合に適応される要件

1日あたり、Gmail/Google Workspaceに対して、5,000通以上メールを送信する場合、上記の要件に加えて、以下の要件が追加になります。

SPF/DKIM/DMARCの実装

SPF

自ドメイン名義のメールを送信するメールサーバのIPやホスト名をDNSに登録する仕様。

DKIM

自ドメイン名義のメールの真正性を電子署名によって確認する仕様。

DMARC

SPFとDKIMを補完する3つの機能について定めている仕様です。

• Fromアドレスの詐称を検出する
• Fromアドレスの詐称を検出した場合の処理を受信側MTAに指定する
• 受信側MTAから処理に関する統計レポートを受信する

これら全てを実装することが求められます。
DMARCについては、p=noneで構わないとされていますが、迷惑メール率0.3%の制限を考慮すると、p=quarantineもしくはrejectの設定が実質的に必要です。

ワンクリック配信停止リンクの要件

メールマーケティングにおいては、マーケティングメッセージや購読メッセージにワンクリック配信停止リンクの設置が非常に重要です。
多くのメールでは、Unsubscribe（配信停止）リンクが小さく記載されているのが一般的ですが、メール本文内に明確で目立つサイズで掲載する必要があります。
ユーザをWebサイトの個人設定画面に誘導し、ログイン後に配信停止設定をさせる方法は不適切です。

重要なのは、「ワンクリックでの配信停止」を可能にすることです。

この「ワンクリックでの配信停止」は、RFC2369とRFC8058の仕様があります。
RFC2369の仕様は、メーリングリストを対象としたものです。
それに対して、RFC8058は、もっと広範なメール配信リストに適用可能です。

Googleが求めている「ワンクリックでの配信停止」は、RFC8058に準拠した方法です。
RFC 8058は、電子メールのヘッダーに「List-Unsubscribe」と「List-Unsubscribe-Post」をという２つのヘッダを導入し、購読者が購読解除の意向を示すための新しいメカニズムを提供します。
メールクライアントがこのヘッダーを認識する実装がある場合、ボタンのクリック１つで購読を解除することができます。

List-Unsubscribeヘッダ

List-Unsubscribeには、1つのHTTPS URIが含まれていなければなりません。
このURIにリクエストが飛ぶことで、登録解除を実現するわけです。
HTTPSのURIとは別に、MAILTO:などの他の非HTTP/S URIを含めることもできます。

List-Unsubscribe-Postヘッダ

List-Unsubscribe-Postヘッダーには、「List-Unsubscribe=One-Click」という単一のキー/値のペアが含まれていなければなりません

List-UnsubscribeおよびList-Unsubscribe-Postヘッダーをカバーする有効なDKIMの署名がなければなりません。

これらを反映したメールヘッダは、以下のようになります。

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Resulting POST request

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

選択の自由とメールマーケティング

メールマーケティングにおいて、ユーザの「選択の自由」は非常に重要です。
例えば、商品購入や会員登録時にメールマガジン配信のためのチェックボックスをデフォルトでオンに設定するWebサイトは問題があります。

行動経済学によれば、個人が自ら選択した事柄は積極的に受け入れられ、自分の意志で選んでいないと感じるものには反発が生じる傾向があります。
そのため、自動的に登録されたメールマガジンは迷惑メールとしてマークされる危険が高まります。

人々は自分の選択に対する責任を好み、その選択が自らの意志に基づいていると感じる時に満足感を得ます。
逆に、選択が強制されたり限られていると感じると、不満や反発が生じます。
したがって、ユーザを自動的にメーリングリストに登録する手法は避け、ユーザに選択の自由を与えることが重要です。

考慮事項

Googleは、ホワイトリスト登録はしてくれない

メールプロバイダから、Googleに対して、ホワイトリスト登録を依頼しても、Googleは対応してくれないことを明記しています。
メールプロバイダは、Googleの新しいメールセキュリティポリシーに準拠することで、メールが到達するようになります。

サードパーティのメールプロバイダが対応すべきこと

メール配信サービスや、メルマガ配信サービスのようなサードパーティのメールプロバイダは、メール悪用報告のためのメールアドレス、abuseというアドレスを用意することが求められています。
これは、RFC2142で定められた、組織が一般的に用意しておくべきメールアドレス一覧に入っています。
abuse宛てに報告があったメールについて、適切に対処することが求められています。

アフェリエイトマーケティング

自社がアフィリエイトマーケティングプログラムを利用している場合には、注意が必要です。
アフェリエイトプログラムは、スパマーによって悪用される可能性があります。
利用しているアフェリエイトからスパムメールが出ている場合には、自社の通常のメールもスパムとしてマークされる可能性があります。

フィッシング演習

ドメインからテストフィッシングメッセージやテストキャンペーンを送信しないでください。
ドメインの評判が悪影響を受ける可能性があり、RBL/DNSBLに追加される可能性があります。

バウンスまたは拒否されたメールアドレスを修正する

バウンス(エラーによって届かない)メールや、受信拒否されたメールについて、適切に配信リストから削除しなくてはなりません。
そのようなメールを送り続けている場合は、レピュテーションが下がります。

適用スケジュール

1日あたり5,000通以上、Gmailに対してメール送信する大量配信者向けのポリシー適用は、少し緩和されて、以下のようにスケジュールが発表されました。

まとめ

2024年2月1日からのGoogleが始める新しいメールセキュリティポリシーは、実際は、皆さんが思っている以上に厳しい要件になっています。
早めに対応しないと、2月1日に間に合わない可能性が大きいです。
まずは、DMARCの実装を行い、RUAレポートの監査を開始することをお勧めします。
そうすれば、RUAレポートの監査で、どのサービスやメールサーバの設定がまずいのかが、明確に分かり、手が打てます。