【図解】メール認証とDNS

メールの送信元認証を、DNSの観点から学習し、図解してみました。

送信元メールアドレスを偽装することは比較的簡単で、なりすまし・標的型攻撃によく使われます。私のYahooメールにも、偽Amazonから「アカウント停止するぞ」メールが頻繁に来ています。登録情報が不完全だからって、天下のAmazon様が末端ユーザのアカウントを停止するなんて、特にメリットがないと思うんですけどね。

偽装メール対策として、メールの送信元が正しいかを認証する仕組みがあります。今回は、以下の3種類の技術について調べてみました。

• SPF(Sender Policy Framework)：送信元IPアドレスの認証

• DKIM(DomainKeys Identified Mail)：電子署名による認証

• DMARC(Domain-based Message Authentication, Reporting, and Conformance)：認証失敗時の動作定義

これらの技術は、DNSのTXTレコードを使っている点で共通しています。TXTレコードを使って、決められた文字列をやりとりすることで、送信元の認証や認証失敗時の動作定義をしています。

---

下図が、メール認証とDNSの全体像です。業界スタンダード？の、Alice(example.com)からBob(example.net)にメールを送るシチュエーションですね。図の左上部がAliceが送るメールの情報です。

Aliceからのメールを受け取ったexample.netのメールサーバは、送信元メールアドレスであるexample.comのDNSサーバに問い合わせを行います。

SPF認証では、メール送信元のIPアドレスと、SPFのTXTレコードに記載されているIPアドレスを比較して検証します。送信元の住所として記載されたものが合っているか、Alice本人に電話して確認するようなイメージですね。
TXTレコードには、送信元として許可されたIPアドレス(FQDNでも可)と、認証結果の処理内容が記載されます。ただし、認証結果の処理内容はゆるい定義でしかなく、最終的には受信側の設定に依存します。

DKIM認証では、秘密鍵と公開鍵の仕組みを使って送信元を検証します。メール送信元が秘密鍵を使って電子署名を行い、メール受信者が公開鍵を使って電子署名を検証します。Aliceが特殊な印鑑を押して、Bobがその印影を確認するイメージですね。
TXTレコードには、電子署名の公開鍵が記載されます。また、TXTレコードのホスト名として、[セレクタ名]._domainkeyが使われます。

DMARCは、認証失敗時の動作を定義する仕組みです。SPF認証やDKIM認証だけでは、認証失敗したメール(なりすましメール)が受信側でどう処理されたか、送信側は把握できません。DMARCを使うことで、認証失敗時の動作ポリシーを送信側が公開し、受信側の動作をコントロールしたり、受信側からレポートを上げさせたりすることができます。
TXTレコードには、認証失敗時のポリシー(none、reject、quarantineなど)や、レポートの送付先を指定できます。また、TXTレコードのホスト名として、_dmarcが使われます。

上図では、SPF認証・DKIM認証ともに問題ないので、DMARCの記載は無視して、Bobはメールを受信します。
※DKIM認証の値は一致しませんが、イメージで…

---

次に、AliceになりすましたMalloryが、Bobにメールを送るシチュエーションで考えてみましょう。

送信元のMalloryは、送信元メールアドレスをAliceのものに偽装し、電子署名を付与して、Bobにメールを送信しました。受信側のBobは、送信元メールアドレスexample.comのDNSサーバに問い合わせて検証を行います。

SPF認証では、メールのIPアドレス198.51.100.1と、SPFレコードを比較します。＋で許可された192.0.2.1/32とは合致しないため、~allに該当することになります。~は、不正メールとして処理されるが、配信もされる識別子です。よって、この時点では、SPF認証はNGだがメール受信はする、という状態です。

DKIM認証では、DKIMレコードからAliceの公開鍵を取得し、メールに付与された電子署名と検証します。検証の結果、Aliceの秘密鍵で作成された電子署名ではないことがわかりました。DKIM認証はNGですが、DKIMは受信側の動作には干渉しないので、メール自体は受信する状態です。

DMARCでは、DMARCレコードの記載に沿って、認証失敗時の受信動作を確認します。Aliceの属するexample.comのDMARCレコードには、認証失敗時は受信しない(p=reject)、と定義されています。今回はSPF・DKIMともに認証失敗しているので、受信側のexample.netは、送信側のDMARCレコードの動作定義に従い、このメールを削除します。よって、Bobがこのメールを目にすることはありません。また、DMARCレコードに記載されたdmarc@example.comに対して、集計レポート・認証失敗レポートが送信されます。

---

以上、メール送信元認証の仕組みを、DNSの観点から見てきました。

他のレコードと比較して、TXTレコードは記載の自由度が高く、何に使われているかがわかりにくいものでした。メール送信元認証を通じて、使われ方の一例を知ることができました。

SPF・DKIMでは検知だけを行い、透過or削除の動作定義はDMARCで行う、という点が特徴的だと感じました。ネットワークにおけるIDSとIPSに似ていますが、検知と防御を兼ねるIPSに対して、DMARCは防御専門ですね。

また、記載を間違えれば動作しなかったり、意図しない動作になったりします。~allと-all(チルダとハイフン)とか、紛らわしいです… DNSに限らず、事前の動作検証が大切だと思いました。

実際の運用では、認証失敗したら即削除、みたいなハードな設定は少なそうです。上記の例のようにDMARCの動作をrejectにするのは、結構勇気がいりますね。

【図解】メール認証とDNS - Qiita

#図解 #最近の学び #メール #認証 #メール認証 #DNS #DNSレコード #TXTレコード #SPF #DKIM #DMARC #エンジニア #ネットワーク