2024 年 2 月以降の Gmail のメール送信者のガイドラインに沿うために開発本部でやったこと
はじめまして、開発本部でエンジニアをしている三木本です。
最近 Switch の名作『ゼルダの伝説 ブレス オブ ザ ワイルド』にハマっているのですが、発売がもう 7 年前だということを未だに信じられず、「信じられない…」と呟きながら日々を過ごす今日この頃です。
本記事では表題の通り、2024 年 2 月以降の Gmail のメール送信者のガイドラインに沿うためにスタディスト開発本部でやったことを紹介します。(執筆の 2024/2/2 時点)
メール送信者のガイドラインとは
Google からの発端のアナウンスはこちらで、公式のガイドラインはこちら、FAQ はこちらなのですが、公式の情報を踏まえての概要や具体的な対策については以下の日本語記事で詳しくまとめられています。
2023年10月3日、Googleはスパム対策強化のため、Gmailへ送るメールが満たすべき条件を2024年2月から厳しくすると発表しました。また米国Yahoo!も、2024年2月 第一四半期[1] から同様の対策を行うと発表しています。端的に言えば、この条件を満たさないと宛先にメールが届かなくなるという影響の大きな変更です。
「メール送信者のガイドライン」そのものについての詳しい説明は上記の記事に譲り、早速「スタディストではどうガイドラインと向き合い、何をやったか」を以降にまとめていきます。
ガイドラインの要件と自分達の現状の比較
「Gmail アカウントに 1 日あたり 5,000 件を超えるメールを送信する送信者」かどうか
この条件に当てはまるかどうかで要件の厳しさが変わってくるので、どの事業者もまずこの条件に自分達が当てはまるかを確認すると思います。
前提として、この「Gmail アカウント」には Google Workspace は含まれず、個人で gmail.com を使用してるアカウントへの送信が件数カウントの対象です。
スタディストの場合、主力プロダクトである Teachme Biz は Biz とその名にある通り toB がメインであり、プロダクトのメール送信で使っているドメインからは現状としては 5,000 件を超えて送信していない可能性はありました。
ただ、今後の急なガイドラインの変更に備えるという意味でも、今回のタイミングで「Gmail アカウントに 1 日あたり 5,000 件を超えるメールを送信する送信者」の要件は満たしておくに越したことはないだろう、という結論に至り、厳しい要件前提での対策の検討を進めました。
要件のうち対策が必要そうなものは何か
- Reverse DNS
- 送信時の TLS 接続
- RFC 5322 の準拠
- 送信元 From ドメインに gmail.com を使用しない
- メール再配送時の ARC ヘッダ付与
要件としてあがっているこれら 5 つについては、前述の記事で紹介されている方法を参考に調査して、特段対策は必要ないだろうことを確認しました。
- 送信ドメイン認証
- ワンクリックでの配信登録解除
- 迷惑メール率
この 3 つは対策が必要な可能性があったので、より詳細な調査と対策の実行を進めていきました。
3 つのそれぞれで要件を満たさない可能性があると判断した要素については以降の「主にやったこと」の中で言及していきます。
主にやったこと
送信ドメイン認証
調査
開発本部が管理している Teachme Biz のシステムメールについては、SPF と DKIM 認証は PASS していましたが、SPF の「送信元」、DKIM の「署名元」いずれもドメインが不一致で、DMARC が PASS する条件を満たしていませんでした。
理想としてはどちらもドメイン一致させたいところですが、プロダクトの運用に影響無くすぐ設定できそうだった DKIM の「署名元」のドメインを一致させる作業を進めることにし、それと合わせて DMARC の設定も無かったので DMARC レコードの追加をすることに決めました。
実作業
大きく分けると認証設定含め以下の実作業を行いました。それぞれについて以下詳細を紹介していきます。
- DKIM の「作成者署名」での設定
- DMARC のレコード追加
- 本番設定前のテスト環境の整備とテスト
- 本番設定後の動作確認
- DMARC レポートの読み解き
プロダクトからのメール送信には Amazon SES を使っており、AWS Console 上で DKIM の「第三者署名」の設定になってたのを「作成者署名」に変更するための設定有効化の操作をしたのが DKIM の本番環境での実作業でした。（ドメインの DNS には既に DKIM レコードは存在していたので、実作業としては本当に設定有効化のボタンをポチッと押すのみでした）
DMARC についてもシンプルに、内容としては p=none、 rua には DMARC レポートを受信したいメールアドレスを指定して Route53 で管理しているドメインの DNS にレコードを追加しました。
今までは本番環境とテスト環境でメール送信に使うドメインを分けていなかったので、今回を機にテスト環境のメール送信用のサブドメインを用意し、テスト環境で DNS 周りで同じ設定を再現してメールの送受信やドメイン認証に問題ないことを確認してから本番設定を行なったりもしました。
設定後は、実際に本番でプロダクトから送信されたメールの DMARC が Gmail 上で PASS してることや、 Postmaster Tools で DMARC の認証成功率が変化したこと、DMARC レポート も rua に設定したメールアドレスに届くことを確認できました。
DMARC レポートの内容は、こちらの記事 で紹介されている dmarc-visualizer をローカルにセットアップして、中身を確認しました。
最初はレポートの見方に戸惑い、メール転送時に発生する envelop の from の書き換えや転送に備えての arc の仕組みなど個人的に分かっておらず混乱してましたが、そこは知識をキャッチアップ、社内のメンバーに相談するにつれ懸念点もなくなっていきました。
迷惑メール率
調査
Postmaster Tools にて、迷惑メール率は普段は 0% だが一時的に 0.3% を超えたことがあったので、現状できる対策はないかを確認しました。
スタディストではプロダクトからメールを送るドメインとビジネスサイド(セールスやカスタマーサポート)からメールを送るドメインが一緒のため、どちらが迷惑メールになっているか分かりませんでした。そのため以下調査を行いました。
- Amazon SES での苦情率の確認
- Postmaster Tools にサブドメインも全て追加してそれぞれで迷惑メール率の確認
Gmail 以外からの迷惑メール報告を検知できる Amazon SES での苦情率は常に 0% だったので、プロダクト側からのメール送信起因では無い可能性は少し上がりました。
サブドメインでの迷惑メール率の変化は見受けられなかったので、サブドメイン経由でプロダクトかビジネスサイドかの原因の切り分けはできませんでした。
ビジネスサイドでのメール送信は管理本部が管理しているので、開発本部での調査内容は共有して、引き続き連携してメール送信における各種設定や運用など、対策できる点がないか調査中です。
実作業
設定の変更等の作業は今の所は行いませんでした。
配信停止
調査
アナウンスがあった当初は、「自分達がプロダクトから送信するメールはマーケティング/プロモーションメールではなくトランザクショナルメールのはずだが、安全に倒すならワンクリック登録解除を実装した方が良いか…？」と判断が難しい状態でした。
判断基準は Google のみぞ知るの状態でしたが、開発本部内での検討の結果「プロダクトからのメールが Gmail のプロモーションタブに自動振り分けされることがあればその時再検討しよう」と、年末の時点で特に対策はしないことに決めました。
少し不安が残る状態ではありましたが、年明けの FAQ での情報によると「(意訳) 要件を満たしておらずとも Gmail としてスパム判定することなどはしない」とのことだったので、今となっては対策無しの方針を継続する良い判断材料が増えました。
実作業
調査に記載した通り、ワンクリック登録解除等の実装作業は今の所は行いませんでした。
継続してやってること
以下の監視は週一の定例でザッと確認するようにしています。
状況が安定したり、監視を自動化できたら定例での確認も不要になるかなという見込みです。
最新情報監視
- 公式のガイドラインと FAQ の更新がないか（先に紹介したブログ記事で追記が無いかも参考に）
Postmaster Toolsの監視
- 送信ドメイン認証の成功率 (100% か)
- 迷惑メール率 (0% か)
- compliance status dashboard が追加されてないか (Googleによるとメール送信が要件に沿ってるかこのダッシュボードですぐ分かるようになるとのこと)
DMARCレポートの監視
- 認証結果がイレギュラーなメール送信がないか
迷惑メール報告対策
- 管理本部と連携して取れる対策を調査中
最後に: 取り組んでみての個人的な感想
送信ドメイン認証などは知識がほぼ無いところから対策の担当となりキャッチアップしたので大変ではありましたが、Web プロダクトにはまだ欠かせない「メール」についての知識を深められて、良い経験をさせてもらいました。
プライベートでも迷惑メールはいまだによく受信するし、その中にはなりすましや詐欺目的ではない通常の企業、サービスのメールも迷惑メールと見做されてることも見かけます。それらを自分が受信した時に、「メール送信ドメイン認証が出来ているのか」、「ワンクリック登録解除は実装されてるか」等をチェックすることができるようになったのは、エンジニアとして密かな喜びでした。
この Gmail の新ガイドラインへの対応を行なってた/行なってる方、そうでない方にも、この記事が何かしら役に立ててたら幸いです。
We’re hiring!
スタディストでは、“伝えることを、もっと簡単に” するために、一緒に働く仲間を探しています。
少しでも気になった方はお気軽にご連絡ください！
