こんにちは。インフラエンジニアの井上です。
これは TECHSCORE Advent Calendar 2017の22日目の記事です。

メール送信における認証技術ということで、現在一般的とされる技術に軽くだけ触れさせていただいた上で、昨今、取り入れられはじめている認証技術について書かせていただきたいと思います。
記事中で触れるものは、SPF、DKIM、DMARCですが、SPFとDKIMについて、詳しくは記載しておりませんのでご了承ください。

SPF

まず、最初はSPF(Sender Policy Framework)です。これは、送信メールサーバのIPアドレスが確かに正しい送信者のものだと、送信者のメールアドレスのドメインのDNSのレコードを用いて公開するものです。
この公開情報を参照して、受信側メールサーバは差出人のメールのFrom（Header fromのケースの場合もありますし、Envelope fromのケースもあります）のドメインの該当レコードと実施に送信されたサーバのIPアドレス情報を比較し、正しい送信者かどうかを判断する材料にすることがあります。

DKIM

つぎは、DKIM(DomainKeys Identified Mail)です。これは、受信したメールが、正規の送信者から送信されたメールで改ざんが行われていないことを確認できる電子署名方式の送信ドメイン認証技術です。この技術により、どのドメインから送信されたかを受信サーバ側での検証を実現することができます。具体的には、メール送信時に秘密鍵によって生成した署名情報を、送信者のドメインのDNSレコードによって公開されている公開鍵を使って検証することで、正規の送信者であることと、内容が改ざんされていないことを検証することを可能としています。

DMARC

そして、最後にDMARC(Domain-based Message Authentication, Reporting & Conformance)です。DMARCという技術は、2017年12月現在、日本ではメジャーな取り扱いとはなっていませんが、U.K.では政府サービスには必要、オーストラリア政府の推奨とされており、直近ではDHS（米国国土安全保障省）がDMARCを義務化（2017年12月確認）したりと、世界的に導入を避けられない流れとなってきています。そこで、DMARCを導入するための基礎を紹介させていただきたいと思います。

まず、DMARCという技術の導入は困難かという問いについて、メールの送信者の立場でいえば、決して困難ではないと考えます。今回の記事において、前段としてSPFそしてDKIMというキーワードに軽く触れたのは、これに関係します。DMARCは、単一の認証技術で成り立つわけではなく、SPFとDKIMの2つの認証技術が導入されていることが必須要件です。そして、この２つの認証技術を用いて適切ではないと受信が判断した場合、受信側がどのような対応をするかという取り扱いとレポーティングの先を送信者のドメインのDNSレコードで定義する仕組みがDMARCとなります。では、DNSレコードにどのような定義をするのか以下に例を示したいと思います。まず、従来のSPF/DKIMに関する内容です。以下の例は、BINDなどのゾーンファイルの一例です。ここでは、仮にexample.jpというドメインの場合で考えます。

これは、上から「example.jpの受信メールサーバは優先度10の定義としてmail.example.jpがいます」「example.jpは受信メールサーバとして定義されたサーバのIPアドレスからしかメールを出しません(SPF)」「example.jpのセレクタ20171222の公開鍵の内容はpで定義される中身です（DKIM)」「example.jpドメインのメールのいくつか、もしくはすべてにDKIM署名がされていることを宣言します（DKIM)」「mail.example.jpのIPアドレスは192.0.2.1です」ということを示しています。

そして、DMARCではDNSレコードとして次のような内容を定義します。

この宣言の意味は、「vでDMARCのバージョンを定義（現在は１のみ）」、「pは該当ドメインについての取り扱いを定義」、「spは該当ドメインのサブドメインについての取り扱いを定義」、「riはレポートを受け取る間隔を秒定義」、「ruaでは集計レポートの送信先メールアドレスを定義」、「rufでは認証失敗に関するレポーティング先のメールアドレスを定義」となります。
ここで認証に失敗したメールの取り扱い方法について定義できる値の種類は３つで「none(なにもしない、様子見）」「quarantine（隔離し迷惑メールフォルダなどへ入れる）」「reject(拒否する）」があります。
DMARC導入当初はnoneを指定し、様子見をしつつrejectに変えていくというのが一般的に多いケースです（受け取ったレポートの内容を確認しつつ、徐々に厳しくするのが一般的です）。
そして、取り扱い方法の定義を「reject」とできた場合、正規の送信者にとって生まれる可能性のあるメリットは、「自身のドメインを語った詐称メールが各所に届く可能性が低くなる」、「信用あるドメインでのみメール配信を行わないため、送信に利用するIPアドレスのレピュテーションが高くなる可能性がある」ということから、適切なタイミングを見計らって、noneから移行していくのが好ましいとされています。

各値などの設定方法については dmarc.orgのチュートリアル にて確認いただくのが間違いないと考えます。

DMARC実験体験の報告

ここまで、DMARCとはどういったものかということに触れてきましたが、いざ、設定などを行い、その動作をどのように確認するかという部分に触れます。
ここで私が実装、試験した内容を一例として概略だけを記載します。

今回は、固定IPを払い出していただけるIaaS事業者の仮想サーバを借りて、CentOS 7+Postfix+OpenDKIMでDKIM署名をしたメールを送信する環境を作りました。
（※ サーバの具体的な構築方法は、今回の記事では触れません。）

また、ドメインについては、私が所有するドメインをサブドメインを切らずに利用し、上記のサンプルにあるようなDNSレコードを記載し、DMARCの宣言まで用意しました。
その上で、実際に構築したサーバからメールを出して、DMARCが正常に検証しているかを試しました。今回、DMARCを試すために利用した宛先はGmailでした。
Gmail自身も送信のためにDMARCを採用する方向をとっていますが、受信においても、その内容を検証し、確認できるようになっています。

では、実際に送信したメールをGmailで開き、「メッセージのソースを表示」としてみます。結果は次の通りでした。

表示されたソースの画面の上部にメールに関する情報が表示されますが、下３つが認証の結果で、SPFがPASSして、DKIMもPASSして、そしてDMARCもPASSと確認されました。DMARCについてはSPFやDKIM対応がされていても、実際にDMARCがDNSによって定義されないと項目もでてきません。そういった意味では、今回構築したサーバは正常に認証されたことが証明されています。

また、設定後から数日経過した後に、私の保有するドメインを語ったメール送信があったことを確認できるレポートが届いたことも確認しました。これらを定期的に確認しながら、自ドメインのポリシーを適切に設定する効果についても可能性につながるのではないかと考えます。

 まとめ

昨今、大量の迷惑メールが発信され、送り付けられることが多くなってきましたが、これを防ぐための手段が考案され、実際の技術として、私たちも利用が可能な状況がやってきています。これらの対応策についてもいち早く、情報をキャッチアップして対応しないと、取り残された際は、正規のメールすら受信してもらえなくなる状況が生まれかねない、そして、日本でもDMARCレポート解析サービスなども見られるようになってきたことから、簡易な部分の情報の発信と、実際に環境をためしてみた体験の報告をさせていただきました。