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

セキュリティ » 不正使用対策 以下には、SecurityGatewayのDMARC検証、DMARCレポート、DMARC設定、のDMARCの検証とレポートに関連した3つの設定画面をご用意しています。

DMARC検証

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

DMARC検証に失敗し、DMARCドメインが"p=none"ポリシーを使っていた場合、 特別な処理は行われず、メールは通常通り処理されます。一方で、DMARCドメインが、"p=隔離"や "p=reject"といった制限ポリシーを使っていると、SecurityGatewayはオプションでメールを自動的にユーザーの隔離フォルダへ振り分けたり、件名へテキストを追加したり、メッセージスコアを調整する事ができます。また、ドメインが制限ポリシーを使っていた場合に、SecurityGatewayはポリシーに応じて"X-SGDMARC-Fail-policy: 隔離"や"X-SGDMARC-Fail-policy: reject"をヘッダへ自動挿入します。これにより 送信メールを特定のフォルダへ移動するなどの処理が、ヘッダに含まれる文字列をベースに、Sieveスクリプトやメールサーバーのコンテンツフィルタリングシステムで行えるようになります。

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

DMARCレポーティング

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

DMARC設定

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

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

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

ドメインでDMARCを利用

自分のドメインでDMARCを使用する、つまり、先方のDMARC対応メールサーバーにメールが自分のドメインからのものである事をDMARCを使って検証させるには、まず、最低限どちらか1つがDMARCを使用するよう正しく設定されている、SPF とDKIM のDNSレコードが必要です。DKIMを使っている場合はSecurityGatewayの DKIM署名 オプションも設定する必要があります。また、ドメイン用のDMARC DNSレコードも必要です。特別なフォーマットのTXTレコードのDNSクエリにより、宛先サーバーはDMACポリシーや、使用している認証モード、統計レポートの受信を行うかどうか、レポート送付先アドレス、といった様々なオプションを確認する事ができます。正しくDMARCを設定し、DMARC XMLレポートの受信が始まったら、レポートの読み込みができるオンラインツールを活用して潜在的な問題の分析を行う事ができます。

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

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

Owner Field

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