メールサーバー側で行うメール詐称対策(技術者向け)

目次

SPF

SPF(= Sender Policy Framework)とは、メールの送信元(Sender)ドメインが詐称されていないことを証明するための技術の一つです。
現在のメール送信においては、送信者情報を詐称することが可能で、実際、多くの迷惑メールは他のアドレスになりすまして送られています。そこで、送信者情報を詐称しているメールを判定するためにSPFという送信ドメイン認証技術を使用します。

記述例:単独のIPアドレスで指定する方法

example.jp. IN TXT "v=spf1 ip4:192.168.100.3 ~all"

記述例:AレコードやMXレコードで指定する方法

example.jp. IN TXT "v=spf1 a:mail.example.jp ~all"

example.jp. IN TXT "v=spf1 mx ~all"

上は「mail.example.jp」のAレコードで、下は「example.jp」のMXレコードで指定されたメールサーバーが「正当なメールサーバー」であるという意味になります。

記述ポイント:「~all」ではなく「-all」で指定する方法

「~all」と比較すると「-all」は、より「断定した」指定方法となります。

SPFレコードの設定を誤るとメールの送受信が行えなくなるため、正しく設定が行えているかチェックツール等で確認が必要です。

DKIM

DKIM(Domainkeys Identified Mail)は、電子署名を用いた送信ドメイン認証の機構であり、多くのメールサービスで利用されている。DKIMによる検証では、送信側ではメッセージのヘッダと本文から生成した電子署名をメールヘッダに付加して送信し、受信側でその電子署名を照合することによって送信ドメイン認証を行う。このためDKIMはSPFとは異なり、中継するMTA(メール転送エージェント)で電子メールのデータが変更されない限り、転送メールであっても転送先で正しく認証することができる。

送信側はあらかじめ、署名に使用する秘密鍵と対になる公開鍵をDNS権威サーバで公開しておく。
 送信側がメールを送信する際には、メールの本文とヘッダを元に作成した電子署名を付与して送信する。受信側のメールサーバでメールを受信すると、メールヘッダ中の「DKIM-Signature」内の「d=タグ」で指定されたドメイン名のDNS権威サーバに対して公開鍵を問い合わせる。ただし、送信側がd=タグで指定するドメイン名はメール送信サーバと同一でなくてもよく、第三者のドメイン名を指定することが可能である。例えば、送信者のドメイン名がexample.comの場合でも、d=タグではexample.net等、任意のドメイン名を指定することができる。次に、受信側は公開鍵を取得すると、その公開鍵を用いて電子署名を照合し、DKIM検証を実施する

DMARC

DMARC(Domain-based Message Authentication,Reporting & Conformance)は、上記で解説した2つの送信ドメイン認証(SPF・DKIM)を用いたレポーティングおよびポリシ制御の仕組みで、欧米を中心に近年急速に普及が広がっている技術である。DMARCは、SPFやDKIMのような直接的な認証技術とは異なり、SPFとDKIMを利用して、どちらの検証にも失敗したメールに対して、受信側がどのように取り扱うかの方針を送信ドメイン管理者側が宣言するための機構である。このため、DMARCは受信側におけるなりすましメール受信対策ではなく、送信側のドメイン管理者が自ドメインを詐称したなりすましメールを送信されにくくすることで、自ドメインのブランドを保護するための技術であると言える。

 DMARCには、このような送信ドメイン認証失敗時の制御ポリシに従ったメール配送制御の方法を宣言する機能に加えて、レポーティング機能がある。レポーティング機能では、自ドメイン名を名乗って送信されたメールの傾向の集約レポートや送信ドメイン認証の失敗レポートを受信することで、管理者は自ドメイン名の送信ドメイン認証の効果の状況や、自ドメインを騙って送信されたなりすましメールの状況を把握することができる。

 DMARCを利用するには、送信側と受信側でそれぞれ次のように対応する必要がある。まず送信側では、SPFおよびDKIMの両方、あるいはいずれか一方に対応する必要がある。これに加えて、送信側では自ドメイン名の先頭に「_dmarc.」を負荷したドメイン名(_dmarc.example.com) のTXTレコードとしてDMARCレコードを公開する。DMARCレコード内の「p=タグ」で送信ドメイン認証(SPF・DKIM)に失敗したメールに対する受信側の処理ポリシを宣言することができる。宣言可能な処理ポリシは次の3種類がある。

  • none(処理方法を指定しない)
  • quarantine(隔離する)
  • reject(受信拒否する)

 これらの処理ポリシはあくまで送信側が宣言するものであるため、受信側での実際の処理は運用方針によってさまざまである。例えば処理ポリシがquarantineの場合、受信側では迷惑メールボックスに隔離する運用が考えられる。また、処理ポリシがnoneの場合、受信者は通常通りに受信することになるためDMARC導入による受信拒否効果はないが、送信側ではレポーティング機能を活用して集約情報や認証失敗情報を得ることができる。

 DMARCレコードは、各パラメータの間をセミコロンで区切って記述する。図例では、バージョン情報(v)、認証失敗時の動作ポリシ(p)、集約レポートの送信先(rua)、失敗レポートの送信先(ruf)のパラメータを記述したDMARCレコードの例を示したが、これ以外にも様々なパラメータが存在し、詳細な設定が可能です。

v=DMARC1; p=reject; rua=mailto:admin@example.jp, mailto:dmarc@example.jp; pct=100; adkim=s; aspf=s

<記述例>

txt @ v=spf1 mx a:〇〇〇.com a:smtp.〇〇〇.com ~all
txt _dmarc v=DMARC1; p=quarantine; rua=mailto:〇〇@〇〇〇.jp;

SPF/DKIM/DMARC などのチェックをするサイト

SPF Record Checker

https://dmarcian.com/spf-survey/

DKIM Record Checker

https://dmarcian.com/dkim-inspector/

DMARC Record Checker

https://dmarcian.com/dmarc-inspector/

Facebook
Twitter
Pinterest