[要約] RFC 9991は、DMARCにおいて認証に失敗した個々のメールの詳細を提供する「失敗レポート」（フォレンジックレポート）の仕組みを定義した Proposed Standard（標準化トラック）文書です。プライバシー保護のための機密データ削除に関する規程を明文化し、RFC 6591を更新、RFC 7489を廃止します。
Internet Engineering Task Force (IETF) S. Jones, Ed.
Request for Comments: 9991 DMARC.org
Obsoletes: 7489 A. Vesely, Ed.
Updates: 6591 Tana
Category: Standards Track May 2026
ISSN: 2070-1721
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism.
ドメインベースのメッセージ認証、レポート、および適合性 (DMARC) は、ドメイン所有者が [From:] アドレス フィールドで自分のドメインを使用して電子メール メッセージに関するフィードバックを要求できるメカニズムです。このドキュメントでは、DMARC メカニズムに従って認証に失敗した個々のメッセージの詳細を提供する「失敗レポート」または「失敗メッセージ レポート」について説明します。
This document updates RFC 6591 and obsoletes RFC 7489.
この文書は RFC 6591 を更新し、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/rfc9991.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9991 で入手できます。
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.2. Document Status
2. DMARC Failure Reports
3. Other Failure Reports
4. Reporting Format Update
5. Verifying External Destinations
5.1. Transport
6. IANA Considerations
6.1. Feedback Report Header Fields Registry Update
7. Privacy Considerations
7.1. Data Exposure Considerations
7.2. Report Recipients
7.3. Additional Damage
8. Security Considerations
8.1. Denial of Service
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example Failure Report
Authors' Addresses
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] is a mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting that can be used by a mail-receiving organization to improve mail handling. This document focuses on one type of reporting that can be requested under DMARC.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] は、メール送信元の組織が、メッセージの検証、処理、およびレポートに関するドメインレベルのポリシーと設定を表現できるメカニズムであり、メール受信組織がメール処理を改善するために使用できます。このドキュメントでは、DMARC で要求できる 1 つのタイプのレポートに焦点を当てます。
Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. Their purpose is twofold. On the one hand, they are meant to aid in cases where a Domain Owner wishes to determine the cause of failures that were part of aggregate reports (see [RFC9990]). On the other hand, they can allow the Domain Owner to quickly identify and address harmful messages involving direct domain abuse. It is important to note that these reports can contain the header fields or sometimes the entire content of a failed message, which may contain Personally Identifiable Information (PII). The potential disclosure of PII should be considered when deciding whether to request failure reports as a Domain Owner, or what information to include or redact in failure reports when creating them as a Mail Receiver, or whether to create failure reports at all. Refer to Section 7 for more discussion on privacy considerations.
障害レポートは、単一のメッセージの障害、または同じ理由で失敗した類似のメッセージのグループに関する詳細情報を提供します。彼らの目的は 2 つあります。一方で、これらはドメイン所有者が集約レポートの一部であった障害の原因を特定したい場合に役立つことを目的としています ([RFC9990] を参照)。一方、ドメイン所有者は、直接的なドメイン悪用を伴う有害なメッセージを迅速に特定して対処できるようになります。これらのレポートには、個人を特定できる情報 (PII) が含まれる可能性がある、失敗したメッセージのヘッダー フィールド、または場合によってはコンテンツ全体が含まれる可能性があることに注意することが重要です。ドメイン所有者として障害レポートを要求するかどうか、メール受信者として障害レポートを作成するときに障害レポートにどの情報を含めるか編集するか、あるいはそもそも障害レポートを作成するかどうかを決定する際には、PII の開示の可能性を考慮する必要があります。プライバシーに関する考慮事項の詳細については、セクション 7 を参照してください。
There are a number of terms defined in Section 3.2 of [RFC9989] that are used within this document. Understanding those definitions will aid in reading this document.
[RFC9989] のセクション 3.2 で定義されている多くの用語がこの文書内で使用されています。これらの定義を理解すると、このドキュメントを読むのに役立ちます。
The format of DMARC failure reports is derived from "Authentication Failure Reporting Using the Abuse Reporting Format" [RFC6591], and the terms defined there are used here.
DMARC 失敗レポートの形式は、「不正行為レポート形式を使用した認証失敗レポート」[RFC6591] から派生しており、ここではそこで定義されている用語が使用されます。
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] で説明されているように解釈されます。
This document, in part, along with [RFC9989] and [RFC9990], obsoletes and replaces [RFC7489].
この文書の一部は、[RFC9989] および [RFC9990] とともに廃止され、[RFC7489] に置き換わります。
Besides the header fields or the entire contents of a failed message, failure reports supply details about transmission and DMARC authentication, which may aid a Domain Owner in determining the cause of an authentication failure.
ヘッダー フィールドや失敗したメッセージの内容全体に加えて、失敗レポートには送信と DMARC 認証に関する詳細が提供され、ドメイン所有者が認証失敗の原因を特定するのに役立ちます。
Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Failure reports also provide more information about the failed message than is available in an aggregate report. This allows the failure report consumer to better determine whether the failure is of a message that the Domain Owner intended to authenticate or one for which use of its domain was not authorized.
障害レポートは通常、メール受信者が DMARC 障害を検出した直後に生成され、送信されます。これらのレポートは、集約レポートを待つのではなく、認証失敗時にドメイン所有者に迅速に通知するのに役立ちます。失敗レポートでは、集約レポートで得られる情報よりも失敗したメッセージに関する詳細な情報も提供されます。これにより、障害レポートの利用者は、その障害がドメイン所有者が認証しようとしたメッセージによるものか、ドメインの使用が許可されていないメッセージによるものかどうかをより適切に判断できるようになります。
These reports should include as much of the message header fields and body as possible, consistent with the reporting party's privacy policies, to enable the Domain Owner to diagnose the authentication failure.
これらのレポートには、ドメイン所有者が認証の失敗を診断できるように、報告者のプライバシー ポリシーに従って、メッセージ ヘッダー フィールドと本文をできるだけ多く含める必要があります。
When a Domain Owner requests failure reports for the purpose of forensic analysis, and the Mail Receiver is willing to provide such reports, the Mail Receiver generates and sends a message using the format described in [RFC6591]; this document updates that reporting format, as described in Section 4.
ドメイン所有者がフォレンジック分析の目的で障害レポートを要求し、メール受信者がそのようなレポートを提供する意思がある場合、メール受信者は [RFC6591] で説明されている形式を使用してメッセージを生成して送信します。この文書では、セクション 4 で説明されているように、そのレポート形式が更新されます。
The destination(s) to which failure reports are sent, and options for when they will be sent, are defined by the "ruf" and "fo" tags as provided in Section 4.7 of [RFC9989].
障害レポートが送信される宛先、および送信されるタイミングのオプションは、[RFC9989] のセクション 4.7 に規定されているように、「ruf」タグと「fo」タグによって定義されます。
When multiple Uniform Resource Identifiers (URIs) are provided to receive failure reports, the report generator MUST make an attempt to deliver to each of them. External destinations MUST be verified (see Section 5). Report generators MUST NOT consider "ruf" tags in DMARC Policy Records that have a "psd=y" tag, unless there are specific agreements between the interested parties.
失敗レポートを受信するために複数の URI (Uniform Resource Identifier) が提供されている場合、レポート生成者はそれぞれの URI に配信を試みなければなりません (MUST)。外部宛先は検証されなければなりません (セクション 5 を参照)。レポート生成者は、関係者間で特別な合意がない限り、「psd=y」タグを持つ DMARC ポリシー レコード内の「ruf」タグを考慮してはなりません (MUST NOT)。
Report generators MUST implement a rate-limit on outgoing reports so as not to flood Report Consumers with excessive reports, which would allow denial of service (see Section 8.1).
レポート生成者は、レポート利用者に過度のレポートを大量に送り込み、サービス妨害を可能にすることがないように、送信レポートにレート制限を実装しなければなりません (セクション 8.1 を参照)。
This document only describes DMARC failure reports. DomainKeys Identified Mail (DKIM) failure reports and Sender Policy Framework (SPF) failure reports are described in [RFC6591]. A Mail Receiver that generates DMARC failure reports MAY choose to issue failure reports of the type specific to the authentication mechanism that failed instead of, or in addition to, the DMARC failure report type described here. The Receiver SHALL determine which failure report types, if any, to transmit based on its own policy, the failure in question, and the content of the "fo" tag in the retrieved DMARC Policy Record.
このドキュメントでは、DMARC 障害レポートについてのみ説明します。DomainKeys Identified Mail (DKIM) 障害レポートと Sender Policy Framework (SPF) 障害レポートは [RFC6591] で説明されています。DMARC 失敗レポートを生成するメール受信者は、ここで説明する DMARC 失敗レポート タイプの代わりに、またはそれに加えて、失敗した認証メカニズムに固有のタイプの失敗レポートを発行することを選択してもよい(MAY)。受信者は、受信者自身のポリシー、問題の障害、および取得した DMARC ポリシー レコード内の "fo" タグの内容に基づいて、送信する障害レポート タイプ (存在する場合) を決定するものとします (SHALL)。
Note that DKIM failure reports and SPF failure reports can also be requested using the methods described in [RFC6651] and [RFC6652], respectively. Report generators are free to follow any of the specifications.
DKIM 障害レポートと SPF 障害レポートは、それぞれ [RFC6651] と [RFC6652] で説明されている方法を使用して要求することもできることに注意してください。レポート生成者は、どの仕様にも自由に従うことができます。
Operators implementing this specification also implement an augmented version of failure reporting described in [RFC6591] as follows:
この仕様を実装するオペレータは、[RFC6591] で説明されている障害レポートの拡張バージョンも次のように実装します。
1. A DMARC failure report includes the following Abuse Reporting Format (ARF) header fields, with the indicated normative requirement levels:
1. DMARC 障害レポートには、指定された規範要件レベルを持つ次の Abuse Reporting Format (ARF) ヘッダー フィールドが含まれます。
* Identity-Alignment (REQUIRED; defined below)
* アイデンティティの調整 (必須、以下で定義)
* Delivery-Result (OPTIONAL)
* 配信結果 (オプション)
* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM failures of an aligned identifier)
* DKIM-Domain、DKIM-Identity、DKIM-Selector (整列された識別子の DKIM エラーの場合は必須)
* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if reporting a DKIM failure)
* DKIM-Canonicalized-Header、DKIM-Canonicalized-Body (DKIM 障害を報告する場合はオプション)
* SPF-DNS (REQUIRED for SPF failure of an aligned identifier)
* SPF-DNS (整列された識別子の SPF エラーの場合に必須)
2. The Identity-Alignment field is defined to contain a comma-separated list of authentication mechanism names that failed to authenticate an aligned identity or the keyword "none" if all of the attempted methods were successful at authenticating an aligned identity. Here is the ABNF [RFC5234] (importing comments and/or folding white space (CFWS) from [RFC5322]):
2. Identity-Alignment フィールドは、アライメントされた ID の認証に失敗した認証メカニズム名のカンマ区切りのリスト、または試行されたすべてのメソッドがアライメントされた ID の認証に成功した場合はキーワード「none」を含むように定義されます。以下は ABNF [RFC5234] ([RFC5322] からのコメントおよび/または折りたたみ空白 (CFWS) のインポート) です。
id-align = "Identity-Alignment:" [CFWS]
( "none" /
dmarc-method
*( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS]
dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align
3. Authentication Failure Type "dmarc" is defined for the Auth-Failure field, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator MAY also independently produce an ARF message for any or all of the underlying authentication methods.
3. 認証失敗タイプ「dmarc」は、Auth-Failure フィールドに定義されており、認証メカニズムの一部またはすべてが整合した識別子の生成に失敗したために失敗レポートが生成されるときに使用されます。失敗レポート ジェネレータは、基礎となる認証方法の一部またはすべてに対して ARF メッセージを独立して生成してもよいことに注意してください。
It is possible to specify destinations for failure reports that are outside of the Organizational Domain of the DMARC Policy Record that was requesting the reports. These destinations are commonly referred to as "external destinations" and may represent a different domain controlled by the same organization, a contracted report processing service, or some other arrangement.
レポートを要求していた DMARC ポリシー レコードの組織ドメインの外部にある障害レポートの宛先を指定することができます。これらの宛先は一般に「外部宛先」と呼ばれ、同じ組織、契約したレポート処理サービス、またはその他の取り決めによって制御される別のドメインを表す場合があります。
In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.
外部宛先の場合、失敗レポートを生成するメール受信者は、[RFC9990] のセクション 4 で説明されている外部宛先の検証手順を使用し、その手順で「rua」タグが出現する箇所を「ruf」タグに置き換えなければなりません (MUST)。
This prevents a bad actor from publishing a DMARC Policy Record requesting failure reports to an external destination and then deliberately sending messages that will generate failure reports as a form of abuse. It also prevents a Domain Owner from unilaterally publishing a DMARC Policy Record with an external destination for failure reports, forcing the external destination to deal with unwanted messages and potential privacy issues.
これにより、悪意のある攻撃者が、外部の宛先に障害レポートを要求する DMARC ポリシー レコードを公開し、不正行為として障害レポートを生成するメッセージを意図的に送信することを防ぎます。また、ドメイン所有者が障害レポートの外部宛先を指定して DMARC ポリシー レコードを一方的に公開し、外部宛先が不要なメッセージや潜在的なプライバシー問題に対処することを強制することも防止します。
Email streams carrying DMARC failure reports SHOULD be DMARC-aligned.
DMARC 障害レポートを運ぶ電子メール ストリームは DMARC に合わせてある必要があります (SHOULD)。
We recommend that reporters set a reasonable rate-limit for the number of failure reports sent to any recipient to avoid overloading recipient systems. Unaligned reports may in turn produce subsequent failure reports that could cause mail loops.
受信者のシステムに過負荷がかかるのを避けるために、受信者に送信される障害レポートの数に適切なレート制限を設定することをお勧めします。調整されていないレポートにより、後続の失敗レポートが生成され、メール ループが発生する可能性があります。
IANA has updated the reference and description for the "Identity-Alignment" entry in the "Feedback Report Header Fields" registry within the "Messaging Abuse Reporting Format (MARF) Parameters" registry group, as follows:
IANA は、「Messaging Abuse Reporting Format (MARF) Parameters」レジストリ グループ内の「Feedback Report Header Fields」レジストリの「Identity-Alignment」エントリの参照と説明を次のように更新しました。
Field Name:
フィールド名:
Identity-Alignment
アイデンティティの調整
Description:
説明：
a list of authentication mechanism names that failed to authenticate an aligned identity, or "none" if all were successful
調整された ID の認証に失敗した認証メカニズム名のリスト、またはすべてが成功した場合は「なし」
Multiple Appearances:
複数の外観:
No
いいえ
Related "Feedback-Type":
関連する「フィードバック タイプ」:
auth-failure
認証失敗
Reference:
参照：
RFC 9991
RFC 9991
Status:
状態：
current
現在
The generation and transmission of DMARC failure reports raise significant privacy concerns that must be carefully considered before deployment.
DMARC 障害レポートの生成と送信は、プライバシーに関する重大な懸念を引き起こすため、導入前に慎重に検討する必要があります。
Given these factors, many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports, which provide statistical visibility without exposing sensitive content. Operators that choose to enable failure reporting are strongly encouraged to:
これらの要因を考慮して、多くの大規模プロバイダーは障害レポートの生成を制限するか完全に無効にし、機密コンテンツを公開せずに統計的な可視性を提供する集計レポートに依存することを好みます。障害レポートを有効にすることを選択したオペレーターは、次のことを強くお勧めします。
* Limit the scope and duration of use to targeted diagnostic activities;
* 使用範囲と期間を、対象を絞った診断活動に限定します。
* Ensure that reporting URIs are carefully controlled and validated;
* レポート URI が注意深く管理され、検証されていることを確認します。
* Apply minimization techniques, such as redaction of message bodies and header fields, to reduce sensitive data exposure;
* メッセージ本文やヘッダー フィールドの編集などの最小化手法を適用して、機密データの公開を減らします。
* Always transmit reports over secure channels.
* レポートは常に安全なチャネル経由で送信してください。
In summary, while DMARC failure reports can offer diagnostic value, the associated privacy concerns have led many operators to restrict their use. Aggregate reports remain the recommended mechanism for gaining visibility into authentication results while preserving the confidentiality of end-user communications.
要約すると、DMARC 障害レポートは診断上の価値を提供できますが、関連するプライバシー上の懸念により、多くの通信事業者はその使用を制限しています。集約レポートは、エンドユーザー通信の機密性を維持しながら認証結果を可視化するために推奨されるメカニズムとして引き続き推奨されます。
Particular privacy-specific issues are explored below.
特定のプライバシー固有の問題については、以下で説明します。
Failure reports may include PII and non-public information (NPI) from messages that fail to authenticate, since these reports may contain message content as well as trace header fields. These reports may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [RFC5965] format used for failed-message reporting supports redaction [RFC6590], failed-message reporting is capable of exposing the entire message to the Report Consumer. They may also expose PII, sensitive business data, or other confidential communications to unintended recipients. Such exposure can create regulatory, legal, and operational risks for both senders and receivers. Examples include product launches, termination notices for employees, or calendar data. Even innocuous-seeming failures (such as malformed or "broken" calendar invitations) can result in the leakage of private communications.
失敗レポートには、メッセージの内容とトレース ヘッダー フィールドが含まれる場合があるため、認証に失敗したメッセージからの PII および非公開情報 (NPI) が含まれる場合があります。これらのレポートは送信者と受信者の識別子 (RFC5322.From アドレスなど) を公開する可能性があり、失敗メッセージのレポートに使用される [RFC5965] 形式は編集 [RFC6590] をサポートしていますが、失敗メッセージのレポートはメッセージ全体をレポート コンシューマに公開することができます。また、PII、機密ビジネス データ、またはその他の機密通信が意図しない受信者に公開される可能性があります。このような危険にさらされると、送信者と受信者の両方に規制上、法的上、運用上のリスクが生じる可能性があります。例には、製品の発売、従業員への退職通知、カレンダー データなどがあります。無害に見える障害 (不正な形式または「壊れた」カレンダーへの招待など) によっても、プライベートな通信が漏洩する可能性があります。
Domain Owners requesting reports will receive information about mail using their domain, but which they did not actually cause to be sent. This might provide valuable insight into content used in abusive messages, but it might also expose PII or NPI from legitimate messages mistakenly or accidentally failing authentication.
レポートを要求したドメイン所有者は、自分のドメインを使用しているが実際には送信されなかったメールに関する情報を受け取ります。これにより、不正なメッセージで使用されているコンテンツに関する貴重な洞察が得られる可能性がありますが、誤って認証に失敗したり、誤って認証に失敗したりして、正当なメッセージから PII または NPI が公開される可能性もあります。
Information about the final destination of mail, where it might otherwise be obscured by intermediate systems, may be exposed through a failure report. A commonly cited example is exposure of members of mailing lists when one list member sends messages to the list, and failure reports are generated when that message is delivered to other list members. Those failure reports would be sent to the Domain Owner of the list member posting the message or their delegated Report Consumer(s).
メールの最終宛先に関する情報は、中間システムによって隠蔽される可能性がありますが、障害レポートを通じて公開される可能性があります。よく挙げられる例としては、メーリング リストのメンバーの 1 人がメーリング リストにメッセージを送信し、そのメッセージが他のリスト メンバーに配信されるときに失敗レポートが生成されるときに、そのメンバーが暴露されることがあります。これらの失敗レポートは、メッセージを投稿するリスト メンバーのドメイン所有者、またはその委任されたレポート コンシューマーに送信されます。
Similarly, when message forwarding arrangements exist, Domain Owners requesting reports may receive information about mail forwarded to domains that were not originally part of their messages' recipient list. This means that destinations previously unknown to the Domain Owner may now become visible.
同様に、メッセージ転送の取り決めが存在する場合、レポートを要求するドメイン所有者は、元々メッセージの受信者リストに含まれていなかったドメインに転送されたメールに関する情報を受け取る場合があります。これは、ドメイン所有者が以前は知らなかった宛先が表示されるようになる可能性があることを意味します。
A DMARC Policy Record can specify that reports should be sent to a Report Consumer operating on behalf of the Domain Owner. This might be done when the Domain Owner sends reports to an entity to monitor mail streams for deliverability, performance issues, or abuse. Receipt of such data by third parties may or may not be permitted by the Mail Receiver's privacy policy, terms of use, etc. Domain Owners and Mail Receivers should both review and understand whether their own internal policies constrain the use and transmission of DMARC reporting.
DMARC ポリシー レコードは、ドメイン所有者に代わって動作するレポート コンシューマにレポートを送信するように指定できます。これは、ドメイン所有者がメール ストリームの配信可能性、パフォーマンスの問題、または悪用を監視するためにレポートをエンティティに送信するときに行われる場合があります。第三者によるそのようなデータの受信は、メール受信者のプライバシー ポリシー、利用規約などによって許可されている場合と許可されていない場合があります。ドメイン所有者とメール受信者は両方とも、自身の内部ポリシーが DMARC レポートの使用と送信を制限しているかどうかを確認し、理解する必要があります。
Some potential exists for Report Consumers to perform traffic analysis, making it possible to obtain metadata about the Mail Receiver's traffic. In addition to verifying compliance with policies, Mail Receivers need to consider that before sending reports to a third party. On the other hand, a Domain Owner may publish a destination address that appears to be an Internal Report Consumer but is actually a forwarding address; in this case, the final destination of a report is not guaranteed.
レポート コンシューマがトラフィック分析を実行して、メール レシーバのトラフィックに関するメタデータを取得できる可能性がいくつかあります。メール受信者は、ポリシーへの準拠を検証するだけでなく、レポートを第三者に送信する前にそれを考慮する必要があります。一方、ドメイン所有者は、内部レポートのコンシューマのように見える宛先アドレスを公開する可能性がありますが、実際には転送アドレスである可能性があります。この場合、レポートの最終宛先は保証されません。
The risks associated with failure reports are compounded by volume and content distribution concerns. Partially or unredacted reports may propagate large amounts of spam, phishing, or malware content, all of which may require special handling by Report Consumers or other recipients to avoid incidents. This underscores the need to avoid misconfiguration of the destinations in the "ruf" reporting URIs and the suggestions for redaction in this document, for example, using the method described in [RFC6590]. All of these concerns are heightened for high-volume domains. To mitigate such concerns, the following steps should be considered:
障害レポートに関連するリスクは、ボリュームとコンテンツ配布の問題によってさらに悪化します。部分的または編集されていないレポートは、大量のスパム、フィッシング、またはマルウェア コンテンツを伝播する可能性があり、インシデントを回避するためにレポート利用者または他の受信者による特別な処理が必要となる場合があります。これは、「ruf」レポート URI の宛先の設定ミスを回避する必要性と、たとえば [RFC6590] で説明されている方法を使用したこの文書の編集の提案を強調しています。これらすべての懸念は、大規模ドメインではさらに高まります。このような懸念を軽減するには、次の手順を考慮する必要があります。
By report generators:
レポート生成者による:
* Help prevent accidental access to potentially malicious URIs by substituting hxxp for http;
* http を hxxp に置き換えることで、潜在的に悪意のある URI への誤ったアクセスを防ぐことができます。
* Remove attachments that could embed malicious payload.
* 悪意のあるペイロードが埋め込まれている可能性のある添付ファイルを削除します。
By report consumers:
レポート利用者別:
* Isolate report streams from other mail streams;
* レポート ストリームを他のメール ストリームから分離します。
* Use sandboxes in evaluating failure reports;
* 障害レポートの評価にはサンドボックスを使用します。
* Use network segmentation;
* ネットワークセグメンテーションを使用します。
* Limit access to failure reports to authorized individuals with appropriate security training.
* 障害レポートへのアクセスは、適切なセキュリティ トレーニングを受けた権限のある個人に限定してください。
While reviewing this document and its security considerations, the reader should also review the privacy considerations above, as well as the privacy considerations and security considerations in Sections 10 and 11 of [RFC9989] and in Sections 7 and 8 of [RFC9990].
この文書とそのセキュリティに関する考慮事項を検討する際、読者は上記のプライバシーに関する考慮事項、[RFC9989] のセクション 10 と 11、および [RFC9990] のセクション 7 と 8 にあるプライバシーに関する考慮事項とセキュリティに関する考慮事項も確認する必要があります。
Failure reports represent a possible denial-of-service attack that could be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but which fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate(s), potentially in large numbers. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the ARF [RFC5965]. Indeed, the aim is not to count each and every failure but rather to report different failure conditions. Various pruning techniques are possible, including the following:
障害レポートは、対象となるドメイン所有者からのものであると称して SPF と DKIM の両方に失敗する多数のメッセージを送信する攻撃者によって実行される可能性のあるサービス拒否攻撃の可能性を示します。これにより、参加しているメール受信者がドメイン所有者またはその代理人に失敗レポートを大量に送信する可能性があります。したがって、参加するメール受信者は、ARF [RFC5965] のインシデントフィールドを使用して、これらのレポートを可能な限り集約することが推奨されます。実際、目的は、すべての障害をカウントすることではなく、さまざまな障害状態を報告することです。次のようなさまざまな剪定手法が可能です。
* Store reports for a period of time before sending them, allowing detection, collection, and consolidation of like incidents;
* レポートを送信する前に一定期間保存し、同様のインシデントの検出、収集、統合を可能にします。
* Apply rate-limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).
* 生成される 1 分あたりのレポートの最大数などのレート制限を適用します (残りは破棄されます)。
[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>.
[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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965,
DOI 10.17487/RFC5965, August 2010,
<https://www.rfc-editor.org/info/rfc5965>.
[RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
Potentially Sensitive Data from Mail Abuse Reports",
RFC 6590, DOI 10.17487/RFC6590, April 2012,
<https://www.rfc-editor.org/info/rfc6590>.
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the
Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
April 2012, <https://www.rfc-editor.org/info/rfc6591>.
[RFC6692] Clayton, R. and M. Kucherawy, "Source Ports in Abuse
Reporting Format (ARF) Reports", RFC 6692,
DOI 10.17487/RFC6692, July 2012,
<https://www.rfc-editor.org/info/rfc6692>.
[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>.
[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>.
[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,
Reporting, and Conformance (DMARC) Aggregate Reporting",
RFC 9990, DOI 10.17487/RFC9990, May 2026,
<https://www.rfc-editor.org/info/rfc9990>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012,
<https://www.rfc-editor.org/info/rfc6651>.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
<https://www.rfc-editor.org/info/rfc6652>.
[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>.
This is the full content of a sample failure message, including the message header.
これは、メッセージ ヘッダーを含む、サンプルの失敗メッセージの完全な内容です。
Received: from gen.example (gen.example [192.0.2.1])
(TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
by mail.consumer.example with ESMTPS
id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=gen.example; s=mail; t=1658210268;
bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=;
h=From:To:Date:Subject:From;
b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE
/h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh
LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb
u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG
q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX
Rltp7zdoLdy4A==
From: DMARC Filter <DMARC@gen.example>;
To: dmarcfail@consumer.example
Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT)
Subject: FW: This is the original subject
Mime-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="=_mime_boundary_"
Message-Id: <20220719055748.4AE9D403CC@gen.example>;
This is a MIME-formatted message. If you see this text it means that
your E-mail software does not support MIME-formatted messages.
--=_mime_boundary_
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
This is an authentication failure report for an email message
received from IP 192.0.2.2 on Tue, 19 Jul 2022 00:57:48 -0500.
--=_mime_boundary_
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: auth-failure
Version: 1
User-Agent: DMARC-Filter/1.2.3
Auth-Failure: dmarc
Authentication-Results: gen.example;
dmarc=fail header.from=consumer.example
Identity-Alignment: dkim
DKIM-Domain: consumer.example
DKIM-Identity: @consumer.example
DKIM-Selector: epsilon
Original-Envelope-Id: 65E1A3F0A0
Original-Mail-From: author=gen.example@forwarder.example
Source-IP: 192.0.2.2
Source-Port: 12345
Reported-Domain: consumer.example
--=_mime_boundary_
Content-Type: message/rfc822; charset=utf-8
Content-Transfer-Encoding: 7bit
Authentication-Results: gen.example;
dkim=permerror header.d=forwarder.example header.b="EjCbN/c3";
dkim=temperror header.d=forwarder.example header.b="mQ8GEWPc";
dkim=permerror header.d=consumer.example header.b="hETrymCb";
dkim=neutral header.d=consumer.example header.b="C2nsAp3A";
Received: from mail.forwarder.example
(mail.forwarder.example [IPv6:2001:db8::23ac])
by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826
for <x@gen.example>; Sun, 14 Aug 2022 07:58:29 -0700 (PDT)
Received: from mail.forwarder.example (localhost [127.0.0.1])
by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq
for <x@gen.example>; Tue, 19 Jul 2022 07:57:44 +0200
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
d=forwarder.example; s=ed25519-59hs; t=1658210264;
x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:
List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:
To:References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:
content-type:date:from:in-reply-to:message-id:mime-version:
openpgp:references:subject:to;
b=EjCbN/c3bTU4QkZH/zwTbYxBDp0k8kpmWSXh5h1M7T8J4vtRo+hvafJazT3ZRgq+7
+4dzEQwUhl+NOJYXXNUAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=forwarder.example; s=rsa-wgJg; t=1658210264; x=1663210264;
bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:
List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:
To:References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:
content-type:date:from:in-reply-to:message-id:mime-version:
openpgp:references:subject:to;
b=mQ8GEWPcVpBpeqQ88pcbXpGHBT0J/Rwi8Zd2WZTXWWneQGRCOJLRcbBJpjqnrwtqd
76IqawH86tihz4Z/12J1GBCdNx1gfazsoI3yaqfooRDYg0mSyZHrYhQBmodnPcqZj4
/25L5278sc/UNrYO9az2n7R/skbVZ0bvSo2eEiGU8fcpO8+a5SKNYskhaviAI4eGIB
iRMdEP7gP8dESdnZguNbY5HI32UMDpPPNqajzd/BgcqbveYpRrWCDOhcY47POV7GHM
i/KLHiZXtJsL3/Pr/4TL+HTjdX8EDSsy1K5/JCvJCFsJHnSvkEaJQGLn/2m03eW9r8
9w1bQ90aY+VCQ==
X-Original-To: users@forwarder.example
Received: from mail.consumer.example
(mail.consumer.example [192.0.2.4])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature ECDSA (P-384)
server-digest SHA384)
(Client did not present a certificate)
by mail.forwarder.example (Postfix) with ESMTPS id 4Ln7Qs55xmz4nP
for <users@forwarder.example>;
Tue, 19 Jul 2022 07:57:41 +0200 (CEST)
Authentication-Results: mail.forwarder.example;
arc=none smtp.remote-ip=192.0.2.4
Authentication-Results: mail.forwarder.example;
dkim=pass (512-bit key; secure) header.d=consumer.example
header.i=@consumer.example header.a=ed25519-sha256
header.s=epsilon header.b=hETrymCb;
dkim=pass (1152-bit key; secure) header.d=consumer.example
header.i=@consumer.example header.a=rsa-sha256
header.s=delta header.b=C2nsAp3A
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
d=consumer.example; s=epsilon; t=1658210255;
bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
h=Date:Subject:To:References:From:In-Reply-To;
b=hETrymCbz6T1Dyo5dCG9dk8rPykKLdhJCPFeJ9TiiP/kaoN2afpUYtj+SrI+I83lp
p1F/FfYSGy7zz3Q3OdxBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=consumer.example; s=delta; t=1658210255;
bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
h=Date:To:References:From:In-Reply-To;
b=C2nsAp3AMNX33Nq7nN/StPo921xE3XGF8Ju3iAKdYB3EKhsril0N5IjWGlglJECst
jLNKSo7KWZZ2lkH/dVZ9Rs1GHT2uaKy1sc/xmNIC5rHdhrxammiwpTSo4PsT8disfc
3DVF6Q62n0EsdLFqcw1KY8A9inFqYKY2tqoo+y4zMtItqCYx3xjsj3I0IFLuX
Author: Message Author <author@consumer.example>
Received: from [192.0.2.8] (host-8-2-0-192.isp.example [192.0.2.8])
(AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3,128bits,
ECDHE_RSA_AES_128_GCM_SHA256)
by mail.consumer.example with ESMTPSA
id 00000000005DC076.00004417; Tue, 19 Jul 2022 07:57:35 +0200
Message-ID: <2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example>
Date: Tue, 19 Jul 2022 07:57:33 +0200
List-Id: <users.forwarder.example>
List-Post: <mailto:users@forwarder.example>
List-Help: <mailto:users+help@forwarder.example>
List-Subscribe: <mailto:users+subscribe@forwarder.example>
List-Unsubscribe: <mailto:users+unsubscribe@forwarder.example>
List-Owner: <mailto:users+owner@forwarder.example>
Precedence: list
MIME-Version: 1.0
Subject: This is the original subject
Content-Language: en-US
To: users@forwarder.example
Authentication-Results: consumer.example; auth=pass (details omitted)
From: Message Author <author@consumer.example>
In-Reply-To: <20220718102753.0f6d9dde.cel@example.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
[ Message body was here ]
--=_mime_boundary_--
The Source-Port field definition is given by [RFC6692].
Source-Port フィールドの定義は [RFC6692] によって与えられます。
In the final MIME entity, the local-parts of To and From addresses are reported unredacted. Since we know that the local parts are PII, we can reduce the privacy risk by redacting them. In the example, the report generator could have replaced "users" with "lRLxexey" and "author" with "RT47aVey" throughout the entity.
最終的な MIME エンティティでは、To アドレスと From アドレスのローカル部分が編集されずに報告されます。ローカル部分は PII であることがわかっているため、それらを編集することでプライバシーのリスクを軽減できます。この例では、レポート ジェネレーターはエンティティ全体で「users」を「lRLxexey」に、「author」を「RT47aVey」に置き換えることができます。
If the body of the message is not included, the last MIME entity would have "Content-Type: text/rfc822-headers" instead of "message/ rfc822".
メッセージの本文が含まれていない場合、最後の MIME エンティティには「message/rfc822」ではなく「Content-Type: text/rfc822-headers」が含まれます。
Steven M. Jones (editor)
DMARC.org
Email: smj@dmarc.org
Alessandro Vesely (editor)
Tana
Email: vesely@tana.it