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

6. Policy (ポリシー)

DMARCポリシーは、ドメイン所有者 (Domain Owner) によって公開され、メール受信者 (Mail Receiver) によって適用されます。

ドメイン所有者は、1つ以上のドメインにDNS TXTレコード (セクション6.1で説明) を追加することで、DMARCへの参加を広告します。これにより、ドメイン所有者は、自分のドメインの1つから送信されたと主張するメッセージの処理と、それらのメッセージに関するフィードバックの提供について、メール受信者に対して特定の要求を行います。

ドメイン所有者は、メール受信者によるDMARC評価に参加しないことを選択できます。この場合、ドメイン所有者は単にこれらのスキームへの参加を広告しないだけです。例えば、パス認証チェックの結果が特定の著者ドメイン (Author Domain) の全体的なDMARC結果の一部として考慮されるべきでない場合、ドメイン所有者はSPF passの結果を生成できるSPFポリシーレコードを公開しません。

DMARCメカニズムを実装するメール受信者は、メッセージがDMARCテストに失敗した場合、ドメイン所有者が公開したDMARCポリシーに従うよう最善の努力をすべきです (SHOULD)。メールストリームは複雑になる可能性があるため (転送、既存のRFC5322.Fromドメインなりすましサービスなどによる)、メール受信者はメッセージ処理中にドメイン所有者が公開したポリシーから逸脱してもよく (MAY)、逸脱の事実と理由をフィードバックレポート、特に集約レポート (Aggregate Report) の「PolicyOverride」機能 (セクション7.2を参照) を使用してドメイン所有者に提供すべきです (SHOULD)。

6.1. DMARC Policy Record (DMARCポリシーレコード)​

ドメイン所有者のDMARC設定は、「_dmarc」という名前のサブドメインにDNS TXTレコードとして保存されます。例えば、「example.com」のドメイン所有者は、「_dmarc.example.com」のTXTレコードにDMARC設定を投稿します。同様に、RFC5322.Fromドメインが「example.com」のメールに関するDMARC設定を照会したいメール受信者は、「_dmarc.example.com」のサブドメインに対してDNSにTXTクエリを発行します。DNSに配置されたDMARC設定データは、以降「DMARCレコード」と呼ばれます。

DMARCによるドメインネームサービス (Domain Name Service) の使用は、DMARCがドメイン名を使用することと、実行するクエリの性質によって推進されます。クエリ要件は、単純なパラメトリック情報を取得するためのDNSと一致します。これは、ターゲットドメイン名に関連付けられた情報を保存する確立された方法、すなわちDMARCコンテキストに制限された独立したTXTレコードを使用します。クエリサービスとしてDNSを使用することには、新しいインフラストラクチャを作成するのではなく、非常に確立された運用、管理、および管理インフラストラクチャを再利用するという利点があります。

[DNS]によれば、TXTレコードは複数の「character-string」オブジェクトで構成できます。この場合、DMARC評価を実行するモジュールは、これらの文字列をオブジェクトを順番に結合し、結果を単一の文字列として解析することで連結しなければなりません (MUST)。

6.2. DMARC URIs (DMARC URI)​

[URI]は、リソースを識別するための汎用構文を定義します。DMARCメカニズムは、ドメイン所有者がサポートされている2つのレポートタイプの宛先を指定する形式としてこれを使用します。

このようなURIが指定される場所 (セクション6.3を参照) では、これらのリストを提供できます。レポートは通常、ドメイン所有者が提供した順序で、リストされた各URIに送信されます。受信者は、レポートを送信するURIの数に制限を課してもよい (MAY) ですが、少なくとも2つに送信する機能をサポートしなければなりません (MUST)。URIのリストはカンマ (ASCII 0x2C) で区切られます。

各URIには、送信できる最大レポートサイズを関連付けることができます。これは、区切りカンマまたは終端セミコロンの前に、感嘆符 (ASCII 0x21) に続いて最大サイズ指定を追加することで実現されます。

したがって、DMARC URIは、カンマまたは感嘆符が[URI]に従ってパーセントエンコードされたURI、その後にオプションの感嘆符と最大サイズ指定、そしてリストに追加のレポートURIがある場合はカンマと次のURIが続きます。

例えば、URI mailto:[email protected]!50m は、レポートペイロードが50メガバイトを超えない限り、「[email protected]」にメールでレポートを送信するよう要求します。

正式な定義はセクション6.4で提供されます。

6.3. General Record Format (一般的なレコード形式)​

DMARCレコードは、DKIM [DKIM]で定義されたDNSベースの鍵レコード用の拡張可能な「tag-value」構文に従います。

セクション11は、既知のDMARCタグのレジストリを作成し、この文書で定義された初期セットを登録します。この文書または後の拡張で定義され、したがってそのレジストリに追加されたタグのみが処理されます。未知のタグは無視しなければなりません (MUST)。

6.4. Formal Definition (正式な定義)​

(完全なABNF構文についてはRFC 7489を参照)

6.5. Domain Owner Actions (ドメイン所有者のアクション)​

ドメイン所有者は、認証失敗の処理に関する設定を示すためにDMARCポリシーを公開します。

6.6. Mail Receiver Actions (メール受信者のアクション)​

メール受信者は、DMARCポリシーを照会し、ローカルポリシーに従ってそれらを適用します。

6.7. Policy Enforcement Considerations (ポリシー適用の考慮事項)​

メール受信者は、DMARCポリシーを適用する際、正当な転送シナリオやメーリングリスト操作など、さまざまな要因を考慮すべきです。

に最終更新