[要約] RFC 7489、つまりDomain-based Message Authentication, Reporting, and Conformance (DMARC)は、電子メールの偽装を防ぐためのフレームワークです。この標準は、SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）の検証結果を利用して、ドメイン所有者がどのようにそのドメインから送信されたメールを処理すべきかを示すポリシーを公開できるようにします。DMARCは、メール送信者と受信者の間での信頼性を高め、フィッシングやその他の詐欺的なメールの防止に役立ちます。関連するRFCには、SPFを定義するRFC 7208と、DKIMを定義するRFC 6376があります。
Independent Submission M. Kucherawy, Ed.
Request for Comments: 7489
Category: Informational E. Zwicky, Ed.
ISSN: 2070-1721 Yahoo!
March 2015
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
ドメインベースのメッセージ認証、レポート、および準拠（DMARC）
Abstract
概要
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.
ドメインベースのメッセージ認証、報告、および適合性（DMARC）は、メール送信組織がドメインレベルのポリシーとメッセージの検証、処理、および報告に関する設定を表現できるスケーラブルなメカニズムであり、メール受信組織はこれを使用してメール処理を改善します。
Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.
インターネットメールの発信者は、信頼できる認証済みのドメイン識別子をメッセージに関連付け、それらの識別子を使用するメッセージに関するポリシーを伝達し、それらの識別子を使用してメールについてレポートできる必要があります。これらの機能にはいくつかの利点があります。受信者はドメイン所有者にドメインの使用についてフィードバックを提供できます。このフィードバックは、内部操作の管理と外部ドメイン名の悪用の存在に関する貴重な洞察を提供します。
DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.
DMARCは、認証された電子メールの昇格された配信特権を生成または奨励しません。 DMARCはポリシー配信のメカニズムであり、認証チェックに失敗したメッセージをますます厳格に処理できるようにします。アクションのないものから、配信の変更、メッセージの拒否まで、さまざまです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7489.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7489で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements ....................................................5
2.1. High-Level Goals ...........................................5
2.2. Out of Scope ...............................................6
2.3. Scalability ................................................6
2.4. Anti-Phishing ..............................................7
3. Terminology and Definitions .....................................7
3.1. Identifier Alignment .......................................8
3.2. Organizational Domain .....................................11
4. Overview .......................................................12
4.1. Authentication Mechanisms .................................12
4.2. Key Concepts ..............................................12
4.3. Flow Diagram ..............................................13
5. Use of RFC5322.From ............................................15
6. Policy .........................................................15
6.1. DMARC Policy Record .......................................16
6.2. DMARC URIs ................................................16
6.3. General Record Format .....................................17
6.4. Formal Definition .........................................21
6.5. Domain Owner Actions ......................................22
6.6. Mail Receiver Actions .....................................23
6.7. Policy Enforcement Considerations .........................27
7. DMARC Feedback .................................................28
7.1. Verifying External Destinations ...........................28
7.2. Aggregate Reports .........................................30
7.3. Failure Reports ...........................................36
8. Minimum Implementations ........................................37
9. Privacy Considerations .........................................38
9.1. Data Exposure Considerations ..............................38
9.2. Report Recipients .........................................39
10. Other Topics ..................................................39
10.1. Issues Specific to SPF ...................................39
10.2. DNS Load and Caching .....................................40
10.3. Rejecting Messages .......................................40
10.4. Identifier Alignment Considerations ......................41
10.5. Interoperability Issues ..................................41
11. IANA Considerations ...........................................42
11.1. Authentication-Results Method Registry Update ............42
11.2. Authentication-Results Result Registry Update ............42
11.3. Feedback Report Header Fields Registry Update ............44
11.4. DMARC Tag Registry .......................................44
11.5. DMARC Report Format Registry .............................45
12. Security Considerations .......................................46
12.1. Authentication Methods ...................................46
12.2. Attacks on Reporting URIs ................................46
12.3. DNS Security .............................................47
12.4. Display Name Attacks .....................................47
12.5. External Reporting Addresses .............................48
12.6. Secure Protocols .........................................48
13. References ....................................................49
13.1. Normative References .....................................49
13.2. Informative References ...................................50
Appendix A. Technology Considerations .............................52
A.1. S/MIME .....................................................52
A.2. Method Exclusion ...........................................53
A.3. Sender Header Field ........................................53
A.4. Domain Existence Test ......................................54
A.5. Issues with ADSP in Operation ..............................54
A.6. Organizational Domain Discovery Issues .....................55
Appendix B. Examples ..............................................56
B.1. Identifier Alignment Examples ..............................56
B.2. Domain Owner Example .......................................58
B.3. Mail Receiver Example .....................................63
B.4. Utilization of Aggregate Feedback: Example .................64
B.5. mailto Transport Example ...................................65
Appendix C. DMARC XML Schema ......................................66
Acknowledgements ..................................................73
Authors' Addresses ................................................73
The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail ([DKIM]) provide domain-level authentication. They enable cooperating email receivers to detect mail authorized to use the domain name, which can permit differential handling. (A detailed discussion of the threats these systems attempt to address can be found in [DKIM-THREATS].) However, there has been no single widely accepted or publicly available mechanism to communication of domain-specific message-handling policies for receivers, or to request reporting of authentication and disposition of received mail. Absent the ability to obtain feedback reports, originators who have implemented email authentication have difficulty determining how effective their authentication is. As a consequence, use of authentication failures to filter mail typically does not succeed.
Sender Policy Framework（[SPF]）とDomainKeys Identified Mail（[DKIM]）は、ドメインレベルの認証を提供します。これらは、協力する電子メール受信者がドメイン名の使用を許可されたメールを検出できるようにし、これにより、差分処理が可能になります。 （これらのシステムが対処しようとする脅威の詳細な説明は、[DKIM-THREATS]で見つけることができます。）しかし、受信者のドメイン固有のメッセージ処理ポリシーの通信に対して広く受け入れられているか、公開されている単一のメカニズムはありません。受信したメールの認証と処分の報告を要求する。フィードバックレポートを取得する機能がないと、メール認証を実装した発信者は、認証がどれほど効果的であるかを判断することが困難になります。結果として、メールのフィルタリングに認証エラーを使用すると、通常は成功しません。
Over time, one-on-one relationships were established between select senders and receivers with privately communicated means to assert policy and receive message traffic and authentication disposition reporting. Although these ad hoc practices have been generally successful, they require significant manual coordination between parties, and this model does not scale for general use on the Internet.
時間の経過とともに、ポリシーをアサートしてメッセージトラフィックと認証処理レポートを受信する非公開通信手段を使用して、選択した送信者と受信者の間に1対1の関係が確立されました。これらのアドホックプラクティスは一般的には成功していますが、当事者間の大幅な手動調整が必要であり、このモデルはインターネットでの一般的な使用のために拡張できません。
This document defines Domain-based Message Authentication, Reporting, and Conformance (DMARC), a mechanism by which email operators leverage existing authentication and policy advertisement technologies to enable both message-stream feedback and enforcement of policies against unauthenticated email.
このドキュメントでは、ドメインベースのメッセージ認証、レポート、および適合性（DMARC）を定義します。これは、メールオペレーターが既存の認証およびポリシーアドバタイズメントテクノロジーを利用して、メッセージストリームフィードバックと未認証メールに対するポリシーの適用の両方を可能にするメカニズムです。
DMARC allows Domain Owners and receivers to collaborate by:
DMARCにより、ドメイン所有者と受信者は次の方法でコラボレーションできます。
1. Providing receivers with assertions about Domain Owners' policies
1. ドメイン所有者のポリシーに関するアサーションをレシーバーに提供する
2. Providing feedback to senders so they can monitor authentication and judge threats
2. 送信者にフィードバックを提供して、認証を監視し、脅威を判断できるようにする
The basic outline of DMARC is as follows:
DMARCの基本的な概要は次のとおりです。
1. Domain Owners publish policy assertions about domains via the DNS.
1. ドメイン所有者は、DNSを介してドメインに関するポリシーアサーションを公開します。
2. Receivers compare the RFC5322.From address in the mail to the SPF and DKIM results, if present, and the DMARC policy in DNS.
2. 受信者は、メールのRFC5322.FromアドレスをSPFおよびDKIM結果（存在する場合）と比較し、DNSのDMARCポリシーを比較します。
3. These receivers can use these results to determine how the mail should be handled.
3. これらの受信者はこれらの結果を使用して、メールの処理方法を決定できます。
4. The receiver sends reports to the Domain Owner or its designee about mail claiming to be from their domain.
4. 受信者は、ドメインの所有者またはその指定者に、ドメインからのものであると主張するメールに関するレポートを送信します。
Security terms used in this document are defined in [SEC-TERMS].
このドキュメントで使用されるセキュリティ用語は、[SEC-TERMS]で定義されています。
DMARC differs from previous approaches to policy advertisement (e.g., [SPF] and [ADSP]) in that:
DMARCは、以下の点で、以前のポリシーアドバタイズメントのアプローチ（[SPF]や[ADSP]など）とは異なります。
o Authentication technologies are:
o 認証テクノロジーは次のとおりです。
1. decoupled from any technology-specific policy mechanisms, and
1. テクノロジー固有のポリシーメカニズムから切り離されている
2. used solely to establish reliable per-message domain-level identifiers.
2. 信頼できるメッセージごとのドメインレベルの識別子を確立するためにのみ使用されます。
o Multiple authentication technologies are used to:
o 複数の認証技術は、次の目的で使用されます。
1. reduce the impact of transient authentication errors
1. 一時的な認証エラーの影響を減らす
2. reduce the impact of site-specific configuration errors and deployment gaps
2. サイト固有の構成エラーと展開ギャップの影響を軽減する
3. enable more use cases than any individual technology supports alone
3. 個々のテクノロジーが単独でサポートするよりも多くのユースケースを可能にします
o Receiver-generated feedback is supported, allowing senders to establish confidence in authentication practices.
o 受信者が生成したフィードバックがサポートされているため、送信者は認証手法に自信を確立できます。
o The domain name extracted from a message's RFC5322.From field is the primary identifier in the DMARC mechanism. This identifier is used in conjunction with the results of the underlying authentication technologies to evaluate results under DMARC.
o メッセージのRFC5322.Fromフィールドから抽出されたドメイン名は、DMARCメカニズムの主要な識別子です。この識別子は、DMARCでの結果を評価するために、基盤となる認証技術の結果と組み合わせて使用されます。
Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 10.
DMARCの経験から、特にメールの拒否を引き起こす可能性のある構成では、展開前に十分な検討が必要な、メールとの相互運用性の問題がいくつか明らかになっています。これらについては、セクション10で説明します。
Specification of DMARC is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope.
DMARCの仕様は、次の高レベルの目標、セキュリティの依存関係、詳細な要件、および範囲外として文書化されている項目によって導かれます。
DMARC has the following high-level goals:
DMARCには、次の上位レベルの目標があります。
o Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain.
o ドメイン所有者が認証失敗の優先処理を主張できるようにします。これは、ドメイン内でオーサーシップをしていると主張するメッセージに対してです。
o Allow Domain Owners to verify their authentication deployment.
o ドメイン所有者が認証の導入を確認できるようにします。
o Minimize implementation complexity for both senders and receivers, as well as the impact on handling and delivery of legitimate messages.
o 送信者と受信者の両方の実装の複雑さ、および正当なメッセージの処理と配信への影響を最小限に抑えます。
o Reduce the amount of successfully delivered spoofed email.
o なりすましメールの配信に成功しました。
o Work at Internet scale.
o インターネット規模で働く。
Several topics and issues are specifically out of scope for the initial version of this work. These include the following:
いくつかのトピックと問題は、この作品の最初のバージョンでは特に対象外です。これらには以下が含まれます。
o different treatment of messages that are not authenticated versus those that fail authentication;
o 認証されていないメッセージと認証に失敗したメッセージの扱いが異なります。
o evaluation of anything other than RFC5322.From;
o RFC5322.From以外の評価;
o multiple reporting formats;
o 複数のレポート形式。
o publishing policy other than via the DNS;
o DNS以外の公開ポリシー。
o reporting or otherwise evaluating other than the last-hop IP address;
o ラストホップIPアドレス以外のレポートまたはその他の評価;
o attacks in the RFC5322.From field, also known as "display name" attacks;
o RFC5322.Fromフィールドの攻撃。「表示名」攻撃とも呼ばれます。
o authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and
o ドメイン以外のエンティティの認証。DMARCはSPFとDKIMに基づいて構築されているため、ドメインを認証します。そして
o content analysis.
o 内容分析。
Scalability is a major issue for systems that need to operate in a system as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.
スケーラビリティは、現在のSMTP電子メールと同じくらい広く展開されているシステムで動作する必要があるシステムの主要な問題です。このため、DMARCは、サードパーティの必要性や送信者と受信者間の事前送信契約の回避を目指しています。これにより、現在のメールインフラストラクチャの良い面が維持されます。
Although DMARC does not introduce third-party senders (namely external agents authorized to send on behalf of an operator) to the email-handling flow, it also does not preclude them. Such third parties are free to provide services in conjunction with DMARC.
DMARCは、サードパーティ送信者（つまり、オペレーターに代わって送信することを許可された外部エージェント）を電子メール処理フローに導入しませんが、それらを排除しません。そのような第三者は、DMARCと連携して自由にサービスを提供できます。
DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions). One of the primary uses of this kind of spoofed mail is phishing (enticing users to provide information by pretending to be the legitimate service requesting the information). Thus, DMARC is significantly informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures.
DMARCは、不正なアクターが正当な送信者、特にトランザクションメール（ビジネストランザクションに関する公式メール）の送信者からのメールを送信しないように設計されています。この種のなりすましメールの主な用途の1つはフィッシングです（ユーザーが情報を要求する正当なサービスを装って情報を提供するように誘導する）。したがって、DMARCは、インターネット全体にわたる大規模なフィッシング対策を制定するための継続的な取り組みから大きな情報を得ています。
Although DMARC can only be used to combat specific forms of exact-domain spoofing directly, the DMARC mechanism has been found to be useful in the creation of reliable and defensible message streams.
DMARCは、特定の形式の正確なドメインのスプーフィングと直接対抗するためにのみ使用できますが、DMARCメカニズムは、信頼性のある防御可能なメッセージストリームの作成に役立つことがわかっています。
DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent email. In particular, it does not address the use of visually similar domain names ("cousin domains") or abuse of the RFC5322.From human-readable <display-name>.
DMARCは、なりすましやその他の詐欺メールに関するすべての問題を解決しようとするものではありません。特に、視覚的に類似したドメイン名（「従属ドメイン」）の使用やRFC5322.From人が読める<display-name>の悪用については触れていません。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
Readers are encouraged to be familiar with the contents of [EMAIL-ARCH]. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner could, via the messaging security mechanisms on which DMARC is based, delegate the ability to send mail as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing.
読者は、[EMAIL-ARCH]の内容に精通していることが推奨されます。特に、そのドキュメントは、メッセージングインフラストラクチャのさまざまな役割を定義しており、さまざまなコンテキストで同じように、または別々に表示できます。たとえば、ドメイン所有者は、DMARCが基づいているメッセージングセキュリティメカニズムを介して、ドメイン所有者としてメールを送信する機能を別の役割を持つサードパーティに委任できます。このドキュメントでは、このような役割の違いについては扱いません。読者は続行する前にその資料に精通することをお勧めします。
The following terms are also used:
次の用語も使用されます。
Authenticated Identifiers: Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers". See Section 4.1 for details about the supported mechanisms.
認証済み識別子：認証技術を使用して検証されるドメインレベルの識別子は、「認証済み識別子」と呼ばれます。サポートされるメカニズムの詳細については、セクション4.1を参照してください。
Author Domain: The domain name of the apparent author, as extracted from the RFC5322.From field.
作成者ドメイン：RFC5322.Fromフィールドから抽出された、見かけ上の作成者のドメイン名。
Domain Owner: An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH]. It can also refer to delegates, such as Report Receivers, when those are outside of their immediate management domain.
ドメイン所有者：DNSドメインを所有するエンティティまたは組織。ここで「所有する」という用語は、参照されるエンティティまたは組織がそのDNSドメインの登録を保持していることを示します。ドメインの所有者は、複雑でグローバルに分散した組織から、技術以外のクライアントに代わってサービスを提供するサービスプロバイダー、個人のドメインの管理を担当する個人まで多岐にわたります。この仕様では、[EMAIL-ARCH]で定義されている管理管理ドメインに類似したこの用語を使用しています。また、直接の管理ドメインの外にいる場合、レポートレシーバーなどのデリゲートを参照することもできます。
Identifier Alignment: When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment.
識別子の配置：RFC5322.FromアドレスのドメインがSPFまたはDKIM（またはその両方）によって検証されたドメインと一致する場合、識別子の配置があります。
Mail Receiver: The entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Mail Transport Agents (MTAs).
メール受信者：電子メールを受信して処理するエンティティまたは組織。メールレシーバーは、インターネットに接続する1つ以上のメールトランスポートエージェント（MTA）を操作します。
Organizational Domain: The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., "example.com", where "com" is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2.
組織ドメイン：ドメイン名登録事業者に登録されたドメイン。より正確な方法が存在しない場合、登録されたドメイン名がトップレベルのDNSドメインと1つのコンポーネント（たとえば、「example.com」、「com "はトップレベルドメインです）。組織ドメインは、セクション3.2にあるアルゴリズムを適用して決定されます。
Report Receiver: An operator that receives reports from another operator implementing the reporting mechanism described in this document. Such an operator might be receiving reports about its own messages, or reports about messages related to another operator. This term applies collectively to the system components that receive and process these reports and the organizations that operate them.
レポートレシーバー：このドキュメントで説明するレポートメカニズムを実装する別のオペレーターからレポートを受信するオペレーター。このようなオペレーターは、自身のメッセージに関するレポート、または別のオペレーターに関連するメッセージに関するレポートを受信している可能性があります。この用語は、これらのレポートを受信して処理するシステムコンポーネントおよびそれらを運用する組織に集合的に適用されます。
Email authentication technologies authenticate various (and disparate) aspects of an individual message. For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ HELO domain, or both. These may be different domains, and they are typically not visible to the end user.
電子メール認証技術は、個々のメッセージのさまざまな（そして異なる）側面を認証します。たとえば、[DKIM]はメッセージに署名を付けたドメインを認証し、[SPF]は[SMTP]のRFC5321.MailFrom（MAIL FROM）部分にあるドメインまたはRFC5321.EHLO / HELOドメインを認証できます。 、 または両方。これらは異なるドメインである可能性があり、通常、エンドユーザーには表示されません。
DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier. The RFC5322.From domain was selected as the central identity of the DMARC mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users.
DMARCは、RFC5322.Fromドメインの使用を、認証済み識別子と一致する（一致する）ことを要求することによって認証します。 RFC5322.FromドメインはDMARCメカニズムの中心的なアイデンティティとして選択されました。これは必須のメッセージヘッダーフィールドであり、したがって準拠メッセージに存在することが保証されており、ほとんどのメールユーザーエージェント（MUA）がRFC5322.Fromフィールドを発信元として表しているためです。メッセージの一部として、このヘッダーフィールドのコンテンツの一部またはすべてをエンドユーザーに表示します。
Thus, this field is the one used by end users to identify the source of the message and therefore is a prime target for abuse. Many high-profile email sources, such as email service providers, require that the sending agent have authenticated before email can be generated. Thus, for these mailboxes, the mechanism described in this document provides recipient end users with strong evidence that the message was indeed originated by the agent they associate with that mailbox, if the end user knows that these various protections have been provided.
したがって、このフィールドはメッセージのソースを識別するためにエンドユーザーが使用するフィールドであり、したがって乱用の主なターゲットになります。電子メールサービスプロバイダーなど、多くの注目度の高い電子メールソースでは、電子メールを生成する前に送信エージェントを認証する必要があります。したがって、これらのメールボックスについて、このドキュメントで説明するメカニズムは、エンドユーザーがこれらのさまざまな保護が提供されていることを知っている場合、メッセージが実際にそのメールボックスに関連付けられているエージェントによって発信されたという強力な証拠を受信者のエンドユーザーに提供します。
Domain names in this context are to be compared in a case-insensitive manner, per [DNS-CASE].
このコンテキストのドメイン名は、[DNS-CASE]に従って、大文字と小文字を区別しない方法で比較されます。
It is important to note that Identifier Alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed, absent, or repeated RFC5322.From field, since in that case there is no reliable way to determine a DMARC policy that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid RFC5322 message object, and handling of such non-compliant cases is outside of the scope of this specification. Further discussion of this can be found in Section 6.6.1.
IDMAは[MAIL]ごとに無効なメッセージ、特にRFC5322.Fromフィールドの形式が正しくない、存在しない、または繰り返されるメッセージでは発生しないことに注意してください。その場合、DMARCを特定する信頼できる方法がないためです。メッセージに適用されるポリシー。したがって、DMARC操作は、入力が有効なRFC5322メッセージオブジェクトであることを前提としており、このような非準拠のケースの処理は、この仕様の範囲外です。この詳細については、6.6.1項を参照してください。
Each of the underlying authentication technologies that DMARC takes as input yields authenticated domains as their outputs when they succeed. From the perspective of DMARC, each can be operated in a "strict" mode or a "relaxed" mode. A Domain Owner would normally select strict mode if it wanted Mail Receivers to apply DMARC processing only to messages bearing an RFC5322.From domain exactly matching the domains those mechanisms will verify. Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains.
DMARCが入力として使用する基盤となる認証テクノロジはそれぞれ、成功したときに認証済みドメインを出力として生成します。 DMARCの観点から見ると、それぞれを「厳密」モードまたは「緩和」モードで操作できます。ドメインオーナーは通常、RFC5322が付いたメッセージにのみメールレシーバーがDMARC処理を適用するようにしたい場合、ストリクトモードを選択します。オペレーターが検証済みドメインのサブドメインを持つメッセージフローにも影響を与えたい場合は、リラックスモードを使用できます。
DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed. (Note that these are not related to DKIM's "simple" and "relaxed" canonicalization modes.) In relaxed mode, the Organizational Domains of both the [DKIM]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment.
DMARCは、DKIM認証の結果に基づいて、IDアラインメントを厳密または緩和することを許可します。 （これらはDKIMの「シンプル」および「リラックス」正規化モードとは関係がないことに注意してください。）リラックスモードでは、両方の[DKIM]認証済み署名ドメインの組織ドメイン（の「d =」タグの値から取得）署名）とRFC5322.Fromドメインの署名は、識別子が整合していると見なされる場合、等しくなければなりません。厳密モードでは、両方の完全修飾ドメイン名（FQDN）間の完全一致のみが、識別子の整列を生成すると見なされます。
To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address.
たとえば、リラックスモードで、検証されたDKIM署名が「example.com」の「d =」ドメインで正常に検証され、RFC5322.Fromアドレスが「alerts@news.example.com」である場合、DKIM「d = "ドメインとRFC5322.Fromドメインは"整合 "していると見なされます。厳密モードでは、「d =」ドメインがアドレスのFQDNと正確に一致しないため、このテストは失敗します。
However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result, as "com" should appear on all public suffix lists (see Appendix A.6.1) and therefore cannot be an Organizational Domain.
ただし、「d = com」の値を持つDKIMシグネチャは、「com」がすべてのパブリックサフィックスリスト（付録A.6.1を参照）に表示される必要があるため、組織ドメインになることができないため、「整列」結果を決して許可しません。
Identifier Alignment is required because a message can bear a valid signature from any domain, including domains used by a mailing list or even a bad actor. Therefore, merely bearing a valid signature is not enough to infer authenticity of the Author Domain.
メッセージは、メーリングリストや悪意のある人物が使用するドメインを含む、あらゆるドメインからの有効な署名を保持できるため、識別子の調整が必要です。したがって、有効な署名を付けるだけでは、作成者ドメインの信頼性を推測するのに十分ではありません。
Note that a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies.
1つのメールに複数のDKIM署名を含めることができます。DKIM署名が調整および検証されている場合、DMARCの「合格」と見なされます。
DMARC permits Identifier Alignment, based on the result of an SPF authentication, to be strict or relaxed.
DMARCは、SPF認証の結果に基づいて、IDアライメントを厳密または緩和することを許可します。
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
リラックスモードでは、[SPF]で認証されたドメインとRFC5322.Fromドメインが同じ組織ドメインを持っている必要があります。厳密モードでは、完全なDNSドメインの一致のみが識別子のアライメントを生成すると見なされます。
Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier.
[SPF]による「純粋なSPF」実装がその識別子をチェックする場合でも、RFC5321.HELO IDは通常DMARCのコンテキストでは使用されません（それ以外の場合はnullのリバースパスを「偽造」する必要がある場合を除く）。
For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode.
たとえば、メッセージが「cbg.bounces.example.com」のRFC5321.MailFromドメインでSPFチェックに合格し、RFC5322.Fromフィールドのアドレス部分に「payments@example.com」が含まれている場合、認証済みのRFC5321。 MailFromドメイン識別子とRFC5322.Fromドメインは、緩和モードでは「整合」していると見なされますが、厳密モードでは考慮されません。
If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified.
DMARCが他の認証メカニズムの使用を含むように拡張される場合、RFC5322.Fromドメインとの整合を検証できるように、拡張機能はドメイン識別子の抽出を許可する必要があります。
The Organizational Domain is determined using the following algorithm:
組織ドメインは、次のアルゴリズムを使用して決定されます。
1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list.
1. 「パブリックサフィックス」リスト、つまり登録用に予約されているDNSドメイン名のリストを取得します。一部の国のトップレベルドメイン（TLD）は特定の登録要件を設けています。たとえば、英国では会社の登録を「.co.uk」に配置しています。 「.com」などの他のTLDは、トップレベルDNSドメインのIANAレジストリに表示されます。公開サフィックスリストは、これらすべての結合です。付録A.6.1には、公開サフィックスリストの取得に関する説明が含まれています。
2. Break the subject DNS domain name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "example.com", "com" would be label 1 and "example" would be label 2.
2. 対象のDNSドメイン名を「n」の順序付けられたラベルのセットに分割します。これらのラベルには右から左に番号を付けます。たとえば、「example.com」の場合、「com」はラベル1、「example」はラベル2になります。
3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x".
3. パブリックサフィックスリストで、対象のDNSドメインで見つかったラベルの最大数と一致する名前を検索します。その数を "x"とします。
4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the "x+1"th label from the subject domain. This new name is the Organizational Domain.
4. パブリックサフィックスリストから一致する名前を使用し、サブジェクトドメインからの「x + 1」番目のラベルにプレフィックスを付けて、新しいDNSドメイン名を作成します。この新しい名前は組織ドメインです。
Thus, since "com" is an IANA-registered TLD, a subject domain of "a.b.c.d.example.com" would have an Organizational Domain of "example.com".
したがって、「com」はIANA登録TLDであるため、「a.b.c.d.example.com」のサブジェクトドメインは「example.com」の組織ドメインを持つことになります。
The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.
サフィックスを決定するプロセスは、現在ヒューリスティックなプロセスです。正確または最新であることを保証するリストはありません。
This section provides a general overview of the design and operation of the DMARC environment.
このセクションでは、DMARC環境の設計と操作の概要を説明します。
The following mechanisms for determining Authenticated Identifiers are supported in this version of DMARC:
このバージョンのDMARCでは、認証済み識別子を決定するための次のメカニズムがサポートされています。
o [DKIM], which provides a domain-level identifier in the content of the "d=" tag of a validated DKIM-Signature header field.
o [DKIM]。検証されたDKIM-Signatureヘッダーフィールドの「d =」タグのコンテンツにドメインレベルの識別子を提供します。
o [SPF], which can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes MAIL FROM processing for cases in which the MAIL command has a null path.
o [SPF]。[SMTP] HELO / EHLOコマンドで見つかったドメイン（HELO ID）と、SMTP MAILコマンドで見つかったドメイン（MAIL FROM ID）の両方を認証できます。 DMARCは、MAIL FROM IDのSPF認証の結果を使用します。 [SPF]のセクション2.4は、MAILコマンドにnullパスがある場合のMAIL FROM処理について説明しています。
DMARC policies are published by the Domain Owner, and retrieved by the Mail Receiver during the SMTP session, via the DNS.
DMARCポリシーはドメイン所有者によって公開され、SMTPセッション中にDNS経由でメールレシーバーによって取得されます。
DMARC's filtering function is based on whether the RFC5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a DMARC policy is published for the domain name found in the RFC5322.From field, and that domain name is not validated through SPF or DKIM, the disposition of that message can be affected by that DMARC policy when delivered to a participating receiver.
DMARCのフィルタリング機能は、RFC5322.FromフィールドドメインがSPFまたはDKIMからの認証済みドメイン名と整合（一致）しているかどうかに基づいています。 RFC5322.Fromフィールドにあるドメイン名に対してDMARCポリシーが公開され、そのドメイン名がSPFまたはDKIMを通じて検証されない場合、そのメッセージの処理は、参加している受信者に配信されるときにそのDMARCポリシーの影響を受ける可能性があります。
It is important to note that the authentication mechanisms employed by DMARC authenticate only a DNS domain and do not authenticate the local-part of any email address identifier found in a message, nor do they validate the legitimacy of message content.
DMARCで採用されている認証メカニズムはDNSドメインのみを認証し、メッセージで見つかった電子メールアドレス識別子のローカル部分は認証せず、メッセージコンテンツの正当性を検証しないことに注意することが重要です。
DMARC's feedback component involves the collection of information about received messages claiming to be from the Organizational Domain for periodic aggregate reports to the Domain Owner. The parameters and format for such reports are discussed in later sections of this document.
DMARCのフィードバックコンポーネントには、ドメイン所有者への定期的な集計レポートのために組織ドメインからのものであると主張する受信メッセージに関する情報の収集が含まれます。このようなレポートのパラメーターと形式については、このドキュメントの後のセクションで説明します。
A DMARC-enabled Mail Receiver might also generate per-message reports that contain information related to individual messages that fail SPF and/or DKIM. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [AFRF].
DMARC対応のメールレシーバーは、SPFやDKIMに失敗した個々のメッセージに関連する情報を含むメッセージごとのレポートを生成する場合もあります。メッセージごとの障害レポートは、展開をデバッグする場合（認証に失敗してもメッセージが正当であると判断できる場合）または攻撃の分析に役立つ情報源です。このようなサービスの機能はDMARCによって有効になりますが、[AFRF]などの他の参照資料で定義されています。
A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:
メッセージは、サポートされる認証メカニズムの少なくとも1つが以下の場合にDMARCチェックを満たします。
1. produces a "pass" result, and
1. 「合格」結果を生成し、
2. produces that result based on an identifier that is in alignment, as defined in Section 3.
2. セクション3で定義されているように、整列している識別子に基づいてその結果を生成します。
+---------------+
| Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
+---------------+ . . .
| . . .
V V V .
+-----------+ +--------+ +----------+ +----------+ .
| MSA |<***>| DKIM | | DKIM | | SPF | .
| Service | | Signer | | Verifier | | Verifier | .
+-----------+ +--------+ +----------+ +----------+ .
| ^ ^ .
| ************** .
V * .
+------+ (~~~~~~~~~~~~) +------+ * .
| sMTA |------->( other MTAs )----->| rMTA | * .
+------+ (~~~~~~~~~~~~) +------+ * .
| * ........
| * .
V * .
+-----------+ V V
+---------+ | MDA | +----------+
| User |<--| Filtering |<***>| DMARC |
| Mailbox | | Engine | | Verifier |
+---------+ +-----------+ +----------+
MSA = Mail Submission Agent MDA = Mail Delivery Agent
MSA =メール送信エージェントMDA =メール配信エージェント
The above diagram shows a simple flow of messages through a DMARC-aware system. Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to the supported message authentication schemes, and asterisk lines indicate data exchange between message-handling modules and message authentication modules. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.
上の図は、DMARC対応システムを介したメッセージの単純なフローを示しています。実線は実際のメッセージフローを示し、点線はサポートされているメッセージ認証スキームに関連するメッセージポリシーを取得するために使用されるDNSクエリを含み、アスタリスク線はメッセージ処理モジュールとメッセージ認証モジュール間のデータ交換を示します。 「sMTA」は送信MTA、「rMTA」は受信MTAです。
In essence, the steps are as follows:
基本的に、手順は次のとおりです。
1. Domain Owner constructs an SPF policy and publishes it in its DNS database as per [SPF]. Domain Owner also configures its system for DKIM signing as described in [DKIM]. Finally, Domain Owner publishes via the DNS a DMARC message-handling policy.
1. ドメイン所有者はSPFポリシーを作成し、[SPF]に従ってDNSデータベースに公開します。ドメイン所有者は、[DKIM]で説明されているように、DKIM署名用にシステムを構成します。最後に、ドメイン所有者はDNSを介してDMARCメッセージ処理ポリシーを公開します。
2. Author generates a message and hands the message to Domain Owner's designated mail submission service.
2. 作成者はメッセージを生成し、ドメイン所有者の指定したメール送信サービスにメッセージを渡します。
3. Submission service passes relevant details to the DKIM signing module in order to generate a DKIM signature to be applied to the message.
3. 送信サービスは、メッセージに適用されるDKIM署名を生成するために、関連する詳細をDKIM署名モジュールに渡します。
4. Submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s).
4. 送信サービスは、署名されたメッセージを指定のトランスポートサービスに中継して、目的の受信者にルーティングします。
5. Message may pass through other relays but eventually arrives at a recipient's transport service.
5. メッセージは他のリレーを通過する可能性がありますが、最終的には受信者のトランスポートサービスに到着します。
6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which requires queries to the Author Domain's DNS data (when identifiers are aligned; see below).
6. 受信者配信サービスは、必要なデータをそれぞれのモジュールに渡すことにより、SPFおよびDKIM認証チェックを実行します。各モジュールには、作成者ドメインのDNSデータへのクエリが必要です（識別子が揃っている場合。以下を参照）。
7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)
7. これらの結果は、作者のドメインとともにDMARCモジュールに渡されます。 DMARCモジュールは、そのドメインのDNSからポリシーを取得しようとします。見つからない場合、DMARCモジュールは組織ドメインを決定し、DNSからポリシーを取得する試みを繰り返します。 （これについては、セクション6.6.3で詳しく説明します。）
8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail") and can optionally cause one of two kinds of reports to be generated (not shown).
8. ポリシーが見つかると、作成者のドメインとSPFおよびDKIMの結果が組み合わされてDMARCポリシーの結果（「合格」または「不合格」）が生成され、オプションで2種類のレポートのいずれかが生成されます（示されています）。
9. Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown).
9. 受信者トランスポートサービスは、メッセージを受信者の受信トレイに配信するか、DMARCの結果に基づいて他のローカルポリシーアクションを実行します（図には示されていません）。
10. When requested, Recipient transport service collects data from the message delivery session to be used in providing feedback (see Section 7).
10. 要求されると、受信者トランスポートサービスはメッセージ配信セッションからデータを収集して、フィードバックの提供に使用します（セクション7を参照）。
One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, which is part of a body of data that has been trivially forged throughout the history of email.
DMARCのセキュリティ監視の最も明白なポイントの1つは、識別子、つまりRFC5322.Fromアドレスに焦点を合わせるという選択です。これは、電子メールの履歴全体で簡単に偽造されたデータの本文の一部です。
Several points suggest that it is the most correct and safest thing to do in this context:
いくつかの点から、このコンテキストで行うことが最も正確で最も安全な方法であることがわかります。
o Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present.
o メッセージ自体の一部であるすべての識別子の中で、これが存在することが保証されている唯一のものです。
o It seems the best choice of an identifier on which to focus, as most MUAs display some or all of the contents of that field in a manner strongly suggesting those data as reflective of the true originator of the message.
o ほとんどのMUAは、メッセージの真の発信者を反映するものとしてそれらのデータを強く示唆する方法でそのフィールドの内容の一部またはすべてを表示するので、焦点を合わせる識別子の最良の選択のようです。
The absence of a single, properly formed RFC5322.From field renders the message invalid. Handling of such a message is outside of the scope of this specification.
適切に形成された単一のRFC5322.Fromフィールドがないと、メッセージは無効になります。このようなメッセージの処理は、この仕様の範囲外です。
Since the sorts of mail typically protected by DMARC participants tend to only have single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 with respect to the expected syntax of this field. See Section 6.6 for details.
DMARC参加者によって通常保護される種類のメールは単一の作成者しかいない傾向があるため、DMARC参加者は通常、このフィールドの予想される構文に関して、RFC5322のわずかに制限されたプロファイルで動作します。詳細については、セクション6.6を参照してください。
DMARC policies are published by Domain Owners and applied by Mail Receivers.
DMARCポリシーはドメイン所有者によって公開され、メール受信者によって適用されます。
A Domain Owner advertises DMARC participation of one or more of its domains by adding a DNS TXT record (described in Section 6.1) to those domains. In doing so, Domain Owners make specific requests of Mail Receivers regarding the disposition of messages purporting to be from one of the Domain Owner's domains and the provision of feedback about those messages.
ドメイン所有者は、ドメインにDNS TXTレコード（6.1で説明）を追加することにより、そのドメインの1つ以上のDMARC参加をアドバタイズします。その際、ドメイン所有者は、ドメイン所有者のドメインの1つからのものであると主張するメッセージの処理とそれらのメッセージに関するフィードバックの提供に関して、メール受信者に特定の要求を行います。
A Domain Owner may choose not to participate in DMARC evaluation by Mail Receivers. In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result.
ドメイン所有者は、メール受信者によるDMARC評価に参加しないことを選択できます。この場合、ドメイン所有者は、これらのスキームへの参加を宣伝することを拒否します。たとえば、パス認証チェックの結果を特定の作成者ドメインの全体的なDMARC結果の一部と見なすべきではない場合、ドメイン所有者は、SPFパス結果を生成できるSPFポリシーレコードを公開しません。
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner's published DMARC policy when a message fails the DMARC test. Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).
DMARCメカニズムを実装するメールレシーバーは、メッセージがDMARCテストに失敗した場合、ドメインオーナーの公開されたDMARCポリシーに準拠するように最善の努力をする必要があります（SHOULD）。電子メールストリームは複雑になる可能性があるため（転送、既存のRFC5322、ドメインスプーフィングサービスなどから）、メール受信者はメッセージ処理中にドメイン所有者の公開されたポリシーから逸脱する場合があり、その逸脱の事実と理由を利用できるようにする必要があります（SHOULD）。フィードバックレポートを介して、特に集計レポートの「PolicyOverride」機能を使用して、ドメイン所有者（セクション7.2を参照）
Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". Similarly, a Mail Receiver wishing to query for DMARC preferences regarding mail with an RFC5322.From domain of "example.com" would issue a TXT query to the DNS for the subdomain of "_dmarc.example.com". The DNS-located DMARC preference data will hereafter be called the "DMARC record".
ドメイン所有者のDMARC設定は、「_ dmarc」という名前のサブドメインにDNS TXTレコードとして保存されます。たとえば、「example.com」のドメイン所有者は、「_ dmarc.example.com」のTXTレコードにDMARC設定を投稿します。同様に、RFC5322.Fromドメインが「example.com」のメールに関するDMARCプリファレンスを照会するメール受信者は、「_ dmarc.example.com」のサブドメインのDNSにTXTクエリを発行します。 DNSに配置されたDMARCプリファレンスデータは、以降「DMARCレコード」と呼ばれます。
DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS, for obtaining simple parametric information. It uses an established method of storing the information, associated with the target domain name, namely an isolated TXT record that is restricted to the DMARC context. Use of the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.
DMARCによるドメインネームサービスの使用は、DMARCによるドメイン名の使用と、それが実行するクエリの性質によって促進されます。単純なパラメトリック情報を取得するために、クエリ要件はDNSと一致します。ターゲットドメイン名、つまりDMARCコンテキストに制限されている分離されたTXTレコードに関連付けられた、確立された情報格納方法を使用します。クエリサービスとしてDNSを使用すると、新しいインフラストラクチャを作成するのではなく、非常に確立された運用、管理、および管理インフラストラクチャを再利用できるという利点があります。
Per [DNS], a TXT record can comprise several "character-string" objects. Where this is the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string.
[DNS]ごとに、TXTレコードは複数の「文字列」オブジェクトで構成できます。この場合、DMARC評価を実行するモジュールは、オブジェクトを順番に結合し、結果を単一の文字列として解析することにより、これらの文字列を連結する必要があります。
[URI] defines a generic syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner specifies the destination for the two report types that are supported.
[URI]は、リソースを識別するための一般的な構文を定義します。 DMARCメカニズムはこれを、ドメイン所有者がサポートされる2つのレポートタイプの宛先を指定する形式として使用します。
The place such URIs are specified (see Section 6.3) allows a list of these to be provided. A report is normally sent to each listed URI in the order provided by the Domain Owner. Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two. The list of URIs is separated by commas (ASCII 0x2C).
そのようなURIが指定されている場所（セクション6.3を参照）では、これらのURIのリストを提供できます。レポートは通常、ドメイン所有者から提供された順序で、リストされている各URIに送信されます。受信者は、レポートを送信するURIの数に制限を課してもよい（MAY）が、少なくとも2つに送信する機能をサポートしなければならない（MUST）。 URIのリストはコンマで区切られます（ASCII 0x2C）。
Each URI can have associated with it a maximum report size that may be sent to it. This is accomplished by appending an exclamation point (ASCII 0x21), followed by a maximum-size indication, before a separating comma or terminating semicolon.
各URIには、送信できる最大レポートサイズを関連付けることができます。これは、感嘆符（ASCII 0x21）を追加し、その後に最大サイズを示すことにより、コンマを区切るか、セミコロンで終了します。
Thus, a DMARC URI is a URI within which any commas or exclamation points are percent-encoded per [URI], followed by an OPTIONAL exclamation point and a maximum-size specification, and, if there are additional reporting URIs in the list, a comma and the next URI.
したがって、DMARC URIは、[URI]ごとにカンマまたは感嘆符がパーセントでエンコードされたURIであり、その後にオプションの感嘆符と最大サイズの指定が続きます。リストに追加のレポートURIがある場合は、コンマと次のURI。
For example, the URI "mailto:reports@example.com!50m" would request that a report be sent via email to "reports@example.com" so long as the report payload does not exceed 50 megabytes.
たとえば、URI「mailto：reports@example.com！50m」は、レポートのペイロードが50メガバイトを超えない限り、レポートを電子メールで「reports@example.com」に送信するように要求します。
A formal definition is provided in Section 6.4.
正式な定義はセクション6.4にあります。
DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].
DMARCレコードは、DKIM [DKIM]で定義されたDNSベースのキーレコードの拡張可能な「タグ値」構文に従います。
Section 11 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored.
セクション11では、既知のDMARCタグのレジストリを作成し、このドキュメントで定義されている初期セットを登録します。このドキュメントまたはそれ以降の拡張機能で定義され、したがってそのレジストリに追加されたタグのみが処理されます。不明なタグは無視する必要があります。
The following tags are introduced as the initial valid DMARC tags:
以下のタグは、初期の有効なDMARCタグとして導入されています。
adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. See Section 3.1.1 for details. Valid values are as follows:
adkim：（plain-text; OPTIONAL;デフォルトは "r"です。）ドメイン所有者が厳密なDKIM識別子調整モードを必要とするかどうかを示します。詳細については、セクション3.1.1を参照してください。有効な値は次のとおりです。
r: relaxed mode
r：リラックスモード
s: strict mode
s：厳格モード
aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. See Section 3.1.2 for details. Valid values are as follows:
aspf：（plain-text; OPTIONAL;デフォルトは "r"です。）ドメイン所有者が厳密なSPF識別子調整モードを必要とするか緩和するかを示します。詳細については、セクション3.1.2を参照してください。有効な値は次のとおりです。
r: relaxed mode
r：リラックスモード
s: strict mode
s：厳格モード
fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:
fo：障害レポートオプション（プレーンテキスト、オプション、デフォルトは「0」）障害レポートの生成に必要なオプションを提供します。レポートジェネレーターは、要求されたオプションに従うことを選択できます。 「下記」のrufタグも指定されていない場合、このタグのコンテンツは無視する必要があります。このタグの値は、次のように、障害報告オプションを示す、コロンで区切られた文字のリストです。
0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.
0：基礎となるすべての認証メカニズムが整列した「合格」結果を生成できない場合、DMARC障害レポートを生成します。
1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.
1：基礎となる認証メカニズムが、調整された「合格」結果以外のものを生成した場合、DMARC障害レポートを生成します。
d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [AFRF-DKIM].
d：アライメントに関係なく、メッセージに評価に失敗した署名が含まれている場合は、DKIM障害レポートを生成します。 DKIM固有のレポートについては、[AFRF-DKIM]で説明されています。
s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF].
s：メッセージが整列に関係なくSPF評価に失敗した場合、SPF障害レポートを生成します。 SPF固有のレポートについては、[AFRF-SPF]で説明されています。
p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows:
p：要求されたメール受信者ポリシー（プレーンテキスト、ポリシーレコードには必須）。ドメイン所有者の要求に応じて受信者が実行するポリシーを示します。サブドメインポリシーが「sp」タグを使用して明示的に記述されていない限り、ポリシーはクエリされたドメインとサブドメインに適用されます。このタグはポリシーレコードにのみ必須であり、サードパーティのレポートレコードには必須ではありません（セクション7.1を参照）。可能な値は次のとおりです。
none: The Domain Owner requests no specific action be taken regarding delivery of messages.
none：ドメイン所有者は、メッセージの配信に関して特定のアクションを要求しません。
quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".
検疫：ドメイン所有者は、DMARCメカニズムのチェックに失敗したメールを、メール受信者が疑わしいものとして処理することを望んでいます。メールレシーバーの機能によっては、「スパムフォルダーに配置する」、「強度を上げて精査する」、「疑わしいとしてフラグを立てる」などの意味があります。
reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.
reject：ドメイン所有者は、DMARCメカニズムチェックに失敗したメールをメール受信者が拒否することを望んでいます。拒否は、SMTPトランザクション中に発生する必要があります（SHOULD）。 SMTP拒否方法とその影響については、セクション10.3を参照してください。
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The purpose of the "pct" tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of "all or nothing" is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. See Section 6.6.4 for details. Note that random selection based on this percentage, such as the following pseudocode, is adequate:
pct：（0から100までのプレーンテキスト整数、オプション、オプション、デフォルトは100）。 DMARCポリシーが適用されるドメイン所有者のメールストリームからのメッセージの割合。ただし、これはDMARCで生成されたレポートには適用しないでください。これらのレポートはすべて、妨げられずに送受信する必要があります。 「pct」タグの目的は、ドメイン所有者がDMARCメカニズムの遅いロールアウトの実施を実施できるようにすることです。 「オールオアナッシング」の見込みは、多くの組織が強力な認証ベースのメカニズムを試すことを妨げていると認識されています。詳細については、セクション6.6.4を参照してください。次の擬似コードのように、このパーセンテージに基づくランダム選択が適切であることに注意してください。
if (random mod 100) < pct then selected = true else selected = false
if（random mod 100）<pct then selected = true else selected = false
rf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both [SPF] and [DKIM] tests to report details of the individual failure. The values MUST be present in the registry of reporting formats defined in Section 11; a Mail Receiver observing a different value SHOULD ignore it or MAY ignore the entire DMARC record. For this version, only "afrf" (the auth-failure report type defined in [AFRF]) is presently supported. See Section 7.3 for details. For interoperability, the Authentication Failure Reporting Format (AFRF) MUST be supported.
rf：メッセージ固有の障害レポートに使用される形式（コロンで区切られた値の平文リスト、オプション、デフォルトは "afrf"）。このタグの値は、メッセージが[SPF]と[DKIM]の両方のテストに失敗して個々の失敗の詳細を報告するときに使用される、ドメイン所有者から要求された1つ以上のレポート形式のリストです。値は、セクション11で定義されているレポート形式のレジストリに存在している必要があります。別の値を監視するメールレシーバーはそれを無視するか、DMARCレコード全体を無視する必要があります。このバージョンでは、「afrf」（[AFRF]で定義されているauth-failureレポートタイプ）のみが現在サポートされています。詳細については、セクション7.3を参照してください。相互運用性のために、認証失敗報告形式（AFRF）をサポートする必要があります。
ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis.
ri：集約レポート間で要求される間隔（プレーンテキストの32ビット符号なし整数、オプション、デフォルトは86400）。要求された秒数以下で区切られた集約レポートを生成するためのレシーバーへの要求を示します。 DMARC実装は、日次レポートを提供できなければならず、要求されたときに時間別レポートを提供できなければなりません（SHOULD）。ただし、日次レポート以外はベストエフォートベースで対応できると理解されています。
rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma or exclamation point that is part of such a DMARC URI MUST be encoded per Section 2.1 of [URI] so as to distinguish it from the list delimiter or an OPTIONAL size limit. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 12.5 for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate aggregate feedback reports. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in Section 7.2.
rua：集約フィードバックの送信先アドレス（DMARC URIのコンマ区切りのプレーンテキストリスト。オプション）。このようなDMARC URIの一部であるコンマまたは感嘆符は、[URI]のセクション2.1に従ってエンコードして、リストの区切り文字またはオプションのサイズ制限と区別する必要があります。セクション7.1では、URIのドメイン名がポリシーをアドバタイズするドメインのドメイン名と異なる場合に適用される考慮事項について説明します。その他の考慮事項については、セクション12.5を参照してください。任意の有効なURIを指定できます。メールレシーバーは、「mailto：」URIのサポート、つまり電子メールを介してDMARCレポートを送信する機能を実装する必要があります。提供されない場合、メール受信者は集約フィードバックレポートを生成してはなりません（MUST NOT）。メールレシーバーでサポートされていないURIは無視する必要があります。集計フィードバックレポートの形式については、セクション7.2で説明しています。
ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag above). The format of the message to be generated MUST follow the format specified for the "rf" tag. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate failure reports. See Section 12.5 for additional considerations.
ruf：メッセージ固有の障害情報が報告されるアドレス（DMARC URIのコンマ区切りのプレーンテキストリスト。オプション）。存在する場合、ドメイン所有者は、特定の方法でDMARC評価に失敗したメッセージに関する詳細な失敗レポートを送信するようにメールレシーバーに要求しています（上記の「fo」タグを参照）。生成されるメッセージの形式は、「rf」タグに指定された形式に従う必要があります。セクション7.1では、URIのドメイン名がポリシーをアドバタイズするドメインのドメイン名と異なる場合に適用される考慮事項について説明します。メールレシーバーは、「mailto：」URIのサポート、つまり電子メールを介してDMARCレポートを送信する機能を実装する必要があります。指定しない場合、メール受信者は失敗レポートを生成してはなりません（MUST NOT）。その他の考慮事項については、セクション12.5を参照してください。
sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3.
sp：すべてのサブドメインの要求されたメールレシーバーポリシー（プレーンテキスト、オプション）。ドメイン所有者の要求に応じて受信者が実行するポリシーを示します。照会されたドメインのサブドメインにのみ適用され、ドメイン自体には適用されません。その構文は、上記で定義した「p」タグの構文と同じです。存在しない場合、「p」タグで指定されたポリシーをサブドメインに適用する必要があります。セクション6.6.3で説明されているDMARCポリシー検出メカニズムの影響により、組織ドメインのサブドメインで公開されているDMARCレコードの「sp」は無視されることに注意してください。
v: Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1". The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.
v：バージョン（プレーンテキスト、必須）。取得したレコードをDMARCレコードとして識別します。 「DMARC1」の値が必要です。このタグの値は正確に一致する必要があります。存在しない場合や存在しない場合は、取得したレコード全体を無視する必要があります。リストの最初のタグでなければなりません。
A DMARC policy record MUST comply with the formal specification found in Section 6.4 in that the "v" and "p" tags MUST be present and MUST appear in that order. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright.
DMARCポリシーレコードは、「v」タグと「p」タグが存在しなければならず、その順序で出現しなければならないという点で、セクション6.4にある正式な仕様に準拠する必要があります。不明なタグは無視する必要があります。レコードの残りの部分の構文エラーは、デフォルト値（存在する場合）を優先して破棄するか、完全に無視する必要があります（SHOULD）。
Note that given the rules of the previous paragraph, addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC.
前の段落のルールを踏まえると、新しいタグをタグの登録済みリストに追加すること自体は、DMARCの新しいバージョンを生成する必要はありません（「v」タグの値に対応する変更を伴う）が、既存のタグには新しいバージョンのDMARCが必要です。
The formal definition of the DMARC format, using [ABNF], is as follows:
[ABNF]を使用したDMARC形式の正式な定義は次のとおりです。
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; "URI" is imported from [URI]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit
; within an unsigned 64-bit integer
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
dmarc-sep = *WSP %x3b *WSP
dmarc-request = "p" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-srequest = "sp" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-auri = "rua" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-furi = "ruf" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-adkim = "adkim" *WSP "=" *WSP
( "r" / "s" )
dmarc-aspf = "aspf" *WSP "=" *WSP
( "r" / "s" )
dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT
dmarc-fo = "fo" *WSP "=" *WSP
( "0" / "1" / "d" / "s" )
*(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))
dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
; registered reporting formats only
dmarc-percent = "pct" *WSP "=" *WSP
1*3DIGIT
"Keyword" is imported from Section 4.1.2 of [SMTP].
「キーワード」は、[SMTP]のセクション4.1.2からインポートされます。
A size limitation in a dmarc-uri, if provided, is interpreted as a count of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the number is presumed to be a basic byte count. Note that the units are considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc.
dmarc-uriのサイズ制限は、指定されている場合、オプションの単位サイズが続く単位の数として解釈されます（キロバイトの場合は「k」、メガバイトの場合は「m」、ギガバイトの場合は「g」、テラバイトの場合は「t」） 。単位がない場合、その数は基本的なバイト数と見なされます。単位は2の累乗と見なされることに注意してください。キロバイトは2 ^ 10、メガバイトは2 ^ 20などです。
To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both.
DMARCメカニズムを実装するために、ドメイン所有者に必要な唯一のアクションは、DNSでのDMARCポリシーレコードの作成です。ただし、DMARCを意味のある方法で使用するには、ドメイン所有者は少なくとも、レポートを受信するためのアドレスを確立するか、認証技術を展開して識別子の整合性を確保する必要があります。ほとんどのドメイン所有者は、両方を実行する必要があります。
DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate.
DMARCレポートはサイズが大きく、それらを受信するアドレスは一般に公開されるため、ドメイン所有者は、レポートを受信して処理するための専用のメールアドレスを設定し、必要に応じてこれらのメールアドレスに不正行為対策を展開することをお勧めします。
Authentication technologies are discussed in [DKIM] (see also [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF].
認証技術については、[DKIM]（[DKIM-OVERVIEW]および[DKIM-DEPLOYMENT]も参照）および[SPF]で説明されています。
This section describes receiver actions in the DMARC environment.
このセクションでは、DMARC環境でのレシーバーアクションについて説明します。
The domain in the RFC5322.From field is extracted as the domain to be evaluated by DMARC. If the domain is encoded with UTF-8, the domain name must be converted to an A-label, as described in Section 2.3 of [IDNA], for further processing.
RFC5322.Fromフィールドのドメインは、DMARCによって評価されるドメインとして抽出されます。ドメインがUTF-8でエンコードされている場合は、[IDNA]のセクション2.3で説明されているように、ドメイン名をAラベルに変換して、さらに処理する必要があります。
In order to be processed by DMARC, a message typically needs to contain exactly one RFC5322.From domain (a single From: field with a single domain in it). Not all messages meet this requirement, and handling of them is outside of the scope of this document. Typical exceptions, and the way they have been historically handled by DMARC participants, are as follows:
DMARCで処理するために、メッセージには通常、RFC5322.Fromドメインが1つだけ含まれている必要があります（ドメインが1つあるFrom：フィールドが1つ）。すべてのメッセージがこの要件を満たしているわけではなく、それらの処理はこのドキュメントの範囲外です。典型的な例外と、それらがDMARC参加者によって歴史的に処理されてきた方法は、次のとおりです。
o Messages with multiple RFC5322.From fields are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
o RFC5322.Fromフィールドが複数あるメッセージは、RFC 5322 [メール]でそのフォームが禁止されているため、通常は拒否されます。
o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format;
o 複数のアドレス（つまり、評価される複数のドメイン名）を含む単一のRFC5322.Fromフィールドを持つメッセージは、通常DMARCによって保護される種類のメールではこの形式を使用しないため、通常は拒否されます。
o Messages that have no RFC5322.From field at all are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
o RFC5322.Fromフィールドがまったくないメッセージは、RFC 5322 [メール]でそのフォームが禁止されているため、通常は拒否されます。
o Messages with an RFC5322.From field that contains no meaningful domains, such as RFC 5322 [MAIL]'s "group" syntax, are typically ignored.
o RFC 5322 [MAIL]の「グループ」構文など、意味のあるドメインを含まないRFC5322.Fromフィールドを持つメッセージは、通常無視されます。
The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail.
構文的に有効な複数値のRFC5322.Fromフィールドの場合には、特定の課題があります。この場合のプロセスは、RFC5322.Fromフィールドにある各ドメインを作成者ドメインとして使用してDMARCチェックを適用し、失敗したチェックの中から選択した最も厳密なポリシーを適用することです。
To arrive at a policy for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps.
個々のメッセージのポリシーに到達するには、メール受信者は次のアクションまたはそれらと同等の意味を実行する必要があります。ステップ2〜4は並行して実行できますが、ステップ5と6は前のステップからの入力を必要とします。
The steps are as follows:
手順は次のとおりです。
1. Extract the RFC5322.From domain from the message (as above).
1. RFC5322.Fromドメインをメッセージから抽出します（上記のとおり）。
2. Query the DNS for a DMARC policy record. Continue if one is found, or terminate DMARC evaluation otherwise. See Section 6.6.3 for details.
2. DNSにDMARCポリシーレコードを照会します。見つかった場合は続行するか、そうでない場合はDMARC評価を終了します。詳細については、セクション6.6.3を参照してください。
3. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature.
3. DKIM署名検証チェックを実行します。 1つのメールに複数のDKIM署名が含まれる場合があります。このステップの結果は、アルゴリズムの残りの部分に渡され、チェックされた各DKIM署名からの「d =」タグの値を含める必要があります。
4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check.
4. SPF検証チェックを実行します。このステップの結果は残りのアルゴリズムに渡され、SPFチェックを完了するために使用されるドメイン名を含める必要があります。
5. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures.
5. 識別子の配置チェックを実施します。認証チェックとポリシー検出が実行されると、メールレシーバーは、セクション3で説明されているように、認証済み識別子が整合しているかどうかを確認します。1つ以上の認証済み識別子がRFC5322.Fromドメインと整合している場合、メッセージはDMARCメカニズムチェック。他のすべての条件（認証の失敗、識別子の不一致）は、DMARCメカニズムチェックの失敗と見なされます。
6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details.
6. ポリシーを適用します。 DMARCメカニズムのチェックに失敗したメールは、ドメイン所有者の検出されたDMARCポリシーに従って破棄されます。詳細については、セクション6.3を参照してください。
Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a Message Receiver not to consider the results of that underlying authentication protocol at all.
ドメイン所有者がSPFまたはDKIMのいずれかを使用していない場合に適用されるヒューリスティック（たとえば、[Best-Guess-SPF]）は使用しないでください。ドメイン所有者がメッセージレシーバーを考慮しないことを望む場合があるためです。その基礎となる認証プロトコルの結果。
DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them fail due to a temporary error, the Receiver evaluating the message is unable to conclude that the DMARC mechanism had a permanent failure; they therefore cannot apply the advertised DMARC policy. When otherwise appropriate, Receivers MAY send feedback reports regarding temporary errors.
DMARC評価は、基になる認証メカニズムの1つが境界整列された識別子に合格した後にのみ「合格」結果を生成できます。一時的なエラーが原因でどちらも成功せず、どちらか一方または両方が失敗した場合、メッセージを評価する受信者は、DMARCメカニズムに永続的な障害があると結論付けることができません。したがって、アドバタイズされたDMARCポリシーを適用できません。特に適切な場合、受信者は一時的なエラーに関するフィードバックレポートを送信できます。
Handling of messages for which SPF and/or DKIM evaluation encounter a permanent DNS error is left to the discretion of the Mail Receiver.
SPFやDKIMの評価で永続的なDNSエラーが発生したメッセージの処理は、メール受信者の裁量に任されています。
As stated above, the DMARC mechanism uses DNS TXT records to advertise policy. Policy discovery is accomplished via a method similar to the method used for SPF records. This method, and the important differences between DMARC and SPF mechanisms, are discussed below.
上記のように、DMARCメカニズムはDNS TXTレコードを使用してポリシーをアドバタイズします。ポリシーの検出は、SPFレコードに使用される方法と同様の方法で行われます。この方法と、DMARCメカニズムとSPFメカニズムの重要な違いについて、以下で説明します。
To balance the conflicting requirements of supporting wildcarding, allowing subdomain policy overrides, and limiting DNS query load, the following DNS lookup scheme is employed:
ワイルドカードのサポート、サブドメインポリシーのオーバーライドの許可、DNSクエリの負荷の制限という相反する要件のバランスを取るために、次のDNSルックアップスキームが採用されています。
1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322.From domain in the message. A possibly empty set of records is returned.
1. メール受信者は、メッセージ内のRFC5322.Fromドメインにあるものと一致するDNSドメインのDMARC TXTレコードをDNSに照会する必要があります。空のレコードセットが返されます。
2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.
2. DMARCの現在のバージョンを識別する「v =」タグで始まらないレコードは破棄されます。
3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned.
3. セットが現在空の場合、メールレシーバーは、メッセージ内のRFC5322.Fromドメイン（異なる場合）の代わりに、組織ドメインと一致するDNSドメインでDMARC TXTレコードをDNSに照会する必要があります。このレコードには、組織ドメインのサブドメインに対してアサートされるポリシーを含めることができます。空のレコードセットが返されます。
4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.
4. DMARCの現在のバージョンを識別する「v =」タグで始まらないレコードは破棄されます。
5. If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message.
5. 残りのセットに複数のレコードが含まれている場合、またはレコードが含まれていない場合、ポリシー検出は終了し、DMARC処理はこのメッセージに適用されません。
6. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" tag that is not valid, then:
6. 取得したポリシーレコードに有効な「p」タグが含まれていない場合、または無効な「sp」タグが含まれている場合は、次のようになります。
1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing;
1. 「rua」タグが存在し、構文的に有効なレポートURIが少なくとも1つ含まれている場合、メールレシーバーは、有効な「v」タグと「p = none」を含むレコードが取得されたかのように動作し、処理を続行する必要があります。
2. otherwise, the Mail Receiver applies no DMARC processing to this message.
2. それ以外の場合、メールレシーバーはこのメッセージにDMARC処理を適用しません。
If the set produced by the mechanism above contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC mechanism to the message.
上記のメカニズムによって生成されたセットにDMARCポリシーレコードが含まれていない場合（つまり、一時的なDNSエラーではなく、そのようなレコードがないことを示す場合）、メールレシーバーはDMARCメカニズムをメッセージに適用しないでください（SHOULD NOT）。
Handling of DNS errors when querying for the DMARC policy record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed").
DMARCポリシーレコードのクエリ時のDNSエラーの処理は、メールレシーバーの裁量に任されています。たとえば、メールフローの中断を最小限に抑えるために、一時的なエラーによってメッセージが配信される（「フェールオープン」）か、メッセージが一時的に拒否される（つまり、SMTP 4yx応答）場合があります。状態がおそらくクリアされた後、MTAは再試行して、DMARCの明確な結論に到達できるようにします（「フェイルクローズ」）。
If the "pct" tag is present in the policy record, the Mail Receiver MUST NOT enact the requested policy ("p" tag or "sp" tag") on more than the stated percent of the totality of affected messages. However, regardless of whether or not the "pct" tag is present, the Mail Receiver MUST include all relevant message data in any reports produced.
「pct」タグがポリシーレコードに存在する場合、メールレシーバーは、要求されたポリシー（「p」タグまたは「sp」タグ）を、影響を受けるメッセージの総数の指定されたパーセントを超えて制定してはなりません（MUST NOT）。 「pct」タグが存在するかどうかに関係なく、メールレシーバーは、生成されるレポートにすべての関連メッセージデータを含める必要があります。
If email is subject to the DMARC policy of "quarantine", the Mail Receiver SHOULD quarantine the message. If the email is not subject to the "quarantine" policy (due to the "pct" tag), the Mail Receiver SHOULD apply local message classification as normal.
電子メールが「隔離」のDMARCポリシーの対象である場合、メール受信者はメッセージを隔離する必要があります（SHOULD）。電子メールが「隔離」ポリシーの対象ではない場合（「pct」タグのため）、メール受信者は通常どおりローカルメッセージ分類を適用する必要があります（SHOULD）。
If email is subject to the DMARC policy of "reject", the Mail Receiver SHOULD reject the message (see Section 10.3). If the email is not subject to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies. This behavior allows Domain Owners to experiment with progressively stronger policies without relaxing existing policy.
電子メールが「拒否」のDMARCポリシーの対象である場合、メール受信者はメッセージを拒否する必要があります（セクション10.3を参照）。メールに「拒否」ポリシーが適用されていない場合（「pct」タグが原因）、メール受信者は「隔離」ポリシーが適用されているかのようにメールを処理する必要があります（SHOULD）。この動作により、ドメイン所有者は、既存のポリシーを緩和することなく、段階的に強力なポリシーを試すことができます。
Mail Receivers implement "pct" via statistical mechanisms that achieve a close approximation to the requested percentage and provide a representative sample across a reporting period.
メールレシーバーは、統計的メカニズムを介して「pct」を実装し、要求されたパーセンテージに近づき、レポート期間全体にわたって代表的なサンプルを提供します。
The results of Mail Receiver-based DMARC processing should be stored for eventual presentation back to the Domain Owner in the form of aggregate feedback reports. Sections 6.3 and 7.2 discuss aggregate feedback.
メールレシーバーベースのDMARC処理の結果は、最終的なフィードバックとして集計フィードバックレポートの形でドメインオーナーに戻すために保存する必要があります。セクション6.3および7.2では、総計のフィードバックについて説明します。
Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism check. The DMARC mechanism does not inform Mail Receivers whether an email stream is "good". Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled criminal campaigns.
メール受信者は、電子メールがDMARCメカニズムチェックに合格した場合でも、電子メールを拒否または隔離することを選択できます。 DMARCメカニズムは、メールストリームが「良好」であるかどうかをメール受信者に通知しません。メールレシーバーは、DMARC対応の犯罪キャンペーンの可能性に対抗するために、乱用防止テクノロジーを維持することをお勧めします。
Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. Mail Receivers need to make a best effort not to increase the likelihood of accepting abusive mail if they choose not to comply with a Domain Owner's reject, against policy. At a minimum, addition of the Authentication-Results header field (see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing mail is done. When this is done, the DNS domain name thus recorded MUST be encoded as an A-label.
メール受信者は、ドメイン所有者が「拒否」ポリシーを公開している場合でも、DMARCメカニズムチェックに失敗した電子メールを受け入れることを選択できます（MAY）。メール受信者は、ポリシーに反してドメイン所有者の拒否に応じないことを選択した場合、不正メールを受け入れる可能性を高めないように最善の努力をする必要があります。失敗したメールの配信が行われた場合、少なくとも、Authentication-Resultsヘッダーフィールド（[AUTH-RESULTS]を参照）の追加が推奨されます。これが行われるとき、このように記録されたDNSドメイン名は、Aラベルとしてエンコードされる必要があります。
Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. They are not required to report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns.
メールレシーバーは、DMARCポリシーが原因である集約フィードバックレポートで、ポリシーアクションの拒否または隔離を報告する義務があります。ローカルポリシーの結果である拒否または検疫アクションを報告する必要はありません。ローカルポリシー情報が公開されている場合、乱用者はスパムキャンペーンの有効性と配信率に関する洞察を得ることができます。
Final disposition of a message is always a matter of local policy. An operator that wishes to favor DMARC policy over SPF policy, for example, will disregard the SPF policy, since enacting an SPF-determined rejection prevents evaluation of DKIM; DKIM might otherwise pass, satisfying the DMARC evaluation. There is a trade-off to doing so, namely acceptance and processing of the entire message body in exchange for the enhanced protection DMARC provides.
メッセージの最終的な処理は、常にローカルポリシーの問題です。たとえば、SPFポリシーよりもDMARCポリシーを優先することを希望するオペレーターは、SPFポリシーを無視します。これは、SPFによって決定された拒否を実行すると、DKIMの評価が妨げられるためです。それ以外の場合、DKIMは合格し、DMARC評価を満たします。そうすることにはトレードオフがあります。つまり、DMARCが提供する強化された保護と引き換えに、メッセージ本文全体を受け入れて処理します。
DMARC-compliant Mail Receivers typically disregard any mail-handling directive discovered as part of an authentication mechanism (e.g., Author Domain Signing Practices (ADSP), SPF) where a DMARC record is also discovered that specifies a policy other than "none". Deviating from this practice introduces inconsistency among DMARC operators in terms of handling of the message. However, such deviation is not proscribed.
DMARC準拠のメールレシーバーは通常、「なし」以外のポリシーを指定するDMARCレコードも検出される認証メカニズム（たとえば、Author Domain Signing Practices（ADSP）、SPF）の一部として検出されたメール処理ディレクティブを無視します。この方法から逸脱すると、メッセージの処理に関してDMARCオペレーター間で不整合が生じます。ただし、そのような逸脱は禁止されていません。
To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.
ドメイン所有者が既存のメール処理に影響を与えずにDMARCフィードバックを受信できるようにするには、「p = none」の検出されたポリシーで既存のメール処理を変更しないでください。
Mail Receivers SHOULD also implement reporting instructions of DMARC, even in the absence of a request for DKIM reporting [AFRF-DKIM] or SPF reporting [AFRF-SPF]. Furthermore, the presence of such requests SHOULD NOT affect DMARC reporting.
メールレシーバーは、DKIMレポート[AFRF-DKIM]またはSPFレポート[AFRF-SPF]のリクエストがない場合でも、DMARCのレポート指示を実装する必要があります（SHOULD）。さらに、そのようなリクエストの存在はDMARCレポートに影響を与えないでください。
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メカニズムをフィードバックの形で実装し、実施するかについての可視性を提供することは、正確な認証展開を確立および維持するために重要です。ドメイン所有者は、ポリシーと実践がどのような影響を与えているかを確認できると、検疫とポリシーの拒否をより積極的に利用できるようになります。
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 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 [URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken:
メールレシーバーがDNSでDMARCポリシーを検出し、そのレコードが検出された組織ドメインが、「rua」または「」で指定された[URI]の権限コンポーネントのホスト部分の組織ドメインと同一でない場合ruf "タグ、次の検証手順を実行する必要があります。
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 if needed.
3. 必要に応じてAラベルに変換した後、ポリシーの取得元のドメイン名を付加します。
4. 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.
4. 構成された名前でTXTレコードのDNSを照会します。このリクエストの結果がなんらかの一時的なDNSエラー（タイムアウトなど）である場合、メールレシーバーは一時的に配信を失敗させて、後で検証テストを繰り返すことができます。
5. For each record returned, parse the result as a series of "tag=value" pairs, i.e., the same overall format as the policy record (see Section 6.4). In particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list. Discard any that do not pass this test.
5. 返された各レコードについて、結果を一連の「tag = value」ペアとして解析します。つまり、ポリシーレコードと同じ全体形式です（6.4項を参照）。特に、「v = DMARC1」タグは必須であり、リストの最初に出現する必要があります。このテストに合格しないものはすべて破棄します。
6. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.
6. 結果に基本的な解析を通過するTXTリソースレコードが含まれていない場合、外部レポートの関係を明確に判断できません。やめる。
7. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Receiver.
7. 解析後に少なくとも1つのTXTリソースレコードがセットに残っている場合、外部レポートの配置はレポートレシーバーによって承認されました。
8. If a "rua" or "ruf" 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 Receiver 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.
8. 「rua」または「ruf」タグがこのように検出された場合は、ドメインのDMARCポリシーレコードから抽出された対応する値を、このレコードで見つかった値に置き換えます。これにより、レポートレシーバーはレポートの宛先を上書きできます。ただし、ループや間接的な悪用を防ぐために、オーバーライドするURIは最初のステップと同じ宛先ホストを使用する必要があります。
For example, if a DMARC policy query for "blue.example.com" contained "rua=mailto:reports@red.example.net", the 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」のタグを含む単一の応答が返された場合、2つの間の関係が確認されます。さらに、「red.example.net」は、必要に応じて「blue.example.com」によって要求されたレポートの宛先を上書きする機会があります。
Where the above algorithm fails to confirm that the external reporting was authorized by the Report Receiver, 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.
上記のアルゴリズムが、外部レポートがレポートレシーバーによって承認されたことの確認に失敗した場合、URIは、レポートを生成するメールレシーバーによって無視される必要があります。さらに、確認するレコードに、オーバーライドを発行するドメイン発行とは異なるホストを持つURIが確認レコードに含まれている場合、レポートを生成するメールレシーバーは、元のURIまたはオーバーライドURIのいずれかにレポートを生成してはなりません。
A Report Receiver publishes such a record in its DNS if it wishes to receive reports for other domains.
レポートレシーバーは、他のドメインのレポートを受信する場合は、そのようなレコードをDNSに公開します。
A Report Receiver 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 Receiver 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）が有効になるまで、変更に時間がかかる場合があります。
A Mail Receiver might decide not to enact this procedure if, for example, it relies on a local list of domains for which external reporting addresses are permitted.
メール受信者は、たとえば、外部レポートアドレスが許可されているドメインのローカルリストに依存している場合、この手順を実行しないと決定する場合があります。
The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into:
DMARC集計フィードバックレポートは、ドメイン所有者に以下に対する正確な洞察を提供するように設計されています。
o authentication results,
o 認証結果、
o corrective action that needs to be taken by Domain Owners, and
o ドメイン所有者が行う必要がある是正措置
o the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers.
o メール受信者が処理するメールストリームに対するドメイン所有者DMARCポリシーの影響。
Aggregate DMARC feedback provides visibility into real-world email streams that Domain Owners need to make informed decisions regarding the publication of 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) Mail Receiver-originated feedback reports 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認証を通過したメッセージと通過しなかったメッセージに関するデータが含まれます。
The format for these reports is defined in Appendix C.
これらのレポートの形式は、付録Cで定義されています。
The report SHOULD include the following data:
レポートには、次のデータを含める必要があります。
o The DMARC policy discovered and applied, if any
o DMARCポリシーが発見され、適用された場合、
o The selected message disposition
o 選択したメッセージの処理
o The identifier evaluated by SPF and the SPF result, if any
o SPFによって評価された識別子とSPF結果（ある場合）
o The identifier evaluated by DKIM and the DKIM result, if any
o DKIMによって評価された識別子と、DKIMの結果（ある場合）
o For both DKIM and SPF, an indication of whether the identifier was in alignment
o DKIMとSPFの両方で、識別子が整列していたかどうかの指標
o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy
o 明示的なサブドメインポリシーがない場合でも、送信者の組織ドメインからのメールとは別に、各ドメイン所有者のサブドメインのデータ
o Sending and receiving domains
o ドメインの送受信
o The policy requested by the Domain Owner and the policy actually applied (if different)
o ドメイン所有者が要求したポリシーと実際に適用されたポリシー（異なる場合）
o The number of successful authentications
o 成功した認証の数
o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents
o 配信が他のフィルターエージェントによって最終的にブロックされた場合でも、受信したすべてのメッセージに基づくメッセージの数
Note that Domain Owners or their agents may change the published DMARC policy 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ポリシーをいつでも変更できることに注意してください。メールレシーバーの観点から見ると、これはレポート期間中に発生し、その期間中、その期間の終わりにレポートが生成されるとき、または後続のレポート期間中に、すべてメールレシーバーの実装に応じて通知されます。これらの状況では、メール受信者が次のいずれかを実行する可能性があります。
o 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;
o レポートに「policy_published」要素が1つしか含まれていない場合でも、そのようなレポート期間に、古いポリシーに基づくメッセージの性質を含む単一の集約レポート、または2つのポリシーの混合を生成します。
o generate multiple reports for the same period, one for each published policy occurring during the reporting period;
o レポート期間中に発生した公開されたポリシーごとに1つ、同じ期間の複数のレポートを生成します。
o generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval.
o 要求されたレポート間隔に関係なく、更新されたポリシーが検出されたときに終了時間が発生するレポートを生成します。
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 and Domain Owners to be aware of this situation and allow for such mixed reports during the propagation of the new policy to Mail Receivers.
このようなポリシーの変更は、特定のドメインではまれであると予想されますが、メールレシーバーでのより厳しいポリシー監視要件は、インターネット規模で非常に大きな負担を生み出します。したがって、レポートコンシューマとドメインオーナーは、この状況を認識し、メール受信者への新しいポリシーの伝達中にそのような混合レポートを許可する責任があります。
Aggregate reports are most useful when they all cover a common time period. By contrast, correlation of these reports from multiple generators when they cover incongruent time periods is difficult or impossible. Report generators SHOULD, wherever possible, adhere to hour boundaries for the reporting period they are using. For example, starting a per-day report at 00:00; starting per-hour reports at 00:00, 01:00, 02:00; etc. Report generators using a 24-hour report period are strongly encouraged to begin that period at 00:00 UTC, regardless of local timezone or time of report production, in order to facilitate correlation.
集計レポートは、すべてが共通の期間をカバーしている場合に最も役立ちます。対照的に、一致しない期間をカバーする場合、複数のジェネレーターからのこれらのレポートの相関は困難または不可能です。レポートジェネレーターは、可能な限り、使用しているレポート期間の時間境界を遵守する必要があります（SHOULD）。たとえば、日別レポートを00:00に開始します。 1時間ごとのレポートを00：00、01：00、02：00に開始します。相関を容易にするために、24時間のレポート期間を使用するレポートジェネレーターは、ローカルタイムゾーンやレポート作成の時刻に関係なく、00：00 UTCにその期間を開始することを強くお勧めします。
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」タグの存在は、フィードバックの送信先を指定します。
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.
「rua」タグで指定されたURIが他に指定されていない場合、フィードバックレポートを生成するメールレシーバーは安全なトランスポートメカニズムを採用する必要があります（SHOULD）。
The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.
メール受信者は、レポートを準備した後、提供されたレポートURIを指定された順序で評価する必要があります。生成されたレポートで超過したサイズ制限を含むレポートURI（圧縮後および特定のトランスポートメカニズムで必要なエンコード後）は使用しないでください。サポートされているURIに関する受信者の制限まで、残りのすべてのURIに集約レポートを配信する試みを行う必要があります。
If transport 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, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver SHOULD send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent.
公開されたURIによってアドバタイズされたサービスがレポートを受け入れることができないためにトランスポートが不可能である場合（たとえば、URIが到達不能なサービスを参照しているか、提供されたすべてのURIが生成されたレコードが超過するサイズ制限を指定している）、メールレシーバーはSHOULDレポートが利用可能であるが送信できなかったことを示す短いレポート（セクション7.2.2を参照）を送信します。メールレシーバーはそのデータをキャッシュして後で再試行するか、送信できなかったデータを破棄する場合があります。
The message generated by the Mail Receiver MUST be a [MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part).
メール受信者によって生成されたメッセージは、[MIME]に従ってフォーマットされた[MAIL]メッセージである必要があります。集計レポート自体は、メッセージのいずれかの部分に含める必要があります。人間が読める部分は、MIMEパート（テキスト/プレーンパートなど）として含めることができます（MAY）。
The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type "application/ gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The filename is typically constructed using the following ABNF:
集計データは、GZIP圧縮を行う必要があるXMLファイルである必要があります。圧縮の適用を拒否すると、レポートが大きくなりすぎて受信者が処理できなくなる場合があります（一般的に観察される受信者の制限は10メガバイトです）。圧縮を行うと、一部の計算コストでレポートを受け入れる可能性が高くなります。集約データは、圧縮されている場合は[application / gzip]（[GZIP]を参照）、それ以外の場合は "text / xml"のメディアタイプを使用して存在する必要があります（SHOULD）。ファイル名は通常、次のABNFを使用して作成されます。
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
receiver = domain ; imported from [MAIL]
レシーバー=ドメイン; [MAIL]からインポート
policy-domain = domain
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
extension = "xml" / "xml.gz"
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.
「unique-id」を使用すると、メールレシーバーによって生成されるオプションの一意のIDで、同じドメイン所有者内の異なるソースによって同時に生成された複数のレポートを区別できます。
For example, this is a possible 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.gz
No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest.
特定のMIMEメッセージ構造は必要ありません。集約レポートアドレスは、規定のメディアタイプとファイル名でMIMEパーツを抽出し、残りを無視するように装備されていると想定されます。
Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports.
DMARCフィードバックデータを伝送する電子メールストリームはDMARCメカニズムに準拠する必要があるため、「パス」が整列します（セクション3.1を参照）。これにより、レポートの利用者が不正なレポートを処理するリスクを最小限に抑えることができます。
The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF:
個々のレポート送信のRFC5322.Subjectフィールドは、次のABNFに準拠する必要があります（SHOULD）。
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
msg-id ; from RFC 5322
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 line-wrapped as allowed by [MAIL]:
たとえば、これはメールレシーバー「mail.receiver.example」からドメインオーナー「example.com」へのレポートの可能なサブジェクトフィールドです。 [MAIL]で許可されているとおりに改行されます。
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. See Section 7.2.2 for further discussion.
このトランスポートメカニズムでは、フィードバックデータのサイズがジェネレーターまたはコンシューマーのいずれかの最大許容添付ファイルサイズを超えると、問題が発生する可能性があります。詳細については、セクション7.2.2を参照してください。
The specification as written allows for the addition of other registered URI schemes to be supported in later versions.
記述された仕様では、他の登録済みURIスキームを追加して、以降のバージョンでサポートできます。
When a Mail Receiver is unable to complete delivery of a report via any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD generate an error message. An attempt MUST be made to send this report to all listed "mailto" URIs, and it MAY also be sent to any or all other listed URIs.
メールレシーバーがドメイン所有者によってリストされたURIのいずれかを介してレポートの配信を完了できない場合、メールレシーバーはエラーメッセージを生成する必要があります（SHOULD）。リストされたすべての「mailto」URIにこのレポートを送信する試みを行わなければなりません。また、リストされた他のいずれかまたはすべてのURIに送信することもできます（MAY）。
The error report MUST be formatted per [MIME]. A text/plain part MUST be included that contains field-value pairs such as those found in Section 2 of [DSN]. The fields required, which may appear in any order, are as follows:
エラーレポートは[MIME]ごとにフォーマットする必要があります。 [DSN]のセクション2にあるようなフィールドと値のペアを含むテキスト/プレーン部分を含める必要があります。必要なフィールドは次のとおりです。順序は任意です。
Report-Date: A [MAIL]-formatted date expression indicating when the transport failure occurred.
Report-Date：トランスポートエラーがいつ発生したかを示す[MAIL]形式の日付式。
Report-Domain: The domain-name about which the failed report was generated.
Report-Domain：失敗したレポートが生成されたドメイン名。
Report-ID: The Report-ID: that the report tried to use.
Report-ID：レポートが使用しようとしたレポートID。
Report-Size: The size, in bytes, of the report that was unable to be sent. This MUST represent the number of bytes that the Mail Receiver attempted to send. Where more than one transport system was attempted, the sizes may be different; in such cases, separate error reports MUST be generated so that this value matches the actual attempt that was made.
Report-Size：送信できなかったレポートのサイズ（バイト単位）。これは、メール受信者が送信を試みたバイト数を表す必要があります。複数の輸送システムが試みられた場合、サイズは異なる場合があります。このような場合、この値が実際に行われた試行と一致するように、個別のエラーレポートを生成する必要があります。
Submitter: The domain-name representing the Mail Receiver that generated, but was unable to submit, the report.
提出者：レポートを生成したが提出できなかったメール受信者を表すドメイン名。
Submitting-URI: The URI(s) to which the Mail Receiver tried, but failed, to submit the report.
Submitting-URI：メール受信者がレポートを送信するために試行したが失敗したURI。
An additional text/plain part MAY be included that gives a human-readable explanation of the above and MAY also include a URI that can be used to seek assistance.
上記の人間が読める説明を提供する追加のテキスト/プレーン部分を含めることができます。また、支援を求めるために使用できるURIを含めることもできます（MAY）。
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. Whether the failure is due to an infrastructure problem or the message is inauthentic, failure reports also provide more information about the failed message than is available in an aggregate report.
障害レポートは通常生成され、メールレシーバーがDMARC障害を検出した直後に送信されます。これらのレポートは、集計レポートを待つのではなく、認証エラーが発生したときにドメイン所有者にすばやく通知するのに役立ちます。失敗の原因がインフラストラクチャの問題であるか、メッセージが信頼できないものであるかに関係なく、失敗レポートは、集計レポートで利用できるよりも、失敗したメッセージに関する詳細情報を提供します。
These reports SHOULD include any URI(s) from the message that failed authentication. These reports SHOULD include as much of the message and message header as is reasonable to support the Domain Owner's investigation into what caused the message to fail authentication and track down the sender.
これらのレポートには、認証に失敗したメッセージのURIを含める必要があります（SHOULD）。これらのレポートには、メッセージが認証に失敗した原因のドメイン所有者の調査をサポートし、送信者を突き止めるのに妥当な限り、メッセージとメッセージヘッダーを含める必要があります（SHOULD）。
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 [AFRF]; this document updates that reporting format, as described in Section 7.3.1.
ドメイン所有者がフォレンジック分析の目的で障害レポートを要求し、メールレシーバーがそのようなレポートを提供する用意がある場合、メールレシーバーは[AFRF]で説明されている形式を使用してメッセージを生成および送信します。このドキュメントは、セクション7.3.1で説明されているように、そのレポート形式を更新します。
The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3.
レポートの宛先と性質は、セクション6.3で定義されている「ruf」タグと「fo」タグによって定義されます。
Where multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them.
障害レポートを受信するために複数のURIが選択されている場合、レポートジェネレーターはそれらのそれぞれに配信を試行する必要があります。
An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([ARF]). Various aggregation techniques are possible, including the following:
明らかな考慮事項は、サービス拒否攻撃であり、攻撃者は意図した被害者のドメイン所有者からのものであると称して多数のメッセージを送信しますが、SPFとDKIMの両方に失敗します。これにより、参加しているメールレシーバーがドメインオーナーまたはその代理人に、潜在的に巨大なボリュームで障害レポートを送信することになります。したがって、参加しているメール受信者は、乱用報告フォーマット（[ARF]）の[インシデント]フィールドを使用して、これらのレポートをできる限り集約することをお勧めします。以下を含むさまざまな集約手法が可能です。
o only send a report to the first recipient of multi-recipient messages;
o 複数の受信者メッセージの最初の受信者にのみレポートを送信します。
o store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents;
o レポートを送信する前に一定期間保存し、同様のインシデントの検出、収集、およびレポートを可能にします。
o apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).
o 生成される1分あたりの最大レポート数などのレート制限を適用します（残りは破棄されます）。
Operators implementing this specification also implement an augmented version of [AFRF] as follows:
この仕様を実装するオペレーターは、次のように[AFRF]の拡張バージョンも実装します。
1. A DMARC failure report includes the following ARF header fields, with the indicated normative requirement levels:
1. DMARC障害レポートには、次のARFヘッダーフィールドが含まれ、指定された規範的な要件レベルが含まれます。
* Identity-Alignment (REQUIRED; defined below)
* Identity-Alignment（必須、以下で定義）
* Delivery-Result (OPTIONAL)
* 配信結果（オプション）
* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the message was signed by DKIM)
* DKIM-Domain、DKIM-Identity、DKIM-Selector（メッセージがDKIMによって署名された場合は必須）
* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if the message was signed by DKIM)
* DKIM-Canonicalized-Header、DKIM-Canonicalized-Body（メッセージがDKIMによって署名されている場合はオプション）
* SPF-DNS (REQUIRED)
* SPF-DNS（必須）
2. The "Identity-Alignment" field is defined to contain a comma-separated list of authentication mechanism names that produced an aligned identity, or the keyword "none" if none did. ABNF:
2. 「Identity-Alignment」フィールドは、アラインされたIDを生成した認証メカニズム名のコンマ区切りのリスト、または何もしなかった場合はキーワード「none」を含むように定義されています。 ABNF：
id-align = "Identity-Alignment:" [CFWS] ( "none" / dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) [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, 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 AFRF message for any or all of the underlying authentication methods.
3. 認証失敗タイプ "dmarc"が定義されています。これは、認証メカニズムの一部またはすべてが整列された識別子の生成に失敗したために失敗レポートが生成されるときに使用されます。失敗レポートジェネレーターは、基礎となる認証方法のいずれかまたはすべてに対してAFRFメッセージを個別に生成する場合があることに注意してください。
A minimum implementation of DMARC has the following characteristics:
DMARCの最小実装には、次の特性があります。
o Is able to send and/or receive reports at least daily;
o 少なくとも毎日、レポートを送受信できます。
o Is able to send and/or receive reports using "mailto" URIs;
o 「mailto」URIを使用してレポートを送受信できます。
o Other than in exceptional circumstances such as resource exhaustion, can generate or accept a report up to ten megabytes in size;
o リソースの枯渇などの例外的な状況以外では、最大10メガバイトのレポートを生成または受け入れることができます。
o If acting as a Mail Receiver, fully implements the provisions of Section 6.6.
o メールレシーバーとして機能する場合、セクション6.6の規定を完全に実装します。
This section discusses security issues specific to private data that may be included in the interactions that are part of DMARC.
このセクションでは、DMARCの一部である対話に含まれる可能性のあるプライベートデータに固有のセキュリティ問題について説明します。
Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the identifiers involved in DMARC validation.
集計レポートの範囲は、DMARCポリシーと廃棄結果、基になる認証メカニズムに関する情報、DMARC検証に関連する識別子に限定されます。
Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. Domain Owners are able to analyze individual reports and attempt to determine root causes of authentication mechanism failures, gain insight into misconfigurations or other problems with email and network infrastructure, or inspect messages for insight into abusive practices.
失敗したメッセージのレポートは、認証の失敗に関するメッセージ固有の詳細を提供します。個々のレポートには、メッセージコンテンツとトレースヘッダーフィールドを含めることができます。ドメイン所有者は、個々のレポートを分析して、認証メカニズムの失敗の根本的な原因を特定し、電子メールおよびネットワークインフラストラクチャの設定ミスやその他の問題を洞察したり、不正行為の洞察を得るためにメッセージを検査したりできます。
Both report types may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [AFRF] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient.
どちらの種類のレポートでも送信者と受信者の識別子（RFC5322.Fromアドレスなど）が公開される可能性があります。失敗したメッセージのレポートに使用される[AFRF]形式は編集をサポートしますが、失敗したメッセージのレポートはメッセージ全体をレポートの受信者に公開できます。
Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed.
レポートを要求するドメイン所有者は、それらからのメールであると主張するメールに関する情報を受け取ります。したがって、中間システムによって隠されている可能性のあるメールの最終宛先に関する情報が公開されます。
When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.
メッセージ転送の取り決めが存在する場合、レポートを要求するドメイン所有者は、メッセージの受信者リストの一部ではなかったドメインに転送されたメールに関する情報も受け取ります。つまり、これまでドメイン所有者が知らなかった宛先ドメインが表示されるようになる可能性があります。
Disclosure of information about the messages is being requested by the entity generating the email in the first place, i.e., the Domain Owner and not the Mail Receiver, so this may not fit squarely within existing privacy policy provisions. For some providers, aggregate reporting and failed-message reporting are viewed as a function similar to complaint reporting about spamming or phishing and are treated similarly under the privacy policy. Report generators (i.e., Mail Receivers) are encouraged to review their reporting limitations under such policies before enabling DMARC reporting.
メッセージに関する情報の開示は、最初に電子メールを生成するエンティティ、つまりドメインオーナーであり、メールレシーバーではないため、要求されているため、既存のプライバシーポリシーの規定に完全には適合しない場合があります。一部のプロバイダーでは、集約レポートと失敗メッセージレポートは、スパムまたはフィッシングに関する苦情レポートと同様の機能と見なされ、プライバシーポリシーの下で同様に扱われます。レポートジェネレーター（つまり、メールレシーバー）は、DMARCレポートを有効にする前に、そのようなポリシーに基づいてレポートの制限を確認することをお勧めします。
A DMARC 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.
レポートの受信者がトラフィック分析を実行して、Receiverのトラフィックに関するメタデータを取得できる可能性があります。ポリシーへの準拠を検証することに加えて、受信者は第三者にレポートを送信する前にそれを考慮する必要があります。
This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record.
このセクションでは、DMARCの開発で行われた、主に履歴を記録するための選択に関するいくつかのトピックについて説明します。
Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many large network ranges. Domain Owners are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC record.
DMARCはSPFポリシーレコードのセマンティクスを本質的に変更するものではありませんが、歴史的にそのようなポリシーの施行は緩やかで、多くの大規模なネットワーク範囲を含む非常に広範なレコードを発行するようになりました。ドメイン所有者は、DMARCレコードを発行する前に、SPFレコードを注意深く確認して、ドメイン所有者に代わって送信する権限があるネットワークを理解することを強くお勧めします。
Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.
一部のレシーバーアーキテクチャは、DMARC操作の前にSPFを実装する場合があります。これは、「-all」などの送信者のSPFメカニズムの「-」接頭辞により、拒否が処理の早い段階で有効になり、DMARC処理が行われる前にメッセージが拒否される可能性があることを意味します。 「-all」を使用することを選択するオペレーターは、これに注意する必要があります。
DMARC policies are communicated using the DNS and therefore inherit a number of considerations related to DNS caching. The inherent conflict between freshness and the impact of caching on the reduction of DNS-lookup overhead should be considered from the Mail Receiver's point of view. Should Domain Owners publish a DNS record with a very short TTL, Mail Receivers can be provoked through the injection of large volumes of messages to overwhelm the Domain Owner's DNS. Although this is not a concern specific to DMARC, the implications of a very short TTL should be considered when publishing DMARC policies.
DMARCポリシーはDNSを使用して通信されるため、DNSキャッシングに関連する多くの考慮事項を継承します。鮮度とDNSルックアップオーバーヘッドの削減に対するキャッシュの影響との間の固有の競合は、メールレシーバーの観点から検討する必要があります。ドメインオーナーが非常に短いTTLでDNSレコードを公開する場合、メールレシーバーは大量のメッセージの注入を通じて引き起こされ、ドメインオーナーのDNSを圧倒する可能性があります。これはDMARCに固有の問題ではありませんが、DMARCポリシーを公開するときは、TTLが非常に短い場合の影響を考慮する必要があります。
Conversely, long TTLs will cause records to be cached for long periods of time. This can cause a critical change to DMARC parameters advertised by a Domain Owner to go unnoticed for the length of the TTL (while waiting for DNS caches to expire). Avoiding this problem can mean shorter TTLs, with the potential problems described above. A balance should be sought to maintain responsiveness of DMARC preference changes while preserving the benefits of DNS caching.
逆に、TTLが長いと、レコードが長期間キャッシュされます。これにより、ドメイン所有者によってアドバタイズされたDMARCパラメータに重大な変更が加えられ、TTLの長さの間（DNSキャッシュの期限が切れるのを待っている間）気付かれない可能性があります。この問題を回避すると、TTLが短くなり、上記の潜在的な問題が発生する可能性があります。 DNSキャッシュの利点を維持しながら、DMARC設定変更の応答性を維持するためにバランスをとる必要があります。
This proposal calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification ([DSN]), since fraudulent messages caught and rejected using DMARC would then result in annoying generation of such failure reports that go back to the RFC5321.MailFrom address.
この提案では、特定の状況下でSMTPセッション中にメッセージを拒否する必要があります。 DMARCを使用して不正なメッセージがキャッチおよび拒否されると、RFC5321.MailFromアドレスに戻るような失敗レポートが生成されるため、これは配信ステータス通知（[DSN]）の生成よりも望ましい方法です。
This synchronous rejection is typically done in one of two ways:
この同期拒否は、通常、次の2つの方法のいずれかで行われます。
o Full rejection, wherein the SMTP server issues a 5xy reply code as an indication to the SMTP client that the transaction failed; the SMTP client is then responsible for generating notification that delivery failed (see Section 4.2.5 of [SMTP]).
o 完全な拒否。SMTPサーバーは、5xy応答コードを、トランザクションが失敗したことをSMTPクライアントに示すものとして発行します。 SMTPクライアントは、配信が失敗したという通知の生成を担当します（[SMTP]のセクション4.2.5を参照）。
o A "silent discard", wherein the SMTP server returns a 2xy reply code implying to the client that delivery (or, at least, relay) was successfully completed, but then simply discarding the message with no further action.
o 「サイレント破棄」。SMTPサーバーが2xy応答コードを返し、配信（または少なくともリレー）が正常に完了したことを意味しますが、その後は何もせず単にメッセージを破棄します。
Each of these has a cost. For instance, a silent discard can help to prevent backscatter, but it also effectively means that the SMTP server has to be programmed to give a false result, which can confound external debugging efforts.
これらのそれぞれにコストがあります。たとえば、サイレント破棄は後方散乱を防ぐのに役立ちますが、SMTPサーバーが誤った結果を与えるようにプログラムする必要があることも意味し、外部のデバッグ作業を混乱させる可能性があります。
Similarly, the text portion of the SMTP reply may be important to consider. For example, when rejecting a message, revealing the reason for the rejection might give an attacker enough information to bypass those efforts on a later attempt, though it might also assist a legitimate client to determine the source of some local issue that caused the rejection.
同様に、SMTP応答のテキスト部分も考慮する必要があります。たとえば、メッセージを拒否する場合、拒否の理由を明らかにすることにより、攻撃者は後で試行する際にそれらの作業を回避するのに十分な情報を得ることができますが、正当なクライアントが拒否の原因となったローカルの問題の原因を特定するのにも役立ちます。
In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A receiver might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. Many systems are able to scan the SMTP reply text to determine the nature of the rejection. Thus, providing a machine-detectable reason for rejection allows the problems causing rejections to be properly addressed by automated systems. For example:
後者の場合、SMTP拒否を行うときに、明確なヒントを提供することは、問題の解決に役立ちます。受信者は、返信テキストのどこかに「DMARC」という単語を使用して、拒否の理由をプレーンテキストで示す場合があります。多くのシステムは、SMTP応答テキストをスキャンして、拒否の性質を判別できます。したがって、機械で検出可能な拒否の理由を提供することで、拒否を引き起こす問題を自動システムで適切に対処できます。例えば：
550 5.7.1 Email rejected per DMARC policy for example.com
550 5.7.1 example.comのDMARCポリシーに従ってメールが拒否されました
If a Mail Receiver elects to defer delivery due to inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code.
メール受信者がDMARCポリシーを取得または適用できないために配信を延期することを選択した場合、これは4xy SMTP応答コードで行うのが最善です。
The DMARC mechanism allows both DKIM and SPF-authenticated identifiers to authenticate email on behalf of a Domain Owner and, possibly, on behalf of different subdomains. If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain, the subdomain can be used to generate DMARC-passing email on behalf of the Organizational Domain.
DMARCメカニズムにより、DKIMとSPFで認証された識別子の両方が、ドメイン所有者に代わって、場合によっては異なるサブドメインに代わってメールを認証できます。悪意のあるユーザーまたは知らないユーザーがサブドメインのSPFレコードまたはDKIMセレクターレコードの制御を取得できる場合、サブドメインを使用して、組織ドメインに代わってDMARCを通過する電子メールを生成できます。
For example, an attacker who controls the SPF record for "evil.example.com" can send mail with an RFC5322.From field containing "foo@example.com" that can pass both authentication and the DMARC check against "example.com".
たとえば、「evil.example.com」のSPFレコードを制御する攻撃者は、「foo.example.com」を含むRFC5322.Fromフィールドを使用してメールを送信し、「example.com」に対する認証とDMARCチェックの両方を通過させることができます。 。
The Organizational Domain administrator should be careful not to delegate control of subdomains if this is an issue, and to consider using the "strict" Identifier Alignment option if appropriate.
組織ドメインの管理者は、これが問題である場合はサブドメインの制御を委任しないように注意し、適切な場合は「厳密な」識別子配置オプションの使用を検討する必要があります。
DMARC limits which end-to-end scenarios can achieve a "pass" result.
DMARCは、どのエンドツーエンドのシナリオが「合格」の結果を達成できるかを制限します。
Because DMARC relies on [SPF] and/or [DKIM] to achieve a "pass", their limitations also apply.
DMARCは「SPF」や「DKIM」に依存して「パス」を実現するため、それらの制限も適用されます。
Additional DMARC constraints occur when a message is processed by some Mediators, such as mailing lists. Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost. These transformations may conform to standards but will still prevent a DMARC "pass".
追加のDMARC制約は、メーリングリストなどの一部のメディエーターによってメッセージが処理されるときに発生します。メディエーターを通過させると、認証が失敗するか、IDアライメントが失われることがよくあります。これらの変換は標準に準拠している可能性がありますが、DMARCの「合格」は阻止されます。
In addition to Mediators, mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a "pass" result.
メディエーターに加えて、承認された独立した第三者によって送信されたメールは、IDアラインメントを使用して送信されない可能性があり、これも「合格」結果を防ぎます。
Issues specific to the use of policy mechanisms alongside DKIM are further discussed in [DKIM-LISTS], particularly Section 5.2.
DKIMと一緒のポリシーメカニズムの使用に固有の問題については、[DKIM-LISTS]で、特にセクション5.2でさらに説明します。
This section describes actions completed by IANA.
このセクションでは、IANAによって実行されるアクションについて説明します。
IANA has added the following to the "Email Authentication Methods" registry:
IANAは、「Email Authentication Methods」レジストリに以下を追加しました。
Method: dmarc
方法：dmarc
Defined: RFC 7489
定義済み：RFC 7489
ptype: header
ptype：ヘッダー
Property: from
プロパティ：から
Value: the domain portion of the RFC5322.From field
値：RFC5322.Fromフィールドのドメイン部分
Status: active
ステータス：アクティブ
Version: 1
バージョン：1
IANA has added the following in the "Email Authentication Result Names" registry:
IANAは、「Email Authentication Result Names」レジストリに以下を追加しました。
Code: none
コード：なし
Existing/New Code: existing
既存/新規コード：既存
Defined: [AUTH-RESULTS]
定義済み：[AUTH-RESULTS]
Auth Method: dmarc (added) Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted.
認証方法：dmarc（追加）意味：整列された識別子のDMARCポリシーレコードが発行されなかったか、整列された識別子を抽出できませんでした。
Status: active
ステータス：アクティブ
Code: pass
コード：パス
Existing/New Code: existing
既存/新規コード：既存
Defined: [AUTH-RESULTS]
定義済み：[AUTH-RESULTS]
Auth Method: dmarc (added)
認証方法：dmarc（追加）
Meaning: A DMARC policy record was published for the aligned identifier, and at least one of the authentication mechanisms passed.
意味：整列された識別子に対してDMARCポリシーレコードが発行され、認証メカニズムの少なくとも1つが合格しました。
Status: active
ステータス：アクティブ
Code: fail
コード：失敗
Existing/New Code: existing
既存/新規コード：既存
Defined: [AUTH-RESULTS]
定義済み：[AUTH-RESULTS]
Auth Method: dmarc (added)
認証方法：dmarc（追加）
Meaning: A DMARC policy record was published for the aligned identifier, and none of the authentication mechanisms passed.
意味：整列されたIDに対してDMARCポリシーレコードが発行され、認証メカニズムのいずれも通過しませんでした。
Status: active
ステータス：アクティブ
Code: temperror
コード：temperror
Existing/New Code: existing
既存/新規コード：既存
Defined: [AUTH-RESULTS]
定義済み：[AUTH-RESULTS]
Auth Method: dmarc (added)
認証方法：dmarc（追加）
Meaning: A temporary error occurred during DMARC evaluation. A later attempt might produce a final result.
意味：DMARCの評価中に一時的なエラーが発生しました。後で試行すると、最終結果が生成される可能性があります。
Status: active Code: permerror
ステータス：アクティブコード：permerror
Existing/New Code: existing
既存/新規コード：既存
Defined: [AUTH-RESULTS]
定義済み：[AUTH-RESULTS]
Auth Method: dmarc (added)
認証方法：dmarc（追加）
Meaning: A permanent error occurred during DMARC evaluation, such as encountering a syntactically incorrect DMARC record. A later attempt is unlikely to produce a final result.
意味：DMARC評価中に、構文的に正しくないDMARCレコードの検出など、永続的なエラーが発生しました。後で試行しても、最終的な結果は得られません。
Status: active
ステータス：アクティブ
The following has been added to the "Feedback Report Header Fields" registry:
「フィードバックレポートヘッダーフィールド」レジストリに以下が追加されました。
Field Name: Identity-Alignment
フィールド名：Identity-Alignment
Description: indicates whether the message about which a report is being generated had any identifiers in alignment as defined in RFC 7489
説明：レポートが生成されているメッセージに、RFC 7489で定義されている識別子と一致するものがあるかどうかを示します
Multiple Appearances: No
複数の外観：いいえ
Related "Feedback-Type": auth-failure
関連する「フィードバックタイプ」：auth-failure
Reference: RFC 7489
リファレンス：RFC 7489
Status: current
ステータス：現在
A new registry tree called "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" has been created. Within it, a new sub-registry called the "DMARC Tag Registry" has been created.
「ドメインベースのメッセージ認証、レポート、および適合性（DMARC）パラメータ」と呼ばれる新しいレジストリツリーが作成されました。その中に、「DMARC Tag Registry」と呼ばれる新しいサブレジストリが作成されました。
Names of DMARC tags must be registered with IANA in this new sub-registry. New entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [IANA-CONSIDERATIONS]. Each registration must include the tag name; the specification that defines it; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the new tag and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
DMARCタグの名前は、この新しいサブレジストリのIANAに登録する必要があります。新しいエントリは、[IANA-CONSIDERATIONS]に従って、必要な仕様の条件を満たしている方法で文書化されている値にのみ割り当てられます。各登録にはタグ名を含める必要があります。それを定義する仕様;簡単な説明;そして、そのステータスは、「現在」、「実験的」、または「歴史的」のいずれかでなければなりません。指定された専門家は、提供された仕様が新しいタグを適切に記述し、DMARCコンテキスト内でドメイン所有者とメール受信者によってどのように使用されるかを明確に示すことを確認する必要があります。
To avoid version compatibility issues, tags added to the DMARC specification are to avoid changing the semantics of existing records when processed by implementations conforming to prior specifications.
バージョン互換性の問題を回避するために、DMARC仕様に追加されたタグは、以前の仕様に準拠する実装によって処理されるときに既存のレコードのセマンティクスを変更しないようにするためのものです。
The initial set of entries in this registry is as follows:
このレジストリの最初のエントリセットは次のとおりです。
+----------+-------------+---------+------------------------------+
| Tag Name | Reference | Status | Description |
+----------+-------------+---------+------------------------------+
| adkim | RFC 7489 | current | DKIM alignment mode |
+----------+-------------+---------+------------------------------+
| aspf | RFC 7489 | current | SPF alignment mode |
+----------+-------------+---------+------------------------------+
| fo | RFC 7489 | current | Failure reporting options |
+----------+-------------+---------+------------------------------+
| p | RFC 7489 | current | Requested handling policy |
+----------+-------------+---------+------------------------------+
| pct | RFC 7489 | current | Sampling rate |
+----------+-------------+---------+------------------------------+
| rf | RFC 7489 | current | Failure reporting format(s) |
+----------+-------------+---------+------------------------------+
| ri | RFC 7489 | current | Aggregate Reporting interval |
+----------+-------------+---------+------------------------------+
| rua | RFC 7489 | current | Reporting URI(s) for |
| | | | aggregate data |
+----------+-------------+---------+------------------------------+
| ruf | RFC 7489 | current | Reporting URI(s) for |
| | | | failure data |
+----------+-------------+---------+------------------------------+
| sp | RFC 7489 | current | Requested handling policy |
| | | | for subdomains |
+----------+-------------+---------+------------------------------+
| v | RFC 7489 | current | Specification version |
+----------+-------------+---------+------------------------------+
Also within "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters", a new sub-registry called "DMARC Report Format Registry" has been created.
また、「ドメインベースのメッセージ認証、レポート、および適合（DMARC）パラメータ」内に、「DMARCレポート形式レジストリ」と呼ばれる新しいサブレジストリが作成されました。
Names of DMARC failure reporting formats must be registered with IANA in this registry. New entries are assigned only for values that satisfy the definition of Specification Required, per
DMARC障害レポート形式の名前は、このレジストリのIANAに登録する必要があります。新しいエントリは、必要な仕様の定義を満たす値にのみ割り当てられます。
[IANA-CONSIDERATIONS]. In addition to a reference to a permanent specification, each registration must include the format name; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the report format and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
[IANA-CONSIDERATIONS]。永続的な仕様への参照に加えて、各登録にはフォーマット名を含める必要があります。簡単な説明;そして、そのステータスは、「現在」、「実験的」、または「歴史的」のいずれかでなければなりません。指定専門家は、提供された仕様がレポート形式を適切に記述し、DMARCコンテキスト内でドメイン所有者とメール受信者によってどのように使用されるかを明確に示すことを確認する必要があります。
The initial entry in this registry is as follows:
このレジストリの最初のエントリは次のとおりです。
+--------+-------------+---------+-----------------------------+
| Format | Reference | Status | Description |
| Name | | | |
+--------+-------------+---------+-----------------------------+
| afrf | RFC 7489 | current | Authentication Failure |
| | | | Reporting Format (see |
| | | | [AFRF]) |
+--------+-------------+---------+-----------------------------+
This section discusses security issues and possible remediations (where available) for DMARC.
このセクションでは、DMARCのセキュリティの問題と考えられる改善策（可能な場合）について説明します。
Security considerations from the authentication methods used by DMARC are incorporated here by reference.
DMARCで使用される認証方法のセキュリティに関する考慮事項は、参照によりここに組み込まれます。
URIs published in DNS TXT records are well-understood possible targets for attack. Specifications such as [DNS] and [ROLES] either expose or cause the exposure of email addresses that could be flooded by an attacker, for example; MX, NS, and other records found in the DNS advertise potential attack destinations; common DNS names such as "www" plainly identify the locations at which particular services can be found, providing destinations for targeted denial-of-service or penetration attacks.
DNS TXTレコードで公開されたURIは、よく理解された攻撃の標的である可能性があります。 [DNS]や[ROLES]などの仕様は、たとえば、攻撃者によってフラッディングされる可能性がある電子メールアドレスを公開するか、または公開します。 DNSにあるMX、NS、およびその他のレコードは、潜在的な攻撃の宛先をアドバタイズします。 「www」などの一般的なDNS名は、特定のサービスが見つかる場所を明確に識別し、標的型のサービス拒否攻撃または侵入攻撃の宛先を提供します。
Thus, Domain Owners will need to harden these addresses against various attacks, including but not limited to:
したがって、ドメイン所有者はこれらに限定されないが、以下を含むさまざまな攻撃に対してこれらのアドレスを強化する必要があります。
o high-volume denial-of-service attacks;
o 大量のサービス拒否攻撃。
o deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities;
o 解析または処理の脆弱性を特定または悪用することを目的とした、不正なレポートの意図的な作成。
o deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.
o 提出者または報告されたドメインのフィールドに対する虚偽のクレームを含むレポートの意図的な構築。侵害されたが既知のメール受信者からの虚偽のデータの可能性を含みます。
The DMARC mechanism and its underlying technologies (SPF, DKIM) depend on the security of the DNS. To reduce the risk of subversion of the DMARC mechanism due to DNS-based exploits, serious consideration should be given to the deployment of DNSSEC in parallel with the deployment of DMARC by both Domain Owners and Mail Receivers.
DMARCメカニズムとその基盤となるテクノロジー（SPF、DKIM）は、DNSのセキュリティに依存しています。 DNSベースのエクスプロイトによるDMARCメカニズムの破壊のリスクを減らすには、ドメイン所有者とメールレシーバーの両方によるDMARCの展開と並行してDNSSECを展開することを真剣に検討する必要があります。
Publication of data using DNSSEC is relevant to Domain Owners and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers.
DNSSECを使用したデータの公開は、ドメイン所有者およびサードパーティのレポートレシーバーに関連しています。 DNSSEC対応の解決は、メール受信者とレポート受信者に関連しています。
A common attack in messaging abuse is the presentation of false information in the display-name portion of the RFC5322.From field. For example, it is possible for the email address in that field to be an arbitrary address or domain name, while containing a well-known name (a person, brand, role, etc.) in the display name, intending to fool the end user into believing that the name is used legitimately. The attack is predicated on the notion that most common MUAs will show the display name and not the email address when both are available.
メッセージングの不正使用における一般的な攻撃は、RFC5322.Fromフィールドの表示名部分に誤った情報を表示することです。たとえば、そのフィールドの電子メールアドレスが任意のアドレスまたはドメイン名であり、表示名に既知の名前（人物、ブランド、役割など）が含まれている可能性があります。ユーザーが名前が正当に使用されていると信じ込ませます。攻撃は、ほとんどの一般的なMUAが表示名を表示し、両方が使用可能な場合はメールアドレスを表示しないという概念に基づいています。
Generally, display name attacks are out of scope for DMARC, as further exploration of possible defenses against these attacks needs to be undertaken.
一般に、表示名攻撃はDMARCの範囲外です。これらの攻撃に対する可能な防御策をさらに調査する必要があるためです。
There are a few possible mechanisms that attempt mitigation of these attacks, such as the following:
次のような、これらの攻撃の緩和を試みるいくつかの可能なメカニズムがあります。
o If the display name is found to include an email address (as specified in [MAIL]), execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally. However, this addresses only a very specific attack space, and spoofers can easily circumvent it by simply not using an email address in the display name. There are also known cases of legitimate uses of an email address in the display name with a domain different from the one in the address portion, e.g.,
o 表示名に（[MAIL]で指定された）メールアドレスが含まれていることが判明した場合は、最初に発見されたドメイン名ではなく、そこにあるドメイン名に対してDMARCメカニズムを実行します。ただし、これは非常に特定の攻撃スペースにのみ対応しており、スプーファーは表示名に電子メールアドレスを使用しないだけで簡単に回避できます。アドレス部分のドメインとは異なるドメインを使用して、表示名に電子メールアドレスを合法的に使用する既知のケースもあります。たとえば、
From: "user@example.org via Bug Tracker" <support@example.com>
o In the MUA, only show the display name if the DMARC mechanism succeeds. This too is easily defeated, as an attacker could arrange to pass the DMARC tests while fraudulently using another domain name in the display name.
o MUAでは、DMARCメカニズムが成功した場合にのみ表示名を表示します。攻撃者が表示名に別のドメイン名を不正に使用している間にDMARCテストに合格するように手配できるため、これも簡単に破られます。
o In the MUA, only show the display name if the DMARC mechanism passes and the email address thus validated matches one found in the receiving user's list of known addresses.
o MUAでは、DMARCメカニズムに合格し、このように検証された電子メールアドレスが受信ユーザーの既知のアドレスのリストにあるアドレスと一致する場合にのみ、表示名を表示します。
To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. In order to accommodate special cases such as a need to get reports about domains that cannot actually receive mail, Section 7.1 describes a DNS-based mechanism for verifying approved external reporting.
悪意のあるユーザーによる悪用を避けるために、レポートアドレスは通常、レポートが要求されるドメイン内にある必要があります。実際にメールを受信できないドメインに関するレポートを取得する必要があるなどの特殊なケースに対応するために、セクション7.1では、承認された外部レポートを検証するためのDNSベースのメカニズムについて説明します。
The obvious consideration here is an increased DNS load against domains that are claimed as external recipients. Negative caching will mitigate this problem, but only to a limited extent, mostly dependent on the default TTL in the domain's SOA record.
ここで明らかな考慮事項は、外部受信者として主張されているドメインに対するDNS負荷の増加です。負のキャッシングはこの問題を軽減しますが、限られた範囲でのみ、主にドメインのSOAレコードのデフォルトTTLに依存します。
Where possible, external reporting is best achieved by having the report be directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination.
可能な場合、外部レポートは、メールを受信できるドメインにレポートを送信し、単純にそれを目的の外部宛先に自動的に転送することによって、最も適切に達成されます。
Note that the addresses shown in the "ruf" tag receive more information that might be considered private data, since it is possible for actual email content to appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the "rua" tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of [DNSSEC] is advisable if this is a concern.
「ruf」タグで示されたアドレスは、実際の電子メールコンテンツが障害レポートに表示される可能性があるため、プライベートデータと見なされる可能性のある詳細情報を受け取ります。したがって、そこに識別されたURIは、「rua」タグで見つかったものよりも侵入試行の魅力的なターゲットです。さらに、サブジェクトドメインのDNSを攻撃して、障害データが攻撃者のシステムに不正にルーティングされるようにすることは、魅力的な可能性があります。これが懸念される場合は、[DNSSEC]の導入をお勧めします。
The verification mechanism presented in Section 7.1 is currently not mandatory ("MUST") but strongly recommended ("SHOULD"). It is possible that it would be elevated to a "MUST" by later security review.
セクション7.1で提示された検証メカニズムは、現在必須ではありません（「必須」）が強く推奨されています（「SHOULD」）。後のセキュリティレビューにより、「必須」に引き上げられる可能性があります。
This document encourages use of secure transport mechanisms to prevent loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms should be avoided.
このドキュメントでは、安全なトランスポートメカニズムを使用して、このような送信を監視できる第三者へのプライベートデータの損失を防ぐことを推奨しています。暗号化されていないメカニズムは避けてください。
In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information.
特に、元々暗号化されているか、そうでなければ保護されているメッセージが、安全に送信されないレポートに表示され、個人情報が明らかになる可能性があります。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[ABNF] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/ rfc5234>。
[AFRF] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012, <http://www.rfc-editor.org/info/rfc6591>.
[AFRF] Fontana、H。、「Abuse Reporting Formatを使用した認証失敗の報告」、RFC 6591、2012年4月、<http://www.rfc-editor.org/info/rfc6591>。
[AFRF-DKIM] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012, <http://www.rfc-editor.org/info/rfc6651>.
[AFRF-DKIM] Kucherawy、M。、「Extensions to DomainKeys Identified Mail（DKIM）for Failure Reporting」、RFC 6651、2012年6月、<http://www.rfc-editor.org/info/rfc6651>。
[AFRF-SPF] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012, <http://www.rfc-editor.org/info/rfc6652>.
[AFRF-SPF] Kitterman、S。、「Sender Policy Framework（SPF）Authentication Failure Reporting Using a Abuse Reporting Format」、RFC 6652、2012年6月、<http://www.rfc-editor.org/info/rfc6652> 。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/ info/rfc6376>.
[DKIM] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、STD 76、RFC 6376、2011年9月、<http：/ /www.rfc-editor.org/ info / rfc6376>。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006, <http://www.rfc-editor.org/info/rfc4343>.
[DNS-CASE] Eastlake 3rd、D。、「ドメインネームシステム（DNS）の大文字と小文字の区別の明確化」、RFC 4343、2006年1月、<http://www.rfc-editor.org/info/rfc4343>。
[GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, August 2012, <http://www.rfc-editor.org/info/rfc6713>.
[GZIP] Levine、J。、「The 'application / zlib' and 'application / gzip' Media Types」、RFC 6713、2012年8月、<http://www.rfc-editor.org/info/rfc6713>。
[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[IDNA] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月、<http://www.rfc-editor.org/info/rfc5890>。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月、<http://www.rfc-editor.org/info / rfc2045>。
[SEC-TERMS] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[SEC-TERMS] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[SPF]キッターマンS.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、2014年4月、<http://www.rfc-editor.org/info/rfc7208> 。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009, <http://www.rfc-editor.org/info/rfc5617>.
[ADSP] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「DomainKeys Identified Mail（DKIM）Author Domain Signing Practices（ADSP）」、RFC 5617、2009年8月、<http：// www.rfc-editor.org/info/rfc5617>。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010, <http://www.rfc-editor.org/info/rfc5965>.
[ARF] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能なフォーマット」、RFC 5965、2010年8月、<http://www.rfc-editor.org/info/rfc5965 >。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.
[AUTH-RESULTS] Kucherawy、M.、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7001、2013年9月、<http://www.rfc-editor.org/info/rfc7001>。
[Best-Guess-SPF] Kitterman, S., "Sender Policy Framework: Best guess record (FAQ entry)", May 2010, <http://www.openspf.org/FAQ/Best_guess_record>.
[Best-Guess-SPF] Kitterman、S。、「Sender Policy Framework：Best guess record（FAQ entry）」、2010年5月、<http://www.openspf.org/FAQ/Best_guess_record>。
[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010, <http://www.rfc-editor.org/info/rfc5863>.
[DKIM-DEPLOYMENT] Hansen、T.、Siegel、E.、Hallam-Baker、P。、およびD. Crocker、「DomainKeys Identified Mail（DKIM）Development、Deployment、and Operations」、RFC 5863、2010年5月、<http ：//www.rfc-editor.org/info/rfc5863>。
[DKIM-LISTS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[DKIM-LISTS] Kucherawy、M。、「DomainKeys Identified Mail（DKIM）and Mailing Lists」、BCP 167、RFC 6377、2011年9月、<http://www.rfc-editor.org/info/rfc6377>。
[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009, <http://www.rfc-editor.org/info/rfc5585>.
[DKIM-OVERVIEW] Hansen、T.、Crocker、D。、およびP. Hallam-Baker、「DomainKeys Identified Mail（DKIM）Service Overview」、RFC 5585、2009年7月、<http：//www.rfc-editor。 org / info / rfc5585>。
[DKIM-THREATS] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006, <http://www.rfc-editor.org/info/rfc4686>.
[DKIM-THREATS] Fenton、J。、「Analysis of Motivating DomainKeys Identified Mail（DKIM）」、RFC 4686、2006年9月、<http://www.rfc-editor.org/info/rfc4686>。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[DNSSEC] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Introduction and Requirements」、RFC 4033、2005年3月、<http：//www.rfc -editor.org/info/rfc4033>。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>.
[DSN] Moore、K。およびG. Vaudreuil、 "An Extensible Message Format for Delivery Status Notifications"、RFC 3464、2003年1月、<http://www.rfc-editor.org/info/rfc3464>。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[メールアーク] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月、<http://www.rfc-editor.org/info/rfc5598>。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA-CONSIDERATIONS] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/ rfc5226>。
[ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997, <http://www.rfc-editor.org/info/rfc2142>.
[役割] Crocker、D。、「Common Services、Roles、およびFunctionsのメールボックス名」、RFC 2142、1997年5月、<http://www.rfc-editor.org/info/rfc2142>。
This section documents some design decisions that were made in the development of DMARC. Specifically, addressed here are some suggestions that were considered but not included in the design. This text is included to explain why they were considered and not included in this version.
このセクションでは、DMARCの開発で行われたいくつかの設計上の決定について説明します。具体的には、検討されたが設計には含まれていないいくつかの提案をここで扱います。このテキストは、それらが考慮された理由を説明するために含まれており、このバージョンには含まれていません。
S/MIME, or Secure Multipurpose Internet Mail Extensions, is a standard for encryption and signing of MIME data in a message. This was suggested and considered as a third security protocol for authenticating the source of a message.
S / MIME（Secure Multipurpose Internet Mail Extensions）は、メッセージ内のMIMEデータの暗号化と署名の標準です。これは、メッセージのソースを認証するための3番目のセキュリティプロトコルとして提案および検討されました。
DMARC is focused on authentication at the domain level (i.e., the Domain Owner taking responsibility for the message), while S/MIME is really intended for user-to-user authentication and encryption. This alone appears to make it a bad fit for DMARC's goals.
DMARCはドメインレベルでの認証（つまり、ドメインオーナーがメッセージを担当する）に重点を置いていますが、S / MIMEは実際にはユーザー間の認証と暗号化を目的としています。これだけでも、DMARCの目標に適合しないようです。
S/MIME also suffers from the heavyweight problem of Public Key Infrastructure, which means that distribution of keys used to verify signatures needs to be incorporated. In many instances, this alone is a showstopper. There have been consistent promises that PKI usability and deployment will improve, but these have yet to materialize. DMARC can revisit this choice after those barriers are addressed.
S / MIMEは、公開鍵インフラストラクチャの大きな問題にも悩まされています。つまり、署名の検証に使用される鍵の配布を組み込む必要があります。多くの場合、これだけでも大成功です。 PKIの使いやすさと展開が改善されるという一貫した約束がありましたが、これらはまだ実現していません。 DMARCは、これらの障壁に対処した後、この選択を再検討できます。
S/MIME has extensive deployment in specific market segments (government, for example) but does not enjoy similar widespread deployment over the general Internet, and this shows no signs of changing. DKIM and SPF both are deployed widely over the general Internet, and their adoption rates continue to be positive.
S / MIMEは特定の市場セグメント（政府など）で広範囲に展開されていますが、一般的なインターネット上で同様の広範囲に展開されておらず、これは変化の兆候を示していません。 DKIMとSPFはどちらも一般的なインターネット上で広く展開されており、その採用率は引き続き好調です。
Finally, experiments have shown that including S/MIME support in the initial version of DMARC would neither cause nor enable a substantial increase in the accuracy of the overall mechanism.
最後に、実験により、DMARCの初期バージョンにS / MIMEサポートが含まれていても、メカニズム全体の精度が大幅に向上することはありません。
It was suggested that DMARC include a mechanism by which a Domain Owner could tell Message Receivers not to attempt validation by one of the supported methods (e.g., "check DKIM, but not SPF").
DMARCには、ドメインオーナーがメッセージレシーバーに、サポートされている方法のいずれか（「DKIMをチェックするが、SPFはチェックしない」など）による検証を試行しないように指示できるメカニズムが含まれていることが示唆されました。
Specifically, consider a Domain Owner that has deployed one of the technologies, and that technology fails for some messages, but such failures don't cause enforcement action. Deploying DMARC would cause enforcement action for policies other than "none", which would appear to exclude participation by that Domain Owner.
具体的には、テクノロジーの1つを導入したドメインオーナーについて考えてみましょう。そのテクノロジーは一部のメッセージで失敗しますが、そのような失敗は強制措置の原因にはなりません。 DMARCを展開すると、「なし」以外のポリシーが適用され、そのドメイン所有者による参加が除外されたように見えます。
The DMARC development team evaluated the idea of policy exception mechanisms on several occasions and invariably concluded that there was not a strong enough use case to include them. The specific target audience for DMARC does not appear to have concerns about the failure modes of one or the other being a barrier to DMARC's adoption.
DMARC開発チームは、いくつかの状況でポリシー例外メカニズムのアイデアを評価し、それらを含めるのに十分な強力なユースケースがないと常に結論付けました。 DMARCの特定の対象者は、一方または他方の障害モードがDMARCの採用の障害となっていることに懸念を抱いているようには見えません。
In the scenario described above, the Domain Owner has a few options:
上記のシナリオでは、ドメイン所有者にはいくつかのオプションがあります。
1. Tighten up its infrastructure to minimize the failure modes of the single deployed technology.
1. インフラストラクチャを強化して、単一のデプロイされたテクノロジーの障害モードを最小限に抑えます。
2. Deploy the other supported authentication mechanism, to offset the failure modes of the first.
2. 最初の失敗モードを相殺するために、サポートされている他の認証メカニズムをデプロイします。
3. Deploy DMARC in a reporting-only mode.
3. DMARCをレポート専用モードで展開します。
It has been suggested in several message authentication efforts that the Sender header field be checked for an identifier of interest, as the standards indicate this as the proper way to indicate a re-mailing of content such as through a mailing list. Most recently, it was a protocol-level option for DomainKeys, but on evolution to DKIM, this property was removed.
メーリングリストなどを通じてコンテンツを再メールすることを示す適切な方法として規格がこれを示しているため、いくつかのメッセージ認証の取り組みでは、Senderヘッダーフィールドで対象の識別子を確認することが推奨されています。最近では、これはDomainKeysのプロトコルレベルのオプションでしたが、DKIMへの進化により、このプロパティは削除されました。
The DMARC development team considered this and decided not to include support for doing so, for the following reasons:
DMARC開発チームはこれを検討し、次の理由により、そうするためのサポートを含めないことにしました。
1. The main user protection approach is to be concerned with what the user sees when a message is rendered. There is no consistent behavior among MUAs regarding what to do with the content of the Sender field, if present. Accordingly, supporting checking of the Sender identifier would mean applying policy to an identifier the end user might never actually see, which can create a vector for attack against end users by simply forging a Sender field containing some identifier that DMARC will like.
1.ユーザー保護の主なアプローチは、メッセージが表示されたときにユーザーに表示されるものに関係することです。存在する場合、送信者フィールドのコンテンツをどうするかに関してMUA間で一貫した動作はありません。したがって、Sender識別子のチェックをサポートするということは、エンドユーザーが実際に見ることのない識別子にポリシーを適用することを意味し、DMARCが好む識別子を含むSenderフィールドを偽造するだけで、エンドユーザーに対する攻撃のベクトルを作成できます。
2. Although it is certainly true that this is what the Sender field is for, its use in this way is also unreliable, making it a poor candidate for inclusion in the DMARC evaluation algorithm.
2. これがSenderフィールドの目的であることは確かですが、この方法での使用も信頼できないため、DMARC評価アルゴリズムに含める候補としては不十分です。
3. Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC evaluation algorithm in terms of which policy is to be applied and when.
3. ポリシーを検出する複数の方法を許可すると、どのポリシーをいつ適用するかという点で、DMARC評価アルゴリズムに許容できないあいまいさが生じます。
A common practice among MTA operators, and indeed one documented in [ADSP], is a test to determine domain existence prior to any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated and assuming that the domain is nonexistent if it could be determined that no such records were published for that domain name.
MTAオペレーターの間での一般的な慣行、そして実際[ADSP]で文書化されているものは、より高価な処理の前にドメインの存在を決定するためのテストです。これは通常、評価対象の名前についてMX、A、またはAAAAリソースレコードのDNSをクエリし、そのドメイン名に対してそのようなレコードが発行されていないと判断できた場合、ドメインが存在しないと想定して行われます。
The original pre-standardization version of this protocol included a mandatory check of this nature. It was ultimately removed, as the method's error rate was too high without substantial manual tuning and heuristic work. There are indeed use cases this work needs to address where such a method would return a negative result about a domain for which reporting is desired, such as a registered domain name that never sends legitimate mail and thus has none of these records present in the DNS.
このプロトコルの元の事前標準化バージョンには、この性質の必須チェックが含まれていました。手作業による調整やヒューリスティックな作業を行わなければメソッドのエラー率が高すぎるため、最終的には削除されました。確かに、この作業が対処する必要があるユースケースがあり、そのようなメソッドが、報告が必要なドメインについて否定的な結果を返す場合があります。たとえば、正当なメールを送信せず、DNSにこれらのレコードが存在しない登録済みドメイン名などです。 。
DMARC has been characterized as a "super-ADSP" of sorts.
DMARCは、一種の「スーパーADSP」として特徴付けられています。
Contributors to DMARC have compiled a list of issues associated with ADSP, gained from operational experience, that have influenced the direction of DMARC:
DMARCへの貢献者は、DMSPの方向性に影響を与えた、運用経験から得られたADSPに関連する問題のリストをまとめました。
1. ADSP has no support for subdomains, i.e., the ADSP record for example.com does not explicitly or implicitly apply to subdomain.example.com. If wildcarding is not applied, then spammers can trivially bypass ADSP by sending from a subdomain with no ADSP record.
1. ADSPはサブドメインをサポートしていません。つまり、example.comのADSPレコードは明示的または暗黙的にsubdomain.example.comに適用されません。ワイルドカードが適用されていない場合、スパマーはADSPレコードのないサブドメインから送信することにより、ADSPを簡単にバイパスできます。
2. Nonexistent subdomains are explicitly out of scope in ADSP. There is nothing in ADSP that states receivers should simply reject mail from NXDOMAINs regardless of ADSP policy (which of course allows spammers to trivially bypass ADSP by sending email from nonexistent subdomains).
2. ADSPでは、存在しないサブドメインは明示的に範囲外です。 ADSPのポリシーに関係なく、受信者はNXDOMAINからのメールを単に拒否する必要があると述べているADSPには何もありません（もちろん、スパマーは存在しないサブドメインから電子メールを送信してADSPを簡単にバイパスできます）。
3. ADSP has no operational advice on when to look up the ADSP record.
3. ADSPは、ADSPレコードを検索するタイミングに関する運用上のアドバイスはありません。
4. ADSP has no support for using SPF as an auxiliary mechanism to DKIM.
4. ADSPは、DKIMの補助メカニズムとしてSPFを使用することをサポートしていません。
5. ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the receiver should apply the policy. This is important for large-volume senders.
5. ADSPは遅いロールアウトをサポートしていません。つまり、受信者がポリシーを適用する必要がある電子メールの割合を構成する方法はありません。これは、大量の送信者にとって重要です。
6. ADSP has no explicit support for an intermediate phase where the receiver quarantines (e.g., sends to the recipient's "spam" folder) rather than rejects the email.
6. ADSPは、電子メールを拒否するのではなく、受信者が隔離する（たとえば、受信者の「スパム」フォルダーに送信する）中間フェーズを明示的にサポートしていません。
7. The binding between the "From" header domain and DKIM is too tight for ADSP; they must match exactly.
7. "From"ヘッダードメインとDKIMの間のバインドは、ADSPには強すぎます。それらは完全に一致する必要があります。
Although protocols like ADSP are useful for "protecting" a specific domain name, they are not helpful at protecting subdomains. If one wished to protect "example.com" by requiring via ADSP that all mail bearing an RFC5322.From domain of "example.com" be signed, this would "protect" that domain; however, one could then craft an email whose RFC5322.From domain is "security.example.com", and ADSP would not provide any protection. One could use a DNS wildcard, but this can undesirably interfere with other DNS activity; one could add ADSP records as fraudulent domains are discovered, but this solution does not scale and is a purely reactive measure against abuse.
ADSPのようなプロトコルは特定のドメイン名を「保護」するのに役立ちますが、サブドメインの保護には役立ちません。 「example.com」のRFC5322.Fromドメインを持つすべてのメールに署名することをADSP経由で要求することにより「example.com」を保護したい場合、これはそのドメインを「保護」します。ただし、RFC5322.Fromドメインが「security.example.com」である電子メールを作成でき、ADSPは保護を提供しません。 DNSワイルドカードを使用することもできますが、これは他のDNSアクティビティを妨害する可能性があります。不正なドメインが発見されたときにADSPレコードを追加することもできますが、このソリューションは拡張されず、悪用に対する純粋な対処法です。
The DNS does not provide a method by which the "domain of record", or the domain that was actually registered with a domain registrar, can be determined given an arbitrary domain name. Suggestions have been made that attempt to glean such information from SOA or NS resource records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries.
DNSは、「記録のドメイン」、またはドメインレジストラーに実際に登録されたドメインを、任意のドメイン名を指定して特定できる方法を提供しません。このような情報をSOAまたはNSリソースレコードから収集しようとする提案が出されていますが、DNSのパーティション分割は常に管理境界で行われるわけではないため、これらも完全に信頼できるわけではありません。
When seeking domain-specific policy based on an arbitrary domain name, one could "climb the tree", dropping labels off the left end of the name until the root is reached or a policy is discovered, but then one could craft a name that has a large number of nonsense labels; this would cause a Mail Receiver to attempt a large number of queries in search of a policy record. Sending many such messages constitutes an amplified denial-of-service attack.
任意のドメイン名に基づいてドメイン固有のポリシーを探す場合、「ツリーを登る」ことができ、ルートに到達するかポリシーが検出されるまで名前の左端からラベルをドロップしますが、次のような名前を作成できます多数のナンセンスラベル。これにより、Mail Receiverはポリシーレコードを検索するために多数のクエリを試行します。このようなメッセージを多数送信すると、サービス拒否攻撃が増幅されます。
The Organizational Domain mechanism is a necessary component to the goals of DMARC. The method described in Section 3.2 is far from perfect but serves this purpose reasonably well without adding undue burden or semantics to the DNS. If a method is created to do so that is more reliable and secure than the use of a public suffix list, DMARC should be amended to use that method as soon as it is generally available.
組織ドメインメカニズムは、DMARCの目標に必要なコンポーネントです。セクション3.2で説明した方法は完全とはほど遠いですが、DNSに過度の負担やセマンティクスを追加することなく、この目的を適切に果たします。公開サフィックスリストを使用するよりも信頼性と安全性の高い方法を作成する場合、DMARCは、一般に利用可能になり次第、その方法を使用するように修正する必要があります。
A public suffix list for the purposes of determining the Organizational Domain can be obtained from various sources. The most common one is maintained by the Mozilla Foundation and made public at <http://publicsuffix.org>. License terms governing the use of that list are available at that URI.
組織ドメインを決定するためのパブリックサフィックスリストは、さまざまなソースから取得できます。最も一般的なものは、Mozilla Foundationによって管理され、<http://publicsuffix.org>で公開されています。そのリストの使用を規定するライセンス条項は、そのURIで入手できます。
Note that if operators use a variety of public suffix lists, interoperability will be difficult or impossible to guarantee.
オペレーターがさまざまなパブリックサフィックスリストを使用する場合、相互運用性を保証することが困難または不可能になることに注意してください。
This section illustrates both the Domain Owner side and the Mail Receiver side of a DMARC exchange.
このセクションでは、DMARC交換のドメイン所有者側とメール受信者側の両方について説明します。
The following examples illustrate the DMARC mechanism's use of Identifier Alignment. For brevity's sake, only message headers are shown, as message bodies are not considered when conducting DMARC checks.
次の例は、DMARCメカニズムによる識別子の整列の使用法を示しています。簡潔にするために、DMARCチェックを実行するときにメッセージ本文は考慮されないため、メッセージヘッダーのみが表示されます。
The following SPF examples assume that SPF produces a passing result.
次のSPFの例では、SPFが合格の結果を生成すると想定しています。
Example 1: SPF in alignment:
例1：SPFの配置：
MAIL FROM: <sender@example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5321.MailFrom parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.
この場合、RFC5321.MailFromパラメータとRFC5322.Fromフィールドは同じDNSドメインを持っています。したがって、識別子は一致しています。
Example 2: SPF in alignment (parent):
例2：整列したSPF（親）：
MAIL FROM: <sender@child.example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5322.From parameter includes a DNS domain that is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in alignment if relaxed SPF mode is requested by the Domain Owner, and not in alignment if strict SPF mode is requested.
この場合、RFC5322.Fromパラメータには、RFC5321.MailFromドメインの親であるDNSドメインが含まれています。したがって、ドメイン所有者からリラックスしたSPFモードが要求された場合、識別子は一致し、厳密なSPFモードが要求された場合、一致しません。
Example 3: SPF not in alignment:
例3：整合していないSPF：
MAIL FROM: <sender@example.net>
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the RFC5321.MailFrom parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.
この場合、RFC5321.MailFromパラメータには、RFC5322.Fromドメインと同じでも親でもないDNSドメインが含まれます。したがって、識別子は一致していません。
The examples below assume that the DKIM signatures pass verification. Alignment cannot exist with a DKIM signature that does not verify.
以下の例では、DKIM署名が検証に合格することを前提としています。検証されないDKIM署名のあるアライメントは存在できません。
Example 1: DKIM in alignment:
例1：整列したDKIM：
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM "d=" parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.
この場合、DKIMの「d =」パラメーターとRFC5322.Fromフィールドには同じDNSドメインがあります。したがって、識別子は一致しています。
Example 2: DKIM in alignment (parent):
例2：整列したDKIM（親）：
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM signature's "d=" parameter includes a DNS domain that is a parent of the RFC5322.From domain. Thus, the identifiers are in alignment for relaxed mode, but not for strict mode.
この場合、DKIM署名の「d =」パラメーターには、RFC5322.Fromドメインの親であるDNSドメインが含まれます。したがって、識別子はリラックスモードでは整列しますが、厳密モードでは整列しません。
Example 3: DKIM not in alignment:
例3：整列していないDKIM：
DKIM-Signature: v=1; ...; d=sample.net; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
In this case, the DKIM signature's "d=" parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.
この場合、DKIM署名の「d =」パラメーターには、RFC5322.Fromドメインと同じでも親でもないDNSドメインが含まれます。したがって、識別子は一致していません。
A Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM. The next step is to publish a DNS record that advertises a DMARC policy for the Domain Owner's Organizational Domain.
DMARCを使用するドメイン所有者は、SPFとDKIMをすでに展開およびテストしている必要があります。次のステップは、ドメイン所有者の組織ドメインのDMARCポリシーを通知するDNSレコードを公開することです。
The owner of the domain "example.com" has deployed SPF and DKIM on its messaging infrastructure. The owner wishes to begin using DMARC with a policy that will solicit aggregate feedback from receivers without affecting how the messages are processed, in order to:
ドメイン「example.com」の所有者は、SPFとDKIMをメッセージングインフラストラクチャに展開しています。所有者は、次の目的で、メッセージの処理方法に影響を与えずに受信者からのフィードバックの集約を求めるポリシーでDMARCの使用を開始したいと考えています。
o Confirm that its legitimate messages are authenticating correctly
o 正当なメッセージが正しく認証されていることを確認します
o Verify that all authorized message sources have implemented authentication measures
o 承認されたすべてのメッセージソースに認証手段が実装されていることを確認する
o Determine how many messages from other sources would be affected by a blocking policy
o ブロッキングポリシーの影響を受ける他のソースからのメッセージの数を決定する
The Domain Owner accomplishes this by constructing a policy record indicating that:
ドメイン所有者は、次のことを示すポリシーレコードを作成してこれを実現します。
o The version of DMARC being used is "DMARC1" ("v=DMARC1")
o 使用されているDMARCのバージョンは "DMARC1"（ "v = DMARC1"）です。
o Receivers should not alter how they treat these messages because of this DMARC policy record ("p=none")
o このDMARCポリシーレコードのため、受信者はこれらのメッセージの処理方法を変更しないでください（ "p = none"）
o Aggregate feedback reports should be sent via email to the address "dmarc-feedback@example.com" ("rua=mailto:dmarc-feedback@example.com")
o 集計フィードバックレポートは、電子メールでアドレス "dmarc-feedback@example.com"（ "rua = mailto：dmarc-feedback@example.com"）に送信する必要があります
o All messages from this Organizational Domain are subject to this policy (no "pct" tag present, so the default of 100% applies)
o この組織ドメインからのすべてのメッセージはこのポリシーの対象になります（「pct」タグが存在しないため、デフォルトの100％が適用されます）
The DMARC policy record might look like this when retrieved using a common command-line tool:
一般的なコマンドラインツールを使用して取得した場合、DMARCポリシーレコードは次のようになります。
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"
To publish such a record, the DNS administrator for the Domain Owner creates an entry like the following in the appropriate zone file (following the conventional zone file format):
このようなレコードを公開するために、ドメイン所有者のDNS管理者は、適切なゾーンファイルに次のようなエントリを作成します（従来のゾーンファイル形式に従って）：
; DMARC record for the domain example.com
;ドメインexample.comのDMARCレコード
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" )
The Domain Owner from the previous example has used the aggregate reporting to discover some messaging systems that had not yet implemented DKIM correctly, but they are still seeing periodic authentication failures. In order to diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.
前の例のドメイン所有者は、集計レポートを使用して、まだDKIMを正しく実装していない一部のメッセージングシステムを検出しましたが、依然として定期的な認証エラーが発生しています。これらの断続的な問題を診断するために、認証の失敗が発生したときにメッセージごとの失敗レポートを要求したいと考えています。
Not all Receivers will honor such a request, but the Domain Owner feels that any reports it does receive will be helpful enough to justify publishing this record. The default per-message report format ([AFRF]) meets the Domain Owner's needs in this scenario.
すべての受信者がそのような要求を尊重するわけではありませんが、ドメイン所有者は、受信するレポートはこのレコードの公開を正当化するのに十分役立つと考えています。デフォルトのメッセージごとのレポート形式（[AFRF]）は、このシナリオでのドメイン所有者のニーズを満たします。
The Domain Owner accomplishes this by adding the following to its policy record from Appendix B.2:
ドメイン所有者は、付録B.2のポリシーレコードに以下を追加することでこれを実現します。
o Per-message failure reports should be sent via email to the address "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
o メッセージごとの障害レポートは、電子メールでアドレス "auth-reports@example.com"（ "ruf = mailto：auth-reports@example.com"）に送信する必要があります
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
一般的なコマンドラインツールを使用して取得すると、DMARCポリシーレコードは次のようになります（表示される出力は1行で表示されますが、ここでは公開のために折り返されています）。
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@example.com"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):
このようなレコードを公開するために、ドメイン所有者のDNS管理者は、適切なゾーンファイルに（従来のゾーンファイル形式に従って）次のようなエントリを作成する場合があります。
; DMARC record for the domain example.com
;ドメインexample.comのDMARCレコード
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com" )
The Domain Owner from the previous example is maintaining the same policy but now wishes to have a third party receive and process the per-message failure reports. Again, not all Receivers will honor this request, but those that do may implement additional checks to validate that the third party wishes to receive the failure reports for this domain.
前の例のドメイン所有者は同じポリシーを維持していますが、サードパーティにメッセージごとの障害レポートを受信して処理させたいと考えています。繰り返しになりますが、すべての受信者がこのリクエストを尊重するわけではありませんが、追加のチェックを実装して、サードパーティがこのドメインの障害レポートの受信を希望していることを検証する場合があります。
The Domain Owner needs to alter its policy record from Appendix B.2.2 as follows:
ドメイン所有者は、付録B.2.2のポリシーレコードを次のように変更する必要があります。
o Per-message failure reports should be sent via email to the address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth-reports@thirdparty.example.net")
o メッセージごとの障害レポートは、電子メールでアドレス "auth-reports@thirdparty.example.net"（ "ruf = mailto：auth-reports@thirdparty.example.net"）に送信する必要があります
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
一般的なコマンドラインツールを使用して取得すると、DMARCポリシーレコードは次のようになります（表示される出力は1行で表示されますが、ここでは公開のために折り返されています）。
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@thirdparty.example.net"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):
このようなレコードを公開するために、ドメイン所有者のDNS管理者は、適切なゾーンファイルに（従来のゾーンファイル形式に従って）次のようなエントリを作成する場合があります。
; DMARC record for the domain example.com
;ドメインexample.comのDMARCレコード
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@thirdparty.example.net" )
Because the address used in the "ruf" tag is outside the Organizational Domain in which this record is published, conforming Receivers will implement additional checks as described in Section 7.1 of this document. In order to pass these additional checks, the third party will need to publish an additional DNS record as follows:
「ruf」タグで使用されるアドレスは、このレコードが公開されている組織ドメインの外にあるため、適合レシーバーは、このドキュメントのセクション7.1で説明されている追加のチェックを実装します。これらの追加のチェックに合格するために、サードパーティは次のように追加のDNSレコードを公開する必要があります。
o Given the DMARC record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the third party will need to publish a TXT resource record at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1".
o ドメイン所有者が「_dmarc.example.com」で発行したDMARCレコードを前提として、サードパーティのDNS管理者は、TXTリソースレコードを「example.com._report._dmarc.thirdparty.example.net」で次のように発行する必要があります。値 "v = DMARC1"。
The resulting DNS record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
一般的なコマンドラインツールを使用して取得すると、結果のDNSレコードは次のようになります（表示される出力は1行で表示されますが、ここでは公開のために折り返されています）。
% dig +short TXT example.com._report._dmarc.thirdparty.example.net "v=DMARC1"
％dig +短いTXT example.com._report._dmarc.thirdparty.example.net "v = DMARC1"
To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):
そのようなレコードを公開するために、example.netのDNS管理者は、適切なゾーンファイルに次のようなエントリを作成する場合があります（従来のゾーンファイル形式に従って）。
; zone file for thirdparty.example.net ; Accept DMARC failure reports on behalf of example.com
; thirdparty.example.netのゾーンファイル。 example.comに代わってDMARC障害レポートを受け入れる
example.com._report._dmarc IN TXT "v=DMARC1"
example.com._report._dmarc IN TXT "v = DMARC1"
Intermediaries and other third parties should refer to Section 7.1 for the full details of this mechanism.
仲介者およびその他の第三者は、このメカニズムの詳細についてセクション7.1を参照する必要があります。
The Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services. It now wishes to request that participating receivers act to reject messages from this subdomain that fail to authenticate.
ドメイン所有者は、メッセージングサービスの運用前テストに使用されるサブドメインにSPFとDKIMを実装しています。次に、参加している受信者が認証に失敗したこのサブドメインからのメッセージを拒否するように動作することを要求します。
As a first step, it will ask that a portion (1/4 in this example) of failing messages be quarantined, enabling examination of messages sent to mailboxes hosted by participating receivers. Aggregate feedback reports will be sent to a mailbox within the Organizational Domain, and to a mailbox at a third party selected and authorized to receive same by the Domain Owner. Aggregate reports sent to the third party are limited to a maximum size of ten megabytes.
最初のステップとして、失敗したメッセージの一部（この例では1/4）を検疫し、参加している受信者がホストするメールボックスに送信されたメッセージを検査できるようにします。集約フィードバックレポートは、組織ドメイン内のメールボックスと、ドメイン所有者が選択して受信することを許可された第三者のメールボックスに送信されます。サードパーティに送信される集約レポートは、最大サイズが10メガバイトに制限されています。
The Domain Owner will accomplish this by constructing a policy record indicating that:
ドメイン所有者は、次のことを示すポリシーレコードを作成してこれを実現します。
o The version of DMARC being used is "DMARC1" ("v=DMARC1")
o 使用されているDMARCのバージョンは "DMARC1"（ "v = DMARC1"）です。
o It is applied only to this subdomain (record is published at "_dmarc.test.example.com" and not "_dmarc.example.com")
o このサブドメインにのみ適用されます（レコードは「_dmarc.test.example.com」で公開され、「_ dmarc.example.com」では公開されません）
o Receivers should quarantine messages from this Organizational Domain that fail to authenticate ("p=quarantine")
o 受信者は、認証に失敗したこの組織ドメインからのメッセージを隔離する必要があります（ "p = quarantine"）
o Aggregate feedback reports should be sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net", with the latter subjected to a maximum size limit ("rua=mailto:dmarc-feedback@ example.com,mailto:tld-test@thirdparty.example.net!10m")
o 集計フィードバックレポートは、メールで「dmarc-feedback@example.com」と「example-tld-test@thirdparty.example.net」のアドレスに送信する必要があります。後者には最大サイズの制限（「rua = mailto： dmarc-feedback @ example.com、mailto：tld-test@thirdparty.example.net！10m "）
o 25% of messages from this Organizational Domain are subject to action based on this policy ("pct=25")
o この組織ドメインからのメッセージの25％は、このポリシーに基づいてアクションの対象になります（ "pct = 25"）
The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):
一般的なコマンドラインツールを使用して取得すると、DMARCポリシーレコードは次のようになります（表示される出力は1行で表示されますが、ここでは公開のために折り返されています）。
% dig +short TXT _dmarc.test.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
mailto:tld-test@thirdparty.example.net!10m; pct=25"
To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file:
このようなレコードを公開するために、ドメイン所有者のDNS管理者は、適切なゾーンファイルに次のようなエントリを作成する場合があります。
; DMARC record for the domain example.com
;ドメインexample.comのDMARCレコード
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net!10m; "
"pct=25" )
A Mail Receiver that wants to use DMARC should already be checking SPF and DKIM, and possess the ability to collect relevant information from various email-processing stages to provide feedback to Domain Owners (possibly via Report Receivers).
DMARCを使用するメールレシーバーは、SPFとDKIMをすでにチェックしている必要があり、さまざまな電子メール処理段階から関連情報を収集して、ドメイン所有者にフィードバックを提供する機能があります（おそらくレポートレシーバーを介して）。
An optimal DMARC-enabled Mail Receiver performs authentication and Identifier Alignment checking during the [SMTP] conversation.
最適なDMARC対応のメールレシーバーは、[SMTP]会話中に認証と識別子アライメントチェックを実行します。
Prior to returning a final reply to the DATA command, the Mail Receiver's MTA has performed:
DATAコマンドへの最終応答を返す前に、メール受信者のMTAは以下を実行しました。
1. An SPF check to determine an SPF-authenticated Identifier.
1. SPFで認証された識別子を決定するためのSPFチェック。
2. DKIM checks that yield one or more DKIM-authenticated Identifiers.
2. 1つ以上のDKIM認証済み識別子を生成するDKIMチェック。
3. A DMARC policy lookup.
3. DMARCポリシーの検索。
The presence of an Author Domain DMARC record indicates that the Mail Receiver should continue with DMARC-specific processing before returning a reply to the DATA command.
作成者ドメインDMARCレコードが存在することは、メール受信者がDATAコマンドへの応答を返す前にDMARC固有の処理を続行する必要があることを示しています。
Given a DMARC record and the set of Authenticated Identifiers, the Mail Receiver checks to see if the Authenticated Identifiers align with the Author Domain (taking into consideration any strict versus relaxed options found in the DMARC record).
DMARCレコードと認証済み識別子のセットが与えられると、メールレシーバーは、認証済み識別子が作成者ドメインと一致するかどうかを確認します（DMARCレコードにある厳密なオプションと緩和されたオプションを考慮に入れます）。
For example, the following sample data is considered to be from a piece of email originating from the Domain Owner of "example.com":
たとえば、次のサンプルデータは、「example.com」のドメイン所有者から送信された電子メールの一部であると見なされます。
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"
In the above sample, both the SPF-authenticated Identifier and the DKIM-authenticated Identifier align with the Author Domain. The Mail Receiver considers the above email to pass the DMARC check, avoiding the "reject" policy that is to be applied to email that fails to pass the DMARC check.
上記のサンプルでは、SPF認証済み識別子とDKIM認証済み識別子の両方が作成者ドメインと一致しています。メール受信者は、上記の電子メールがDMARCチェックに合格したと見なし、DMARCチェックに合格しなかった電子メールに適用される「拒否」ポリシーを回避します。
If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the DMARC-record-specified policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner's policy.
認証済み識別子が作成者ドメインと一致しない場合、メール受信者はDMARCレコードで指定されたポリシーを適用します。ただし、このアクションが実行される前に、メール受信者は外部情報を参照してドメイン所有者のポリシーを上書きできます。たとえば、メール受信者がこの特定のメールが既知の信頼できるフォワーダーから送信されたことを知っている場合（SPFとDKIMの両方が破られることになります）、メール受信者はドメイン所有者のポリシーを無視することを選択できます。
The Mail Receiver is now ready to reply to the DATA command. If the DMARC check yields that the message is to be rejected, then the Mail Receiver replies with a 5xy code to inform the sender of failure. If the DMARC check cannot be resolved due to transient network errors, then the Mail Receiver replies with a 4xy code to inform the sender as to the need to reattempt delivery later. If the DMARC check yields a passing message, then the Mail Receiver continues on with email processing, perhaps using the result of the DMARC check as an input to additional processing modules such as a domain reputation query.
これで、メールレシーバーはDATAコマンドに応答する準備ができました。 DMARCチェックでメッセージが拒否されることが判明した場合、メール受信者は5xyコードで応答して送信者に失敗を通知します。一時的なネットワークエラーが原因でDMARCチェックを解決できない場合、メールレシーバーは4xyコードで応答し、後で配信を再試行する必要があることを送信者に通知します。 DMARCチェックで合格メッセージが生成された場合、メールレシーバーは、おそらくドメインレピュテーションクエリなどの追加処理モジュールへの入力としてDMARCチェックの結果を使用して、電子メール処理を続行します。
Before exiting DMARC-specific processing, the Mail Receiver checks to see if the Author Domain DMARC record requests AFRF-based reporting. If so, then the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC record.
DMARC固有の処理を終了する前に、Mail Receiverは、Author Domain DMARCレコードがAFRFベースのレポートを要求しているかどうかを確認します。その場合、メールレシーバーは、DMARCレコードで提供されるレポートアドレスにAFRFを送信できます。
At the exit of DMARC-specific processing, the Mail Receiver captures (through logging or direct insertion into a data store) the result of DMARC processing. Captured information is used to build feedback for Domain Owner consumption. This is not necessary if the Domain Owner has not requested aggregate reports, i.e., no "rua" tag was found in the policy record.
DMARC固有の処理の終了時に、メールレシーバーは（ロギングまたはデータストアへの直接挿入によって）DMARC処理の結果をキャプチャします。キャプチャされた情報は、ドメイン所有者の消費に関するフィードバックを構築するために使用されます。ドメイン所有者が集計レポートをリクエストしていない場合、つまり、ポリシーレコードに「rua」タグが見つからなかった場合、これは必要ありません。
Aggregate feedback is consumed by Domain Owners to verify a Domain Owner's understanding of how the Domain Owner's domain is being processed by the Mail Receiver. Aggregate reporting data on emails that pass all DMARC-supporting authentication checks is used by Domain Owners to verify that authentication practices remain accurate. For example, if a third party is sending on behalf of a Domain Owner, the Domain Owner can use aggregate report data to verify ongoing authentication practices of the third party.
集約フィードバックは、ドメイン所有者のドメインがメール受信者によってどのように処理されているかについてのドメイン所有者の理解を確認するために、ドメイン所有者によって消費されます。ドメイン所有者は、DMARCをサポートするすべての認証チェックに合格したメールの集計レポートデータを使用して、認証手法が正確であることを確認します。たとえば、サードパーティがドメインオーナーに代わって送信している場合、ドメインオーナーは集計レポートデータを使用して、サードパーティの進行中の認証プラクティスを確認できます。
Data on email that only partially passes underlying authentication checks provides visibility into problems that need to be addressed by the Domain Owner. For example, if either SPF or DKIM fails to pass, the Domain Owner is provided with enough information to either directly correct the problem or understand where authentication-breaking changes are being introduced in the email transmission path. If authentication-breaking changes due to email transmission path cannot be directly corrected, then the Domain Owner at least maintains an understanding of the effect of DMARC-based policies upon the Domain Owner's email.
基礎となる認証チェックに部分的に合格する電子メールのデータは、ドメイン所有者が対処する必要のある問題の可視性を提供します。たとえば、SPFまたはDKIMのいずれかが失敗した場合、ドメイン所有者には、問題を直接修正するか、電子メール送信パスのどこに認証違反の変更が導入されているかを理解するのに十分な情報が提供されます。電子メールの送信パスによる認証違反の変更を直接修正できない場合、ドメイン所有者は、DMARCベースのポリシーがドメイン所有者の電子メールに与える影響を少なくとも理解しています。
Data on email that fails all underlying authentication checks provides baseline visibility on how the Domain Owner's domain is being received at the Mail Receiver. Based on this visibility, the Domain Owner can begin deployment of authentication technologies across uncovered email sources. Additionally, the Domain Owner may come to an understanding of how its domain is being misused.
基礎となるすべての認証チェックに失敗した電子メールのデータは、ドメイン所有者のドメインがメールレシーバーでどのように受信されているかについてのベースラインの可視性を提供します。この可視性に基づいて、ドメイン所有者は、カバーされていない電子メールソースへの認証テクノロジーの導入を開始できます。さらに、ドメイン所有者は、そのドメインがどのように悪用されているかを理解するようになるかもしれません。
A DMARC record can contain a "mailto" reporting address, such as:
DMARCレコードには、次のような「mailto」レポートアドレスを含めることができます。
mailto:dmarc-feedback@example.com
mailto：dmarc-feedback@example.com
A sample aggregate report from the Mail Receiver at mail.receiver.example follows:
次に、mail.receiver.exampleのメールレシーバーからのサンプル集計レポートを示します。
DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
From: dmarc-reporting@mail.receiver.example
Date: Fri, Feb 15 2002 16:54:30 -0800
To: dmarc-feedback@example.com
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
This is a multipart message in MIME format.
これはMIME形式のマルチパートメッセージです。
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
This is an aggregate report from mail.receiver.example.
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.receiver.example!example.com!
1013662812!1013749130.gz"
<gzipped content of report>
<レポートのgzip圧縮されたコンテンツ>
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
Not shown in the above example is that the Mail Receiver's feedback should be authenticated using SPF. Also, the value of the "filename" MIME parameter is wrapped for printing in this specification but would normally appear as one continuous string.
上記の例には、メール受信者のフィードバックをSPFを使用して認証する必要があることは示されていません。また、「filename」MIMEパラメータの値は、この仕様では印刷用にラップされていますが、通常は1つの連続した文字列として表示されます。
The following is the proposed initial schema for producing XML-formatted aggregate reports as described in this document.
このドキュメントで説明されているXML形式の集計レポートを作成するために提案された初期スキーマは次のとおりです。
NOTE: Per the definition of XML, unless otherwise specified in the schema below, the minOccurs and maxOccurs values for each element are set to 1.
注：XMLの定義に従って、以下のスキーマで特に指定されていない限り、各要素のminOccursおよびmaxOccurs値は1に設定されます。
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dmarc.org/dmarc-xml/0.1">
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"/>
<xs:element name="end" type="xs:integer"/>
</xs:all>
</xs:complexType>
<!-- Report generator metadata. -->
<xs:complexType name="ReportMetadataType">
<xs:sequence>
<xs:element name="org_name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
<xs:element name="extra_contact_info" type="xs:string"
minOccurs="0"/>
<xs:element name="report_id" type="xs:string"/>
<xs:element name="date_range" type="DateRangeType"/>
<xs:element name="error" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</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 and sp in the
DMARC 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 DMARC policy that applied to the messages in
this report. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0"/>
<!-- The policy to apply to messages from the domain. -->
<xs:element name="p" type="DispositionType"/>
<!-- The policy to apply to messages from subdomains. -->
<xs:element name="sp" type="DispositionType"/>
<!-- The percent of messages to which policy applies. -->
<xs:element name="pct" type="xs:integer"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"/>
</xs:all>
</xs:complexType>
<!-- 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
thereof. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="forwarded"/>
<xs:enumeration value="sampled_out"/>
<xs:enumeration value="trusted_forwarder"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="local_policy"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!-- How do we allow report generators to include new
classes of override reasons if they want to be more
specific than "other"? -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"/>
<xs:element name="comment" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="DispositionType"/>
<xs:element name="dkim" type="DMARCResultType"/>
<xs:element name="spf" type="DMARCResultType"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018018.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RowType">
<xs:all>
<!-- The connecting IP. -->
<xs:element name="source_ip" type="IPAddress"/>
<!-- The number of matching messages. -->
<xs:element name="count" type="xs:integer"/>
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- DKIM verification result, according to RFC 7001
Section 2.6.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=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1"/>
<!-- The "s=" parameter in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="0"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1"/>
<!-- Any extra information (e.g., from
Authentication-Results). -->
<xs:element name="human_result" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown". -->
<xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error". -->
<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"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="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 no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</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"/>
<xs:element name="identifiers" type="IdentifierType"/>
<xs:element name="auth_results" type="AuthResultType"/>
</xs:sequence>
</xs:complexType>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version"
type="xs:decimal"/>
<xs:element name="report_metadata"
type="ReportMetadataType"/>
<xs:element name="policy_published"
type="PolicyPublishedType"/>
<xs:element name="record" type="RecordType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Descriptions of the PolicyOverrideTypes:
PolicyOverrideTypesの説明：
forwarded: The message was relayed via a known forwarder, or local heuristics identified the message as likely having been forwarded. There is no expectation that authentication would pass.
転送済み：メッセージは既知のフォワーダーを介して中継されました。またはローカルのヒューリスティックにより、メッセージが転送された可能性が高いと識別されました。認証に合格することは期待されていません。
local_policy: The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.
local_policy：メール受信者のローカルポリシーにより、メッセージがドメイン所有者の要求したポリシーアクションの対象から除外されました。
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.
mailing_list：ローカルヒューリスティックは、メッセージがメーリングリスト経由で到着したと判断したため、元のメッセージの認証は成功しないと予想されていました。
other: Some policy exception not covered by the other entries in this list occurred. Additional detail can be found in the PolicyOverrideReason's "comment" field.
その他：このリストの他のエントリでカバーされていないポリシー例外が発生しました。追加の詳細は、PolicyOverrideReasonの「コメント」フィールドにあります。
sampled_out: The message was exempted from application of policy by the "pct" setting in the DMARC policy record.
sampled_out：DMARCポリシーレコードの「pct」設定により、メッセージはポリシーの適用から除外されました。
trusted_forwarder: Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.
trusted_forwarder：メッセージ認証の失敗は、既知の信頼できるフォワーダーのローカルに維持されているリストにメッセージをリンクする他の証拠によって予期されていました。
The "version" for reports generated per this specification MUST be the value 1.0.
この仕様に従って生成されたレポートの「バージョン」は、値1.0でなければなりません。
Acknowledgements
謝辞
DMARC and the draft version of this document submitted to the Independent Submission Editor were the result of lengthy efforts by an informal industry consortium: DMARC.org (see <http://dmarc.org>). Participating companies included Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although the contributors and supporters are too numerous to mention, notable individual contributions were made by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. The contributors would also like to recognize the invaluable input and guidance that was provided early on by J.D. Falk.
DMARCとこのドキュメントのドラフトバージョンは、Independent Submission Editorに提出され、非公式の業界コンソーシアムであるDMARC.org（<http://dmarc.org>を参照）による長い努力の結果です。参加企業には、Agari、American Greetings、AOL、バンクオブアメリカ、Cloudmark、Comcast、Facebook、Fidelity Investments、Google、JPMorgan Chase＆Company、LinkedIn、Microsoft、Netease、PayPal、ReturnPath、Trusted Domain Project、Yahoo！などがあります。貢献者と支持者は多すぎて言及することはできませんが、注目すべき個人の貢献は、J。トレントアダムス、マイケルアドキンス、モニカチュー、デイブクロッカー、ティムドレーゲン、スティーブジョーンズ、フランクマーティン、ブレットマクダウェル、およびポールミッドゲンによって行われました。寄稿者はまた、J.D。フォークによって早期に提供された貴重なインプットとガイダンスを認めたいと考えています。
Additional contributions within the IETF context were made by Kurt Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.
IETFコンテキスト内での追加の貢献は、カートアンダーソン、マイケルジャックアッセル、レバーストウ、アンベネット、ジムフェントン、J。ゴメス、マイクジョーンズ、スコットキッターマン、エリオットリア、ジョンレバイン、S。ムーネサミー、ロルフゾンネフェルド、ヘンリーティムスによって行われました。 、そしてスティーブン・J・ターンブル。
Authors' Addresses
著者のアドレス
Murray S. Kucherawy (editor)
マレー・S・クチェラウィ（編集者）
EMail: superuser@gmail.com
Elizabeth Zwicky (editor) Yahoo!
エリザベス・ズウィッキー（編集者）Yahoo!
EMail: zwicky@yahoo-inc.com