メインコンテンツまでスキップ

4. Overview (概要)

本セクションでは、DMARC環境の設計と動作の一般的な概要を提供します。

4.1. Authentication Mechanisms (認証メカニズム)​

このバージョンのDMARCでは、認証された識別子を決定するための以下のメカニズムがサポートされています：

  • [DKIM]: 検証されたDKIM-Signatureヘッダーフィールドの「d=」タグのコンテンツにドメインレベルの識別子を提供します。

  • [SPF]: [SMTP] HELO/EHLOコマンド（HELO識別子）で見つかったドメインとSMTP MAILコマンド（MAIL FROM識別子）で見つかったドメインの両方を認証できます。DMARCは、MAIL FROM識別子のSPF認証の結果を使用します。[SPF]のセクション2.4は、MAILコマンドがnullパスを持つ場合のMAIL FROM処理について説明しています。

4.2. Key Concepts (主要な概念)​

DMARCポリシーはドメイン所有者によって公開され、SMTPセッション中にメール受信者によってDNSを介して取得されます。

DMARCのフィルタリング機能は、RFC5322.Fromフィールドドメインが、SPFまたはDKIMからの認証されたドメイン名と整合している（一致する）かどうかに基づいています。RFC5322.Fromフィールドで見つかったドメイン名に対してDMARCポリシーが公開されており、そのドメイン名がSPFまたはDKIMを通じて検証されていない場合、参加している受信者に配信されるときに、そのメッセージの処分はそのDMARCポリシーによって影響を受ける可能性があります。

DMARCによって採用されている認証メカニズムは、DNSドメインのみを認証し、メッセージで見つかった電子メールアドレス識別子のローカル部分を認証せず、メッセージコンテンツの正当性も検証しないことに注意することが重要です。

DMARCのフィードバックコンポーネントには、ドメイン所有者への定期的な集約レポートのために、組織ドメインからのものであると主張する受信メッセージに関する情報の収集が含まれます。そのようなレポートのパラメータと形式は、本文書の後のセクションで説明されています。

DMARC対応のメール受信者は、SPFおよび/またはDKIMに失敗した個々のメッセージに関連する情報を含むメッセージごとのレポートも生成する可能性があります。メッセージごとの失敗レポートは、展開をデバッグするとき（認証に失敗してもメッセージが正当であると判断できる場合）、または攻撃を分析するときの有用な情報源です。そのようなサービスの機能はDMARCによって有効化されますが、[AFRF]などの他の参照資料で定義されています。

メッセージは、サポートされている認証メカニズムの少なくとも1つが以下の条件を満たす場合、DMARCチェックを満たします：

  1. 「合格 (pass)」結果を生成し、

  2. セクション3で定義されているように、整合している識別子に基づいてその結果を生成する。

4.3. Flow Diagram (フロー図)​

    +---------------+
    | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
    +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    ^            ^        .
        |                                    **************        .
        V                                                 *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
     | sMTA |------->( other MTAs )----->| rMTA |         *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
                                            |             * ........
                                            |             * .
                                            V             * .
                                     +-----------+        V V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

     MSA = Mail Submission Agent (メール送信エージェント)
     MDA = Mail Delivery Agent (メール配信エージェント)

上の図は、DMARC対応システムを通るメッセージの単純なフローを示しています。実線は実際のメッセージフローを示し、点線はサポートされているメッセージ認証スキームに関連するメッセージポリシーを取得するために使用されるDNSクエリを含み、アスタリスク線はメッセージ処理モジュールとメッセージ認証モジュール間のデータ交換を示します。「sMTA」は送信MTAであり、「rMTA」は受信MTAです。

本質的に、ステップは次のとおりです：

  1. ドメイン所有者は、[SPF]に従ってSPFポリシーを構築し、DNSデータベースに公開します。ドメイン所有者はまた、[DKIM]で説明されているようにDKIM署名のためにシステムを構成します。最後に、ドメイン所有者はDNSを介してDMARCメッセージ処理ポリシーを公開します。

  2. 作成者はメッセージを生成し、ドメイン所有者の指定されたメール送信サービスにメッセージを渡します。

  3. 送信サービスは、メッセージに適用されるDKIM署名を生成するために、関連する詳細をDKIM署名モジュールに渡します。

  4. 送信サービスは、現在署名されたメッセージを、意図された受信者にルーティングするために指定された転送サービスにリレーします。

  5. メッセージは他のリレーを通過する可能性がありますが、最終的には受信者の転送サービスに到着します。

  6. 受信者配信サービスは、必要なデータをそれぞれのモジュールに渡すことによってSPFおよびDKIM認証チェックを実施します。各モジュールは、作成者ドメインのDNSデータへのクエリを必要とします（識別子が整合している場合、以下を参照）。

  7. これらの結果は、作成者のドメインとともにDMARCモジュールに渡されます。DMARCモジュールは、そのドメインのDNSからポリシーを取得しようとします。見つからない場合、DMARCモジュールは組織ドメインを決定し、DNSからポリシーを取得する試みを繰り返します。（これについては、セクション6.6.3でさらに詳しく説明されています。）

  8. ポリシーが見つかった場合、それは作成者のドメインとSPFおよびDKIMの結果と組み合わされて、DMARCポリシー結果（「合格 (pass)」または「不合格 (fail)」）を生成し、オプションで2種類のレポートのいずれかを生成することができます（図には示されていません）。

  9. 受信者転送サービスは、メッセージを受信者の受信トレイに配信するか、DMARC結果に基づいて他のローカルポリシーアクションを実行します（図には示されていません）。

  10. 要求された場合、受信者転送サービスは、フィードバックを提供するために使用されるメッセージ配信セッションからデータを収集します（セクション7を参照）。

に最終更新