ＴＯＤＯ

以下の点で完成度が低いので限定公開です。

署名・検証フローの作図
ＡＲＣがどのようにＤＭＡＲＣの評価をひっくり返すロジック
署名等の段階でどのようなヘッダーが生成されるのかの説明
署名対象となるヘッダーの説明
各機能をどういう風に連結していくのか順番の明示
- ＭＴＡへの設定ファイルの書き方と担保方法

はじめに

２０２３年１１月、グーグル社より、メール送信認証強化のアナウンス¹²がありました。本件については色々とニュースになったので、見たことがある人も多いかと思いますが、メールを使ってるユーザーからすると若干ピンとこない話ではあります。
またグーグル社が言ってるだけで、どうしてそう慌てる必要があるのか？など、疑問に尽きない点があるかと思います。

ここではその点を考慮した上で「メール送信認証」³についての概略と、その運用方法について解説していきます。
誰向け？というと、メールサーバー（ＭＴＡ：メール転送エージェント）を運用する人向けの資料として作成しています。

何かわからないけど、上から設定しろと言われたけど、どんな感じに設定するのか、どう運用するのか、設定順序（優先順位）は？…みたいなことを把握することを目的としています。
ただし、個々の機能の個別の事象については、色々と資料が出回ってるので、そちらを見た方が早いです。そこまで説明しません。
逆に機能の説明は見ても、どういう風に運用するのか今一つピンと来なかったこともあり、その点を中心に解説しています。
ＭＴＡの運用をブラックボックス的に扱ってる人向けではない解説となります。

メール送信認証とは？

アナウンスでは「メール認証」というキーワードが出てきます。メール送信認証と違うのでは？と思うところですが、「メール送信認証」のことを意味してます。
単純に「メール認証」と言えば、メール送信時に設定するＩＤとパスワード、いわゆるＳＭＴＰ認証（ＳＭＴＰＡＵＴＨ）のことを指すのが一般的です。
古のシステムなら POP3 before SMTP といった機能についても言及する人がいるかと思いますが、今では廃止に値する機能となります。そんな設定（サービス）はさっさと切りましょう。
今時ＳＭＴＰ認証に対応していないサービスは色々とおかしいです⁴。

話を戻して、グーグル社が言うところの「メール送信者」、ここでのテーマである「メール送信認証」というのは何を意味するのでしょうか。
メール送るの自分だよね、という認識があればこそ、自分が何かしないといけない気になるし、具体的に何をするべきかよく分からないと思うのですが、直接的には無関係（間接的に影響ある）となります。

「メール送信者」は、具体的には「メールサービスプロバイダー」（ＭＳＰ）という人達に向けた話となります。
ＭＳＰとは、インターネットサービスプロバイダ（ＩＳＰ）と契約した時、携帯キャリアと契約した時、学校で、会社で、Ｇメール／Ｙａｈｏｏメールで、自前で、など、メールの送受信サービス⁵を謳ってるサービスを提供する組織ないしはサービスのことを指しています。それぞれの組織で運用されるメールサービスが従うべきガイドライン（ＦＡＱ参照）となります。
ユーザーが間接的に影響受けるというのはこのことで、直接的には無関係となります。

より具体的には、それら組織の中で動いている、いわゆるＭＴＡに対する設定への要求となります。
本設定を行うためにはＤＮＳサーバーへの設定権限と、ＭＴＡに対する設定権限⁶が必要になります。

メール送信認証で要求される設定

メール送信認証で要求される、つまりメールを送信する際に、ＭＴＡが満たさなければならない設定は以下の３つです。
４つ目（ＡＲＣ）については設定はマストではありませんが、かなり性質が異なりますので別立てします。基本は３つです。

ＳＰＦ
- ＭＴＡが送信する時のＩＰアドレスをＤＮＳで広告します（ＤＮＳ側の設定）。
ＤＫＩＭ
- ＭＴＡが送信する内容（ヘッダー）について改ざんされていないことを保証するため、秘密鍵で署名を行います（ＭＴＡ側の設定）。
- 署名を検証するために、公開鍵をＤＮＳで広告します（ＤＮＳ側の設定）。
ＤＭＡＲＣ
- 上記ＳＰＦ／ＤＫＩＭでの成功・失敗した場合のポリシーをＤＮＳにて広告します（ＤＮＳ側の設定）。

上記の技術を使用して、メール送信者が正当なメールアドレスで送信していることを保証するための仕組みを指して「メール送信認証」と称しています。

これら設定を行う場合、どの程度の難易度でどこに、何を設定すれば良いのか、は下記の表にまとめました。

項目	ＭＴＡ設定	設定順序	ＤＮＳ設定	難易度	ＤＮＳの設定単位	備考
ＳＰＦ	×	×	○	低	サブドメイン毎
ＤＫＩＭ	○	→	○	高	サブドメイン毎	ＭＴＡを設定してからＤＮＳを設定します
ＤＭＡＲＣ	×	×	◎	低～高	ｅＴＬＤ＋１毎⁷	サブドメインについて別途設定⁸

一応ＤＭＡＲＣ的にはＳＰＦとＤＫＩＭどちらかを満たせば良い運用が可能です。可能なはずですが、両方満たすように運用した方が、よりメールが安全に受信してくれる効果が期待されます（ＦＡＱ参照）。

ＳＰＦの設定については難易度は低く、古くから携帯キャリアでの対応が必須だったこともあり、かなりの割合で設定されてるはずです⁹。

ＤＫＩＭの設定についてはそれなりにコツはあります。ここでは OpenDKIM と Yenma について言及に留めておきます。単純な設定で済むケースもありますので、状況に応じて確認が必要です（ＦＡＱ参照）。
いずれにせよ、ＭＴＡ側で設定を行った後、ＤＮＳに設定する、という流れになります。

ＤＭＡＲＣの設定は、ＤＮＳの設定のみであことから、本質的にＳＰＦ並に簡単です。ポリシーの表明だけなので、ほぼテンプレート通りとなります。
その代わり、ＳＰＦの設定が正しいか、ＤＫＩＭの設定が正しいか、自己の管理下にある全てのＭＴＡで問題無いかの確認が必要になります。
その辺りの確認が必要な点が難易度を上げているのと、ＭＴＡの増減によりポリシーの適用範囲外になってしまうＭＴＡが無いかのモニタリングが必要な点が、更に運用をめんどくさくしてしまう要素になります。
ＤＭＡＲＣのポリシーが主張するとおり、ＳＰＦとＤＫＩＭの設定をこまめにメンテナンスされることが要求されます。
またそれら設定から外れた分について、レポートする機能があることから、定期的に見守る必要があります。

なお、時間が無い場合はＳＰＦ＋ＤＭＡＲＣのみ設定するのが、一番の早道となります。おいおいＤＫＩＭに対応していきましょう。

ＡＲＣについて

ＳＰＦ／ＤＫＩＭはメーリングリスト、メール転送等のメカニズムと相性が悪い。そのための仕組みがＡＲＣで、転送等での再送信時に、ＳＰＦ／ＤＫＩＭ／ＤＭＡＲＣで検証した結果、ＤＫＩＭで署名した内容を保存することで、メールを受けた側で検証を行う仕組みである。

メール送信時にＤＫＩＭ／ＡＲＣの署名が行われるタイミングとフロー

各種メーラー（ＭＵＡ）から送られてきたメールをＭＴＡが受け取り、それの宛先を調べて、該当するメールサーバー（ＭＴＡ）に送るのが基本的なフローとなります。
ＤＫＩＭとＡＲＣは、その途中で処理が行われます。ここではｍｉｌｔｅｒという仕組みを前提にフローを説明します。

ＭＵＡがＭＴＡにＳＭＴＰで接続し、メールを送信する
ＭＴＡがヘッダーを受け取った時点で、前処理を行う（ドメイン名補完など）
清書されたヘッダー情報からＤＫＩＭ署名を行い、ヘッダーに追加する
ＤＫＩＭ署名を含むヘッダー情報をＡＲＣで署名する
残るボディを受け取るって送る

ｍｉｌｔｅｒの仕組み上、メールを受け取ったタイミングでＤＫＩＭ署名およびＡＲＣ署名が行われます。送信のタイミングで行われない点に注意が必要です。
ＤＫＩＭに関してはその振る舞いはシンプルであるため、受信時か送信時かのどちらでも同じ振る舞いが期待できますが、ＡＲＣはその必要性と署名のタイミングが難しいです。

メール受信時にＳＰＦ／ＤＫＩＭ／ＤＭＡＲＣ／ＡＲＣの検証が行われるタイミングとフロー

外部のメールサーバー（ＭＵＡ）から送られてきたメールをＭＴＡが受け取り、メールの受信・転送といった動作が基本的なフローとなります。
ＳＰＦ／ＤＫＩＭ／ＤＭＡＲＣ／ＡＲＣの検証は、メールを受け取ってる最中に行われます。ここではｍｉｌｔｅｒという仕組みを前提にフローを説明します。

外部のメールサーバーがＭＴＡにＳＭＴＰで接続し、メールを送信する
ＳＭＴＰコマンドである MAIL FROM: が送られた時点（いわゆるエンベロープフロム）で、接続元ＩＰアドレスと合わせてＳＰＦの検証が行われます。
引き続きヘッダーを受け取った時点で、ＤＫＩＭ署名の検証が行われます。
ＳＰＦ／ＤＫＩＭの検証が終わったのち、ＤＭＡＲＣの評価が行われます。
さらにＡＲＣの検証を行い、場合によってはＤＭＡＲＣの評価を覆す。
残るボディを受け取る

よくある質問とその答え

Ｑ．なんでこんなことするの？

Ａ．なりすまし迷惑メール対策の一環です。自分の預かり知らぬ場所から、自分の名前を勝手に名乗って、勝手にメールを送る、そういう不届き者に対する抑制策となります。
ただし完璧な技術というわけでもないので「なりすまし迷惑メール対策」⊇「メール送信認証」という包含関係があります。
これは以下のことが前提となるからです。

すべてのメール送信者がメール送信認証に対応すること
メール送信者が正規であること、乗っ取られてメール送信された場合までカバーされていないこと

もちろんメール送信認証したうえで「迷惑メール」を送ることについては本技術はカバーしていません。
この場合、レピュテーションという形で、迷惑メール対策を施すことになります。

Ｑ．従わないと行けないって、設定しなくてもいいのでは？

Ａ．数多のユーザーがいるＧメール宛へのメール送信を行わないというのであれば問題ありません。
ただしグーグルだけで無く、この方向性に賛同している他のＭＳＰ¹⁰も多数いることから、これらＭＳＰの対応が進むにつれて、送れるメール先が無くなることを意味します。

Ｑ．送れなくなるって？

Ａ．設定しなくても送ることはできなくもないですが、そのうち「受信してくれなくなる」ことを指して、「送れなくなる」です。

Ｑ．なんでグーグルが言ったからって対応しないといけないのですか？

Ａ．Ｇメールという数多のユーザーが利用しているサービスの提供元だからです。
業界的（フィッシング対策協議会）に音頭を取って対応を進めていた話ではありますが、一般に与えるインパクトの度合いは桁外れに違いました。
これら業界からのアナウンスがあっても対応しなかった所が、駆け込みで大騒ぎになりました¹¹¹²¹³。

なおこの問題は日本だけの問題ではなく、全世界的に進んでいた方向性ではあります。

Ｑ．ＤＫＩＭ対応についてＭＴＡの状況確認とは何ですか？

Ａ．使用するＭＴＡ毎により事情が変わるため、です。自前でＭＴＡを運用しているなら、ＤＫＩＭ署名アプリのインストールと設定が必要になります。
外部のＭＳＰサービスを利用している場合は、ＭＳＰの案内に沿って対応します。
アンケート等で外部サービスを使用している場合は、外部サービス側の案内にしたがって対応する必要があります。
最後のものが曲者で、ＭＴＡ管理者の管理外のサーバーを利用している場合がありますので、そこも含めて設定が担保される必要があります。

Ｑ．ＳＰＦ＋ＤＭＡＲＣでＯＫじゃないの？

Ａ．現在、ＳＰＦかつ／またはＤＫＩＭの認証が通ればＯＫとする運用になっています。その点で言えばＹｅｓです。
ただしＤＭＡＲＣポリシー的にはその制御ができません。ある日、ＳＰＦかつＤＫＩＭとポリシーの解釈が行われる可能性があります。
またメール受信側でＳＰＦとＤＫＩＭが必須とする可能性もあります。いずれにせよ、アンコン状態です。

参考文献

https://support.google.com/a/answer/81126?hl=ja ↩
https://support.google.com/a/answer/14229414?hl=ja ↩
「送信ドメイン認証」と呼称することもあります。自分としてはより包括的な「メール送信認証」という呼称を使用します。 ↩
認証を要求せずに送ることができるケースもあると思いますが、そういう細かい設定については言及しません。 ↩
メール配信業者はメール受信しないじゃん、とツッコミたくなりますが、メール送信するだけの業者（＝ＭＳＰ）も今回の対象です。 ↩
より具体的にはインストール等の作業が発生しえます。単純な設定だけで済むケースもありますが、ＭＴＡ毎、仕様するメールサービス毎の仕様によるので、要確認です。 ↩
実質的なトップレベルドメイン（ｅＴＬＤ）のサブドメイン。組織や個人がレジストラにお願いして、取得するドメイン名を指します。 ↩
サブドメインについても明示することが可能ですが、まとめて一括になります。サブドメイン単位でポリシーを明記することはできません。 ↩
総務省資料より２０１６年時点で９３．１４％ ↩
https://support.yahoo-net.jp/PccMail/s/article/H000007395 ↩
Ｇメール自体は２０１５年１０月頃（公式アナウンスが見つからず、周辺記事から判断）からＤＭＡＲＣを運用しています。唐突に強化を主張したわけではありません。 ↩
「メール送信者のガイドライン」自体は２０２３年１１月に発表、その適用を２０２４年０２月から…としてアナウンスしました。 ↩
わずか３か月で対応が求められたように見えますが、業界的には１０年の歳月をかけています。今までその手のアナウンスを見なかったことが騒ぎを大きくしています。 ↩

メール送信認証、如何にしてＳＰＦ／ＤＫＩＭ／ＤＭＡＲＣ／ＡＲＣを使いこなすか