2023/10 に発表された Gmail メール送信者のガイドライン変更 に関する話です。
日本では、こちらの IIJ のブログ記事が出たことで話題になりましたね。
ざっくりいうと、
- 2024/02 以降、Gmail（
Google Workspace を含む）のアカウントに対して 5,000 通／日以上のメールを送信する場合、SPF・DKIM・DMARC への対応が必須になる
という話です。
2023/12/04 追記（12/25 修正）：
Google から追加のアナウンス（FAQ）が公開され、Google Workspace アカウント宛てのメール送信は対象外であることが明記されました。
送信者のガイドラインは Google Workspace アカウントから送信されるメールにも適用されますか？
個人の Gmail アカウントにメールを送信する場合、Google Workspace ユーザーを含むすべての送信者がメール送信者のガイドラインの要件を満たしている必要があります。この要件は、Google Workspace の受信メールとドメイン内のメールには適用されません。
blastengine を有料プランで利用中のユーザには、すでにメールでアナウンスがあったのでご存知かと思います。
また、ガイドラインにはその他の注意事項もいくつか記されています。
この記事では、前述のガイドラインに沿った対応をする際のポイントについて 完全に個人の独断で 記していきます。
この記事では、SPF・DKIM・DMARC の設定方法そのものの解説は行いません。
お使いのメール送信サービスのマニュアルを確認するか、以下の Gmail（Google Workspace）ヘルプなどを参照してください。
- なりすまし、フィッシング、迷惑メールの防止を支援する（Google Workspace 管理者 ヘルプ）
いきなりまとめ
-
SPF・DKIM・DMARC レコードを設定したら、設定内容を必ずチェックする
- ツールを使って各レコードをチェックする
- 実際の環境で Gmail 宛て（あわせて他のメールサービス宛て）にメールを送信して SPF・DKIM・DMARC が PASS していることを確認する
- Postmaster Tools で監視する
- DMARC を「初手
p=none」のまま放置しない -
メールフォームを設置・運用している場合は、メールの送信形式と悪用に気を付ける
- RFC5322 に準拠する
- 迷惑メールの送信に悪用されないようにする
-
マーケティング目的のメールはワンクリックで配信停止できるようにする
-
List-Unsubscribe-Post・List-Unsubscribeヘッダを含めて送信する - その他の方法で受信者が容易に配信登録を解除できるようにする
-
SPF・DKIM・DMARC レコードを設定したら、設定内容を必ずチェックする
SPF・DKIM・DMARC の各レコードを登録したら、その内容が正しいことを必ずチェックします。
ツールを使って各レコードをチェックする
例えば、レコードのチェックには次のようなツールが利用可能です。
実行例：
spf 実行例：
個人的には、特に以下の点に注意が必要だと考えています。
SPF レコードの DNS ルックアップ回数超過
SPF では、送信者のドメイン認証を行う際、DNS への問い合わせ（ルックアップ）が 1 件につき 10 回までに制限されています（RFC7208）。
近年では、マーケティング目的のメールを専用のクラウドサービスを利用して送信するケースが多いですが、その場合 SPF レコードにincludeを使用して送信元を追加していく関係で、どうしてもルックアップ回数が多くなります。
加えて、そのようなメールサービスではincludeした先の SPF レコードの内容がたびたび変更されるため、月に 1 回など定期的にチェックしていないと、知らないうちにルックアップ回数が 10 を超えてしまっていることもあります。
また、ルックアップ回数が 10 を超えたからといって、直ちにすべての宛先でメールが届かなくなるとは限らないので、うっかりしていると気づかない可能性もあります。
1 つのドメインで複数のメール送信サービスを利用している場合は特に注意が必要です。
2,048 ビット（以上）の DKIM 公開鍵登録ミス
DNS のレコードに文字列を登録する際、1 つの文字列は 255 文字まで の制限があるケースが多いのですが、DKIM の公開鍵を（Base64 エンコーディングして）登録する場合 2,048 ビット鍵では 255 文字を超えてしまいます。
その場合、文字列を引用符で囲んで分割すれば良いのですが、単純にコピペする場合と比べるとコピペミスする可能性が高くなります。
2023/12/13 追記：
逆に、鍵生成に OpenDKIM を使う場合は最初から分割された書式で生成されるため、例えばお名前.com の DNS レコード設定など引用符も分割も不要な書式で登録すべきケースでは、引用符を除外して単一の文字列に変換する必要があります。
ツールでチェックしたら、実際に受信して確認する
実際に Gmail で受信し、メッセージのソースを表示 で SPF・DKIM・DMARC が PASS していることを確認します。
（あわせて他のメールサービスでも受信して確認します）
2023/12/13 追記：
DMARC については、ツールによるレコードのチェックは即時に実施可能ですが、実際にメールを送信して PASS の確認が可能になるまでには時間が掛かることがあります。
例えば、Gmail の場合はこちらの注意書きにあるように、SPF・DKIM レコード登録後 48 時間以上経過してからでないと DMARC の PASS 確認ができません。
（注意書きには「SPF・DKIM レコード登録後 48 時間以上経ってから DMARC レコードを登録するように」という趣旨の文章が書かれていますが、SPF・DKIM レコードと同じタイミングで DMARC レコードを登録してしまった場合も、PASS 確認ができるまでにタイムラグがあります）
DMARC を設定する前に、DKIM（DomainKeys Identified Mail）と SPF（Sender Policy Framework）を設定してください。DMARC を有効にする 48 時間以上に、DKIM と SPF でメールを認証している必要があります。
Postmaster Tools で監視する
SPF・DKIM・DMARC の運用を開始したら、Google の Postmaster Tools でメール送信状況を監視します。
迷惑メール率が 0.10% 未満に維持されることを目指すとともに、0.30% 以上の状態が継続的に発生しない ように注意します。
DMARC を「初手p=none」のまま放置しない
2023/12/13 追記：
この項目については 2024/02 時点で達成できている必要はありません が、今後の動向を考えると当然に意識しておく必要があります。
DMARC をp=noneで登録しても、「メールの送信が SPF または DKIM の指定に従っていなくても DMARC のチェックは PASS させる」 という意味ですので、受信者にとっては「DMARC レコードが登録されている」以上の（「信頼できる送信者である」と判断する上での）意味はありません。
そのため、2024/02 時点ではとりあえず Google が求める要件をパスしたとしても、それ以降も高い評価が維持されることは保証されません。
いずれ、DMARC 本来のチェックが機能するように p=quarantine（検疫）またはp=reject（拒否）を指定して、メールの送信が SPF・DKIM の指定に従っていない場合は検疫または拒否するポリシーに変更する 必要があります。
なお、その際「pctタグの値を0から100に徐々に上げていき、ポリシーどおりにチェックする割合を上げる」という方法が（仕組みの上では）可能になっていますが、
-
0の指定は Gmail では指定範囲外- どう解釈されるか不透明
-
1〜99の指定は受信側サーバで正しく使用されないケースがある
ため、実質的にpct=100以外の指定を取るのはリスクがある（想定どおりの動きにならない可能性がある）といえるでしょう。
このようなこともあり、現在ドラフト段階の DMARCbis ではpctタグの代わりにtタグが提案されているようです。
- DMARC の "pct" は DMARCbis で "t=" に置き換えられる（MailData ブログ）
メールフォームを設置・運用している場合は、メールの送信形式と悪用に気を付ける
ここからは SPF・DKIM・DMARC 必須化の話からは外れますが、メールの送信ドメインの評価を下げないようにしてメールの到達率を高い状態に保つための話です。
自社の Web サイトに問い合わせフォームを設置して登録された内容をメール送信している場合、送信内容が RFC5322 に準拠しているか（ヘッダなどの過不足がないか）に注意します。
さらに、
- Perl・PHP などのメール送信スクリプトが使用されている場合、フォーム以外からの送信に悪用されないようにする
- フォームからのメール送信が、いたずらや広告など別の目的に悪用されないようにする
- メール送信前に登録内容を適切にチェックする
- 場合によっては登録内容そのもののメール送信をやめる
- 登録者へのフィードバック機能は、登録者のメールアドレスを詐称される可能性が高いので、ログイン（認証）不要の Web ページには極力実装しない
- bot からの登録を防ぐために、reCaptcha（v3） や Turnstile などを組み込む
などの対策を講じます。
マーケティング目的のメールはワンクリックで配信停止できるようにする
前述のガイドラインにも記されているとおり、RFC2369・RFC8058 で規定されているList-Unsubscribe・List-Unsubscribe-Post両ヘッダをメールに組み込んで、ワンクリックで配信解除できるようにします。
または、その他の方法（仕組み）で受信者が容易に配信登録を解除できるようにします。
送信したメールが（受信者によって）迷惑メールとして報告されないようにするのが重要です。
その他
こちらも前述のガイドラインに記されているとおり、通知など他の目的のメールの本文にプロモーション目的の内容を含めないよう注意が必要です。
人によっては、メールのフッタに（本文とは無関係の）宣伝目的の文章や URL を常時含めて送信しているケースがありますが、そのようなことは送信者のドメインの評価を下げ、メールが正しく届かないリスクを上げるので、避けたほうが良いでしょう。
以上、対応のポイントについて記しました。
SPF のルックアップ回数にしても迷惑メール率にしてもそうですが、スポット的な対応だけではなく、継続的な監視や対応が必要ですね。
明日（2 日目）は satodaisuke さんです。
2023/12/04 追記：
同じチームのメンバーが、当 Advent Calendar に記事を投稿しました。
なお、blastengine の検証を実施したときの記事はこちらです。