ナビゲーション: セキュリティメニュー > セキュリティマネージャ > 送信者認証: DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC)とは、メールのFrom:ヘッダを偽装したスパムやフィッシングメールを減らす目的で設計された標準規格です。DMARCを使う事で、ドメイン所有者はDNSを通して、宛先サーバーに対し自分のドメインを名乗ってはいるものの、実際の情報とは異なっているメールをどのように扱うか、といった情報を、ポリシーとして通達できるようになります。このポリシーは、宛先のDNSサーバーが受信メールの処理中に行うDNSクエリに応じて、隔離・削除・何もしない（通常通り処理する）といった処理が行われます。ポリシーに加え、ドメインのDMARC用DNSレコードには、サーバーに対して自社ドメインの名乗る偽装メールの数や失敗した認証の回数や、それぞれの詳細情報をDMARCレポートとして送信するようリクエストも含まれています。DMARCのレポート機能はメールの認証処理の効果やドメインがどの位の頻度で偽装されているのかを検証するのに大変役立つ機能です。

セキュリティ設定画面の中の送信者認証へ、DMARC検証とレポート設定用に、DMARC検証、DMARCレポート、DMARC設定の3つの画面があります。

DMARC検証

DMARC検証処理の1つとして、MDaemonは受信メールのFrom:ヘッダに含まれるドメインに対して、DMARCのDNSクエリを行います。ここではドメインがDMARCを使用しているかどうかを確認し、使用している場合は、ポリシーやその他DMARC関連情報を含んだDMARC DNSレコードを取得します。更に、DMARCはSPF やDKIM を使ってメールの検証を行い、最低でもどちらかの検証で成功しないと、DMARC検証を通過できません。メールの検証に成功すると、MDaemonは残りの配送処理やフィルタリング処理を通常通り行います。DMARC検証に失敗した場合は、ドメインのDMARCポリシーとMDaemonのDMARC検証失敗メールの処理設定の組み合わせに応じて、メールの処理が行われます。

DMARC検証に失敗し、DMARCドメインが"p=none"ポリシーを使っていた場合、 特別な処理は行われず、メールは通常通り処理されます。一方で、DMARCドメインが、"p=quarantine"や "p=reject"といった制限ポリシーを使っていると、MDaemonはオプションでメールを自動的にユーザーのスパム(Junk E-mail)フォルダへ振り分ける事もできます。また、ドメインが"p=reject"ポリシーを使っていた場合に、MDaemonにメールを拒否するよう設定する事もできます。制限ポリシーで検証に失敗したメールについては、更にMDaemonの設定によって、"X-MDDMARC-Fail-policy: quarantine"ヘッダを挿入する事ができます。このヘッダを使う事で、コンテンツフィルタで、メールを指定したフォルダへ移動するといった、何らかの処理を行う事ができます。

DMARC検証はデフォルトで有効で、ほとんどのMDaemon設定で推奨しています。

DMARCレポート

MDaemonがDNSへDMARCレコードの問合せを行った際、DMARCレコードに、対象ドメインを名乗るメールでDMARC検証に失敗したものを、ドメイン所有者にレポートとして提供するように求めるタグが含まれている場合があります。DMARCレポートのオプションでは、要求されている種類のレポートの送信を行うかどうかの指定や、レポートに追加するメタ情報の指定を行う事ができます。統計レポートはUTCの深夜に送信され、失敗レポートは、検証に失敗する毎に送信されます。レポートは常にXMLファイルをzip圧縮した上でメールへ添付し送信され、このレポートを簡単に閲覧するための様々なツールがオンラインで提供されています。

デフォルトでMDaemonは統計レポートや失敗レポートを送信しません。レポートを送信するには、DMARCレポート画面で関連するオプションを有効にして下さい。

DMARC設定

DMARC設定ではDKIMの特定の情報をレポートに含むかどうか、DMARCのDNSレコードをログへ残すかどうか、MDaemonがDMARCで使用するPublic Suffixファイルを更新するかどうか、といった様々な設定が行えます。

DMARC検証とメーリングリスト

DMARCの目的が、メールのFrom:ヘッダのドメインが偽装されていない事を確認するためのものであるため送信サーバーは当然対象ドメインとしてメール送信する事を許可されていなくてはなりません。これはメーリングリストに対して独自の問題を引き起こす場合があります。これは、異なるドメインのメーリングリストメンバーがメーリングリストのアドレスでメール送信を行い、From:ヘッダの変換は行われていない、という状況がよくあるためです。つまり、受信サーバーがメーリングリストのメールに対してDMARC検証を行った場合、メールがFrom:ヘッダのドメインとして公式に認定されて場所から届いたものとして判断されるという事です。DMARCドメインが制限DMARCポリシーを使っていた場合、これによりメールは受信サーバーで隔離されたり拒否される事になります。環境によっては、宛先メールアドレスがメーリングリストのメンバーから削除されてしまう場合もあります。こうした問題を回避するため、MDaemonは制限DMARCポリシーを使っているドメインからのメーリングリストメールを受信すると、メールのFrom:ヘッダをメーリングリストのアドレスへ書き換えます。また、制限ポリシーを使っているドメインからのメーリングリストメールを受け付けないようMDaemonを設定する事もできます。このオプションで、制限ポリシーを使っているドメインのユーザーからのメーリングリストに対する投稿を効率よく止める事ができます。From:ヘッダを書き換えるオプションは、メーリングリストエディタのヘッダ画面からアクセスできます。メールを拒否するためのオプションへは、設定画面からアクセスできます。

MDaemonドメインでDMARCを利用

自分のドメインでDMARCを使用する、つまり、先方のDMARC対応メールサーバーにメールが自分のドメインからのものである事をDMARCを使って検証させるには、まず、DNS用に、SPFとDKIMレコードを作成します。最低限その中の1つは正常に動作させておく必要があります。もしもDKIMを使用する場合は、更にMDaemon側のDKIM署名オプションを設定します。追加で、DMARC用のDNSレコードを作成します。DNSへこの特殊な形式のTXTレコードの問合せを行うと、受信側のサーバーは送信元ドメインのDMARCポリシーと、使用している認証モード、レポートの要求有無、レポートの送信先メールアドレス、といった、追加パラメータを確認します。

DMARCを正しく設定し、DMARC XMLレポートの受信が始まったら、レポートの表示や潜在的な問題の分析を行う様々なオンラインツールが利用できます。利便性向上のため、\MDaemon\App\フォルダの中にも、DMARCレポーターというツールがパッケージされています。DMARCReporterReadMe.txtで使用方法を確認して下さい。

DMARC TXTリソースレコードの定義

以下は最も基本的な、広く使われているDMARCレコードです。詳細な情報や、設定方法については、こちらを参照して下さい: www.dmarc.org.

Ownerフィールド

DMARCリソースレコードのOwner (又は「Name」や「left-hand」)フィールドは _dmarc で指定するか、レコードを適用するドメインやサブドメインを指定するための _dmarc.domain.name を使用します。

例:

example.comのDMARCレコード

_dmarc IN TXT "v=DMARC1;p=none"

このレコードは user@example.com や、user@support.example.com, user@mail.support.example.comといった、example.comのサブドメインからのメール全てに適用されます。

_dmarc.support.example.com IN TXT "v=DMARC1;p=none"

このレコードはuser@support.example.comには適用されますが、user@example.comには適用されません。

_dmarc.support IN TXT "v=DMARC1;p=none"

このレコードは user@support.example.com, user@a.support.example.com, user@a.b.support.example.comなどからのメール全てに適用されます。

DMARCレコードのタグと値

必須タグ

オプションタグ

下記のタグはオプションです。タグが使われていない場合は、それぞれのデフォルト値が代わりに使用されます。

DMARCの仕様に関する詳細な情報は、次を参照して下さい: www.dmarc.org.

参照:

DMARC検証

DMARCレポート

DMARC設定

メーリングリスト » 設定

メーリングリスト » ヘッダ