SPF、DKIM、DMARCの話（メールの正しさを信じる方法をざっくり整理）

あくまでも、送られてきたメールがおかしくないかというお話。
その検証のための仕組みがいくつかあって、強度が異なる。

SPFとDKIMは検証の方式のこと。
DMARCは検証後の動きを定義したもの。
若干粒度が異なるけど、3つ列挙します。

ざっくりと。

メールの見た目は自由に変えられる

メール関連のことだから。
前提になる話。

メールを受信する側は、メールを送信した側が設定してきた値を解釈して、いろいろと処理したり表示したりする。
当然のことながら、受信側は、メール送信側が書いてきたものを解釈する以外の手段がない。

本文の話に限らず、ヘッダー部分に関しても同じ。
というか、今回話題にするのは送信者情報が書かれるヘッダー部分。
リアルのお手紙でたとえるなら、差出人欄のところ。お手紙を受け取った人は、送信側が書いた内容を見て「そうか」と思うしかない。
メールの世界でも同じ。

メールの送信者情報の見た目は、送信側でどうとでもできる。

どこからでもメール送信できる

「メールを送る」と聞くと、メールアプリ（メーラー）からの送信という行為が真っ先に思いつくかもしれない。
が、そのほかにもメールを送る仕組みは存在する。

たとえば、ニュースレター（メールマガジン）を一斉に配信するシステムが考えられる。
メーラーのように宛先をいちいち設定しているわけではなく、あらかじめ登録済みの会員などの情報があって、別にメール文面を作る仕組みがあって、配信日時を決めたら、会員に一斉配信とかいったことでしょう。

ほかにも、運用中の業務システムで異常を検知したときに自動配信されるメールとか、ホームページのお問合せフォームに入力された情報を自動送信するメールとか、サービス申込時にメールアドレスを確認するための自動配信メールとか、いろいろ。
ほとんどの場合で共通するのは、「送信専用です」みたいなことが書かれてること。いずれもメーラーアプリを使ってるわけではない。
メールを送り出す仕組みは結構シンプル。
仕組み上、受信も可能ではあるんだが、確認する手段は複雑で実用的じゃないってこともある。

つまり、メーラーを使わなくてもメールは送信可能。

何が言いたいかというと。
メールもリアルの郵便といっしょで、誰がどこからでも送れるということ。
どこのポストに投函しても、宛先が合っていれば届く。

そして、誰からだったとしても、宛先が合ってさえいれば届く。。

送信者名は送信者が決めていい

メールの仕組みとして、送信者名のところの表示は、送信側で指定できる。

メールアプリだと「From」のところに表示される文字列。
送信側は、メールアドレスが何であっても、受信側の「From」のところに好きな文字列を表示するように依頼できる。あくまでも送信側の依頼というかたちだけれど、受信側では聞いてあげることが多いでしょう。

たとえば、送信アドレスが「aaa@example.com」だとしても、「bbb@example.com」だとしても、受信側に「システムサポート」と表示してもらうことが可能。

そしてさらに、送信アドレスを偽証することも可能だったりする。
誰であったとしても、どこから送信するかに関わらず、「ccc@example.com」を送信アドレスとしてメールを作成することが、理郎的に可能ということ。

お互いに最善を尽くすしかない

インターネットの世界は、ベストエフォートの世界。
お互いが最善を尽くすことで成立している。
メールはインターネット技術を使っているので、考え方は同じ。

送信側は、メールを送り出すところまでが責任範囲。
決められた情報を決められた書式で記載したものを送り出す。
お作法は決まっている。けれども、それに則らなくてもよかったりする。
なんとなく合っていれば成立してしまう。

受信側は、受け取った情報が決められた書式で書かれていると信じて、人の目に見えるかたちのメールとして解釈し、表示するところまでが責任範囲。
お作法に多少の揺らぎがあったとしても、がんばって解釈しようとする考え方。長くはない歴史ではあるものの、いろいろな技術が絡み合っているため、いくつかの流派があるようなものだったりする。
そもそも完全な状態で情報が揃わないことがあるといった前提でもある。

ここで話題にするのは、メールが正しいかを送信側に問合わせればいいじゃないか、ということ。
受信側は、メールの正しさを確認するための仕組みを構築する。これは受信側ががんばるという前提があるから。
送信側は、問合せに対して正しい情報を返答するための仕組みを用意しておく。

受信側が認証する前提

ずいぶんと長い前置きが続いてしまいましたが。
受信側でメールの正しさを確認するための仕組みがいくつかあり、どんなものかを整理するわけです。
話題にするのは以下の3つ。

• 正しさを確認できるルール
  • SPF
  • DKIM
• 正しくないときの動きを決める仕組み
  • DMARC

3つとも、DNS（Domain Name System）を使う。
本来はドメイン名とIPアドレスの対応付けを司る役回り。だけど他にも情報を保有することはできるし、みんなが利用できる仕組みだから、メールの正当性確認にも使わせてもらいましょう。

というわけで、主に受信側メールサーバーががんばります。
届いたメールの正当性をいちいちDNSに問合せ。
正しければ受信側クライアント（受信者）に流せばいい。

正しくないときには、基本的には遮断。。
ただし、どうするかは受信側の設定次第。DMARCの場合は、対応方法まで指定されてる上に、送信側にレポートを返してあげる。

項目	SPF	DKIM	DMARC
概要	送信側のサーバーが正しいかを確認して、なりすましを見破る。	電子署名を使って、受信したメールが改ざんされてないかを見破る。	受信したメールがおかしいと見破ったときの動きを決める。
検証に利用するもの	IPアドレス	電子証明書	SPFかDKIM。 もしくは両方。

そもそも、対応するシステムの構築が前提。

IPアドレスで信用する「SPF」

Sender Policy Framework

送信側のIPアドレスが正しければよし。

悪意のある送信者が送り出してくるメールは、見た目を変えてたとしても、送信サーバーのIPアドレスが正しくなければ弾ける。裏側で検証できるということ。

事前準備

DNSに、「正しいIPアドレス」を登録しておく。
送信するサーバーは複数あるだろうから、DNSには複数のIPアドレスを登録することになるでしょう。メールの送信に利用する仕組みは、メーラーアプリだけじゃなく、各種システムなどがあるため。

設定はDNSにSPFレコード（TXTレコード）を追加するくらい。
送信サーバーのIPアドレス確認などはあるだろうが、その他の設定はない。

メール送信

普通にメール送信するだけ。
ただし登録済みのIPアドレス（を保持しているサーバー）からに限る。

IPアドレスの偽装が可能かと言われれば、可能。。

受信側での検証

送信サーバーのIPアドレスを確認して、DNSに問合せ。
認証できればよし。

おかしなメールだった場合にどうするかは、受信側の取扱い次第。
送信側が知ることはできない。

証明書で信用する「DKIM」

Domain Keys Identified Mail

電子証明書を使って電子署名されたメールを送信する。
受信側では、メールの送信者が正しいことに加えて、メールの内容が改ざんされてないことまで分かる。

悪意のある送信者が電子証明書まで偽装することはほぼ不可能なので、信頼性は高い。

ちなみに、電子証明書の取得にはお金がかかる。

事前準備

DNSに、電子署名に利用する電子証明書の情報を登録しておく。

さらに、メール送信時に電子署名を付与する必要があるので、そのための各種設定が必要。
電子署名をメーラーで付けるかメールサーバーで付けるかはお任せ。
送信側システムでの設定もお忘れなく。

DNSに domainkey レコードを追加。
さらに電子署名用のシステム構築が必要ということ。

メール送信

メール送信時には電子署名を付与する。

電子署名の偽装はほぼ不可能。

受信側での検証

メールに付与されてる電子署名を確認して、DNSで検証。
合っていれば、送信元が正しくて、かつ、メールの内容も正しいことが証明できる。

おかしなメールだった場合にどうするかは、受信側の取扱い次第。
送信側が知ることはできない。

信用できないときの動きを指定できる「DMARC」

Domain-based Message Authentication, Reporting and Conformance

受信側メールサーバーの対応方法をお願いするための仕組み。
前提になるのは、SPFやDKIMによる認証。どちらかでも両方でもいい。
特に、検証に失敗したときにどうするか、ポリシーを送信側が決める。

事前準備

DNSに、DMARCのポリシーを設定。

それ以外の設定は、認証に使う技術次第。
SPFならそれに対応したもの。
DKIMならそれに対応したもの。

純粋なDMARCという仕組みの設定だけに注目すれば、DNSへの設定だけ。

メール送信

メール送信がどうなるかは、認証に利用する技術次第。
SPFなら特になし。
DKIMならいろいろと。

純粋なDMARKに限れば、メール送信には関与しない。

受信側での検証

検証方法は、SPFなのかDKIMなのか、両方なのかによって相応に。
二勝できなかったときの受信側メールサーバーの動きを指定するのがDMARC。

正しいメールはそのままでいい。（Pass）

認証できなかった場合（Fail）のポリシーを指定してる。
何もせずに通す（None）のか、検疫する（Quarantine）のか、拒否する（Reject）のか。
そして認証結果は、レポートとして送信側に返すことが可能。

おかしなメールだったときにどうするか、送信側が決められる。
基本的には検疫ということになるでしょう。何もせずに通すことはあり得ないし、拒否させるならレポートはいらない。

メールが受信側でどう扱われたかを送信側で知ることができれば、悪意ある送信者からの攻撃なのか、送信側の技術的な問題なのか判断できるということ。

送信側で準備したお墨付きを受信側が利用する

SPF、DKIM、DMARC、それぞれの設定をざっくりまとめると、下表のとおり。
送信側では、主に自身の正しさをどうやって確認してもらえるかといった情報を準備。
受信側では、対応するシステムを構築して、メールの正しさを確認。

正しさを確認できる範囲や複雑さによって、安全性は評価される。

項目	SPF	DKIM	DMARC
概要	送信側のサーバーが正しいかを確認して、なりすましを見破る。	電子署名を使って、受信したメールが改ざんされてないかを見破る。	受信したメールがおかしいと見破ったときの動きを決める。
送信側の設定 ［DNS］	送信に利用するIPアドレスを登録。	送信メールに載せる電子署名を登録。	受信時の対応をどうするか登録。
送信側の設定 ［メールサーバー］	なし	送信時に電子署名を付けるように設定。	検証レポートを受信できるように設定。
送信側の設定 ［その他］	なし	なし	受信したレポートを見るための仕組みの構築。
受信側の設定	SPFに対応させる。 送信元IPアドレスをDNSで検証。	DKIMに対応させる。 公開鍵情報を使ってDNSで検証。	DMARCに対応させる。 受信したメールが変なときに送信側にレポートを返すように設定。
検証に利用するもの	IPアドレス	電子証明書	SPFかDKIM。 もしくは両方。
構築の難易度（相対的かつ独断）	DNSへの設定だけなので難易度は低い。	証明書の金額が気になるし署名付与の設定が必要で難易度が高い。	SPFかDKIMができていれば、DNSへの設定だけなので難易度は低いが、確認のための難易度は高い。
安全性 （一般的に言われているもの）	低	中	高

送信側も受信側も、それぞれ相応の準備は必要。
設定だったり、システム高地くだったり。
複雑ならいいわけだが、やれるかどうかはまた難しい問題。
使える資金は限られているものです。何に重きを置くかで、どこまでやるか、やれるか、考えなくちゃいけない。

ちなみにここでの話題は、メールの盗聴を防ぐということではない。
送信者が正しいことや、メールの内容が改ざんされていないことを保証できるという話。

つまりDKIMを利用したところで、平文送信なら盗聴は防げない。
盗聴されたくないなら、メールを暗号化する技術を採用すること。
秘密鍵暗号方式でも公開鍵暗号方式でも、対応するシステムはある。
SSL/TLSとか使えばいい。証明書の用意が必要だが。