メールアドレスの偽造は、インターネット上で、様々な不正行為を目的に使用されています。
アドレスを不正使用のために偽装する事を スプーフィング と呼んでいて、スパムやウィルス付メールのほとんどは、送信者が自分の身元を隠すため、スプーフィングされたアドレスで配信されています。
メールアドレスの偽装そのものは、メールソフトの設定画面で送信者アドレスを変更するだけでも簡単に行えてしまうため、 Sender Policy Framework（SPF） や Sender ID , DKIM といったドメイン認証技術は、こうしたスプーフィング対策を目的として開発されました。
先ほどのようなメールアドレスのスプーフィングなどに対応するため、大規模なISPの中には、独自のIPアドレスフィルタリングやスパムチェック機能を提供するISPも増えてきました。
セキュリティを強固にすると、怖くなるのが誤検知により、自社のサーバーから送信されたメールが正常に配信されないというリスクです。
SPFやDKIMに対応する事は、『誤検知』を最小限にする目的で使用される場合もあります。
ISPが、SPFやDKIMに対応しているサーバーを、接続元のネットワークに依らず、信頼するサーバーとみなす事が増えてきたためです。
…と、説明が長くなってしまいましたが、SPFもDKIMも、実装してみるとあっけないほど簡単で、それにも関わらず多方面にプラスの意味で影響力の強い技術なので、実装する事をお勧めします。
SPF、SenderID、DKIMは全て、同じ目的である『スプーフィング』に対抗するための仕組みではあるのですが、ご察しの通り、その実装はそれぞれ異なります。
SPFとSender ID
SPFとSenderIDは、送信元ドメインのDNSへ、メールサーバのIPなどを登録しておき、このDNS情報を、メール受信時に、受信側のメールサーバーが確認することで、メールの送信が、正規のメールサーバーから行われたものであるかを確認するものです。
SPFとSenderIDの検証に必要なDNS情報は、SPFとSenderIDとで同一ですが、メールを受信する際に検証するヘッダ情報が、SPFとSenderIDとで異なります。
- SPFの場合: SMTPセッションのMAIL FROM（MFROM）
- Sender-IDの場合: PRAレコード(これはSender: From: Resent-Sender: Resent-From: の情報を元に生成されるレコードです）とSPFのMFROM
SPFとSenderIDはどちらも、送信元のDNSサーバーへメールサーバのIPなどの情報を追加するだけで済むため、簡単に送信元サーバーの正当性を確認できる手段ではありますが、メールサーバーを複数台経由してメール送信する場合や、ウィルスチェックサーバーなどの中継サーバーを経由してメール送信を行った場合、MAIL FROMの値とDNSのレコードが一致せず、認証に失敗してしまいます。
SPFとSender IDの実装の流れ
ドメイン認証の実装としては、大きく、ドメイン認証を「受ける側」と、ドメイン認証を「検証する側」をそれぞれ考える必要があります。
ドメイン認証を受けるには、DNSへレコードを追加します。
DNSの設定変更だけで済み、メールサーバー等の設定は必要ありません。DNSレコードは、例えば次のようになります。
wareportal.co.jp IN TXT "v=spf1 a mx ptr ip4:[111.111.111.111] mx:mail.wareportal.co.jp +all"
ドメイン認証を検証、つまり、上記のDNSレコードを、メール受信時にチェックする場合は、メールサーバーや中継サーバー側で設定が必要になります。
DKIM
DKIMは、メールの送信時、送信側のメールサーバーで、メールのヘッダーと本文から、公開鍵暗号方式を使って電子署名を生成し、メールヘッダへ秘密鍵として格納します。
この秘密鍵に対応した公開鍵を、送信元のDNSへ登録しておきます。
メール送信時、受信側メールサーバーは、送信元ドメインのDNSから公開鍵を取得し、電子署名が正規なものかどうかを判定しています。
DKIMの場合は、先述の、中継サーバーを経由した場合などであっても、正しく送信元の認証が行えます。
ただし、メーリングリストのメールなど、途中でメール本文が書き換えられてしまうような場合、（メール本文から電子署名を生成するため）認証に失敗してしまうという欠点があります。
こうした事態を避けるため、MDaemonメールサーバーなど、製品によって、デフォルトでメーリングリスト用の受信メッセージから、DKIM署名を自動削除するよう構成されているものもあります。
DKIMの実装の流れ
先ほどと同様、ドメイン認証の実装としては、大きく、ドメイン認証を「受ける側」と、ドメイン認証を「検証する側」をそれぞれ考える必要があります。
まずは電子署名付きのメールを送信するため（つまりドメイン認証を「受ける側」）の設定の流れです。
- 1：メール送信時、電子署名を生成するために必要な、秘密鍵と公開鍵を用意します。生成方法ですが、Linux系であれば、opensslコマンドを使用しますし、Windows系であれば、メールサーバーソフトウェア上で電子署名の生成機能を持っていたりします。
- 2：作成した秘密鍵と公開鍵のうち、公開鍵を、DNSサーバーへ登録します。 例えば、メールサーバーがmail.wareportal.co.jpで、公開鍵が「publickey」だった場合、DNSへ登録するレコードは以下のようになります。
- 3：メール送信時に電子署名を付与するための設定を行います。これはメールサーバーや中継サーバー側での設定となります。
ここまでがDKIMでメール送信するための流れです。
DKIM署名を検証するための設定は、これとは別に行います。検証自体はメールサーバーや中継サーバーで行われますので、そちらでの設定が必要です。
SPF・SenderIDとDKIMのどちらがいい？
この質問、実は個人的にも幾度となくされてきたものではあるのですが、結論から言うと、『環境に依る』のだと思っています。
もう少しきちんと説明すると（すみません…）署名するサーバー=(別のサーバーやアプライアンスへメール転送を行う事なく)直接メールを社外に対して配信するサーバーであれば、SPFやSenderIDの方が、手軽且つ簡単に実装できます。
一方で、メールサーバー側で電子署名を付与してから、ウィルスチェックやフィルタリングなど、他のシステムへメールを全部転送する必要があるような環境では、DKIMの利用するのが最も適しています。
転送された時点で、SPFやSenderIDでは、（送信元サーバーの）IPアドレスと、受信側サーバーがやり取りしているIPアドレスとが異なるため、認証に失敗してしまうのです。
送信元IPアドレスを意識する必要がない場合はSPF・SenderIDを使い、送信元IPアドレスを意識しなくてはならない場合や、逆に、送信元IPアドレスに依らず確実にメール配信を行いたい場合には、DKIMの実装がお勧めです。
メールマガジン
月に1回程度、不定期に製品の最新情報をお届けしています。メールアドレスをご記入の上、右側のボタンを押してください。