Google, Yahoo の Sender Guidelines について

2023年11月07日火曜日

【この記事を書いた人】
今村侑輔

2015 年新卒入社。途中、2年ほど IIJ Europe に出向経験もあるが SMX の中の人として長年スパムメールと奮闘中。M3AAWG, JPAAWG にも参加し始め、メッセージングエンジニアとして頑張ってます。最近の趣味はぶらり都バス旅。

「Google, Yahoo の Sender Guidelines について」のイメージ

CONTENTS

2023年10月初旬、Google と米国 Yahoo! からとある衝撃的な発表があった。

要約すると、送信ドメイン認証に対応していないメールは受け取らない という内容である。

送信ドメイン認証(SPF, DKIM, DMARC) の普及や活用については世界各国で議論がされており、特に DMARC については RFC 公開されて今年で 8 年が経つが未だに日本国内における普及率が低い点が問題視されている。

引用：https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/datashu.html#f00277

送信ドメイン認証について

まずは、送信ドメイン認証について復習をしよう。
弊社の他のブログ “エンタープライズIT [COLUMNS]” でも送信ドメイン認証についての解説記事を公開しているが、改めて記載する。

SPF(Sender Policy Framework) は 2006年に RFC4408 として公開され、”ドメインオーナーがメールの送信元 IP アドレスなどを宣言することでメールの信頼性を担保する” 仕組みである。

現在、RFC4408 は廃止されており RFC7208 に更新されている

DKIM (DomainKey Identified Mail) はメール送信者がメールヘッダや本文に電子署名ならびに対応するレコードを公開し、メール受信者がそれらを評価することでなりすましや改ざんを防ぐ仕組みである。

DMARC (Domain-based Message Authentication, Reporting, and Conformance) は SPF, DKIM を元にした認証が失敗したメールの取り扱いについて、送信元が受信者に対して推奨アクションを宣言し受信者はそれを元にメールの取り扱いを決める仕組みである。またその認証結果を送信元にフィードバックする機能も規格されている。

組織 (ドメイン所有者) に求められる対応

今回の Google, 米国 Yahoo! の発表により、少なくとも Google や米国 Yahoo! 宛にメールを送信する必要がある場合、自組織がメール送信に用いるドメインについては送信ドメイン認証に対応しなければメールを受け取ってもらえなくなってしまう。

そのため、Google 宛に 5,000 通/日もメールを送信しないドメインについては SPF もしくは DKIM の対応をする必要があり、それ以上のメールを送信する場合は、SPF, DKIM, DMARC すべてに対応しなければならない。

今回、Google は 5,000 通/日というしきい値を設けてはいるが、このしきい値というのは多くのメール送信者にとってあまり大きな意味を持つしきい値ではなく、最終的にはすべての送信ドメイン認証に対応する必要が出てくるのであろう。

SPF については、メールの送信元となる IP をすべて洗い出し、精査し、レコードに羅列する。

DKIM については、そのドメインを使って送信される正規なメールのすべてに対して、公開鍵暗号方式による秘密鍵を用いて署名をし、署名の際に指定したセレクタに対応したレコードを公開する。

DMARC については、SPF, DKIM の検証結果を元に認証失敗したメールについて、受信者にどうして欲しいかをポリシーとして公開する。

3 行にまとめはしたが、実際に何をどうすればいいのだろうか。

例えばメール送信サーバをオンプレミスで実装している場合
- SPF 設定するために組織でどの IP アドレスからメールを送信しているかメール送信をしている部署にヒアリングをする
- DKIM 鍵署名をするために OpenDKIM 等の OSS で実装を進める
- DMARC 導入のために DMARC レコードを登録し、DMARC レポートを受信して解析をする

もし、読者が 1 から送信ドメイン認証を設定しなければならないのであれば、2024/02 までにすべての対応を終わらせるのは難しいだろう。

何をしたらいいかわからない、という方はひとまず DMARC レコード p=none を指定して公開し、レポートを受信して結果を眺めることをオススメする。
DMARC レポートの実態は xml ファイルなのでそのまま直接眺めることはオススメしない。
DMARC レポートを集計して可視化できるシステムで受信するように DMARC レコードを書こう。
間違っても、自分のアドレスや自社のメーリングリストを送信先に設定しないほうがよいだろう。

また、送信ドメイン認証を pass させるのが難しいとよく話題に上がるのが “転送メール” と “メーリングリスト” である。

今回は詳しくここに記載することはしないが、Google 宛に日々メールを転送するようなメール運用をしている場合、2024/02 までに運用の仕方を見直す必要があるだろう。

SMX でできること

例えばではあるが、弊社の法人向けメール SaaS である IIJセキュアMXサービスでは各種送信ドメイン認証への対応をできるだけ簡潔に設定できるような機能を提供している。

SPF
- メール送信に SecureMX を利用する場合、弊社管理の IP からインターネット宛にメール送信をするため、弊社管理のレコードを include すればよい
DKIM
- SPF と同じく、メール送信に SecureMX を利用する場合、弊社設備内で DKIM 署名をする設定を on/off ボタン 1つで設定可能となっている
DMARC
- DMARC レコードに設定する rua に弊社で準備したアドレスを設定することで、管理画面にて可視化された DMARC レポートの一覧ならびに集計データを参照可能となっている
- SPF, DKIM, DMARC の対応においてメールを送信した組織やプロバイダから送られてくる DMARC レポートを解析することは不可欠である

最後に

送信ドメイン認証は、自組織のドメインの価値/ブランドを守るためのものであると筆者は考えている。
“いままでは何もせずにメールを送れていたのに…” と考えるのではなく、”うちのドメインを守らなくては” という使命感を持って対応を進めていただきたいと思う。
また、今回の Guidelines 更新を受けて改めて、”自組織のドメインを使ってインターネットにメールを送信すること” が持つ責任について再考していただきたい。

【編集部より・2024/01/24追記】
送信ドメイン認証(SPF, DKIM, DMARC)の設定を進める中で、現在利用中のDNSサーバ(DNSサーバホスティングサービス)に送信ドメイン認証で必要なTXTレコードが記載できないという制限がある事が発覚するケースもあるようです。メールサーバだけでなく、DNSサーバの仕様にもご注意ください。
IIJが提供するDNSプラットフォームサービスは、TXTレコードの記載に対応しています。