Internet Engineering Task Force (IETF) A. Brotman, Ed.
Request for Comments: 9990 Comcast, Inc.
Obsoletes: 7489 May 2026
Category: Standards Track
ISSN: 2070-1721
Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record.
ドメインベースのメッセージ認証、レポート、および適合性 (DMARC) を使用すると、ドメイン所有者は受信者からの集約レポートを要求できます。このレポートは XML ドキュメントであり、後で他のタイプのデータを指定できるようにする拡張可能な要素が含まれています。受信者は、関連付けられた DNS レコードで宣言されているドメイン所有者の指定された宛先に集約レポートを送信できます。
This document obsoletes RFC 7489.
この文書は RFC 7489 を廃止します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9990.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9990 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.1.1. Notation
1.1.2. DMARC Terminology
2. Document Status
3. DMARC Feedback
3.1. Aggregate Reports
3.1.1. Description of the Content of the XML File
3.1.2. Handling Domains in Reports
3.1.3. DKIM Signatures in Aggregate Reports
3.1.4. Unique Identifiers in Aggregate Reporting
3.1.5. Error Element
3.1.6. Policy Override Reason
3.2. Extensions
3.3. Changes in Policy During a Reporting Period
3.4. Report Request Discovery
3.5. Report Delivery
3.5.1. Definition of Report-ID
3.5.2. Email
3.5.3. Other Methods
3.5.4. Handling of Duplicates
4. Verifying External Destinations
5. Extensible Reporting
6. IANA Considerations
6.1. Registration for the DMARC Namespace
6.2. Registration for the DMARC XML Schema
7. Privacy Considerations
7.1. Report Recipients
7.2. Data Contained Within Reports
7.3. Feedback Leakage
8. Security Considerations
8.1. Report Content as an Attack
8.2. False Information
8.3. Disclosure of Filtering Information
9. Operational Considerations
9.1. Report Generation
9.2. Report Evaluation
9.3. Report Storage
10. References
10.1. Normative References
10.2. Informative References
Appendix A. DMARC XML Schema
Appendix B. Sample Report
Appendix C. Differences from RFC 7489
Acknowledgements
Author's Address
A key component of Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] is the ability for Domain Owners to request that Mail Receivers provide various types of reports. These reports allow Domain Owners to have insight into which IP addresses are sending on their behalf and some insight into whether or not the volume may be legitimate.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] の重要なコンポーネントは、ドメイン所有者がメール受信者にさまざまな種類のレポートを提供するように要求できる機能です。これらのレポートにより、ドメイン所有者は、どの IP アドレスが自分に代わって送信しているのかを把握し、ボリュームが正当であるかどうかについてある程度の洞察を得ることができます。
These reports expose information relating to the DMARC policy, as well as the outcome of Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] validation.
これらのレポートは、DMARC ポリシーに関連する情報と、Sender Policy Framework (SPF) [RFC7208] および DomainKeys Identified Mail (DKIM) [RFC6376] の検証の結果を公開します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Certain properties of mail messages described in this document are referenced using notation found in [RFC5598] (e.g., "RFC5322.From").
この文書で説明されているメールメッセージの特定のプロパティは、[RFC5598] にある表記法 (例: "RFC5322.From") を使用して参照されます。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and [RFC7405].
この仕様は、[RFC5234] および [RFC7405] の Augmented Backus-Naur Form (ABNF) 表記を使用します。
There are a number of terms defined in [RFC9989] that are used within this document. Understanding those definitions will aid in reading this document. The terms below are of noted interest:
[RFC9989] で定義され、この文書内で使用される用語が多数あります。これらの定義を理解すると、このドキュメントを読むのに役立ちます。以下の用語は特に興味深いものです。
* Author Domain
* 著者のドメイン
* DMARC Policy Record
* DMARCポリシーレコード
* Domain Owner
* ドメイン所有者
* Mail Receiver
* メール受信者
* Organizational Domain
* 組織ドメイン
* Report Consumer
* レポートコンシューマ
This document, in part, along with [RFC9989] and [RFC9991], obsoletes and replaces DMARC [RFC7489]. Note that errata for this document has been addressed as described in [RFC9989].
この文書の一部は、[RFC9989] および [RFC9991] とともに廃止され、DMARC [RFC7489] に置き換わります。この文書の正誤表は [RFC9989] で説明されているように対処されていることに注意してください。
Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies.
メール受信者がフィードバックの形で DMARC メカニズムを実装および強制する方法をドメイン所有者に可視化することは、正確な認証展開を確立および維持するために重要です。ドメイン所有者がポリシーや慣行がどのような影響を及ぼしているかを確認できれば、検疫ポリシーや拒否ポリシーをより積極的に使用できるようになります。
The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into:
DMARC 集約フィードバック レポートは、ドメイン所有者に以下に関する正確な洞察を提供するように設計されています。
* authentication results,
* 認証結果、
* corrective action that needs to be taken by Domain Owners, and
* ドメイン所有者が実行する必要がある是正措置、および
* the effect of Domain Owner DMARC policy on mail streams processed by Mail Receivers.
* メール受信者によって処理されるメール ストリームに対するドメイン所有者の DMARC ポリシーの影響。
Aggregate DMARC feedback provides visibility into real-world mail streams that Domain Owners need in order to make informed decisions regarding the publication of a DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forged Mail Receivers are getting, they can make better decisions about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently.
集約された DMARC フィードバックにより、ドメイン所有者が DMARC ポリシーの公開に関して情報に基づいた決定を下すために必要な現実のメール ストリームの可視性が提供されます。ドメイン所有者が、送信している正規のメール、そのメールの認証結果、およびメール受信者が取得している偽造メールを把握していれば、必要なポリシーと、それらのポリシーを有効にするために実行する必要がある手順について、より適切な決定を下すことができます。ドメイン所有者がポリシーを適切に設定し、その効果を理解すると、メール受信者は自信を持ってポリシーに従って行動できます。
Visibility comes in the form of daily (or more frequent) feedback reports that are originated from Mail Receivers and that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not.
可視性は、メール受信者から発信され、ドメイン所有者に関連するメッセージ ストリームに関する集計データを含む毎日の (またはより頻繁な) フィードバック レポートの形式で提供されます。この情報には、DMARC 認証を通過したメッセージと通過しなかったメッセージに関するデータが含まれます。
A separate report MUST be generated for each DMARC Policy Domain encountered during the reporting period. See below for further explanation in Section 3.1.2 ("Handling Domains in Reports").
レポート期間中に発生した DMARC ポリシー ドメインごとに個別のレポートを生成しなければなりません (MUST)。詳細については、以下のセクション 3.1.2 (「レポートでのドメインの処理」) を参照してください。
The report may include the following data:
レポートには次のデータが含まれる場合があります。
* The DMARC policy discovered and applied, if any
* 検出および適用された DMARC ポリシー (存在する場合)
* The selected message disposition
* 選択したメッセージの性質
* The identifier evaluated by SPF and the SPF result, if any
* SPF によって評価された識別子と SPF 結果 (存在する場合)
* The identifier evaluated by DKIM and the DKIM result, if any
* DKIM によって評価された識別子と DKIM の結果 (存在する場合)
* For both DKIM and SPF, an indication of whether the identifier was in DMARC alignment (see Section 3.2.10 of [RFC9989])
* DKIM と SPF の両方について、識別子が DMARC アライメントにあるかどうかを示すもの ([RFC9989] のセクション 3.2.10 を参照)
* Sending and receiving domains
* 送受信ドメイン
* The number of successful authentications
* 認証成功数
* The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents.
* 他のフィルタリング エージェントによって最終的に配信がブロックされた場合でも、受信したすべてのメッセージに基づくメッセージの数。
Each report MUST contain data for only one DMARC Policy Domain. A single report MUST contain data for one policy configuration. If multiple configurations were observed during a single reporting period, a reporting entity MAY choose to send multiple reports; otherwise, the reporting entity SHOULD note only the final configuration observed during the period. See below for further information.
各レポートには、1 つの DMARC ポリシー ドメインのみのデータが含まれなければなりません (MUST)。単一のレポートには、1 つのポリシー構成のデータが含まれている必要があります。単一の報告期間中に複数の設定が観察された場合、報告主体は複数の報告を送信することを選択してもよい(MAY)。それ以外の場合、報告主体は、期間中に観察された最終構成のみを記録すべきである(SHOULD)。詳細については、以下を参照してください。
The format for these reports is defined in the XML Schema Definition (XSD) in Appendix A. The XSD includes the possible values for some of the elements below. Most of these values have a definition tied to [RFC9989].
これらのレポートの形式は、付録 A の XML スキーマ定義 (XSD) で定義されています。XSD には、以下のいくつかの要素に使用できる値が含まれています。これらの値のほとんどには、[RFC9989] に関連付けられた定義があります。
The format is also described in the following sections. Each section describes a collection of sibling elements in the XML hierarchy. There are pointers to where in the hierarchy each table fits.
この形式については、次のセクションでも説明します。各セクションでは、XML 階層内の兄弟要素のコレクションについて説明します。各テーブルが階層内のどこに収まるかを示すポインターがあります。
If a document does not match the specified format, the document evaluator SHOULD discard the report. The evaluator MAY choose to try to utilize some of the data; however, if the format is in question, the data may be as well. The report evaluator MAY choose to contact the report generator so that they may be alerted to an issue with the report format.
文書が指定された形式と一致しない場合、文書評価者はレポートを破棄すべきです(SHOULD)。評価者は、データの一部を利用することを選択してもよい(MAY)。ただし、形式に問題がある場合は、データも問題になる可能性があります。レポート評価者は、レポート形式の問題について警告を受けるために、レポート作成者に連絡することを選択してもよい(MAY)。
The column "#" specifies how many times an element may appear -- this is sometimes referred to as multiplicity. The possible values are:
列「#」は、要素が出現する回数を指定します。これは多重度と呼ばれることもあります。可能な値は次のとおりです。
O:
O:
OPTIONAL, zero or one element
オプション、0 個または 1 個の要素
R:
R:
REQUIRED, exactly one element
必須、要素は 1 つだけ
*:
*:
OPTIONAL, zero or more elements
省略可能、0 個以上の要素
+:
+:
REQUIRED, one or more elements
必須、1 つ以上の要素
Some elements contain text meant for humans and support an optional "lang" attribute whose value indicates the language of its contents. The default value is "en". Elements supporting this optional attribute are marked with "[@lang]" at the start of their content description in the following tables.
一部の要素には人間向けのテキストが含まれており、その値が内容の言語を示すオプションの「lang」属性をサポートしています。デフォルト値は「en」です。このオプションの属性をサポートする要素には、次の表の内容説明の先頭に「[@lang]」というマークが付けられています。
DMARC aggregate feedback reports have the root element "feedback" with its XML namespace set to the DMARC namespace.
DMARC 集約フィードバック レポートには、ルート要素「フィードバック」があり、その XML 名前空間が DMARC 名前空間に設定されています。
+==============+===+===========================================+
| Element name | # | Content |
+==============+===+===========================================+
| feedback | R | First level elements; see Section 3.1.1.2 |
+--------------+---+-------------------------------------------+
Table 1: The XML Root Element
表 1: XML ルート要素
The elements in this table MUST appear in the order listed.
この表の要素は、リストされている順序で出現する必要があります。
+==================+===+============================================+
| Element name | # | Content |
+==================+===+============================================+
| version | O | MUST have the value 1.0. |
+------------------+---+--------------------------------------------+
| report_metadata | R | Report generator metadata; see |
| | | Section 3.1.1.3. |
+------------------+---+--------------------------------------------+
| policy_published | R | The DMARC policy configuration |
| | | observed by the receiving |
| | | system; see Section 3.1.1.5. |
+------------------+---+--------------------------------------------+
| extension | O | Allows for future |
| | | extensibility; see |
| | | Section 3.1.1.6. |
+------------------+---+--------------------------------------------+
| record | + | Record(s) of the feedback from |
| | | the report generator; see |
| | | Section 3.1.1.7. |
+------------------+---+--------------------------------------------+
Table 2: First Level Elements of the Aggregate Feedback Report
表 2: 集計フィードバック レポートの第 1 レベルの要素
There MUST be at least one "record" element; these elements contain data stating that IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element.
少なくとも 1 つの「レコード」要素が必要です。これらの要素には、IP アドレスが作成者ドメインのメッセージを受信システムに配信したことを示すデータが含まれています。報告される IP アドレスごとに、少なくとも 1 つの「レコード」要素が存在します。
+====================+===+=========================================+
| Element name | # | Content |
+====================+===+=========================================+
| org_name | R | Name of the Reporting Organization. |
+--------------------+---+-----------------------------------------+
| email | R | Contact to use when contacting the |
| | | Reporting Organization. |
+--------------------+---+-----------------------------------------+
| extra_contact_info | O | [@lang] Additional contact details. |
+--------------------+---+-----------------------------------------+
| report_id | R | Unique Report-ID; see Section 3.5.1. |
+--------------------+---+-----------------------------------------+
| date_range | R | The reporting period; see |
| | | Section 3.1.1.4. |
+--------------------+---+-----------------------------------------+
| error | O | [@lang] Error messages encountered when |
| | | processing the DMARC Policy Record; see |
| | | Section 3.1.5. |
+--------------------+---+-----------------------------------------+
| generator | O | The name and version of the report |
| | | generator; this can help the Report |
| | | Consumer find out where to report bugs. |
+--------------------+---+-----------------------------------------+
Table 3: Report Generator Metadata
表 3: レポート ジェネレーターのメタデータ
This element describes the time range in UTC defining the reporting period of this report.
この要素は、このレポートのレポート期間を定義する時間範囲を UTC で記述します。
+==============+===+================================+
| Element name | # | Content |
+==============+===+================================+
| begin | R | Start of the reporting period. |
+--------------+---+--------------------------------+
| end | R | End of the reporting period. |
+--------------+---+--------------------------------+
Table 4: Contents of the "date_range" Element
表 4: 「date_range」要素の内容
* "begin" and "end" contain the number of seconds since the epoch.
* 「begin」と「end」には、エポックからの秒数が含まれます。
The "begin" and "end" elements are meant to denote the reporting period and not the first/last observed message from the reporting period. When generating reports, these reporting periods SHOULD NOT overlap. Typically, the reporting period will encompass a single UTC day, beginning at 0000UTC.
「begin」要素と「end」要素は、レポート期間を示すことを目的としており、レポート期間の最初/最後に観察されたメッセージを示すものではありません。レポートを生成する場合、これらのレポート期間は重複してはなりません。通常、レポート期間には、0000UTC から始まる 1 日 (UTC) が含まれます。
This element provides information on the DMARC Policy Record published for the Author Domain. The elements from "p" and onwards contain the discovered or default value for the DMARC policy applied.
この要素は、作成者ドメインに対して公開された DMARC ポリシー レコードに関する情報を提供します。「p」以降の要素には、適用された DMARC ポリシーの検出された値またはデフォルト値が含まれます。
Unspecified tags have their default values.
未指定のタグにはデフォルト値があります。
+==================+===+=======================================+
| Element name | # | Content |
+==================+===+=======================================+
| domain | R | The DMARC Policy Domain. |
+------------------+---+---------------------------------------+
| discovery_method | O | The method used to discover the DMARC |
| | | Policy Record used during evaluation. |
+------------------+---+---------------------------------------+
| p | R | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| sp | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| np | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| fo | O | The value for the failure reporting |
| | | options. |
+------------------+---+---------------------------------------+
| adkim | O | The DKIM Identifier Alignment mode. |
+------------------+---+---------------------------------------+
| aspf | O | The SPF Identifier Alignment mode. |
+------------------+---+---------------------------------------+
| testing | O | The value of the "t" tag. |
+------------------+---+---------------------------------------+
Table 5: Contents of the "policy_published" Element
表 5: 「policy_published」要素の内容
* "discovery_method" can have the value "psl" or "treewalk", where "psl" is the method from [RFC7489] and "treewalk" is described in [RFC9989].
* 「discovery_method」は値「psl」または「treewalk」を持つことができます。「psl」は[RFC7489]のメソッドであり、「treewalk」は[RFC9989]で説明されています。
* Many of the items above (p, sp, etc.) are defined in [RFC9989].
* 上記の項目の多く (p、sp など) は [RFC9989] で定義されています。
Use of extensions may cause elements to be added here. These elements MUST be namespaced.
拡張機能を使用すると、ここに要素が追加される場合があります。これらの要素には名前空間を付ける必要があります。
+==========================+===+==========================+
| Element name | # | Content |
+==========================+===+==========================+
| <any namespaced element> | * | File level elements |
| | | defined by an extension. |
+--------------------------+---+--------------------------+
Table 6: Contents of the "extension" Element
表 6: 「extension」要素の内容
* "<any namespaced element>": Zero or more elements in the namespace of the related extension declared in the XML root element.
* "<任意の名前空間要素>": XML ルート要素で宣言された関連拡張子の名前空間内の 0 個以上の要素。
The report MUST contain one or more records stating which IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element.
レポートには、どの IP アドレスが作成者ドメインのメッセージを受信システムに配信したかを示す 1 つ以上のレコードが含まれていなければなりません (MUST)。報告される IP アドレスごとに、少なくとも 1 つの「レコード」要素が存在します。
This element contains all the authentication results that were evaluated by the receiving system for the given set of messages.
この要素には、指定された一連のメッセージに対して受信システムによって評価されたすべての認証結果が含まれます。
An unlimited number of "record" elements may be specified.
「record」要素は無制限に指定できます。
Use of extensions may cause other elements to be added to the end of the record; such elements MUST be namespaced.
拡張子を使用すると、レコードの末尾に他の要素が追加される場合があります。このような要素には名前空間を付ける必要があります。
One record (IP, result, authentication identifiers) per tuple.
タプルごとに 1 つのレコード (IP、結果、認証識別子)。
The elements in this table MUST appear in the order listed.
この表の要素は、リストされている順序で出現する必要があります。
+==============+===+============================================+
| Element name | # | Content |
+==============+===+============================================+
| row | R | See Section 3.1.1.8. |
+--------------+---+--------------------------------------------+
| identifiers | R | The data that was used to apply policy for |
| | | the given "row"; see Section 3.1.1.10. |
+--------------+---+--------------------------------------------+
| auth_results | R | The data related to authenticating the |
| | | messages associated with this sending IP |
| | | address; see Section 3.1.1.11. |
+--------------+---+--------------------------------------------+
| <any | * | Record level elements defined by an |
| namespaced | | extension. |
| element> | | |
+--------------+---+--------------------------------------------+
Table 7: Contents of the "record" Element
表 7: 「record」要素の内容
* "<any namespaced element>": Zero or more elements in the namespace of the related extension declared in the XML root element.
* "<任意の名前空間要素>": XML ルート要素で宣言された関連拡張子の名前空間内の 0 個以上の要素。
A "row" element contains the details of the connecting system, and how many mail messages were received from it, for the particular combination of the policy evaluated.
「row」要素には、評価されたポリシーの特定の組み合わせについて、接続システムの詳細と、そこから受信したメール メッセージの数が含まれます。
+==================+===+=======================================+
| Element name | # | Content |
+==================+===+=======================================+
| source_ip | R | The connecting IP address. |
| | | IPv4address or IPv6address as defined |
| | | in Section 3.2.2 of [RFC3986]. |
+------------------+---+---------------------------------------+
| count | R | Number of messages for which the |
| | | "policy_evaluated" was applied. |
+------------------+---+---------------------------------------+
| policy_evaluated | R | The DMARC disposition applied to |
| | | matching messages; see |
| | | Section 3.1.1.9. |
+------------------+---+---------------------------------------+
Table 8: Contents of the "row" Element
表 8: 「row」要素の内容
This element describes the results of applying the DMARC policy. If alignment fails and the policy applied does not match the DMARC Policy Domain's configured policy, the "reason" element MUST be included.
この要素は、DMARC ポリシーを適用した結果を記述します。調整が失敗し、適用されたポリシーが DMARC ポリシー ドメインの設定されたポリシーと一致しない場合は、「reason」要素を含める必要があります。
The elements in this table MUST appear in the order listed.
この表の要素は、リストされている順序で出現する必要があります。
+==============+===+==========================================+
| Element name | # | Content |
+==============+===+==========================================+
| disposition | R | The result of applying the DMARC policy. |
+--------------+---+------------------------------------------+
| dkim | R | The result of the DKIM DMARC Identifier |
| | | Alignment test. |
+--------------+---+------------------------------------------+
| spf | R | The result of the SPF DMARC Identifier |
| | | Alignment test. |
+--------------+---+------------------------------------------+
| reason | * | Policy override reason; see |
| | | Section 3.1.1.14. |
+--------------+---+------------------------------------------+
Table 9: Contents of the "policy_evaluated" Element
表 9: 「policy_evaluated」要素の内容
* "spf" and "dkim" MUST be the evaluated values as they relate to DMARC, not the values the receiver may have used when overriding the policy.
* 「spf」と「dkim」は、ポリシーをオーバーライドするときに受信者が使用した値ではなく、DMARC に関連する評価値でなければなりません (MUST)。
* "reason" elements are meant to contain any notes the reporter might want to include as to why the "disposition" policy does not match the "policy_published", such as a local policy override.
* 「reason」要素には、ローカル ポリシーのオーバーライドなど、「disposition」ポリシーが「policy_published」と一致しない理由について報告者が含めたいメモを含めることを目的としています。
+===============+===+===========================================+
| Element name | # | Content |
+===============+===+===========================================+
| header_from | R | The RFC5322.From domain from the message. |
+---------------+---+-------------------------------------------+
| envelope_from | O | The RFC5321.MailFrom domain that the SPF |
| | | check has been applied to. |
+---------------+---+-------------------------------------------+
| envelope_to | O | The RFC5321.RcptTo domain from the |
| | | message. |
+---------------+---+-------------------------------------------+
Table 10: Contents of the "identifiers" Element
表 10: 「identifiers」要素の内容
* "envelope_from" MAY exist but be empty if the message had a null reverse-path (see Section 4.5.5 of [RFC5321]).
* "envelope_from" は存在してもよいが、メッセージにヌルのリバースパスが含まれている場合は空であってもよい ([RFC5321] のセクション 4.5.5 を参照)。
This element contains DKIM and SPF results, uninterpreted with respect to DMARC.
この要素には、DMARC に関して解釈されていない DKIM および SPF の結果が含まれます。
If validation is attempted for any DKIM signature, the results MUST be included in the report (within reason; see Section 3.1.3 ("DKIM Signatures in Aggregate Reports") below for handling numerous signatures).
DKIM 署名の検証が試行された場合は、その結果をレポートに含める必要があります (理由の範囲内。多数の署名の処理については、以下のセクション 3.1.3 (「集計レポートの DKIM 署名」) を参照してください)。
The elements in this table MUST appear in the order listed.
この表の要素は、リストされている順序で出現する必要があります。
+==============+===+=============================+
| Element name | # | Content |
+==============+===+=============================+
| dkim | * | DKIM authentication result; |
| | | see Section 3.1.1.12. |
+--------------+---+-----------------------------+
| spf | O | SPF authentication result; |
| | | see Section 3.1.1.13. |
+--------------+---+-----------------------------+
Table 11: Contents of the "auth_results" Element
表 11: 「auth_results」要素の内容
+==============+===+===============================================+
| Element name | # | Content |
+==============+===+===============================================+
| domain | R | The domain that was used during validation |
| | | (the "d=" tag in the signature). |
+--------------+---+-----------------------------------------------+
| selector | R | The selector that was used during validation |
| | | (the "s=" tag in the signature). |
+--------------+---+-----------------------------------------------+
| result | R | DKIM verification result; see below. |
+--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+
Table 12: Contents of the "dkim" Element
表 12: 「dkim」要素の内容
* "result" is a lowercase string where the value is one of the results defined in Section 2.7.1 of [RFC8601].
* "result" は小文字の文字列で、値は [RFC8601] のセクション 2.7.1 で定義された結果の 1 つです。
Only the "MAIL FROM" identity (see Section 2.4 of [RFC7208]) is used in DMARC.
DMARC では、「MAIL FROM」アイデンティティ ([RFC7208] のセクション 2.4 を参照) のみが使用されます。
+==============+===+===============================================+
| Element name | # | Content |
+==============+===+===============================================+
| domain | R | The domain that was used during validation. |
+--------------+---+-----------------------------------------------+
| scope | O | The source of the domain used during |
| | | validation. |
+--------------+---+-----------------------------------------------+
| result | R | SPF verification result; see below. |
+--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+
Table 13: Contents of the "spf" Element
表 13: 「spf」要素の内容
* The only valid value for the "scope" element is "mfrom".
* 「scope」要素の有効な値は「mfrom」のみです。
* "result" is a lowercase string where the value is one of the results defined in Section 2.7.2 of [RFC8601].
* "result" は小文字の文字列で、値は [RFC8601] のセクション 2.7.2 で定義された結果の 1 つです。
The policy override reason consists of a pre-defined override type and free-text comment; see Section 3.1.6.
ポリシー オーバーライドの理由は、事前定義されたオーバーライド タイプと自由テキストのコメントで構成されます。セクション 3.1.6 を参照してください。
+==============+===+============================================+
| Element name | # | Content |
+==============+===+============================================+
| type | R | The reason the DMARC policy was overridden |
+--------------+---+--------------------------------------------+
| comment | O | [@lang] Further details, if available. |
+--------------+---+--------------------------------------------+
Table 14: Contents of the "reason" Element
表 14: 「reason」要素の内容
In the same report, there MUST be a single DMARC Policy Domain, though there could be multiple RFC5322.From domains. Each RFC5322.From domain will create its own "record" within the report. Consider the case where there are three domains with traffic volume to report: example.com, foo.example.com, and bar.example.com. There will be explicit DMARC Policy Records for example.com and bar.example.com, with distinct policies. There is no explicit DMARC Policy Record for foo.example.com, so it will be reliant on the policy described for example.com. For a report period, there would now be two reports.
同じレポートには、複数の RFC5322.From ドメインが存在する可能性がありますが、単一の DMARC ポリシー ドメインが存在する必要があります。各 RFC5322.From ドメインは、レポート内に独自の「レコード」を作成します。レポートするトラフィック量のあるドメインが 3 つある場合を考えてみましょう: example.com、foo.example.com、bar.example.com。example.com と bar.example.com には、個別のポリシーを持つ明示的な DMARC ポリシー レコードが存在します。foo.example.com には明示的な DMARC ポリシー レコードがないため、example.com について説明されているポリシーに依存します。レポート期間中に 2 つのレポートが存在することになります。
The first report will be for bar.example.com and contain only one "record", for bar.example.com. The second report will be for example.com and will contain multiple "record" elements, one for example.com and one for foo.example.com (and by extension, other "record" elements for subdomains that likewise did not have an explicit DMARC Policy Record).
最初のレポートは bar.example.com 用であり、bar.example.com の「レコード」が 1 つだけ含まれています。2 番目のレポートは example.com となり、複数の「record」要素が含まれます。1 つは example.com で、もう 1 つは foo.example.com です (さらに、同様に明示的な DMARC ポリシー レコードを持たなかったサブドメインの他の「record」要素も含まれます)。
Within a single message, the possibility exists that there could be multiple DKIM signatures. When validation of the message occurs, some signatures may pass, while some may not. As these pertain to DMARC, and especially to aggregate reporting, reporters may not find it clear which DKIM signatures they should include in a report. Signatures, regardless of outcome, could help the report ingester determine the source of a message. However, there is a preference as to which signatures are included.
1 つのメッセージ内に複数の DKIM 署名が存在する可能性があります。メッセージの検証が行われるとき、一部の署名は合格する可能性がありますが、一部の署名は合格しない可能性があります。これらは DMARC、特に集計レポートに関連するため、レポーターはどの DKIM 署名をレポートに含めるべきか明確ではない場合があります。署名は、結果に関係なく、レポート取り込み側がメッセージのソースを特定するのに役立ちます。ただし、どの署名が含まれるかについては優先事項があります。
1. A signature that passes DKIM, in strict alignment with the RFC5322.From domain
1. RFC5322.From ドメインと厳密に整合した、DKIM を通過する署名
2. A signature that passes DKIM, in relaxed alignment with the RFC5322.From domain
2. RFC5322.From ドメインと緩く調整された、DKIM を渡す署名
3. Any other DKIM signatures that pass
3. 合格するその他の DKIM 署名
4. DKIM signatures that do not pass
4. 通過しない DKIM 署名
A report SHOULD contain no more than 100 signatures for a given "row", in decreasing priority.
レポートには、優先順位の低い順に、特定の「行」に対して 100 個以下の署名を含めるべきです (SHOULD)。
There are a few places where a unique identifier is specified as part of the body of the report, the subject, and so on. These unique identifiers should be consistent per each report. Specified below, the reader will see a "Report-ID" and "unique-id". These are the fields that MUST be identical when used.
レポートの本文や件名などの一部として一意の識別子が指定されている場所がいくつかあります。これらの一意の識別子は、各レポートごとに一貫している必要があります。以下に指定すると、リーダーには「レポート ID」と「一意の ID」が表示されます。これらのフィールドは、使用時に同一である必要があります。
Here are a few examples of information contained within the "error" element(s):
「error」要素に含まれる情報の例をいくつか示します。
* DMARC Policy Record evaluation errors (invalid "rua", "sp", etc.)
* DMARC ポリシー レコードの評価エラー (無効な「rua」、「sp」など)
* Multiple DMARC Policy Records at a given location
* 特定の場所にある複数の DMARC ポリシー レコード
Be mindful that the "error" element is an unbounded string but should not contain an extremely large body. Provide enough information to assist the Domain Owner with understanding some issues with their authentication or DMARC Policy Record.
「error」要素は無制限の文字列ですが、極端に大きな本文を含めるべきではないことに注意してください。ドメイン所有者が認証または DMARC ポリシー レコードに関する問題を理解するのに役立つ十分な情報を提供します。
The "reason" element, indicating an override of the DMARC policy, consists of a mandatory "type" element and an optional "comment" element. The "type" element MUST have one of the pre-defined values listed below. The "comment" element is an unbounded string for providing further details.
DMARC ポリシーのオーバーライドを示す「reason」要素は、必須の「type」要素とオプションの「comment」要素で構成されます。「type」要素には、以下にリストされている事前定義された値のいずれかがなければなりません。「comment」要素は、詳細を提供するための無制限の文字列です。
Possible values for the policy override type:
ポリシー オーバーライド タイプの可能な値は次のとおりです。
"local_policy":
"ローカルポリシー":
The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.
メール受信者のローカル ポリシーにより、ドメイン所有者が要求したポリシー アクションの対象からメッセージが除外されました。
"mailing_list":
"メーリングリスト":
Local heuristics determined that the message arrived via a mailing list, and thus authentication of the original message was not expected to succeed.
ローカル ヒューリスティックにより、メッセージがメーリング リスト経由で到着したため、元のメッセージの認証が成功するとは予想されないと判断されました。
"other":
"他の"：
Some policy exception not covered by the other entries in this list occurred. Additional details can be found in the "comment" element.
このリストの他のエントリではカバーされていないポリシー例外が発生しました。追加の詳細は「コメント」要素に記載されています。
"policy_test_mode":
「ポリシーテストモード」:
The message was exempted from application of policy by the testing mode ("t" tag) in the DMARC Policy Record.
メッセージは、DMARC ポリシー レコードのテスト モード (「t」タグ) によってポリシーの適用から除外されました。
"trusted_forwarder":
"trusted_forwarder":
Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.
メッセージ認証の失敗は、ローカルに維持されている既知の信頼できるフォワーダーのリストにメッセージを結び付ける他の証拠によって予期されていました。
The document format supports optional elements for extensions. The absence or existence of this section SHOULD NOT create an error when processing reports. This will be covered in Section 5 ("Extensible Reporting").
ドキュメント形式は、拡張子のオプション要素をサポートしています。このセクションが存在しなくても、レポートを処理するときにエラーが発生してはなりません。これについては、セクション 5 (「拡張レポート」) で説明します。
Note that Domain Owners or their agents may change the published DMARC Policy Record for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following:
ドメイン所有者またはそのエージェントは、ドメインまたはサブドメインの公開された DMARC ポリシー レコードをいつでも変更できることに注意してください。メール受信者の観点から見ると、これはレポート期間中に発生し、メール受信者の実装に応じて、その期間中、レポートが生成されるその期間の終わり、またはその後のレポート期間中に気づく可能性があります。このような状況では、メール受信者が次のいずれかを実行する可能性があります。
* generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element
* このようなレポート期間に対して、レポートに 1 つの「policy_published」要素しか含まれていない場合でも、古いポリシー、または 2 つのポリシーの混合に基づくメッセージの処理を含む単一の集計レポートを生成します。
* generate multiple reports for the same period, one for each published policy occurring during the reporting period
* 同じ期間に対して複数のレポートを生成します。レポート期間中に発生した公開ポリシーごとに 1 つずつレポートを生成します。
Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. Therefore, it is the responsibility of Report Consumers (i.e., vendors) and Domain Owners to be aware of this situation and expect such mixed reports during the propagation of the new policy to Mail Receivers.
このようなポリシーの変更は、特定のドメインでは頻繁に行われないと予想されますが、メール受信側のポリシー監視要件がより厳格になると、インターネット規模では非常に大きな負担が生じます。したがって、この状況を認識し、メール受信者への新しいポリシーの伝播中にそのような混合レポートが発生することを予期するのは、レポート コンシューマ (ベンダー) とドメイン所有者の責任です。
A Mail Receiver discovers reporting requests when it looks up a DMARC Policy Record that corresponds to an RFC5322.From domain on received mail. The presence of the "rua" tag specifies where to send feedback.
メール受信者は、受信メールの RFC5322.From ドメインに対応する DMARC ポリシー レコードを検索するときに、レポート要求を検出します。「rua」タグの存在により、フィードバックの送信先が指定されます。
The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs (see [RFC9989]) in the order given. If any of the URIs are malformed, they SHOULD be ignored. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.
メール受信者は、レポートを作成した後、提供されたレポート URI ([RFC9989] を参照) を指定された順序で評価しなければなりません (MUST)。URI のいずれかが不正な形式である場合、それらは無視されるべきです(SHOULD)。受信者のサポートされる URI の制限まで、残りのすべての URI に集約レポートを配信する試みが行われなければなりません (MUST)。
If delivery is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable), the Mail Receiver MAY cache that data and try again later or MAY discard data that could not be sent.
公開された URI によってアドバタイズされたサービスがレポートを受け入れることができないために配信が不可能な場合 (例、URI が到達不能なサービスを参照している場合)、メール受信者はそのデータをキャッシュして後で再試行してもよい (MAY)、または送信できなかったデータを破棄してもよい (MAY)。
Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism, meaning the report should be delivered over a channel employing TLS (SMTP+STARTTLS).
「rua」タグで指定された URI が特に指定していない場合、フィードバック レポートを生成するメール受信者は安全なトランスポート メカニズムを採用する必要があります (SHOULD)。つまり、レポートは TLS (SMTP+STARTTLS) を採用したチャネル経由で配信される必要があります。
This identifier MUST be unique among reports to the same domain to aid receivers in identifying duplicate reports should they happen. The Report-ID value should be constructed using the following ABNF:
この識別子は、重複レポートが発生した場合に受信者が識別できるように、同じドメインへのレポート間で一意でなければなりません。Report-ID 値は、次の ABNF を使用して構築する必要があります。
ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322
ridtxt = ("<" ridfmt ">") / ridfmt
The format specified here is not very strict, as the key goal is uniqueness. In order to create this uniqueness, the Mail Receiver may wish to use elements such as the receiving domain, the sending domain, and a timestamp in combination. An example string might be "1721054318-example.com@example.org". An alternate could use a date string such as "2024-03-27_example.com@example.org".
主な目的は一意性であるため、ここで指定する形式はそれほど厳密ではありません。この一意性を生み出すために、メール受信者は受信ドメイン、送信ドメイン、タイムスタンプなどの要素を組み合わせて使用することを望む場合があります。文字列の例は、「1721054318-example.com@example.org」などです。代わりに、「2024-03-27_example.com@example.org」などの日付文字列を使用することもできます。
The message generated by the Mail Receiver MUST be as described in [RFC5322] and formatted per [RFC2045]. The aggregate report itself MUST be included in one of the parts of the message, as an attachment with a corresponding media type from below. A human-readable annotation MAY be included as a body part (with a human-friendly content-type, such as "text/plain" or "text/html").
メール受信者によって生成されるメッセージは、[RFC5322] で説明されているとおりであり、[RFC2045] に従ってフォーマットされていなければなりません (MUST)。集計レポート自体は、以下の対応するメディア タイプの添付ファイルとして、メッセージの一部に含める必要があります。人間が読める注釈を本文部分として含めてもよい(MAY) (「text/plain」や「text/html」など、人間にわかりやすいコンテンツタイプを持つ)。
The aggregate data MUST be an XML file that SHOULD be subjected to GZIP [RFC1952] compression. Declining to apply compression can cause the report to be too large for a receiver to process (the total message size could exceed the receiver SMTP size limit); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data MUST be present using the media type "application/gzip" if compressed (see [RFC6713]) and "text/xml" otherwise. The attachment filename MUST be constructed using the following ABNF:
集計データは、GZIP [RFC1952] 圧縮を受ける XML ファイルでなければなりません (MUST)。圧縮の適用を拒否すると、レポートが大きすぎて受信者が処理できない可能性があります (合計メッセージ サイズが受信者の SMTP サイズ制限を超える可能性があります)。圧縮を行うと、ある程度の計算コストはかかりますが、レポートが受け入れられる可能性が高まります。集約データは、圧縮されている場合 ([RFC6713] を参照)、メディア タイプ "application/gzip"、圧縮されていない場合は "text/xml" を使用して存在しなければなりません (MUST)。添付ファイル名は、次の ABNF を使用して作成する必要があります。
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
receiver = domain-name
; imported from RFC 6376
policy-domain = domain-name
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
unique-id = 1*(ALPHA / DIGIT)
extension = "xml" / "xml.gz"
The following primitive tokens that are used but otherwise unspecified are taken from "Core Rules" (Appendix B.1 of [RFC5234]): DIGIT, ALPHA.
使用されているが特に指定されていない次のプリミティブ トークンは、「コア ルール」([RFC5234] の付録 B.1) から取得されています: DIGIT、ALPHA。
The extension MUST be "xml" for a plain XML file or "xml.gz" for an XML file compressed using GZIP.
拡張子は、プレーン XML ファイルの場合は「xml」、GZIP を使用して圧縮された XML ファイルの場合は「xml.gz」でなければなりません。
"unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner. A viable option may be to explore Universally Unique Identifiers (UUIDs) [RFC9562].
「unique-id」を使用すると、メール受信者によって生成されるオプションの一意の ID を使用して、同じドメイン所有者の異なるソースによって同時に生成された複数のレポートを区別できます。実行可能なオプションは、Universally Unique Identifiers (UUID) [RFC9562] を検討することかもしれません。
If a report generator needs to re-send a report, the system MUST use the same filename as the original report. This would allow the receiver to overwrite the data from the original or discard the second instance of the report.
レポート ジェネレーターがレポートを再送信する必要がある場合、システムは元のレポートと同じファイル名を使用しなければなりません。これにより、受信者は元のデータを上書きしたり、レポートの 2 番目のインスタンスを破棄したりすることができます。
For example, this is a sample filename for the gzip file of a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example":
たとえば、これはメール受信者「mail.receiver.example」からドメイン所有者「example.com」へのレポートの gzip ファイルのサンプル ファイル名です。
mail.receiver.example!example.com!1013662812!1013749130.xml.gz
mail.receiver.example!example.com!1013662812!1013749130.xml.gz
No specific MIME message structure is required for the message body. It is presumed that the aggregate reporting address will be equipped to extract body parts with the prescribed media type and filename and ignore the rest.
メッセージ本文に特定の MIME メッセージ構造は必要ありません。集約レポート アドレスには、規定のメディア タイプとファイル名を持つ本文部分を抽出し、残りを無視する機能が備わっていると想定されます。
Mail streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of [RFC9989]). This practice minimizes the risk of Report Consumers processing fraudulent reports.
DMARC フィードバック データを運ぶメール ストリームは DMARC メカニズムに準拠しなければなりません (MUST)。その結果、整列された「パス」が得られます ([RFC9989] のセクション 4.4 を参照)。これにより、レポート利用者が不正なレポートを処理するリスクが最小限に抑えられます。
The RFC5322.Subject field for individual report submissions MUST conform to the following ABNF:
個々のレポート提出の RFC5322.Subject フィールドは、次の ABNF に準拠する必要があります。
; FWS is imported from RFC 5322
dmarc-subject = %s"Report" 1*FWS %s"Domain:"
1*FWS domain-name 1*FWS ; policy domain
%s"Submitter:" 1*FWS
domain-name 1*FWS ; report generator
[ %s"Report-ID:" 1*FWS ridtxt ] ; defined above
The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver.
最初のドメイン名は、レポートが生成された DNS ドメイン名を示します。2 番目のドメイン名は、レポートを生成するメール受信者を表す DNS ドメイン名を示します。フィールドの Report-ID: 部分の目的は、ドメイン所有者がメール受信者によって送信される可能性のある重複レポートを識別して無視できるようにすることです。
For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is folded as allowed by [RFC5322]:
たとえば、これは、メール受信者「mail.receiver.example」からドメイン所有者「example.com」へのレポートの場合に考えられる件名フィールドです。[RFC5322] で許可されているように折りたたまれます。
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <sample-ridtxt@example.com>
This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer.
このトランスポート メカニズムは、フィードバック データ サイズがジェネレーターまたはコンシューマーのいずれかで許容される最大添付ファイル サイズを超えると、問題が発生する可能性があります。
Optionally, the report sender MAY choose to use the same "ridtxt" as a part or whole of the RFC5322.Message-Id header included with the report. Doing so may help receivers distinguish when a message is a re-transmission or duplicate report.
オプションで、レポート送信者は、レポートに含まれる RFC5322.Message-Id ヘッダーの一部または全体として同じ「ridtxt」を使用することを選択してもよい(MAY)。そうすることで、受信者がメッセージが再送信であるか重複レポートであるかを区別するのに役立ちます。
The specification as written allows for the addition of other registered URI schemes to be supported in later versions.
書かれた仕様では、他の登録された URI スキームの追加が、後のバージョンでサポートされるようになります。
There may be a situation where the report generator attempts to deliver duplicate information to the receiver. This may manifest as an exact duplicate of the report or as duplicate information between two reports. In these situations, the decision of how to handle the duplicate data lies with the receiver. As noted above, the sender MUST use the same unique identifiers when sending the report. This allows the receiver to better understand when duplicates happen. Here are a few options on how to handle that duplicate information:
レポート作成者が重複した情報を受信者に配信しようとする状況が発生する可能性があります。これは、レポートの正確な複製、または 2 つのレポート間の重複情報として現れる場合があります。このような状況では、重複データをどのように処理するかは受信側が決定します。上で述べたように、送信者はレポートを送信するときに同じ一意の識別子を使用しなければなりません (MUST)。これにより、受信者は重複がいつ発生したかをよりよく理解できるようになります。重複した情報を処理する方法に関するいくつかのオプションを次に示します。
* Reject back to sender, ideally with a permfail error noting the duplicate receipt
* 送信者に拒否し、理想的には重複した受信を示す permfail エラーを返します。
* Discard upon receipt
* 受け取り次第破棄
* Inspect the contents to evaluate the timestamps and reported data, act as appropriate
* コンテンツを検査してタイムスタンプと報告されたデータを評価し、必要に応じて行動します。
* Accept the duplicate data
* 重複データを受け入れる
When accepting the data, it's likely that the duplicate data has not yet been noticed and is a one-off experience. Long-term duplicate data is not ideal. In the situation of a partial time frame overlap, there is no clear way to distinguish the impact of the overlap. The receiver would need to accept or reject the duplicate data in whole.
データを受け入れるときは、重複データにまだ気づいていない可能性が高く、1 回限りのエクスペリエンスです。長期にわたる重複データは理想的ではありません。部分的な時間枠が重複している状況では、重複の影響を区別する明確な方法はありません。受信側は、重複データ全体を受け入れるか拒否する必要があります。
It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them.
リクエストを行うドメイン所有者の権限の範囲外にあるさまざまなレポートの宛先を指定することができます。これにより、メール サーバーを運用していないドメインでもレポートを要求し、レポートを受信して処理できる場所にレポートを送信することができます。
Without checks, this would allow a bad actor to publish a DMARC Policy Record that requests that reports be sent to a victim address and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.
チェックがなければ、悪意のある攻撃者が被害者のアドレスにレポートを送信するよう要求する DMARC ポリシー レコードを公開し、DKIM チェックと SPF チェックの両方に失敗する大量のメールをさまざまな宛先に送信することが可能になります。被害者には望まない報告が殺到することになります。したがって、検証メカニズムが組み込まれています。
When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:
メール受信者が DNS で DMARC ポリシー レコードを発見し、そのレコードが発見された組織ドメインが、「rua」タグで指定された [RFC3986] の権限コンポーネントのホスト部分の組織ドメインと同一ではない場合、次の検証手順を実行する必要があります。
1. Extract the host portion of the authority component of the URI. Call this the "destination host", as it refers to a Report Receiver.
1. URI の権限コンポーネントのホスト部分を抽出します。レポート受信者を指すため、これを「宛先ホスト」と呼びます。
2. Prepend the string "_report._dmarc".
2. 文字列「_report._dmarc」を先頭に追加します。
3. Prepend the domain name from which the policy was retrieved, after conversion to an A-label [RFC5890] if needed.
3. 必要に応じて、A ラベル [RFC5890] に変換した後、ポリシーの取得元のドメイン名を先頭に追加します。
4. If the length of the constructed name exceed DNS limits, a positive determination of the external reporting relationship cannot be made; stop.
4. 構築された名前の長さが DNS 制限を超える場合、外部レポート関係を肯定的に判断することはできません。停止。
5. Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later.
5. 構築された名前で TXT レコードを DNS にクエリします。このリクエストの結果が、何らかの種類の一時的な DNS エラー (タイムアウトなど) である場合、メール受信者は、後で検証テストを繰り返すことができるように、配信を一時的に失敗することを選択してもよい(MAY)。
6. For each record returned, parse the result as a series of "tag=value" pairs, i.e., the same overall format as the DMARC Policy Record (see Section 4.7 of [RFC9989]). In particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list. Discard any that do not pass this test. A trailing ";" is optional.
6. 返された各レコードについて、結果を一連の「tag=value」ペア、つまり DMARC ポリシー レコードと同じ全体形式として解析します ([RFC9989] のセクション 4.7 を参照)。特に、「v=DMARC1」タグは必須であり、リストの最初に表示されなければなりません。このテストに合格しないものは破棄します。末尾の「;」はオプションです。
7. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.
7. 結果に基本的な解析に合格した TXT リソース レコードが含まれていない場合、外部レポート関係を肯定的に判断することはできません。停止。
8. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Consumer.
8. 解析後に少なくとも 1 つの TXT リソース レコードがセット内に残っている場合、外部レポートの取り決めはレポート コンシューマによって承認されています。
9. If a "rua" tag is thus discovered, replace the corresponding value extracted from the domain's DMARC Policy Record with the one found in this record. This permits the Report Consumer to override the report destination. However, to prevent loops or indirect abuse, the overriding URI MUST use the same destination host from the first step.
9. このようにして「rua」タグが検出された場合は、ドメインの DMARC ポリシー レコードから抽出された対応する値を、このレコード内で見つかった値に置き換えます。これにより、レポート コンシューマがレポートの宛先をオーバーライドできるようになります。ただし、ループや間接的な悪用を防ぐために、オーバーライドする URI は最初のステップから同じ宛先ホストを使用しなければなりません (MUST)。
For example, if the DMARC Policy Record for "blue.example.com" contained "rua=mailto:reports@red.example.net", the Organizational Domain host extracted from the latter ("red.example.net") does not match "blue.example.com", so this procedure is enacted. A TXT query for "blue.example.com._report._dmarc.red.example.net" is issued. If a single reply comes back containing a tag of "v=DMARC1", then the relationship between the two is confirmed. Moreover, "red.example.net" has the opportunity to override the report destination requested by "blue.example.com" if needed.
たとえば、「blue.example.com」の DMARC ポリシー レコードに「rua=mailto:reports@red.example.net」が含まれている場合、後者から抽出された組織ドメイン ホスト (「red.example.net」) は「blue.example.com」と一致しないため、この手順が実行されます。「blue.example.com._report._dmarc.red.example.net」に対する TXT クエリが発行されます。「v=DMARC1」のタグを含む単一の応答が返されれば、両者の関係が確認されます。さらに、「red.example.net」は、必要に応じて、「blue.example.com」によって要求されたレポートの送信先をオーバーライドする機会があります。
Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report. Further, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI. A Report Consumer publishes such a record in its DNS if it wishes to receive reports for other domains.
上記のアルゴリズムが外部レポートがレポート コンシューマによって承認されたことを確認できない場合、レポートを生成するメール受信者は URI を無視しなければなりません (MUST)。さらに、確認レコードに、オーバーライドを公開するドメインとはホストが再び異なる URI が含まれている場合、レポートを生成するメール受信者は、元の URI またはオーバーライド URI へのレポートを生成してはなりません (MUST NOT)。レポート コンシューマは、他のドメインのレポートを受信したい場合、そのようなレコードを DNS に公開します。
A Report Consumer that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.
任意のドメインのレポートを受信するレポート コンシューマは、ワイルドカード DNS レコードを使用できます。たとえば、少なくとも「v=DMARC1」を含む「*._report._dmarc.example.com」の TXT リソース レコードは、example.com が任意のドメインの DMARC レポートを受信する意思があることを確認します。
If the Report Consumer is overcome by volume, it can simply remove the confirming DNS record. However, due to positive caching, the change could take as long as the Time to Live (TTL) on the record to go into effect.
レポート コンシューマの量が多すぎる場合は、確認中の DNS レコードを削除するだけで済みます。ただし、ポジティブ キャッシュのため、変更が有効になるまでにレコードの存続期間 (TTL) と同じくらい時間がかかる可能性があります。
If the DNS query length is excessively long (Step 4 above), the Domain Owner may need to consider using a shorter domain name or coordinate with another party that may allow for a shorter DNS label.
DNS クエリの長さが過度に長い場合 (上記の手順 4)、ドメイン所有者は、より短いドメイン名の使用を検討するか、より短い DNS ラベルを許可する他の当事者と調整する必要がある場合があります。
DMARC reports allow for some extensibility, as defined by future documents that utilize DMARC as a foundation. These extensions MUST be properly formatted XML and meant to exist within the structure of a DMARC report. Two positions of type "<any>" are provided in the existing DMARC structure: one at file level in an "<extension>" element after "<policy_published>" and one at record level after "<auth_results>". In either case, the extensions MUST contain a URI to the definition of the extension so that the receiver understands how to interpret the data.
DMARC レポートでは、DMARC を基盤として利用する将来の文書で定義されるように、ある程度の拡張性が可能です。これらの拡張子は、適切にフォーマットされた XML でなければならず、DMARC レポートの構造内に存在する必要があります。既存の DMARC 構造にはタイプ「<any>」の 2 つの位置が提供されます。1 つは「<policy_published>」の後の「<extension>」要素内のファイル レベルで、もう 1 つは「<auth_results>」の後のレコード レベルです。いずれの場合も、受信者がデータの解釈方法を理解できるように、拡張機能には拡張機能の定義への URI が含まれなければなりません (MUST)。
At file level:
ファイルレベル:
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns:ext="URI for an extension-supplied name space">
...
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>none</sp>
<testing>n</testing>
</policy_published>
<extension>
<ext:arc-override>never</ext:arc-override>
</extension>
Within the "record" element:
「record」要素内:
...
<record>
<row>
...
</row>
<identifiers>
...
</identifiers>
<auth_results>
...
</auth_results>
<ext:arc-results>
...
</ext:arc-results>
</record>
<record>
...
Here "arc-override" and "arc-results" are hypothetical element names defined in the extension's namespace.
ここで、「arc-override」と「arc-results」は、拡張機能の名前空間で定義された仮想の要素名です。
Extension elements are optional. Any number of extensions is allowed. If a processor is unable to handle an extension in a report, it SHOULD ignore the data and continue to the next extension.
拡張要素はオプションです。拡張子はいくつでも許可されます。プロセッサがレポート内の拡張を処理できない場合、データを無視して次の拡張に進むべきです(SHOULD)。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.
この文書では、URN を使用して、[RFC3688] で説明されているレジストリ メカニズムに準拠する XML 名前空間と XML スキーマを記述します。2 つの URI 割り当てが IANA によって登録されています。
IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" group:
IANA は、「IETF XML レジストリ」グループ内の「ns」レジストリに次の URI を登録しました。
URI:
URI:
urn:ietf:params:xml:ns:dmarc-2.0
urn:ietf:params:xml:ns:dmarc-2.0
Registrant Contact:
登録者の連絡先:
The IESG (iesg@ietf.org)
IESG (iesg@ietf.org)
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following URI in the "schema" registry within the "IETF XML Registry" group:
IANA は、「IETF XML レジストリ」グループ内の「スキーマ」レジストリに次の URI を登録しました。
URI:
URI:
urn:ietf:params:xml:schema:dmarc-2.0
urn:ietf:params:xml:スキーマ:dmarc-2.0
Registrant Contact:
登録者の連絡先:
The IESG (iesg@ietf.org)
IESG (iesg@ietf.org)
XML:
XML:
See the DMARC XML schema [W3C.REC-xmlschema-1] [W3C.REC-xmlschema-2] in Appendix A of this document.
このドキュメントの付録 A の DMARC XML スキーマ [W3C.REC-xmlschema-1] [W3C.REC-xmlschema-2] を参照してください。
This section discusses exposure related to DMARC aggregate reporting.
このセクションでは、DMARC 集計レポートに関連するエクスポージャについて説明します。
A DMARC Policy Record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting.
DMARC ポリシー レコードは、ドメイン所有者に代わって動作する仲介者にレポートを送信するように指定できます。これは、ドメイン所有者がメール ストリームの不正使用やパフォーマンスの問題を監視するエンティティと契約するときに行われます。第三者によるそのようなデータの受信は、メール受信者のプライバシー ポリシー、利用規約、またはその他の同様の管理文書によって許可される場合と許可されない場合があります。ドメイン所有者とメール受信者の両方は、独自の内部ポリシーが DMARC レポートの使用と送信を制限しているかどうかを確認し、理解する必要があります。
Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party.
レポート受信者がトラフィック分析を実行して、受信者のトラフィックに関するメタデータを取得できる可能性がいくつかあります。受信者は、ポリシーへの準拠を検証するだけでなく、レポートを第三者に送信する前にそれを考慮する必要があります。
Aggregate feedback reports contain aggregated data relating to messages purportedly originating from the Domain Owner. The data does not contain any identifying characteristics about individual users. No personal information such as individual mail addresses, IP addresses of individuals, or the content of any messages is included in reports.
集約フィードバック レポートには、ドメイン所有者から発信されたとされるメッセージに関連する集約データが含まれています。このデータには、個々のユーザーを識別する特徴は含まれません。レポートには、個人のメール アドレス、IP アドレス、メッセージの内容などの個人情報は含まれません。
Mail Receivers should have no concerns in sending reports, as they do not contain personal information. In all cases, the data within the reports relates to the domain-level authentication information provided by mail servers sending messages on behalf of the Domain Owner. This information is necessary to assist Domain Owners in implementing and maintaining DMARC.
レポートには個人情報が含まれていないため、メール受信者はレポートを送信する際に心配する必要はありません。いずれの場合も、レポート内のデータは、ドメイン所有者に代わってメッセージを送信するメール サーバーによって提供されるドメイン レベルの認証情報に関連しています。この情報は、ドメイン所有者が DMARC を実装および維持するのを支援するために必要です。
Domain Owners should have no concerns in receiving reports, as they do not contain personal information. The reports only contain aggregated data related to the domain-level authentication details of messages claiming to originate from their domain. This information is essential for the proper implementation and operation of DMARC. Domain Owners who are unable to receive reports for organizational reasons can choose to exclusively direct the reports to an external processor.
ドメイン所有者は、個人情報が含まれていないため、レポートを受け取ることを心配する必要はありません。レポートには、ドメインから発信されたと主張するメッセージのドメイン レベルの認証の詳細に関連する集計データのみが含まれます。この情報は、DMARC の適切な実装と運用に不可欠です。組織上の理由によりレポートを受信できないドメイン所有者は、レポートを外部処理者のみに送信することを選択できます。
Providing feedback reporting to Public Suffix Operators (PSOs) for a Public Suffix Domain (PSD) [RFC9989] can, in some cases, cause information to leak out of an organization to the PSO. This leakage could potentially be utilized as part of a program of pervasive surveillance (see [RFC7624]). There are roughly three cases to consider:
パブリック サフィックス ドメイン (PSD) [RFC9989] のパブリック サフィックス オペレーター (PSO) にフィードバック レポートを提供すると、場合によっては、情報が組織から PSO に漏洩する可能性があります。この漏洩は、広範な監視プログラムの一部として利用される可能性があります ([RFC7624] を参照)。考慮すべきケースは大きく 3 つあります。
Single Organization PSDs (e.g., ".mil"):
単一組織の PSD (例: 「.mil」):
Aggregate reports based on PSD DMARC have the potential to contain information about mail related to entities managed by the organization. Since both the PSO and the Organizational Domain Owners are common, there is no additional privacy risk for either normal or non-existent domain reporting due to PSD DMARC.
PSD DMARC に基づく集計レポートには、組織によって管理されているエンティティに関連するメールに関する情報が含まれる可能性があります。PSO と組織のドメイン所有者は両方とも共通であるため、PSD DMARC による通常のドメイン レポートまたは存在しないドメイン レポートによる追加のプライバシー リスクはありません。
Multi-organization PSDs requiring DMARC usage (e.g., ".bank"):
DMARC の使用を必要とする複数組織 PSD (例: 「.bank」):
Aggregate reports based on PSD DMARC will only be generated for domains that do not publish a DMARC Policy Record at the Organizational Domain or host level. For domains that do publish the required DMARC Policy Records, the feedback reporting addresses of the Organizational Domain (or hosts) will be used. The only direct risk of feedback leakage for these PSDs are for Organizational Domains that are out of compliance with PSD policy. Data on non-existent domains would be sent to the PSO.
PSD DMARC に基づく集計レポートは、組織ドメインまたはホスト レベルで DMARC ポリシー レコードを公開していないドメインに対してのみ生成されます。必要な DMARC ポリシー レコードを公開するドメインの場合、組織ドメイン (またはホスト) のフィードバック レポート アドレスが使用されます。これらの PSD のフィードバック漏洩の直接的なリスクは、PSD ポリシーに準拠していない組織ドメインのみです。存在しないドメイン上のデータは PSO に送信されます。
Multi-organization PSDs not requiring DMARC usage (e.g., ".com"):
DMARC の使用を必要としない複数組織 PSD (例: 「.com」):
Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs can be significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO if that PSO itself has a DMARC Policy Record that specifies a "rua" tag. Any non-DMARC Organizational Domain would have its feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive.
このような PSD 内に DMARC を展開していない組織ドメインのプライバシー リスクは重大になる可能性があります。非 DMARC 組織ドメインの場合、PSO 自体に「rua」タグを指定する DMARC ポリシー レコードがある場合、すべての DMARC フィードバックは PSO に送られます。DMARC 以外の組織ドメインでは、フィードバック レポートが PSO にリダイレクトされます。このようなレポートの内容は、特に既存のドメインに関してはプライバシーに配慮したものです。
PSOs will receive feedback on non-existent domains, which may be similar to existing Organizational Domains. Feedback related to such domains have a small risk of carrying information related to an actual Organizational Domain. To minimize this potential concern, PSD DMARC feedback MUST be limited to aggregate reports. Failure reports carry more detailed information and present a greater risk.
PSO は、既存の組織ドメインと同様の、存在しないドメインに関するフィードバックを受け取ります。このようなドメインに関連するフィードバックには、実際の組織ドメインに関連する情報が含まれるリスクがわずかにあります。この潜在的な懸念を最小限に抑えるために、PSD DMARC フィードバックは集計レポートに限定されなければなりません。障害レポートにはより詳細な情報が含まれており、より大きなリスクが生じます。
While reviewing this document and its security considerations, it is ideal that the reader also review the Privacy Considerations section above, as well as the privacy considerations and security considerations in Sections 10 and 11 of [RFC9989].
この文書とそのセキュリティに関する考慮事項を検討する際、読者は上記のプライバシーに関する考慮事項のセクション、および [RFC9989] のセクション 10 および 11 のプライバシーに関する考慮事項とセキュリティに関する考慮事項も確認することが理想的です。
Aggregate reports are supposed to be processed automatically. An attacker might attempt to compromise the integrity or availability of the report processor by sending malformed reports. In particular, the archive decompressor and XML parser are at risk to resource exhaustion attacks (zip bomb or XML bomb).
集計レポートは自動的に処理されることになっています。攻撃者は、不正な形式のレポートを送信することで、レポート プロセッサの整合性や可用性を侵害しようとする可能性があります。特に、アーカイブ解凍プログラムと XML パーサーは、リソース枯渇攻撃 (zip ボムまたは XML ボム) の危険にさらされています。
The data contained within aggregate reports may be forged. An attacker might attempt to interfere with or influence policy decisions by submitting false reports in large volume. The attacker could also be attempting to influence platform architecture decisions. A volume-based attack may also impact the ability for a Report Receiver to accept reports from other entities.
集計レポートに含まれるデータは偽造される可能性があります。攻撃者は、虚偽のレポートを大量に送信することで、ポリシーの決定に干渉したり影響を与えようとしたりする可能性があります。攻撃者は、プラットフォーム アーキテクチャの決定に影響を与えようとしている可能性もあります。ボリュームベースの攻撃は、レポート受信者が他のエンティティからレポートを受け入れる能力にも影響を与える可能性があります。
While not specified in this document itself, the availability of extensions could enable the report generator to disclose information about message placement (Inbox/Spam/etc.). This is very much discouraged as it could relay this information to a malicious party, allowing them to understand more about filtering methodologies at a receiving entity.
このドキュメント自体には明記されていませんが、拡張機能を利用すると、レポート ジェネレーターがメッセージの配置 (受信箱/スパムなど) に関する情報を開示できる可能性があります。これは、この情報を悪意のある当事者に中継して、受信側エンティティでのフィルタリング方法についてさらに理解できるようにする可能性があるため、非常に推奨されません。
* The error fields should be reasonably terse and usable.
* エラーフィールドは適度に簡潔で使いやすいものにする必要があります。
* If reports cannot be generated, the system should ideally log a useful error that helps troubleshoot the issue.
* レポートを生成できない場合、システムは問題のトラブルシューティングに役立つ有用なエラーをログに記録することが理想的です。
As noted above, if a report does not match the specified format, the evaluator will likely find the contents to be in question. Alternately, the evaluator may decide to sideline those reports so they can more easily collaborate with the report generator to identify where the issues are happening.
上で述べたように、レポートが指定された形式と一致しない場合、評価者はその内容に問題があると判断する可能性があります。あるいは、評価者は、問題が発生している場所を特定するためにレポート作成者とより簡単に連携できるように、それらのレポートを脇に置くことを決定する場合もあります。
It's quite likely that the data contained within the reports will be extracted and stored in a system that allows for easy reporting, dashboarding, and/or monitoring. The XML reports themselves are not human readable in bulk, and a system such as the above may aid the Domain Owner with identifying issues.
レポートに含まれるデータが抽出され、簡単なレポート作成、ダッシュボード作成、監視を可能にするシステムに保存される可能性が非常に高くなります。XML レポート自体は人間が大量に読み取れるものではないため、上記のようなシステムはドメイン所有者が問題を特定するのに役立つ可能性があります。
Once a report is accepted and properly parsed by the report evaluator, it is entirely up to that evaluator as to what they wish to do with the XML documents. For some domains, the quantity of reports could be fairly high, or the size of the reports themselves could be large. Once the data from the reports has been extracted and indexed, the reports seemingly have little value in most situations.
レポートが受け入れられ、レポート評価者によって適切に解析されると、XML ドキュメントをどのように処理するかは完全に評価者次第になります。一部のドメインでは、レポートの量がかなり多くなる場合や、レポート自体のサイズが大きくなる場合があります。レポートのデータが抽出され、インデックスが作成されると、ほとんどの状況ではレポートにはほとんど価値がないようです。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip'
Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012,
<https://www.rfc-editor.org/info/rfc6713>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>.
[RFC9989] Herr, T., Ed. and J. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/info/rfc9989>.
[W3C.REC-xmlschema-1]
Thompson, H. S., Ed., Beech, D., Ed., Maloney, M., Ed.,
and N. Mendelsohn, Ed., "XML Schema Part 1: Structures
Second Edition", W3C Recommendation, 28 October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
Latest version available at
https://www.w3.org/TR/xmlschema-1/.
[W3C.REC-xmlschema-2]
Biron, P. V., Ed. and A. Malhotra, Ed., "XML Schema Part
2: Datatypes Second Edition", W3C Recommendation, 28
October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
Latest version available at
https://www.w3.org/TR/xmlschema-2/.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
[RFC9991] Jones, S., Ed. and A. Vesely, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC) Failure
Reporting", RFC 9991, DOI 10.17487/RFC9991, May 2026,
<https://www.rfc-editor.org/info/rfc9991>.
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
elementFormDefault="qualified">
<!-- Elements with an optional "lang" attribute. -->
<xs:complexType name="langAttrString">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"
use="optional" default="en"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- The time range in UTC defining the reporting period of
this report, specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
<xs:element name="end" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Report generator metadata. -->
<xs:complexType name="ReportMetadataType">
<xs:all>
<!-- Reporting Organization -->
<xs:element name="org_name" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- Contact to use when contacting the Reporting Organization -->
<xs:element name="email" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- Additional contact details -->
<xs:element name="extra_contact_info" type="langAttrString"
minOccurs="0" maxOccurs="1"/>
<!-- Unique Report-ID -->
<xs:element name="report_id" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- Timestamps used when forming report data -->
<xs:element name="date_range" type="DateRangeType"
minOccurs="1" maxOccurs="1"/>
<!-- Optional error messages when processing DMARC policy -->
<xs:element name="error" type="langAttrString"
minOccurs="0" maxOccurs="1"/>
<!-- Optional information about the generating software -->
<xs:element name="generator" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="s"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions specified by p, sp, and np in the
DMARC Policy Record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions utilized on messages for this record. -->
<!--
"none": No action taken
"pass": No action, passing DMARC w/enforcing policy
"quarantine": Failed DMARC, message marked for quarantine
"reject": Failed DMARC, marked as reject
-->
<xs:simpleType name="ActionDispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The method used to discover the DMARC Policy Record used during
evaluation. The available values are "psl" and "treewalk",
where "psl" is the method from RFC 7489 and "treewalk" is
described in RFC 9989. -->
<xs:simpleType name="DiscoveryType">
<xs:restriction base="xs:string">
<xs:enumeration value="psl"/>
<xs:enumeration value="treewalk"/>
</xs:restriction>
</xs:simpleType>
<!-- The published DMARC policy. Unspecified tags have their
default values. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The policy published for messages from: -->
<!-- * the domain. -->
<xs:element name="p" type="DispositionType"
minOccurs="1" maxOccurs="1"/>
<!-- * subdomains. -->
<xs:element name="sp" type="DispositionType"
minOccurs="0" maxOccurs="1"/>
<!-- * non-existent subdomains. -->
<xs:element name="np" type="DispositionType"
minOccurs="0" maxOccurs="1"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0" maxOccurs="1"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0" maxOccurs="1"/>
<!-- Method used to find/obtain DMARC policy. -->
<xs:element name="discovery_method" type="DiscoveryType"
minOccurs="0" maxOccurs="1"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<!-- Whether testing mode was declared in the DMARC Record. -->
<xs:element name="testing" type="TestingType"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Values for Testing mode attached to policy. -->
<xs:simpleType name="TestingType">
<xs:restriction base="xs:string">
<xs:enumeration value="n"/>
<xs:enumeration value="y"/>
</xs:restriction>
</xs:simpleType>
<!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
</xs:restriction>
</xs:simpleType>
<!-- Reasons that may affect DMARC disposition or execution. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="local_policy"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="other"/>
<xs:enumeration value="policy_test_mode"/>
<xs:enumeration value="trusted_forwarder"/>
</xs:restriction>
</xs:simpleType>
<!-- Override reason consists of pre-defined override type and
free-text comment. -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="comment" type="langAttrString"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. If alignment fails
and the policy applied does not match the domain's
configured policy, the reason element MUST be specified. -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="ActionDispositionType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="dkim" type="DMARCResultType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="spf" type="DMARCResultType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RowType">
<xs:all>
<!-- The connecting IP. IPv4address or IPv6address
as defined in RFC 3986, Section 3.2.2. -->
<xs:element name="source_ip" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The number of messages for which the
PolicyEvaluatedType was applied. -->
<xs:element name="count" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
<!-- The DMARC disposition applied to matching messages. -->
<xs:element name="policy_evaluated" type="PolicyEvaluatedType"
minOccurs="1" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- DKIM verification result; see RFC 8601, Section 2.7.1. -->
<xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DKIMAuthResultType">
<xs:all>
<!-- The "d=" tag in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The "s=" tag in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1" maxOccurs="1"/>
<!-- Any extra information (e.g., from Authentication-Results). -->
<xs:element name="human_result" type="langAttrString"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF verification result; see RFC 8601, Section 2.7.2. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="SPFAuthResultType">
<xs:all>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope"
minOccurs="0" maxOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="1" maxOccurs="1"/>
<!-- Any extra information (e.g., from Authentication-Results).
The information in the field below should be for a
person to be provided with additional information
that may be useful when debugging SPF authentication
issues. This could include broken records, invalid
DNS responses, etc. -->
<xs:element name="human_result" type="langAttrString"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. -->
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be zero or more DKIM signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There may be zero or one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of
messages. -->
<xs:complexType name="RecordType">
<xs:sequence>
<xs:element name="row" type="RowType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="identifiers" type="IdentifierType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="auth_results" type="AuthResultType"
minOccurs="1" maxOccurs="1"/>
<!-- Extension at record level -->
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ExtensionType">
<xs:sequence>
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version" type="xs:decimal"
minOccurs="0" maxOccurs="1"/>
<xs:element name="report_metadata" type="ReportMetadataType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="policy_published" type="PolicyPublishedType"
minOccurs="1" maxOccurs="1"/>
<!-- Extension at top level -->
<xs:element name="extension" type="ExtensionType"
minOccurs="0" maxOccurs="1"/>
<!-- One record (IP, result, IDs Auths) per tuple -->
<xs:element name="record" type="RecordType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
<version>1.0</version>
<report_metadata>
<org_name>Sample Reporter</org_name>
<email>report_sender@example-reporter.com</email>
<extra_contact_info>...</extra_contact_info>
<report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>
<date_range>
<begin>302832000</begin>
<end>302918399</end>
</date_range>
<generator>Example DMARC Aggregate Reporter v1.2</generator>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>none</sp>
<np>none</np>
<testing>n</testing>
<discovery_method>treewalk</discovery_method>
</policy_published>
<record>
<row>
<source_ip>192.0.2.123</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>pass</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>example.com</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>abc123</selector>
</dkim>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>
Here is a bulleted list of some of the more noticeable/important differences between DMARC [RFC7489] and this document:
以下は、DMARC [RFC7489] とこの文書の間の最も顕著/重要な相違点のいくつかを箇条書きで示したものです。
* Many elements of the defining XSD have been clarified, which means the structure of the report should be more consistent
* XSD を定義する多くの要素が明確化されたため、レポートの構造はより一貫したものになる必要があります。
* The report identifier has more structure
* レポート識別子にはさらに多くの構造があります
* Clarification provided about the number of domains to be addressed per report
* レポートごとに対処されるドメインの数についての明確化
* The addition of extensions as part of the report structure
* レポート構造の一部としての拡張機能の追加
* PSD is now included as part of the specification
* PSD が仕様の一部として含まれるようになりました
* Selector is now required when reporting a DKIM signature
* DKIM 署名を報告するときにセレクターが必須になりました
Furthermore, the original DMARC specification was contained within a single document: [RFC7489]. The original document has been split into three documents: [RFC9989], this document, and [RFC9991]. This allows these pieces to potentially be altered in the future without re-opening the entire document, as well as allowing them to move through the IETF process independently.
さらに、元の DMARC 仕様は単一の文書 [RFC7489] に含まれていました。元の文書は、[RFC9989]、この文書、および [RFC9991] の 3 つの文書に分割されました。これにより、これらの部分は、ドキュメント全体を再度開くことなく、将来的に変更される可能性があり、IETF プロセスを個別に通過できるようになります。
Many thanks are deserved to those that helped create this document. Much of the content was created from [RFC7489] and has now been updated to be more clear and correct some outstanding issues. The IETF DMARC Working Group has spent much time working to finalize this effort, and significant contributions were made by Seth Blank, Todd Herr, Steve Jones, Scott Kitterman, Murray S. Kucherawy, Daniel Kvål, Barry Leiba, John Levine, Martijn van der Lee, Alessandro Veseley, and Matthäus Wander.
この文書の作成に協力していただいた方々に多大な感謝を申し上げます。コンテンツの多くは [RFC7489] から作成されており、より明確になり、いくつかの未解決の問題が修正されるように更新されました。IETF DMARC ワーキング グループは、この取り組みを完成させるために多くの時間を費やし、Seth Blank、Todd Herr、Steve Jones、Scott Kitterman、Murray S. Kucherawy、Daniel Kvål、Barry Leiba、John Levine、Martijn van der Lee、Alessandro Veseley、Matthaus Wander によって多大な貢献が行われました。
Alex Brotman (editor)
Comcast, Inc.
Email: alex_brotman@comcast.com