Internet Engineering Task Force (IETF) T. Herr, Ed.
Request for Comments: 9989 Valimail
Obsoletes: 7489, 9091 J. Levine, Ed.
Category: Standards Track Standcore LLC
ISSN: 2070-1721 May 2026
This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol.
このドキュメントでは、ドメインベースのメッセージ認証、レポート、および適合性 (DMARC) プロトコルについて説明します。
DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail.
DMARC を使用すると、電子メールの作成者ドメインの所有者は、ドメインの使用の検証を有効にして、失敗した検証に関するドメイン所有者またはパブリック サフィックス オペレータのメッセージ処理設定を示し、ドメイン名の使用に関するレポートを要求することができます。メール受信組織は、受信メールの処理の選択肢を評価するときにこの情報を使用できます。
This document obsoletes RFCs 7489 and 9091.
この文書は RFC 7489 および 9091 を廃止します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9989.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9989 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Requirements
2.1. High-Level Goals
2.2. Anti-Phishing
2.3. Scalability
2.4. Out of Scope
3. Terminology and Definitions
3.1. Conventions Used in This Document
3.2. Definitions
3.2.1. Authenticated Identifiers
3.2.2. Author Domain
3.2.3. DKIM Signing Domain
3.2.4. SPF Domain
3.2.5. DMARC Policy Domain
3.2.6. DMARC Policy Record
3.2.7. Domain Owner
3.2.8. Domain Owner Assessment Policy
3.2.9. Enforcement
3.2.10. Identifier Alignment
3.2.11. Mail Receiver
3.2.12. Monitoring Mode
3.2.13. Non-Existent Domains
3.2.14. Organizational Domain
3.2.15. Public Suffix Domain (PSD)
3.2.16. Public Suffix Operator (PSO)
3.2.17. PSO-Controlled Domain Names
3.2.18. Report Consumer
4. Overview and Key Concepts
4.1. DMARC Basics
4.2. Use of RFC5322.From
4.3. Authentication Mechanisms
4.4. Identifier Alignment Explained
4.4.1. DKIM-Authenticated Identifiers
4.4.2. SPF-Authenticated Identifiers
4.4.3. Alignment and Extension Technologies
4.5. DMARC Policy Record Explained
4.6. DMARC Reporting URIs
4.7. DMARC Policy Record Format
4.8. Formal Definition
4.9. Flow Diagram
4.10. DNS Tree Walk
4.10.1. DMARC Policy Discovery
4.10.2. Identifier Alignment Evaluation
5. DMARC Participation
5.1. Domain Owner Actions
5.1.1. Publish an SPF Record for an Aligned Domain
5.1.2. Configure Sending System for DKIM Signing Using an
Aligned Domain
5.1.3. Set Up a Mailbox to Receive Aggregate Reports
5.1.4. Publish a DMARC Policy Record for the Author Domain and
Organizational Domain
5.1.5. Collect and Analyze Reports
5.1.6. Remediate Unaligned or Unauthenticated Mail Streams
5.1.7. Decide Whether to Update Domain Owner Assessment Policy
to Enforcement
5.1.8. A Note on Large, Complex Organizations and
Decentralized DNS Management
5.2. PSO Actions
5.3. Mail Receiver Actions
5.3.1. Extract Author Domain
5.3.2. Determine If the DMARC Mechanism Applies
5.3.3. Determine If Authenticated Identifiers Exist
5.3.4. Conduct Identifier Alignment Checks If Necessary
5.3.5. Determine DMARC "Pass" or "Fail"
5.3.6. Apply Policy If Appropriate
5.3.7. Store Results of DMARC Processing
5.3.8. Send Aggregate Reports
5.3.9. Optionally Send Failure Reports
5.4. Policy Enforcement Considerations
6. DMARC Feedback
7. Other Topics
7.1. Issues Specific to SPF
7.2. Rejecting Messages
7.3. Interoperability Issues
7.4. Interoperability Considerations
8. Conformance Requirements for Full DMARC Participation
9. IANA Considerations
9.1. Email Authentication Methods Registry Update
9.2. Email Authentication Result Names Registry Update
9.3. DMARC Tags Registry Update
9.4. DMARC Report Formats Registry Update
9.5. Underscored and Globally Scoped DNS Node Names Registry
Update
10. Privacy Considerations
10.1. Aggregate Report Considerations
10.2. Failure Report Considerations
11. Security Considerations
11.1. Authentication Methods
11.2. Attacks on Reporting URIs
11.3. DNS Security
11.4. Display Name Attacks
11.5. Denial of DMARC Processing Attacks
11.6. External Reporting Addresses
11.7. Secure Protocols
11.8. Relaxed Alignment Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Technology Considerations
A.1. S/MIME
A.2. Method Exclusion
A.3. Sender Header Field
A.4. Domain Existence Test
A.5. Organizational Domain Discovery Issues
A.6. Removal of the "pct" Tag
Appendix B. Examples
B.1. Identifier Alignment Examples
B.1.1. SPF
B.1.2. DKIM
B.2. Domain Owner Example
B.2.1. Entire Domain, Monitoring Mode
B.2.2. Entire Domain, Monitoring Mode, Per-Message Failure
Reports
B.2.3. Per-Message Failure Reports Directed to Third Party
B.2.4. Overriding Destination Addresses
B.2.5. Subdomain, Testing, and Multiple Aggregate Report URIs
B.3. Mail Receiver Example
B.3.1. SMTP Session Example
B.4. Organizational and Policy Domain Tree Walk Examples
B.4.1. Simple Organizational and Policy Example
B.4.2. Deep Tree Walk Example
B.4.3. Example with a PSD DMARC Policy Record
B.5. Utilization of Aggregate Feedback: Example
Appendix C. Changes from RFC 7489
C.1. Informational vs. Standards Track
C.2. Changes to Terminology and Definitions
C.2.1. Terms Added
C.2.2. Definitions Updated
C.3. Policy Discovery and Organizational Domain Determination
C.4. Reporting
C.5. Tags
C.5.1. Tags Added
C.5.2. Tags Removed
C.6. Expansion of Domain Owner Actions Section
C.7. Report Generator Recommendations
C.8. Removal of RFC 7489, Appendix A.5
C.9. RFC 7489 Errata Summary
C.9.1. RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.1.1
C.9.2. RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.1.1
C.9.3. RFC Errata, Erratum ID 5440, RFC 7489, Section 7.1 and
Appendices B.2.1, B.2.3, and B.2.4
C.9.4. RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1
C.9.5. RFC Errata, Erratum ID 5221, RFC 7489, Appendix C
C.9.6. RFC Errata, Erratum ID 5229, RFC 7489, Appendix C
C.9.7. RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3
C.9.8. RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1
C.9.9. RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2
C.9.10. RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1
C.9.11. RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1
C.9.12. RFC Errata, Erratum ID 7835, RFC 7489, Section 6.6.3
C.9.13. RFC Errata, Erratum ID 7865, RFC 7489, Appendix C
C.9.14. RFC Errata, Erratum ID 5151, RFC 7489, Section 1
C.9.15. RFC Errata, Erratum ID 5774, RFC 7489, Appendix C
C.10. General Editing and Formatting
Acknowledgements
Acknowledgements - RFC 7489
Authors' Addresses
Abusive email often includes unauthorized and deceptive use of a domain name in the "From" header field defined in Section 3.6.2 of [RFC5322] and referred to as RFC5322.From. The domain typically belongs to an organization expected to be known to -- and presumably trusted by -- the recipient. The Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] protocols provide domain-level authentication but are not directly associated with the RFC5322.From domain, also known as the Author Domain (Section 3.2.2). DMARC leverages these two protocols, providing a method for Domain Owners to publish a DNS TXT record describing the email authentication policies for the Author Domain and to request specific handling for messages using that domain that fail validation checks. These DNS records are called DMARC Policy Records (Section 3.2.6).
不正な電子メールには、[RFC5322] のセクション 3.6.2 で定義され、RFC5322.From と呼ばれる「From」ヘッダー フィールドにドメイン名が不正に使用され、不正に使用されることがよくあります。通常、ドメインは受信者に知られている、そしておそらく受信者から信頼されていると予想される組織に属しています。Sender Policy Framework (SPF) [RFC7208] および DomainKeys Identified Mail (DKIM) [RFC6376] プロトコルはドメインレベルの認証を提供しますが、作成者ドメインとも呼ばれる RFC5322.From ドメインとは直接関連付けられていません (セクション 3.2.2)。DMARC はこれら 2 つのプロトコルを活用し、ドメイン所有者が作成者ドメインの電子メール認証ポリシーを記述した DNS TXT レコードを公開し、そのドメインを使用して検証チェックに失敗したメッセージに対する特定の処理を要求する方法を提供します。これらの DNS レコードは DMARC ポリシー レコードと呼ばれます (セクション 3.2.6)。
As with SPF and DKIM, DMARC validation results in a verdict of either "pass" or "fail". A DMARC result of "pass" requires not only an SPF or DKIM pass verdict for the email message but also and more importantly that the domain associated with the SPF or DKIM pass be "aligned" with the Author Domain in one of two modes -- "relaxed" or "strict". Domains are said to be in "relaxed alignment" if they have the same Organizational Domain (Section 3.2.14); a domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as that domain. On the other hand, domains are in "strict alignment" if and only if they are identical. The choice of required alignment mode is left to the Domain Owner (Section 3.2.7) that publishes a DMARC Policy Record.
SPF および DKIM と同様、DMARC 検証の結果は「合格」または「不合格」のいずれかになります。DMARC の結果が「合格」の場合は、電子メール メッセージの SPF または DKIM の合格判定だけでなく、さらに重要なことに、SPF または DKIM パスに関連付けられたドメインが、「緩和」または「厳密」の 2 つのモードのいずれかで作成者ドメインと「調整」されていることも必要です。ドメインが同じ組織ドメインを持っている場合、ドメインは「緩和された調整」にあると言われます (セクション 3.2.14)。ドメインの組織ドメインは、そのドメインの名前空間階層の最上位にあり、そのドメインと同じ管理権限を持ちます。一方、ドメインは、それらが同一である場合にのみ「厳密に一致」します。必要な調整モードの選択は、DMARC ポリシー レコードを発行するドメイン所有者 (セクション 3.2.7) に任されています。
A DMARC pass for a message indicates only that the use of the Author Domain has been validated for that message as authorized by the Domain Owner. Such authorization does not carry an explicit or implicit value assertion about that message or about the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable. For a mail-receiving organization participating in DMARC, a message that passes DMARC validation is part of a message stream reliably associated with the Author Domain. Therefore, reputation assessment of that stream by the mail-receiving organization can assume the use of that Author Domain is authorized by the Domain Owner.
メッセージの DMARC パスは、そのメッセージに対する作成者ドメインの使用がドメイン所有者によって承認されたものとして検証されていることのみを示します。このような承認には、そのメッセージまたはドメイン所有者に関する明示的または暗黙的な値のアサーションが含まれていないため、DMARC パス自体は、受信者の受信箱への配信が安全であるか、望ましいかどうかを保証しません。DMARC に参加しているメール受信組織の場合、DMARC 検証に合格したメッセージは、作成者ドメインに確実に関連付けられたメッセージ ストリームの一部となります。したがって、メール受信組織によるそのストリームの評判評価では、その作成者ドメインの使用がドメイン所有者によって許可されていると想定できます。
On the other hand, a message that fails this validation is not necessarily associated with the Author Domain and so should not affect the Author Domain's reputation. The phrase "not necessarily associated" was purposely chosen here, as it is important to understand that some messages making authorized use of the Author Domain can still fail DMARC validation checks. [RFC7960] and Section 7 of this document both discuss reasons why such failures may happen. Because of this, a mail-receiving organization that performs DMARC validation can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so. DMARC is commonly used as one input to more complex filtering decisions, and so the mail-receiving organization might choose different actions entirely.
一方、この検証に失敗したメッセージは必ずしも作成者ドメインに関連付けられているわけではないため、作成者ドメインの評判に影響を与えることはありません。「必ずしも関連付けられているわけではない」という表現は、作成者ドメインを許可されて使用する一部のメッセージでも DMARC 検証チェックに失敗する可能性があることを理解することが重要であるため、ここでは意図的に選択されています。[RFC7960] とこの文書のセクション 7 は両方とも、そのような失敗が発生する理由について説明しています。このため、DMARC 検証を実行するメール受信組織は、ドメイン所有者が要求した検証失敗時のメッセージ処理を受け入れることを選択できますが、そうする必要はありません。DMARC は通常、より複雑なフィルタリング決定への 1 つの入力として使用されるため、メール受信組織はまったく異なるアクションを選択する可能性があります。
DMARC, in the associated documents [RFC9990] and [RFC9991], also specifies a reporting framework. Using it, a mail-receiving organization can generate regular reports about messages that use Author Domains for which a DMARC Policy Record exists; those reports are sent to the address(es) specified by the Domain Owner in the DMARC Policy Record. Domain Owners can use these reports, especially the aggregate reports, not only to identify sources of mail attempting to fraudulently use their domain but also (and perhaps more importantly) to flag and fix gaps in their own authentication practices. However, as with honoring the Domain Owner's stated mail handling preference, a mail-receiving organization supporting DMARC is under no obligation to send requested reports; although, it is recommended that they do send aggregate reports.
DMARC は、関連文書 [RFC9990] および [RFC9991] でレポート フレームワークも指定しています。これを使用すると、メール受信組織は、DMARC ポリシー レコードが存在する作成者ドメインを使用するメッセージに関する定期レポートを生成できます。これらのレポートは、DMARC ポリシー レコードでドメイン所有者によって指定されたアドレスに送信されます。ドメイン所有者は、これらのレポート、特に集計レポートを使用して、ドメインを不正に使用しようとするメールの送信元を特定するだけでなく、(おそらくさらに重要なことに) 独自の認証慣行のギャップにフラグを立てて修正することもできます。ただし、ドメイン所有者の指定されたメール処理設定を尊重する場合と同様、DMARC をサポートするメール受信組織には、要求されたレポートを送信する義務はありません。ただし、集計レポートを送信することをお勧めします。
The use of DMARC creates some interoperability challenges that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 7.
DMARC を使用すると、特にメールが拒否される可能性のある構成では、導入前に十分な検討が必要となる相互運用性の課題がいくつか生じます。これらについてはセクション 7 で説明します。
The following sections describe topics that guide the specification of DMARC.
次のセクションでは、DMARC の仕様をガイドするトピックについて説明します。
DMARC has the following high-level goals:
DMARC には次のような高レベルの目標があります。
* Allow Domain Owners (Section 3.2.7) and Public Suffix Operators (PSOs) (Section 3.2.16) to validate their email authentication deployments.
* ドメイン所有者 (セクション 3.2.7) とパブリック サフィックス オペレーター (PSO) (セクション 3.2.16) が電子メール認証の展開を検証できるようにします。
* Allow Domain Owners and PSOs to assert their desired message handling for validation failures on messages purporting to have authorship within the domain.
* ドメイン所有者と PSO が、ドメイン内に作成者があると称するメッセージの検証エラーに対する希望のメッセージ処理を主張できるようにします。
* Minimize implementation complexity for both senders and receivers.
* 送信者と受信者の両方の実装の複雑さを最小限に抑えます。
* Reduce the amount of successfully delivered spoofed emails.
* 正常に配信されるなりすましメールの量を減らします。
* Work at Internet scale.
* インターネット規模で作業します。
DMARC is designed to prevent the unauthorized use of the Author Domain (Section 3.2.2) of an email message, a technique known as "spoofing". Such unauthorized usage can frequently be found in messages impersonating a domain belonging to a business entity, i.e., messages that are meant to entice the recipient to provide sensitive information, such as usernames, passwords, and financial account information. These spoofed messages are commonly referred to as "phishing".
DMARC は、電子メール メッセージの作成者ドメイン (セクション 3.2.2) の不正使用 (「スプーフィング」として知られる手法) を防止するように設計されています。このような不正使用は、企業エンティティに属するドメインになりすましたメッセージ、つまり受信者にユーザー名、パスワード、金融口座情報などの機密情報を提供するよう誘導するメッセージで頻繁に見られます。これらのなりすましメッセージは一般に「フィッシング」と呼ばれます。
DMARC can only be used to combat specific forms of exact-domain spoofing directly. DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent emails. In particular, it does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name, as defined in Section 3.4 of [RFC5322].
DMARC は、特定の形式の完全ドメイン スプーフィングに直接対抗するためにのみ使用できます。DMARC は、なりすましメールや詐欺メールに関するすべての問題を解決しようとするわけではありません。特に、[RFC5322] のセクション 3.4 で定義されている、視覚的に類似したドメイン名の使用や、人間が判読できる RFC5322.From 表示名の悪用には対処しません。
Scalability is a significant issue for systems that need to operate in an environment 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 と連携してサービスを自由に提供できます。
Several topics and issues are specifically out of scope of this work. These include the following:
いくつかのトピックや問題は特にこの作業の範囲外です。これらには次のものが含まれます。
* Different treatment of messages that are not authenticated (e.g., those that have no DKIM signature or those sent using an Author Domain (Section 3.2.2) for which no DMARC Policy Record (Section 3.2.6) exists versus those that fail validation;
* 認証されていないメッセージ (DKIM 署名がないメッセージ、または DMARC ポリシー レコード (セクション 3.2.6) が存在しない作成者ドメイン (セクション 3.2.2) を使用して送信されたメッセージと、検証に失敗したメッセージの異なる処理。
* Evaluation of anything other than the RFC5322.From header field;
* RFC5322.From ヘッダー フィールド以外の評価。
* Multiple reporting formats;
* 複数のレポート形式。
* Publishing policy other than via the DNS;
* DNS 経由以外でポリシーを公開する。
* Reporting or otherwise evaluating other than the last-hop IP address;
* ラストホップ IP アドレス以外のレポートまたは評価。
* Attacks in the display name portions of the RFC5322.From header field, also known as "display name" attacks;
* RFC5322.From ヘッダー フィールドの表示名部分での攻撃。「表示名」攻撃とも呼ばれます。
* Authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and
* DMARC はドメインを認証する SPF および DKIM に基づいて構築されているため、ドメイン以外のエンティティの認証。そして
* Content analysis.
* コンテンツ分析。
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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Readers are encouraged to be familiar with the contents of [RFC5598]. 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 (Section 3.2.7) 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.
読者は、[RFC5598] の内容をよく理解することが推奨されます。特に、この文書では、メッセージング インフラストラクチャにおけるさまざまな役割が定義されており、これらの役割はさまざまなコンテキストで同じように見えたり、別々に見えたりする可能性があります。たとえば、ドメイン所有者 (セクション 3.2.7) は、DMARC の基礎となるメッセージング セキュリティ メカニズムを介して、ドメイン所有者としてメールを送信する機能を別の役割を持つサードパーティに委任できます。この文書では、そのような役割間の区別については説明しません。読者は、読み進める前にその内容に慣れることをお勧めします。
The following sections define the terms used in this document.
次のセクションでは、このドキュメントで使用される用語を定義します。
Authenticated Identifiers are those domain-level identifiers for which authorized use is validated using a supported authentication mechanism (Section 4.3).
認証済み識別子は、サポートされている認証メカニズム (セクション 4.3) を使用して許可された使用が検証されるドメインレベルの識別子です。
The Author Domain is the domain name of the apparent author as extracted from the RFC5322.From header field.
Author Domain は、RFC5322.From ヘッダー フィールドから抽出された、明らかな作成者のドメイン名です。
The DKIM Signing Domain is the domain name that is the value of the "d" tag in a validated DKIM-Signature header field in an email message.
DKIM 署名ドメインは、電子メール メッセージ内の検証された DKIM-Signature ヘッダー フィールドの「d」タグの値であるドメイン名です。
SPF [RFC7208] can validate the uses of both the domain found in an SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC relies solely on SPF validation of the MAIL FROM identity. Section 2.4 of [RFC7208] describes the determination of the MAIL FROM identity for cases in which the SMTP MAIL command has a null path, i.e., the mailbox composed of the local-part "postmaster" and the HELO identity.
SPF [RFC7208] は、SMTP [RFC5321] HELO/EHLO コマンドで見つかったドメイン (HELO アイデンティティ) と SMTP MAIL コマンドで見つかったドメイン (MAIL FROM アイデンティティ) の両方の使用を検証できます。DMARC は、MAIL FROM ID の SPF 検証のみに依存します。[RFC7208] のセクション 2.4 では、SMTP MAIL コマンドが null パス、つまりローカル部分の "postmaster" と HELO ID で構成されるメールボックスを持つ場合の MAIL FROM ID の決定について説明しています。
The term "SPF Domain" when used in this document refers to an SPF-validated MAIL FROM identity.
このドキュメントで使用される「SPF ドメイン」という用語は、SPF で検証された MAIL FROM ID を指します。
The DMARC Policy Domain is the domain name at which an applicable DMARC Policy Record (Section 3.2.6) is discovered for the Author Domain (Section 3.2.2) of an email message.
DMARC ポリシー ドメインは、電子メール メッセージの作成者ドメイン (セクション 3.2.2) に対して該当する DMARC ポリシー レコード (セクション 3.2.6) が検出されるドメイン名です。
A DMARC Policy Record is a DNS TXT record published by a Domain Owner (Section 3.2.7) or Public Suffix Operator (PSO) (Section 3.2.16) to enable validation of an Author Domain's (Section 3.2.2) use, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and optionally to request reports about the use of the Author Domain.
DMARC ポリシー レコードは、ドメイン所有者 (セクション 3.2.7) またはパブリック サフィックス オペレーター (PSO) (セクション 3.2.16) によって公開される DNS TXT レコードで、作成者ドメイン (セクション 3.2.2) の使用の検証を有効にし、失敗した検証に関するドメイン所有者または PSO のメッセージ処理設定を示し、オプションで作成者ドメインの使用に関するレポートを要求します。
A Domain Owner is an entity or organization that has control of a given DNS domain, usually by holding its registration. 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 (ADMD), as defined in [RFC5598]. It can also refer to delegates, such as Report Consumers, when those are outside of their immediate management domain.
ドメイン所有者は、通常、その登録を保持することによって、特定の DNS ドメインを制御するエンティティまたは組織です。ドメイン所有者は、グローバルに分散した複雑な組織から、技術系以外のクライアントに代わって業務を行うサービス プロバイダー、個人ドメインの保守を担当する個人まで多岐にわたります。この仕様では、この用語を [RFC5598] で定義されている管理管理ドメイン (ADMD) に類似したものとして使用します。また、レポート コンシューマなどのデリゲートが直接の管理ドメインの外にある場合は、そのデリゲートを指すこともあります。
The Domain Owner Assessment Policy is the message handling preference expressed in a DMARC Policy Record (Section 3.2.6) by the Domain Owner (Section 3.2.7) regarding failed validation of the Author Domain (Section 3.2.2). Possible values are described in Section 4.7.
ドメイン所有者評価ポリシーは、作成者ドメイン (セクション 3.2.2) の検証の失敗に関して、ドメイン所有者 (セクション 3.2.7) によって DMARC ポリシー レコード (セクション 3.2.6) で表現されるメッセージ処理の優先順位です。可能な値についてはセクション 4.7 で説明します。
Enforcement describes a state where the existing Domain Owner Assessment Policy (Section 3.2.8) for an Organizational Domain (Section 3.2.14) and all subdomains below it is not "p=none". This state means that the Organizational Domain and its subdomains can only be used as Author Domains (Section 3.2.2) if they are properly validated using the DMARC mechanism.
施行とは、組織ドメイン (セクション 3.2.14) およびその下のすべてのサブドメインに対する既存のドメイン所有者評価ポリシー (セクション 3.2.8) が「p=none」ではない状態を指します。この状態は、組織ドメインとそのサブドメインが、DMARC メカニズムを使用して適切に検証された場合にのみ、作成者ドメイン (セクション 3.2.2) として使用できることを意味します。
Historically, Domain Owner Assessment Policies of "p=quarantine" or "p=reject" have been higher value signals to Mail Receivers (Section 3.2.11). Messages with Author Domains for which such policies exist that are not validated using the DMARC mechanism will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference.
歴史的に、「p=quarantine」または「p=reject」のドメイン所有者評価ポリシーは、メール受信者にとってより価値の高いシグナルでした (セクション 3.2.11)。DMARC メカニズムを使用して検証されていないポリシーが存在する作成者ドメインを持つメッセージは、DMARC に参加し、ドメイン所有者の明示された処理設定を尊重するメール受信者の受信トレイに届きません。
DMARC describes the concept of alignment between the Author Domain (Section 3.2.2) and an Authenticated Identifier (Section 3.2.1) and requires such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC defines two states for alignment.
DMARC は、作成者ドメイン (セクション 3.2.2) と認証された識別子 (セクション 3.2.1) の間の調整の概念を説明しており、メッセージが DMARC パスを達成するには、このような 2 つの間の識別子の調整が必要です。DMARC は、アラインメントの 2 つの状態を定義します。
When the Author Domain (Section 3.2.2) has the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1), the two are said to be in relaxed alignment.
作成者ドメイン (セクション 3.2.2) が認証済み識別子 (セクション 3.2.1) と同じ組織ドメイン (セクション 3.2.14) を持っている場合、この 2 つは緩和された調整状態にあると言われます。
When the Author Domain (Section 3.2.2) is identical to an Authenticated Identifier (Section 3.2.1), the two are said to be in strict alignment.
作成者ドメイン (セクション 3.2.2) が認証された識別子 (セクション 3.2.1) と同一である場合、この 2 つは厳密に一致していると言われます。
The Mail Receiver is the entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Message Transfer Agents (MTAs).
メール受信者は、電子メールを受信して処理するエンティティまたは組織です。メール受信者は、インターネットに接続された 1 つ以上のメッセージ転送エージェント (MTA) を操作します。
Monitoring Mode describes a state where the existing Domain Owner Assessment Policy (Section 3.2.8) for an Organizational Domain (Section 3.2.14) and all subdomains below it is "p=none", and the Domain Owner (Section 3.2.7) is receiving aggregate reports for the Organizational Domain. While the use of the Organizational Domain and all its subdomains as Author Domains (Section 3.2.2) can still be validated by a Mail Receiver (Section 3.2.11) deploying the DMARC mechanism, the Domain Owner expresses no handling preference for messages that fail DMARC validation. However, the Domain Owner is using the content of the DMARC aggregate reports to make any needed adjustments to the authentication practices for its mail streams.
監視モードは、組織ドメイン (セクション 3.2.14) およびその下のすべてのサブドメインに対する既存のドメイン所有者評価ポリシー (セクション 3.2.8) が「p=none」であり、ドメイン所有者 (セクション 3.2.7) が組織ドメインの集計レポートを受信している状態を示します。組織ドメインとそのすべてのサブドメインを作成者ドメイン (セクション 3.2.2) として使用することは、DMARC メカニズムを導入するメール受信者 (セクション 3.2.11) によって引き続き検証できますが、ドメイン所有者は、DMARC 検証に失敗したメッセージに対する処理の優先順位を表明しません。ただし、ドメイン所有者は DMARC 集約レポートの内容を使用して、メール ストリームの認証方法に必要な調整を行っています。
For DMARC purposes, a non-existent domain is consistent with the term's meaning as described in [RFC8020]. That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist.
DMARC の目的では、存在しないドメインは [RFC8020] で説明されている用語の意味と一致します。つまり、ドメイン名のクエリに対して受信した応答コードが NXDOMAIN の場合、そのドメイン名と考えられるサブドメインは存在しません。
The Organizational Domain for any domain is akin to the ADMD described in [RFC5598]. A domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as the domain. An Organizational Domain is determined by applying the algorithm found in Section 4.10.
あらゆるドメインの組織ドメインは、[RFC5598] で説明されている ADMD に似ています。ドメインの組織ドメインは、そのドメインの名前空間階層の最上位にあり、ドメインと同じ管理権限を持ちます。組織ドメインは、セクション 4.10 にあるアルゴリズムを適用することによって決定されます。
Some domains allow the registration of subdomains that are "owned" by independent organizations. Real-world examples of these domains are ".com", ".org", ".us", and ".co.uk", to name just a few. These domains are called "Public Suffix Domains" (PSDs). For example, "ietf.org" is a registered domain name, and ".org" is its PSD.
一部のドメインでは、独立した組織が「所有」するサブドメインの登録が許可されています。これらのドメインの実例としては、ほんの数例を挙げると、「.com」、「.org」、「.us」、「.co.uk」などがあります。これらのドメインは「パブリック サフィックス ドメイン」(PSD) と呼ばれます。たとえば、「ietf.org」は登録されたドメイン名で、「.org」はその PSD です。
A PSO is an organization that manages operations within a PSD, particularly the DNS records published for names at and under that domain name.
PSO は、PSD 内の操作、特にそのドメイン名およびその下の名前に対して公開される DNS レコードを管理する組織です。
PSO-Controlled Domain Names are names in the DNS that are managed by a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com") or more (e.g., ".co.uk"), depending on the PSO's policy.
PSO 制御のドメイン名は、PSO によって管理される DNS 内の名前です。PSO 制御のドメイン名には、PSO のポリシーに応じて、1 つのラベル (例: 「.com」) または複数のラベル (例: 「.co.uk」) が付いている場合があります。
A Report Consumer is an operator that receives reports from another operator implementing the reporting mechanisms described in [RFC9990] and [RFC9991]. This term applies collectively to the system components that receive and process these reports and the organizations that operate those components.
レポートコンシューマは、[RFC9990] および [RFC9991] で説明されているレポートメカニズムを実装する別のオペレータからレポートを受信するオペレータです。この用語は、これらのレポートを受信して処理するシステム コンポーネントと、それらのコンポーネントを運用する組織に総称的に適用されます。
Report Consumers can receive reports concerning domains for which the Report Consumer is also the Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) or concerning domains that belong to another operator entirely. The DMARC mechanism permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to designate a third party to act as a Report Consumer. See Section 11.6 for further discussion of such designation.
レポート コンシューマは、レポート コンシューマがドメイン所有者 (セクション 3.2.7) または PSO (セクション 3.2.16) でもあるドメインに関するレポート、または完全に別のオペレータに属するドメインに関するレポートを受け取ることができます。DMARC メカニズムを使用すると、ドメイン所有者がそのドメインのレポート コンシューマとして機能したり、レポート コンシューマとして機能するサードパーティを指定したりすることができます。このような指定の詳細については、セクション 11.6 を参照してください。
This section provides a general overview of the design and operation of the DMARC environment.
このセクションでは、DMARC 環境の設計と運用の概要を説明します。
DMARC permits a Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) to enable validation of an Author Domain's (Section 3.2.2) use in an email message, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and to request reports about use of the Author Domain. A domain's DMARC Policy Record (Section 3.2.6) is published in the DNS as a TXT record at the name created by prepending the label "_dmarc" to the domain name and is retrieved through normal DNS queries.
DMARC では、ドメイン所有者 (セクション 3.2.7) または PSO (セクション 3.2.16) が、電子メール メッセージ内での作成者ドメイン (セクション 3.2.2) の使用の検証を有効にし、失敗した検証に関するドメイン所有者または PSO のメッセージ処理設定を示し、作成者ドメインの使用に関するレポートを要求することを許可します。ドメインの DMARC ポリシー レコード (セクション 3.2.6) は、ドメイン名の前にラベル「_dmarc」を付加して作成された名前の TXT レコードとして DNS に公開され、通常の DNS クエリを通じて取得されます。
DMARC's validation mechanism produces a "pass" result if a DMARC Policy Record exists for the Author Domain of an email message and the Author Domain is aligned (Section 3.2.10) with an Authenticated Identifier (Section 3.2.1) from that message. When a DMARC Policy Record exists for the Author Domain and the DMARC mechanism does not produce a "pass" result, the Mail Receiver's (Section 3.2.11) handling of that message can be influenced by the Domain Owner Assessment Policy (Section 3.2.8) expressed in the DMARC Policy Record.
電子メール メッセージの作成者ドメインに対して DMARC ポリシー レコードが存在し、作成者ドメインがそのメッセージの認証済み識別子 (セクション 3.2.1) と一致している場合 (セクション 3.2.10)、DMARC の検証メカニズムは「合格」結果を生成します。作成者ドメインの DMARC ポリシー レコードが存在し、DMARC メカニズムが「合格」結果を生成しない場合、メール受信者 (セクション 3.2.11) によるそのメッセージの処理は、DMARC ポリシー レコードで表現されているドメイン所有者評価ポリシー (セクション 3.2.8) の影響を受ける可能性があります。
It is important to note that the authentication mechanisms employed by DMARC only validate the usage of a DNS domain in an email message. They do not validate the local-part of any email address identifier found in that message, nor do such validations carry an explicit or implicit value assertion about that message or about the Domain Owner.
DMARC で採用されている認証メカニズムは、電子メール メッセージ内での DNS ドメインの使用のみを検証することに注意することが重要です。メッセージ内で見つかった電子メール アドレス識別子のローカル部分は検証されません。また、そのような検証では、そのメッセージまたはドメイン所有者に関する明示的または暗黙的な値の表明も行われません。
DMARC's reporting component involves the collection of information about received messages using the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [RFC9990].
DMARC のレポート コンポーネントには、ドメイン所有者または PSO への定期的な集約レポートのために、作成者ドメインを使用した受信メッセージに関する情報の収集が含まれます。このようなレポートのパラメータと形式については、[RFC9990] で説明されています。
A Mail Receiver participating in DMARC might also generate per-message failure reports that contain information related to individual messages that fail DMARC validation checks. Per-message failure reports are useful sources of information when debugging deployments (if messages can be determined to be legitimate despite failing validation) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [RFC6591] and [RFC9991].
DMARC に参加しているメール受信者は、DMARC 検証チェックに失敗した個々のメッセージに関連する情報を含むメッセージごとの失敗レポートを生成する場合もあります。メッセージごとの障害レポートは、展開をデバッグするとき (検証に失敗したにもかかわらずメッセージが正当であると判断できる場合)、または攻撃を分析するときに役立つ情報源です。このようなサービスの機能は DMARC によって有効になりますが、[RFC6591] や [RFC9991] などの他の参照資料で定義されています。
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. This field is the one used by end users to identify the source of the message, and so it has always been a prime target for abuse through such forgery and other means. That said, of all the identifiers that are part of the message itself, this is the only one required to be present. A message without a single, properly formed RFC5322.From header field does not comply with [RFC5322], and handling such a message is outside of the scope of this specification.
DMARC のセキュリティ精査の最も明白な点の 1 つは、電子メールの歴史を通じて簡単に偽造されてきたデータ本体の一部である、識別子、つまり RFC5322.From アドレスに焦点を当てるという選択です。このフィールドは、エンド ユーザーがメッセージの送信元を特定するために使用するフィールドであるため、常に偽造やその他の手段による悪用の主なターゲットとなってきました。とはいえ、メッセージ自体の一部であるすべての識別子の中で、存在する必要があるのはこれだけです。適切に形成された RFC5322.From ヘッダーフィールドが 1 つもないメッセージは [RFC5322] に準拠しておらず、そのようなメッセージの処理はこの仕様の範囲外です。
The following mechanisms for determining Authenticated Identifiers (Section 3.2.1) are supported in this version of DMARC:
認証された識別子を決定するための次のメカニズム (セクション 3.2.1) が、このバージョンの DMARC でサポートされています。
* DKIM [RFC6376]: The DKIM Signing Domain (Section 3.2.3) from a validated DKIM-Signature header field is an Authenticated Identifier.
* DKIM [RFC6376]: 検証された DKIM-Signature ヘッダーフィールドからの DKIM 署名ドメイン (セクション 3.2.3) は、認証された識別子です。
* SPF [RFC7208]: The validated SPF Domain (Section 3.2.4) from the email message is the Authenticated Identifier.
* SPF [RFC7208]: 電子メール メッセージからの検証された SPF ドメイン (セクション 3.2.4) が認証された識別子です。
DMARC validates the authorized use of the Author Domain (Section 3.2.2) by requiring either that it have the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1) (a condition known as "relaxed alignment" (Section 3.2.10.1)) or that it be identical to the Authenticated Identifier (a condition known as "strict alignment" (Section 3.2.10.2)). The choice of relaxed or strict alignment is left to the Domain Owner (Section 3.2.7) and is expressed in the domain's DMARC Policy Record (Section 3.2.6). In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs. Domain name comparisons in this context are case-insensitive, per [RFC4343].
DMARC は、認証された識別子 (セクション 3.2.1) と同じ組織ドメイン (セクション 3.2.14) を持つこと (「緩和アラインメント」 (セクション 3.2.10.1) として知られる条件)、または認証された識別子と同一であること (「厳密なアライメント」 (セクション 3.2.10.1 セクション) として知られる条件) のいずれかを要求することにより、作成者ドメイン (セクション 3.2.2) の許可された使用を検証します。3.2.10.2))。緩和されたアライメントまたは厳密なアライメントの選択はドメイン所有者に任され (セクション 3.2.7)、ドメインの DMARC ポリシー レコード (セクション 3.2.6) で表現されます。実際には、ほぼすべてのドメイン所有者が、ニーズを満たすのに十分な緩和された調整を行っています。[RFC4343] に従って、このコンテキストでのドメイン名の比較では大文字と小文字が区別されません。
The following table is meant to illustrate possible alignment conditions.
次の表は、考えられる位置合わせ条件を説明することを目的としています。
+==================+==================+=========================+
| Authenticated | Author Domain | Identifier Alignment |
| Identifier | | |
+==================+==================+=========================+
| foo.example.com | news.example.com | relaxed; the two have |
| | | the same Organizational |
| | | Domain, example.com |
+------------------+------------------+-------------------------+
| news.example.com | news.example.com | strict; the two are |
| | | identical |
+------------------+------------------+-------------------------+
| foo.example.net | news.example.com | none; the two do not |
| | | share a common |
| | | Organizational Domain |
+------------------+------------------+-------------------------+
Table 1: Alignment Examples
表 1: 配置の例
It is important to note that Identifier Alignment cannot occur with a message that is not valid per [RFC5322], particularly one with a malformed, absent, or repeated RFC5322.From header field, since in that case, there is no reliable way to determine a DMARC Policy Record (Section 3.2.6) that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid message object [RFC5322]. For non-compliant cases, handling is outside of the scope of this specification. Further discussion of this can be found in Section 11.5.
[RFC5322] に従って有効ではないメッセージ、特に RFC5322.From ヘッダー フィールドが不正、欠落、または繰り返されているメッセージでは識別子のアラインメントを実行できないことに注意することが重要です。その場合、メッセージに適用される DMARC ポリシー レコード (セクション 3.2.6) を決定する信頼できる方法がないからです。したがって、DMARC の動作は、入力が有効なメッセージ オブジェクトであることが前提となります [RFC5322]。非準拠の場合の取り扱いは本仕様の範囲外となります。これについてはセクション 11.5 でさらに説明します。
DKIM permits a Domain Owner to claim some responsibility for a message by associating the domain to the message. This association is done by inserting the domain as the value of the "d" tag in a DKIM-Signature header field, and the assertion of responsibility is validated through a cryptographic signature in the header field. If the cryptographic signature validates, then the DKIM Signing Domain is the DKIM-Authenticated Identifier.
DKIM を使用すると、ドメイン所有者は、ドメインをメッセージに関連付けることによって、メッセージに対する何らかの責任を主張することができます。この関連付けは、DKIM-Signature ヘッダー フィールドの「d」タグの値としてドメインを挿入することによって行われ、責任の表明はヘッダー フィールドの暗号署名によって検証されます。暗号署名が検証された場合、DKIM 署名ドメインは DKIM 認証された識別子になります。
There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party DKIM Signing Domains that are authorized to sign on behalf of a given Author Domain. Therefore, DMARC requires that Identifier Alignment is applied to the DKIM-Authenticated Identifier because a message can bear a valid signature from any domain, even one used by a bad actor. Only a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.
現在、ドメイン所有者が、特定の作成者ドメインに代わって署名することを許可されているサードパーティの DKIM 署名ドメインのリストをアサートできる、一般的に受け入れられているメカニズムはありません。したがって、DMARC では、識別子アライメントが DKIM 認証識別子に適用されることを要求します。これは、メッセージには、たとえ悪意のある者が使用したものであっても、任意のドメインからの有効な署名が含まれる可能性があるためです。作成者ドメインとの識別子の整合性を持つ DKIM 認証済みの識別子のみが、作成者ドメインの許可された使用を検証するのに十分です。
A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.
1 つの電子メールに複数の DKIM 署名を含めることができ、DKIM 認証された識別子が作成者ドメインと一致する場合、DMARC の「合格」結果が生成されると見なされます。
SPF can validate the uses of 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 relies solely on SPF validation of the MAIL FROM identity. If the use of the domain in the MAIL FROM identity is validated by SPF, then that domain is the SPF-Authenticated Identifier.
SPF は、SMTP HELO/EHLO コマンドで見つかったドメイン (HELO ID) と SMTP MAIL コマンドで見つかったドメイン (MAIL FROM ID) の両方の使用を検証できます。DMARC は、MAIL FROM ID の SPF 検証のみに依存します。MAIL FROM ID でのドメインの使用が SPF によって検証された場合、そのドメインは SPF 認証された識別子になります。
There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party domains that are authorized for use as the MAIL FROM identity for mail using a given Author Domain. Therefore, DMARC requires that Identifier Alignment is applied to the SPF-Authenticated Identifier because any Domain Owner, even a bad actor, can publish an SPF record for its domain and send an email that will obtain an SPF "pass" result. Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.
現在、ドメイン所有者が、特定の作成者ドメインを使用するメールの MAIL FROM ID として使用を許可されているサードパーティ ドメインのリストをアサートできる、一般的に受け入れられているメカニズムはありません。したがって、DMARC では、SPF 認証された識別子に識別子のアライメントを適用する必要があります。これは、ドメイン所有者は、たとえ悪意のある者であっても、そのドメインの SPF レコードを公開し、SPF の「合格」結果を取得する電子メールを送信できるためです。作成者ドメインと識別子が一致している SPF 認証済みの識別子のみが、作成者ドメインの許可された使用を検証するのに十分です。
In the future, if DMARC is extended to include the use of other authentication mechanisms, the extensions MUST allow for the assignment of a domain as an Authenticated Identifier so that alignment with the Author Domain can be validated.
将来、DMARC が他の認証メカニズムの使用を含むように拡張される場合、その拡張機能では、作成者ドメインとの整合性を検証できるように、認証された識別子としてドメインの割り当てを許可しなければなりません (MUST)。
A Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) advertises DMARC participation of one or more of its domains by publishing DMARC Policy Records (Section 3.2.6) that will apply to those domains. In doing so, Domain Owners and PSOs indicate their handling preference regarding failed validation for email messages using their domain in the RFC5322.From header field as well as their desire (if any) to receive feedback about such messages in the form of aggregate and/or failure reports.
ドメイン所有者 (セクション 3.2.7) または PSO (セクション 3.2.16) は、1 つ以上のドメインに適用される DMARC ポリシー レコード (セクション 3.2.6) を公開することによって、そのドメインの DMARC 参加を宣伝します。その際、ドメイン所有者と PSO は、RFC5322.From ヘッダー フィールドでドメインを使用した電子メール メッセージの検証に失敗した場合の処理設定と、そのようなメッセージに関するフィードバックを集計レポートや失敗レポートの形式で受け取りたい (ある場合) ことを示します。
DMARC Policy Records are stored as DNS TXT records with names starting with the label "_dmarc". For example, the Domain Owner of "example.com" would publish a DMARC Policy Record at the name "_dmarc.example.com", and a Mail Receiver (Section 3.2.11) wishing to find the DMARC Policy Record for mail with an Author Domain (Section 3.2.2) of "example.com" would issue a TXT query to the DNS for the name "_dmarc.example.com". A Domain Owner or PSO may choose not to participate in DMARC validation by Mail Receivers simply by not publishing a DMARC Policy Record for its Author Domain(s).
DMARC ポリシー レコードは、ラベル「_dmarc」で始まる名前を持つ DNS TXT レコードとして保存されます。たとえば、「example.com」のドメイン所有者は「_dmarc.example.com」という名前で DMARC ポリシー レコードを公開し、「example.com」の作成者ドメイン (セクション 3.2.2) を持つメールの DMARC ポリシー レコードを見つけたいメール受信者 (セクション 3.2.11) は、「_dmarc.example.com」という名前の TXT クエリを DNS に発行します。ドメイン所有者または PSO は、その作成者ドメインの DMARC ポリシー レコードを公開しないだけで、メール受信者による DMARC 検証に参加しないことを選択できます。
DMARC Policy Records can also apply to subdomains of the name at which they are published in the DNS if the record is published at an Organizational Domain (Section 3.2.14) for the subdomains. The Domain Owner Assessment Policy (Section 3.2.8) that applies to the subdomains can be identical to the Domain Owner Assessment Policy that applies to the Organizational Domain but it does not have to be identical. Whether or not it is identical depends on the presence or absence of certain values in the DMARC Policy Record. See Section 4.7 for more details.
DMARC ポリシー レコードは、レコードがサブドメインの組織ドメイン (セクション 3.2.14) で公開されている場合、DNS で公開されている名前のサブドメインにも適用できます。サブドメインに適用されるドメイン所有者評価ポリシー (セクション 3.2.8) は、組織ドメインに適用されるドメイン所有者評価ポリシーと同一であってもかまいませんが、同一である必要はありません。同一かどうかは、DMARC ポリシー レコード内の特定の値の有無によって決まります。詳細については、セクション 4.7 を参照してください。
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 domain name targeted by a DNS query, specifically an isolated TXT record that is restricted to the DMARC context. Using 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 によるドメイン名の使用と、DMARC が実行するクエリの性質によって決まります。クエリ要件は、単純なパラメータ情報を取得するために DNS と一致します。これは、DNS クエリの対象となるドメイン名に関連付けられた情報、具体的には DMARC コンテキストに制限された分離された TXT レコードを保存する確立された方法を使用します。DNS をクエリ サービスとして使用すると、新しいインフラストラクチャを作成するのではなく、非常に確立された運用、管理、および管理インフラストラクチャを再利用できるという利点があります。
Per [RFC1035], a TXT record can comprise multiple "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.
[RFC1035] によれば、TXT レコードは複数の「文字列」オブジェクトで構成できます。この場合、DMARC 評価を実行するモジュールは、オブジェクトを順番に結合し、結果を単一の文字列として解析することによって、これらの文字列を連結しなければなりません (MUST)。
A Domain Owner can choose not to have some underlying authentication mechanisms apply to DMARC evaluation of its Author Domain(s). For example, if a Domain Owner only wants to use DKIM as the underlying authentication mechanism, then the Domain Owner does not publish an SPF record that can produce Identifier Alignment between an SPF-Authenticated Identifier and the Author Domain. Alternatively, if the Domain Owner wishes to rely solely on SPF, then it can send email messages that have no DKIM-Signature header field that would produce Identifier Alignment between a DKIM-Authenticated Identifier and the Author Domain. However, it is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC.
ドメイン所有者は、その作成者ドメインの DMARC 評価に一部の基礎となる認証メカニズムを適用しないことを選択できます。たとえば、ドメイン所有者が基盤となる認証メカニズムとして DKIM のみを使用したい場合、ドメイン所有者は、SPF 認証された識別子と作成者ドメインの間の識別子の位置合わせを生成できる SPF レコードを公開しません。あるいは、ドメイン所有者が SPF のみに依存したい場合は、DKIM 認証された識別子と作成者ドメインの間の識別子調整を生成する DKIM-Signature ヘッダー フィールドを持たない電子メール メッセージを送信できます。ただし、ドメイン所有者は DMARC の基礎となる認証メカニズムとして DKIM と SPF の両方を使用することが推奨されます。
A Mail Receiver implementing the DMARC mechanism gets the Domain Owner's or PSO's published Domain Owner Assessment Policy and can use it to inform its handling decisions for messages that undergo DMARC validation checks and do not produce a result of "pass". Mail handling considerations based on Domain Owner Assessment Policy enforcement are discussed below in Section 5.4.
DMARC メカニズムを実装するメール受信者は、ドメイン所有者または PSO の公開されたドメイン所有者評価ポリシーを取得し、それを使用して、DMARC 検証チェックを受けて「合格」の結果が得られなかったメッセージの処理決定を通知できます。ドメイン所有者評価ポリシーの適用に基づくメール処理の考慮事項については、以下のセクション 5.4 で説明します。
[RFC3986] defines a syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) specifies the destination(s) for the two report types that are supported.
[RFC3986] はリソースを識別するための構文を定義しています。DMARC メカニズムは、ドメイン所有者 (セクション 3.2.7) または PSO (セクション 3.2.16) がサポートされている 2 つのレポート タイプの宛先を指定する形式としてこれを使用します。
The DMARC Policy Record format (Section 4.7) allows for a list of these URIs to be provided, with each URI separated by commas (ASCII 0x2c). A report SHOULD be sent to each listed URI provided in the DMARC Policy Record.
DMARC ポリシー レコード形式 (セクション 4.7) では、各 URI をカンマ (ASCII 0x2c) で区切って、これらの URI のリストを提供できます。レポートは、DMARC ポリシー レコードで提供されるリストされた各 URI に送信されるべきです (SHOULD)。
A formal definition is provided in Section 4.8.
正式な定義はセクション 4.8 に記載されています。
DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].
DMARC ポリシー レコードは、DKIM [RFC6376] で定義されている DNS ベースのキー レコードの拡張可能な「タグ値」構文に従います。
Section 9 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in that registry are to be processed; unknown tags MUST be ignored.
セクション 9 では、既知の DMARC タグのレジストリを作成し、この文書で定義されている初期セットを登録します。そのレジストリで定義されたタグのみが処理されます。不明なタグは無視しなければなりません(MUST)。
The following tags are valid DMARC tags:
次のタグは有効な DMARC タグです。
adkim:
アドキム:
(plain-text; OPTIONAL; default is "r".) Indicates whether the Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) requires strict or relaxed DKIM Identifier Alignment mode. See Section 4.4.1 for details. Valid values are as follows:
(平文; オプション; デフォルトは「r」です。) ドメイン所有者 (セクション 3.2.7) または PSO (セクション 3.2.16) が厳密な DKIM 識別子アライメント モードを必要とするか、緩和した DKIM 識別子アライメント モードを必要とするかを示します。詳細については、セクション 4.4.1 を参照してください。有効な値は次のとおりです。
r:
r:
relaxed mode
リラックスモード
s:
s:
strict mode
厳密モード
aspf:
aspf:
(plain-text; OPTIONAL; default is "r".) Indicates whether the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment mode. See Section 4.4.2 for details. Valid values are as follows:
(プレーンテキスト; オプション; デフォルトは「r」です。) ドメイン所有者または PSO が厳密な SPF 識別子アライメント モードを必要とするか、または緩和した SPF 識別子アライメント モードを必要とするかを示します。詳細については、セクション 4.4.2 を参照してください。有効な値は次のとおりです。
r:
r:
relaxed mode
リラックスモード
s:
s:
strict mode
厳密モード
fo:
fo:
Failure reporting options (plain-text; OPTIONAL; default is "0"). Provides requested options for the 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. This tag can include one or more of the values shown here, with the exception that "0" and "1" are mutually exclusive. If more than one value is assigned to the tag, the list of values should be separated by colons (e.g., fo=0:d), and the values may appear in the list in any order. Valid values and their meanings are as follows:
失敗レポートのオプション (プレーンテキスト、オプション、デフォルトは「0」)。障害レポートを生成するために要求されたオプションを提供します。レポート作成者は、要求されたオプションに従うことを選択できます。"ruf" タグ (下記) も指定されていない場合、このタグの内容は無視されなければなりません (MUST)。このタグには、ここに示す値を 1 つ以上含めることができます。ただし、「0」と「1」は相互に排他的です。タグに複数の値が割り当てられている場合、値のリストはコロンで区切る必要があり (例: fo=0:d)、値は任意の順序でリストに表示できます。有効な値とその意味は次のとおりです。
0:
0:
Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.
すべての基礎となる認証メカニズムが整合した「合格」結果を生成できない場合は、DMARC 失敗レポートを生成します。
1:
1:
Generate a DMARC failure report if any underlying authentication mechanism fails to produce an aligned "pass" result.
基礎となる認証メカニズムが整合した「合格」結果を生成できない場合は、DMARC 失敗レポートを生成します。
d:
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 [RFC6651].
メッセージに評価に失敗した署名が含まれている場合は、そのアライメントに関係なく、DKIM 失敗レポートを生成します。DKIM 固有のレポートは [RFC6651] で説明されています。
s:
s:
Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [RFC6652].
メッセージが SPF 評価に失敗した場合は、その配置に関係なく SPF 失敗レポートを生成します。SPF 固有のレポートは [RFC6652] で説明されています。
np:
np:
Domain Owner Assessment Policy (Section 3.2.8) for non-existent subdomains of the given Organizational Domain (plain-text; OPTIONAL). For this tag, the definition of "non-existent subdomain" is the same as that used for "non-existent domains" in Section 3.2.13. The policy expressed by this tag indicates the message handling preference of the Domain Owner or PSO for mail using non-existent subdomains of the prevailing Organizational Domain and not passing DMARC validation. It applies only to non-existent subdomains of the Organizational Domain queried and not to either existing subdomains or the domain itself. Its syntax is identical to that of the "p" tag defined below. If the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains.
指定された組織ドメインの存在しないサブドメインに対するドメイン所有者評価ポリシー (セクション 3.2.8) (平文、オプション)。このタグの「存在しないサブドメイン」の定義は、セクション 3.2.13 の「存在しないドメイン」に使用される定義と同じです。このタグで表現されるポリシーは、一般的な組織ドメインの存在しないサブドメインを使用し、DMARC 検証に合格しないメールに対するドメイン所有者または PSO のメッセージ処理設定を示します。これは、クエリされた組織ドメインの存在しないサブドメインにのみ適用され、既存のサブドメインやドメイン自体には適用されません。その構文は、以下で定義されている「p」タグの構文と同じです。「np」タグが存在しない場合、「sp」タグで指定されたポリシー (「sp」タグが存在する場合) または「p」タグで指定されたポリシー (「sp」タグが存在しない場合) が、存在しないサブドメインに適用されなければなりません (MUST)。
p:
p:
Domain Owner Assessment Policy (Section 3.2.8) (plain-text; RECOMMENDED for DMARC Policy Records). Indicates the message handling preference of the Domain Owner or PSO for mail using its domain but not passing DMARC validation. The policy applies to the domain queried and to subdomains, unless the subdomain policy is explicitly described using the "sp" or "np" tags. If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none" (see Section 4.10.1). This tag is not applicable for third-party reporting records (see [RFC9990] and [RFC9991]). Possible values are as follows:
ドメイン所有者評価ポリシー (セクション 3.2.8) (平文; DMARC ポリシー レコードに推奨)。ドメインを使用しているが DMARC 検証に合格していないメールに対する、ドメイン所有者または PSO のメッセージ処理設定を示します。「sp」または「np」タグを使用してサブドメイン ポリシーが明示的に記述されていない限り、ポリシーはクエリされたドメインとサブドメインに適用されます。このタグが構文的に有効な DMARC ポリシー レコードに存在しない場合、そのレコードは「p=none」が含まれているかのように扱われます (セクション 4.10.1 を参照)。このタグは、サードパーティのレポート記録には適用されません ([RFC9990] および [RFC9991] を参照)。可能な値は次のとおりです。
none:
なし：
The Domain Owner offers no expression of preference.
ドメイン所有者は、優先順位を表明しません。
quarantine:
検疫：
The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.
ドメイン所有者は、そのようなメールを不審なものと見なします。メールが有効である可能性もありますが、失敗すると重大な懸念が生じます。
reject:
拒否する：
The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid. See Section 7.2 for some discussion of SMTP rejection methods and their implications.
ドメイン所有者は、そのような失敗はすべて、ドメイン名の使用が無効であることを明確に示しているとみなします。SMTP 拒否方法とその影響については、セクション 7.2 を参照してください。
psd:
psd:
A flag indicating whether the domain is a PSD (plain-text; OPTIONAL; default is "u"). Possible values are as follows:
ドメインが PSD であるかどうかを示すフラグ (プレーンテキスト、オプション、デフォルトは「u」)。可能な値は次のとおりです。
y:
y:
PSOs include this tag with a value of "y" to indicate that the domain is a PSD. If a record containing this tag with a value of "y" is found during policy discovery, this information will be used to determine the Organizational Domain and DMARC Policy Domain applicable to the message in question.
PSO には、ドメインが PSD であることを示すために、値「y」を持つこのタグが含まれています。値が「y」のこのタグを含むレコードがポリシー検出中に見つかった場合、この情報は、問題のメッセージに適用される組織ドメインと DMARC ポリシー ドメインを決定するために使用されます。
n:
n:
The DMARC Policy Record is published for a domain that is not a PSD, but it is the Organizational Domain for itself and its subdomains.
DMARC ポリシー レコードは、PSD ではないドメインに対して公開されますが、それ自体とそのサブドメインの組織ドメインです。
u:
u:
The default indicates that the DMARC Policy Record is published for a domain that is not a PSD and may or may not be an Organizational Domain for itself and its subdomains. Use the mechanism described in Section 4.10 for determining the Organizational Domain for this domain.
デフォルトは、DMARC ポリシー レコードが PSD ではないドメインに対して公開され、それ自体とそのサブドメインの組織ドメインである場合とそうでない場合があることを示します。このドメインの組織ドメインを決定するには、セクション 4.10 で説明されているメカニズムを使用します。
rua:
rua:
Addresses to which aggregate feedback reports are to be sent (comma-separated plain-text list of DMARC Reporting URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send aggregate feedback reports as defined in [RFC9990] to the URIs listed. Any valid URI can be specified. A Mail Receiver that sends aggregate feedback reports MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. URIs involving schemes not supported by Mail Receivers MUST be ignored. [RFC9990] also discusses considerations that apply when the domain name of a URI differs from the domain publishing the DMARC Policy Record. See Section 11.6 for additional considerations.
集約フィードバック レポートの送信先アドレス (DMARC レポート URI のカンマ区切りのプレーンテキスト リスト、オプション)。存在する場合、ドメイン所有者はメール受信者に対し、[RFC9990] で定義されている集計フィードバック レポートをリストされた URI に送信するよう要求します。任意の有効な URI を指定できます。集約フィードバックレポートを送信するメール受信者は、「mailto:」URI のサポート、つまり電子メール経由で DMARC レポートを送信する機能を実装しなければなりません (MUST)。タグが指定されていない場合、メール受信者はドメインの集計フィードバック レポートを生成してはなりません。メール受信者によってサポートされていないスキームを含む URI は無視されなければなりません (MUST)。[RFC9990] では、URI のドメイン名が DMARC ポリシー レコードを公開するドメインと異なる場合に適用される考慮事項についても説明しています。その他の考慮事項については、セクション 11.6 を参照してください。
ruf:
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) to the URIs listed. Depending on the value of the "fo" tag, the format for such reports is described in [RFC9991], [RFC6651], and [RFC6652]. Any valid URI can be specified. A Mail Receiver sending failure reports MUST implement support for a "mailto:" URI, i.e., the ability to send message-specific failure information via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate failure reports for the domain. URIs involving schemes not supported by Mail Receivers MUST be ignored. [RFC9990] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 11.6 for additional considerations.
メッセージ固有の障害情報が報告されるアドレス (DMARC URI のカンマ区切りのプレーンテキストのリスト、オプション)。ドメイン所有者が存在する場合、ドメイン所有者は、特定の方法 (上記の「fo」タグを参照) で DMARC 評価に失敗したメッセージに関する詳細な失敗レポートをリストされた URI に送信するようにメール受信者に要求します。"fo" タグの値に応じて、そのようなレポートの形式は [RFC9991]、[RFC6651]、および [RFC6652] で説明されています。任意の有効な URI を指定できます。失敗レポートを送信するメール受信者は、「mailto:」URI のサポート、つまり電子メール経由でメッセージ固有の失敗情報を送信する機能を実装しなければなりません (MUST)。タグが指定されていない場合、メール受信者はドメインの失敗レポートを生成してはなりません。メール受信者によってサポートされていないスキームを含む URI は無視されなければなりません (MUST)。[RFC9990] では、URI のドメイン名がポリシーを宣伝するドメイン名と異なる場合に適用される考慮事項について説明しています。その他の考慮事項については、セクション 11.6 を参照してください。
sp:
sp:
Domain Owner Assessment Policy for all subdomains of the given Organizational Domain (plain-text; OPTIONAL). Indicates the message handling preference of the Domain Owner or PSO for mail using an existing subdomain of the prevailing Organizational Domain and not passing DMARC validation. It applies only to existing subdomains of the message's Organizational Domain in the DNS hierarchy and not to the Organizational Domain itself. Its syntax is identical to that of the "p" tag defined above. If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC Policy Records published on subdomains of Organizational Domains and PSDs due to the effect of the DMARC policy discovery (Section 4.10.1).
指定された組織ドメインのすべてのサブドメインのドメイン所有者評価ポリシー (プレーンテキスト、オプション)。一般的な組織ドメインの既存のサブドメインを使用し、DMARC 検証に合格しないメールに対するドメイン所有者または PSO のメッセージ処理設定を示します。これは、DNS 階層内のメッセージの組織ドメインの既存のサブドメインにのみ適用され、組織ドメイン自体には適用されません。その構文は、上で定義した「p」タグの構文と同じです。「sp」タグが存在せず、「np」タグが存在しないか適用できない場合、「p」タグで指定されたポリシーをサブドメインに適用しなければなりません。DMARC ポリシー検出 (セクション 4.10.1) の影響により、組織ドメインおよび PSD のサブドメインで公開された DMARC ポリシー レコードでは、「sp」が無視されることに注意してください。
t:
t:
DMARC policy test mode (plain-text; OPTIONAL; default is "n"). For the Author Domain to which the DMARC Policy Record applies, the "t" tag serves as a signal to the actor performing DMARC validation checks as to whether or not the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p", "sp", and/or "np" tags to actually be applied. This tag does not affect the generation of DMARC reports, and it has no effect on any policy ("p", "sp", or "np") that is "none". See Appendix A.6 for further discussion of the use of this tag. Possible values are as follows:
DMARC ポリシー テスト モード (プレーンテキスト、オプション、デフォルトは「n」)。DMARC ポリシー レコードが適用される作成者ドメインの場合、「t」タグは、ドメイン所有者が「p」、「sp」、および/または「np」タグで宣言されたドメイン所有者評価ポリシーを実際に適用することを望んでいるかどうかに関して、DMARC 検証チェックを実行するアクターへのシグナルとして機能します。このタグは DMARC レポートの生成には影響しません。また、「none」のポリシー (「p」、「sp」、または「np」) にも影響しません。このタグの使用の詳細については、付録 A.6 を参照してください。可能な値は次のとおりです。
y:
y:
A request that the actor performing the DMARC validation check not apply the policy, but instead apply any special handling rules it might have in place, such as rewriting the RFC5322.From header field (see Appendix A.6). The Domain Owner is currently testing its specified DMARC assessment policy and has an expectation that the policy applied to any failing messages will be one level below the specified policy. That is, if the policy is "quarantine" and the value of the "t" tag is "y", a policy of "none" will be applied to failing messages; if the policy is "reject" and the value of the "t" tag is "y", a policy of "quarantine" will be applied to failing messages, irrespective of any other special handling rules that might be triggered by the "t" tag having a value of "y".
DMARC 検証チェックを実行するアクターがポリシーを適用するのではなく、代わりに RFC5322.From ヘッダー フィールドの書き換えなどの特別な処理ルールを適用するというリクエスト (付録 A.6 を参照)。ドメイン所有者は現在、指定された DMARC 評価ポリシーをテストしており、失敗したメッセージに適用されるポリシーは、指定されたポリシーより 1 レベル下になると予想しています。つまり、ポリシーが「quarantine」で、「t」タグの値が「y」の場合、失敗したメッセージにはポリシー「none」が適用されます。ポリシーが「reject」で、「t」タグの値が「y」の場合、「y」の値を持つ「t」タグによってトリガーされる可能性のある他の特別な処理ルールに関係なく、「quarantine」のポリシーが失敗したメッセージに適用されます。
n:
n:
The default is a request to apply the Domain Owner Assessment Policy as specified to any message that produces a DMARC "fail" result.
デフォルトは、DMARC「失敗」結果を生成するメッセージに対して、指定されたドメイン所有者評価ポリシーを適用する要求です。
v:
v:
Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC Policy Record. This tag MUST be the first tag in the list. The tag value is case sensitive, and the only possible value is "DMARC1". If the tag is not the first in the list, the tag is absent, or the value is not "DMARC1", then the entire record MUST be ignored.
バージョン (プレーンテキスト; 必須)。DMARC ポリシー レコードとして取得されたレコードを識別します。このタグはリストの最初のタグでなければなりません。タグ値では大文字と小文字が区別され、使用可能な値は「DMARC1」のみです。タグがリストの最初でない場合、タグが存在しない場合、または値が「DMARC1」でない場合は、レコード全体を無視しなければなりません(MUST)。
A DMARC Policy Record MUST comply with the formal definition found in this section. Unknown tags MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright.
DMARC ポリシー レコードは、このセクションにある正式な定義に準拠しなければなりません (MUST)。不明なタグは無視しなければなりません(MUST)。レコードの残りの部分にある構文エラーは、デフォルト値 (存在する場合) を優先して破棄するか、完全に無視しなければなりません (MUST)。
Because unknown tags MUST be ignored, the 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 Policy Record format, using ABNF syntax as described in [RFC5234] and [RFC7405], is as follows:
[RFC5234] および [RFC7405] で説明されている ABNF 構文を使用した DMARC ポリシー レコード フォーマットの正式な定義は次のとおりです。
dmarc-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation
; points (ASCII 0x21) MUST be
; encoded
obs-dmarc-uri = dmarc-uri obs-dmarc-report-size
; Obsolete syntax, reporters should ignore the
; obs-dmarc-report-size if it is found in a
; DMARC Policy Record.
obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]
dmarc-sep = *WSP ";" *WSP
equals = *WSP "=" *WSP
dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]
dmarc-tag = 1*ALPHA equals 1*dmarc-value
; any printing characters but semicolon
dmarc-value = %x20-3A / %x3C-7E
dmarc-version = "v" equals %s"DMARC1" ; case sensitive
; specialized syntax of DMARC values
dmarc-request = "none" / "quarantine" / "reject"
dmarc-yorn = "y" / "n"
dmarc-psd = "y" / "n" / "u"
dmarc-rors = "r" / "s"
dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
*(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri))
dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
/ *(dmarc-afrf ":") ("0" / "1")
dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-fo
In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name. The ABNF rule for each dmarc-value is specified in the following table:
各 dmarc-tag では、dmarc-value の構文はタグ名に依存します。各 dmarc-value の ABNF ルールを次の表に指定します。
+==========+===============+
| Tag Name | Value Rule |
+==========+===============+
| p | dmarc-request |
+----------+---------------+
| t | dmarc-yorn |
+----------+---------------+
| psd | dmarc-psd |
+----------+---------------+
| np | dmarc-request |
+----------+---------------+
| sp | dmarc-request |
+----------+---------------+
| adkim | dmarc-rors |
+----------+---------------+
| aspf | dmarc-rors |
+----------+---------------+
| rua | dmarc-urilist |
+----------+---------------+
| ruf | dmarc-urilist |
+----------+---------------+
| fo | dmarc-fo |
+----------+---------------+
Table 2: Tag Names and Values
表 2: タグ名と値
+---------------+ +--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+
| . ^
V V .
+-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+
| Service | | Signer | | Validator|<***>| SPF |
+-----------+ +--------+ +----------+ * | Validator|
| ^ * +----------+
| * *
V v *
+------+ (~~~~~~~~~~~~) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **>| DKIM |
+------+ (~~~~~~~~~~~~) +------+ | Validator|
| +----------+
| ^
V .
+-----------+ .
+---------+ | MDA | v
| User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing |
| Domain(s) |
+-----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
sMTA = sending MTA
rMTA = receiving MTA
The above diagram shows a typical flow of messages through a DMARC-aware system. Dashed lines (e.g., -->) denote the actual message flow, dotted lines (e.g., < . . >) represent DNS queries used to retrieve message policy related to the supported message authentication schemes, and starred lines (e.g., <**>) indicate data exchange between message-handling modules and message authentication modules.
上の図は、DMARC 対応システムを通るメッセージの一般的なフローを示しています。破線 (例: -->) は実際のメッセージ フローを示し、点線 (例: < . . >) はサポートされているメッセージ認証スキームに関連するメッセージ ポリシーを取得するために使用される DNS クエリを表し、星線 (例: <**>) はメッセージ処理モジュールとメッセージ認証モジュール間のデータ交換を示します。
Put simply, when a message reaches a DMARC-aware rMTA, a DNS query will be initiated to determine if a DMARC Policy Record exists that applies to the Author Domain. If a DMARC Policy Record is found, the rMTA will use the results of SPF and DKIM validation checks to determine the DMARC validation status. The DMARC validation status can then factor into the message handling decision made by the recipient's mail system.
簡単に言えば、メッセージが DMARC 対応 rMTA に到達すると、DNS クエリが開始され、作成者ドメインに適用される DMARC ポリシー レコードが存在するかどうかが判断されます。DMARC ポリシー レコードが見つかった場合、rMTA は SPF および DKIM 検証チェックの結果を使用して DMARC 検証ステータスを判断します。DMARC 検証ステータスは、受信者のメール システムによるメッセージ処理の決定に反映されます。
More details on specific actions for the parties involved can be found in Sections 5.1 and 5.3.
関係者に対する具体的な行動の詳細については、セクション 5.1 および 5.3 を参照してください。
An Organizational Domain (Section 3.2.14) serves two different purposes, depending on the context:
組織ドメイン (セクション 3.2.14) は、コンテキストに応じて 2 つの異なる目的を果たします。
* The Organizational Domain of the Author Domain (Section 3.2.2) establishes the DMARC Policy Record (Section 3.2.6) for that domain when no DMARC Policy Record is published specifically for the Author Domain (see Section 4.10.1).
* 作成者ドメイン (セクション 3.2.2 を参照) に対して DMARC ポリシー レコードが特に公開されていない場合、作成者ドメインの組織ドメイン (セクション 3.2.2) は、そのドメインの DMARC ポリシー レコード (セクション 3.2.6) を確立します (セクション 4.10.1 を参照)。
* The Organizational Domains of an Authenticated Identifier (Section 3.2.1) and the Author Domain are used in determining Identifier Alignment between the two (see Section 4.10.2).
* 認証された識別子の組織ドメイン (セクション 3.2.1) と作成者ドメインは、この 2 つの間の識別子の整合性を決定する際に使用されます (セクション 4.10.2 を参照)。
[RFC7489] defined an Organizational Domain as "The domain that was registered with a domain name registrar". [RFC7489] discussed using a Public Suffix List (PSL) as the authoritative list of the parent domains for Organizational Domains and further described a method for determining the Organizational Domain of an Author Domain or an Authenticated Identifier. However, [RFC7489] mandated no requirement for a specific PSL for Mail Receivers to use (though it did suggest the one found at <https://publicsuffix.org/>) nor did it provide any guidance for the frequency of regular retrieval of the PSL by Mail Receivers participating in DMARC. [RFC7489] acknowledged the possibility of interoperability issues caused by Mail Receivers choosing different PSLs and even suggested that if a more reliable and secure method for determining the Organizational Domain could be created, that method should replace reliance on a PSL.
[RFC7489] は、組織ドメインを「ドメイン名レジストラに登録されたドメイン」と定義しました。[RFC7489] は、組織ドメインの親ドメインの権威リストとしてパブリックサフィックスリスト (PSL) を使用することについて議論し、さらに、作成者ドメインの組織ドメインまたは認証された識別子を決定する方法について説明しました。しかし、[RFC7489] は、メール受信者が使用する特定の PSL に対する要件を義務付けておらず (ただし、<https://publicsuffix.org/> にある PSL を推奨していました)、DMARC に参加しているメール受信者による PSL の定期的な取得の頻度に関するガイダンスも提供していませんでした。[RFC7489] は、メール受信者が異なる PSL を選択することによって相互運用性の問題が発生する可能性を認め、組織ドメインを決定するためのより信頼性が高く安全な方法が作成できるのであれば、その方法が PSL への依存に代わるべきであるとさえ示唆しました。
This update to DMARC offers more flexibility to Domain Owners, especially those with large, complex organizations that might want to apply decentralized management to their DNS and their DMARC Policy Records. Rather than just using a PSL to help identify an Organizational Domain, this update defines a discovery technique known colloquially as the "DNS Tree Walk". The target of any DNS Tree Walk is discovery of a valid DMARC Policy Record, and its use in determining an Organizational Domain allows for publishing DMARC Policy Records at multiple points in the namespace.
DMARC のこのアップデートにより、ドメイン所有者、特に DNS と DMARC ポリシー レコードに分散管理を適用したいと考えている大規模で複雑な組織を持つドメイン所有者に、より高い柔軟性が提供されます。このアップデートでは、単に PSL を使用して組織ドメインの識別を支援するのではなく、口語的に「DNS ツリー ウォーク」として知られる検出手法を定義しています。DNS ツリー ウォークの目標は有効な DMARC ポリシー レコードの検出であり、組織ドメインの決定にこれを使用することで、名前空間内の複数のポイントで DMARC ポリシー レコードを発行できます。
However, this flexibility comes at a possible cost. Since the DNS Tree Walk relies on the Mail Receiver making a series of DNS queries, the potential exists for an ill-intentioned Domain Owner to send mail with Author Domains with tens or even hundreds of labels for the purpose of executing a denial-of-service attack on the Mail Receiver. To guard against such abuse of the DNS, a shortcut is built into the process so that Author Domains with more than eight labels do not result in more than eight DNS queries. Observed data at the time of publication showed that Author Domains with up to seven labels were in usage, and so eight was chosen as the query limit to allow for some future expansion of the namespace that did not require updating this document.
ただし、この柔軟性にはコストがかかる可能性があります。DNS ツリー ウォークは、一連の DNS クエリを実行するメール受信者に依存しているため、悪意のあるドメイン所有者が、メール受信者に対してサービス拒否攻撃を実行する目的で、数十、さらには数百のラベルが付いた作成者ドメインでメールを送信する可能性があります。このような DNS の悪用を防ぐために、8 つを超えるラベルを持つ作成者ドメインによって 8 つを超える DNS クエリが発生しないように、プロセスにショートカットが組み込まれています。出版時に観察されたデータでは、最大 7 つのラベルを持つ作成者ドメインが使用されていることが示されていたため、このドキュメントの更新を必要としない将来の名前空間の拡張を考慮して、クエリ制限として 8 が選択されました。
The generic steps for a DNS Tree Walk are as follows:
DNS ツリー ウォークの一般的な手順は次のとおりです。
1. Query the DNS for a TXT record that matches the format of a DMARC Policy Record at the starting point for the Tree Walk. The starting point for the DNS Tree Walk will depend on the ultimate target of the DNS Tree Walk. Sections 4.10.1 and 4.10.2 describe the possible starting points. A possibly empty set of records is returned.
1. ツリー ウォークの開始点で DMARC ポリシー レコードの形式と一致する TXT レコードを DNS にクエリします。DNS ツリー ウォークの開始点は、DNS ツリー ウォークの最終ターゲットによって異なります。セクション 4.10.1 および 4.10.2 では、考えられる開始点について説明します。空の可能性があるレコードのセットが返されます。
2. Records that do not start with a "v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a "psd=n" or "psd=y" tag, stop.
2. DMARC の現在のバージョンを識別する「v」タグで始まらないレコードは破棄されます。単一のターゲットに対して複数の DMARC ポリシー レコードが返された場合、それらはすべて破棄されます。レコードが 1 つ残っており、そのレコードに「psd=n」または「psd=y」タグが含まれている場合は停止します。
3. Break the subject DNS domain name into a set of ordered labels. Assign the count of labels to "x", and number the labels from right to left, e.g., for "a.mail.example.com", "x" would be assigned the value 4, "com" would be label 1, "example" would be label 2, "mail" would be label 3, and so forth.
3. 対象の DNS ドメイン名を順序付けされた一連のラベルに分割します。ラベルの数を「x」に割り当て、ラベルに右から左に番号を付けます。たとえば、「a.mail.example.com」の場合、「x」には値 4 が割り当てられ、「com」はラベル 1、「example」はラベル 2、「mail」はラベル 3 になります。
4. If x < 8, remove the left-most (highest-numbered) label from the subject domain. If x >= 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain. The resulting DNS domain name is the new target for the next lookup.
4. x < 8 の場合、対象ドメインから左端 (最大番号) のラベルを削除します。x >= 8 の場合、7 つのラベルが残るまで対象ドメインから左端 (最も大きい番号) のラベルを削除します。結果の DNS ドメイン名は、次の検索の新しいターゲットになります。
5. Query the DNS for a DMARC Policy Record at the DNS domain name matching this new target. A possibly empty set of records is returned.
5. この新しいターゲットに一致する DNS ドメイン名で DMARC ポリシー レコードを DNS にクエリします。空の可能性があるレコードのセットが返されます。
6. Records that do not start with a "v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a "psd=n" or "psd=y" tag, stop.
6. DMARC の現在のバージョンを識別する「v」タグで始まらないレコードは破棄されます。単一のターゲットに対して複数の DMARC ポリシー レコードが返された場合、それらはすべて破棄されます。レコードが 1 つ残っており、そのレコードに「psd=n」または「psd=y」タグが含まれている場合は停止します。
7. Determine the target for the next query by removing the left-most label from the target of the previous query. Repeat steps 5, 6, and 7 until the process stops or there are no more labels remaining.
7. 前のクエリのターゲットから左端のラベルを削除して、次のクエリのターゲットを決定します。プロセスが停止するかラベルがなくなるまで、手順 5、6、7 を繰り返します。
To illustrate, for a message with the arbitrary Author Domain of "a.b.c.d.e.f.g.h.i.j.mail.example.com", a full DNS Tree Walk would require the following eight queries to potentially locate the DMARC Policy Record or Organizational Domain:
たとえば、任意の作成者ドメインが「a.b.c.d.e.f.g.h.i.j.mail.example.com」であるメッセージの場合、完全な DNS ツリー ウォークでは、DMARC ポリシー レコードまたは組織ドメインを見つけるために次の 8 つのクエリが必要になります。
* _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
* _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
* _dmarc.g.h.i.j.mail.example.com
* _dmarc.g.h.i.j.mail.example.com
* _dmarc.h.i.j.mail.example.com
* _dmarc.h.i.j.mail.example.com
* _dmarc.i.j.mail.example.com
* _dmarc.i.j.mail.example.com
* _dmarc.j.mail.example.com
* _dmarc.j.mail.example.com
* _dmarc.mail.example.com
* _dmarc.mail.example.com
* _dmarc.example.com
* _dmarc.example.com
* _dmarc.com
* _dmarc.com
The DMARC Policy Record to be applied to an email message will be the record found at any of the following locations, listed from highest preference to lowest:
電子メール メッセージに適用される DMARC ポリシー レコードは、次のいずれかの場所にあるレコードになります (優先度の高いものから低いものまで)。
* The Author Domain
* 著者のドメイン
* The Organizational Domain of the Author Domain
* 著者ドメインの組織ドメイン
* The PSD of the Author Domain
* 作成者ドメインの PSD
Policy discovery first starts with a query for a valid DMARC Policy Record at the name created by prepending the label "_dmarc" to the Author Domain of the message being evaluated. If a valid DMARC Policy Record is found there, then this is the DMARC Policy Record to be applied to the message; however, this does not necessarily mean that the Author Domain is the Organizational Domain to be used in Identifier Alignment checks. Whether this is also the Organizational Domain is dependent on the value of the "psd" tag, if present, or some conditions described in Section 4.10.2.
ポリシー検出は、まず、評価対象のメッセージの作成者ドメインの先頭にラベル「_dmarc」を追加して作成された名前の有効な DMARC ポリシー レコードのクエリから始まります。有効な DMARC ポリシー レコードがそこで見つかった場合、これがメッセージに適用される DMARC ポリシー レコードになります。ただし、これは必ずしも作成者ドメインが識別子の整合チェックで使用される組織ドメインであることを意味するわけではありません。これが組織ドメインでもあるかどうかは、「psd」タグの値 (存在する場合)、またはセクション 4.10.2 で説明されているいくつかの条件によって決まります。
If no valid DMARC Policy Record is found by the first query, then perform a DNS Tree Walk to find the Author Domain's Organizational Domain or its Public Suffix Domain. The starting point for this DNS Tree Walk is determined as follows:
最初のクエリで有効な DMARC ポリシー レコードが見つからなかった場合は、DNS ツリー ウォークを実行して、作成者ドメインの組織ドメインまたはそのパブリック サフィックス ドメインを見つけます。この DNS ツリー ウォークの開始点は次のように決定されます。
* If the Author Domain has eight or fewer labels, the starting point will be the immediate parent domain of the Author Domain.
* 作成者ドメインのラベルが 8 つ以下の場合、開始点は作成者ドメインの直接の親ドメインになります。
* Otherwise, the starting point will be the name produced by shortening the Author Domain as described starting in step 3 of Section 4.10.
* それ以外の場合、開始点は、セクション 4.10 のステップ 3 で説明したように、作成者ドメインを短縮して生成された名前になります。
If the DMARC Policy Record to be applied is that of the Author Domain, then the Domain Owner Assessment Policy is taken from the "p" tag of the record.
適用される DMARC ポリシー レコードが作成者ドメインのレコードである場合、ドメイン所有者評価ポリシーはレコードの「p」タグから取得されます。
If the DMARC Policy Record to be applied is that of either the Organizational Domain or the PSD and the Author Domain is a subdomain of that domain, then the Domain Owner Assessment Policy is taken from the "sp" tag (if any) if the Author Domain exists or the "np" tag (if any) if the Author Domain does not exist. In the absence of applicable "sp" or "np" tags, the "p" tag policy is used for subdomains.
適用される DMARC ポリシー レコードが組織ドメインまたは PSD のレコードであり、作成者ドメインがそのドメインのサブドメインである場合、ドメイン所有者評価ポリシーは、作成者ドメインが存在する場合は「sp」タグ (存在する場合) から取得され、作成者ドメインが存在しない場合は「np」タグ (存在する場合) から取得されます。適用可能な「sp」または「np」タグがない場合、サブドメインには「p」タグ ポリシーが使用されます。
If a retrieved DMARC Policy Record does not contain a valid "p" tag, or contains an "sp" or "np" tag that is not valid, then:
取得した DMARC ポリシー レコードに有効な「p」タグが含まれていない場合、または無効な「sp」または「np」タグが含まれている場合は、次のようになります。
* If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing "p=none" was retrieved and continue processing.
* 「rua」タグが存在し、構文的に有効なレポート URI が少なくとも 1 つ含まれている場合、メール受信者は、「p=none」を含むレコードが取得されたかのように動作し、処理を続行しなければなりません (MUST)。
* Otherwise, the Mail Receiver applies no DMARC processing to this message.
* それ以外の場合、メール受信者はこのメッセージに DMARC 処理を適用しません。
If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message.
DNS ツリー ウォークによって生成されたセットに DMARC ポリシー レコードが含まれていない場合 (つまり、一時的な DNS エラーではなくそのようなレコードが存在しないことを示すもの)、メール受信者はメッセージに DMARC メカニズムを適用してはなりません (MUST 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 応答) 場合もあります。これにより、条件がクリアされた可能性があり、明確な DMARC の結論に達することが可能になる (「フェール クローズ」) ことにより、送信側 MTA が再試行するように求められます。
Note: PSD policy is not used for Organizational Domains that have published a DMARC Policy Record. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so.
注: PSD ポリシーは、DMARC ポリシー レコードを公開している組織ドメインには使用されません。具体的には、これは、組織ドメインがフィードバック アドレス (rua/ruf) を拒否した場合にフィードバック アドレス (rua/ruf) を提供するメカニズムではありません。
It may be necessary to perform multiple DNS Tree Walks to determine if an Authenticated Identifier and an Author Domain are in alignment, meaning that they have either the same Organizational Domain (relaxed alignment) or that they're identical (strict alignment). DNS Tree Walks done to discover an Organizational Domain for use in Identifier Alignment Evaluation might start at any of the following locations:
認証された識別子と作成者ドメインが一致しているかどうか、つまり、それらが同じ組織ドメインを持っているか (緩和された一致)、または同一であるか (厳密な一致) を判断するには、複数の DNS ツリー ウォークを実行する必要がある場合があります。識別子調整評価で使用する組織ドメインを検出するために実行される DNS ツリー ウォークは、次のいずれかの場所で開始される場合があります。
* The Author Domain of the message being evaluated.
* 評価されるメッセージの作成者ドメイン。
* The SPF-Authenticated Identifier if there is an SPF "pass" result for the message being evaluated.
* 評価中のメッセージに対して SPF 「合格」結果がある場合の SPF 認証済み識別子。
* Any DKIM-Authenticated Identifier if one or more DKIM "pass" results exist for the message being evaluated.
* 評価対象のメッセージに対して 1 つ以上の DKIM「合格」結果が存在する場合は、DKIM 認証された識別子。
There is no need to perform Identifier Alignment Evaluations under any of the following conditions:
次のいずれかの条件下では、識別子のアライメント評価を実行する必要はありません。
* The Author Domain and the Authenticated Identifier(s) are all the same domain, and there is a DMARC Policy Record published for that domain. In this case, this common domain is treated as the Organizational Domain. For example, if the common domain in question is "mail.example.com", and there is a valid DMARC Policy Record published at "_dmarc.mail.example.com", then "mail.example.com" is the Organizational Domain.
* 作成者ドメインと認証された識別子はすべて同じドメインであり、そのドメインに対して発行された DMARC ポリシー レコードがあります。この場合、この共通ドメインは組織ドメインとして扱われます。たとえば、問題の共通ドメインが「mail.example.com」で、「_dmarc.mail.example.com」に公開されている有効な DMARC ポリシー レコードがある場合、「mail.example.com」が組織ドメインになります。
* No applicable DMARC Policy Record is discovered for the Author Domain. In this case, the DMARC mechanism does not apply to the message in question.
* 作成者ドメインに該当する DMARC ポリシー レコードが見つかりません。この場合、DMARC メカニズムは問題のメッセージに適用されません。
* The DMARC Policy Record for the Author Domain indicates strict alignment. In this case, a simple string comparison of the Author Domain and the Authenticated Identifier(s) is all that is required.
* 作成者ドメインの DMARC ポリシー レコードは、厳密な調整を示します。この場合、必要なのは作成者ドメインと認証された識別子の単純な文字列比較だけです。
To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in Section 4.10 as needed for any of the domains in question.
ドメインの組織ドメインを検出するには、必要に応じて、該当するドメインに対してセクション 4.10 で説明されている DNS ツリー ウォークを実行します。
For each Tree Walk that retrieved valid DMARC Policy Records, select the Organizational Domain from the domains for which valid DMARC Policy Records were retrieved from the longest to the shortest:
有効な DMARC ポリシー レコードを取得した各 Tree Walk について、有効な DMARC ポリシー レコードが取得されたドメインから組織ドメインを最長から最短の順に選択します。
1. If a valid DMARC Policy Record contains the "psd" tag set to "n" ("psd=n"), this is the Organizational Domain, and the selection process is complete.
1. 有効な DMARC ポリシー レコードに、「n」 (「psd=n」) に設定された「psd」タグが含まれている場合、これが組織ドメインであり、選択プロセスは完了です。
2. If a valid DMARC Policy Record, other than the one for the domain where the Tree Walk started, contains the "psd" tag set to "y" ("psd=y"), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete. For example, if in the course of a Tree Walk a DMARC Policy Record is queried for at first "_dmarc.mail.example.com" and then "_dmarc.example.com", and a valid DMARC Policy Record containing the "psd" tag set to "y" is found at "_dmarc.example.com", then "mail.example.com" is the domain one label below "example.com" in the DNS hierarchy and is thus the Organizational Domain.
2. Tree Walk が開始されたドメインのレコード以外の有効な DMARC ポリシー レコードに、「y」 (「psd=y」) に設定された「psd」タグが含まれている場合、組織ドメインは DNS 階層内でこのドメインの 1 ラベル下のドメインとなり、選択プロセスは完了です。たとえば、ツリー ウォークの過程で、最初に「_dmarc.mail.example.com」、次に「_dmarc.example.com」という DMARC ポリシー レコードがクエリされ、「y」に設定された「psd」タグを含む有効な DMARC ポリシー レコードが「_dmarc.example.com」で見つかった場合、「mail.example.com」は、DNS 階層内で「example.com」のラベル 1 つ下のドメインであるため、組織ドメイン。
3. Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels. This is the Organizational Domain and the selection process is complete.
3. それ以外の場合は、ラベルの数が最も少ない名前で見つかった DMARC ポリシー レコードを選択します。これは組織ドメインであり、選択プロセスは完了です。
If this process does not determine the Organizational Domain, then the initial target domain is the Organizational Domain.
このプロセスで組織ドメインが決定されない場合、最初のターゲット ドメインは組織ドメインになります。
For example, given the starting domain "a.mail.example.com", a search for the Organizational Domain would require a series of DNS queries for DMARC Policy Records starting with "_dmarc.a.mail.example.com" and finishing with "_dmarc.com". If there are DMARC Policy Records published at "_dmarc.mail.example.com" and "_dmarc.example.com", but not at "_dmarc.a.mail.example.com" or "_dmarc.com", then the Organizational Domain for this domain would be "example.com".
たとえば、開始ドメインが「a.mail.example.com」の場合、組織ドメインを検索するには、「_dmarc.a.mail.example.com」で始まり「_dmarc.com」で終わる DMARC ポリシー レコードに対する一連の DNS クエリが必要になります。「_dmarc.mail.example.com」および「_dmarc.example.com」には公開されている DMARC ポリシー レコードがあり、「_dmarc.a.mail.example.com」または「_dmarc.com」には公開されていない場合、このドメインの組織ドメインは「example.com」になります。
As another example, given the starting domain "a.mail.example.com", if a search for the Organizational Domain yields a DMARC Policy Record at "_dmarc.mail.example.com" with the "psd" tag set to "n", then the Organizational Domain for this domain would be "mail.example.com".
別の例として、開始ドメインが「a.mail.example.com」であるとすると、組織ドメインを検索すると、「psd」タグが「n」に設定された「_dmarc.mail.example.com」の DMARC ポリシー レコードが得られ、このドメインの組織ドメインは「mail.example.com」になります。
As a last example, given the starting domain "a.mail.example.com", if a search for the Organizational Domain only yields a DMARC Policy Record at "_dmarc.com" and that record contains the tag "psd=y", then the Organizational Domain for this domain would be "example.com".
最後の例として、開始ドメインが「a.mail.example.com」であるとすると、組織ドメインの検索で「_dmarc.com」の DMARC ポリシー レコードのみが得られ、そのレコードにタグ「psd=y」が含まれている場合、このドメインの組織ドメインは「example.com」になります。
This section describes the actions for participating in DMARC for each of three unique entities -- Domain Owners, PSOs, and Mail Receivers.
このセクションでは、ドメイン所有者、PSO、メール受信者という 3 つの固有のエンティティごとに DMARC に参加するためのアクションについて説明します。
A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC will:
DMARC への完全参加を希望するドメイン所有者 (セクション 3.2.7) は、次のことを行います。
* Publish a DMARC Policy Record (Section 3.2.6) to cover each Author Domain (Section 3.2.2) and corresponding Organizational Domain (Section 3.2.14) to which DMARC validation should apply;
* DMARC 検証を適用する必要がある各作成者ドメイン (セクション 3.2.2) および対応する組織ドメイン (セクション 3.2.14) をカバーする DMARC ポリシー レコード (セクション 3.2.6) を公開します。
* Send email that produces at least one -- preferably two -- Authenticated Identifiers (Section 3.2.1) that align with the Author Domain;
* 作成者ドメインに一致する少なくとも 1 つ (できれば 2 つ) の認証済み識別子 (セクション 3.2.1) を生成する電子メールを送信します。
* Receive and monitor the content of DMARC aggregate reports;
* DMARC 集約レポートの内容を受信して監視します。
* Correct authentication shortcomings in mail making authorized use of its domains.
* ドメインを許可して使用するメールにおける認証上の欠陥を修正します。
The following sections describe how to achieve this.
次のセクションでは、これを実現する方法について説明します。
To configure SPF for DMARC, the Domain Owner MUST send mail that has an RFC5321.MailFrom domain that will produce an SPF-Authenticated Identifier (Section 4.4.2) that has Identifier Alignment (Section 4.4) with the Author Domain.
DMARC 用に SPF を設定するには、ドメイン所有者は、作成者ドメインとの識別子の整合 (セクション 4.4) を持つ SPF 認証済み識別子 (セクション 4.4.2) を生成する RFC5321.MailFrom ドメインを持つメールを送信しなければなりません (MUST)。
To configure DKIM for DMARC, the Domain Owner MUST send mail that has a DKIM Signing Domain (Section 3.2.3) that will produce a DKIM-Authenticated Identifier (Section 4.4.1) that has Identifier Alignment (Section 4.4) with the Author Domain.
DMARC 用に DKIM を設定するには、ドメイン所有者は、作成者ドメインとの識別子アライメント (セクション 4.4) を持つ DKIM 認証済み識別子 (セクション 4.4.1) を生成する DKIM 署名ドメイン (セクション 3.2.3) を持つメールを送信しなければなりません (MUST)。
Proper consumption and analysis of DMARC aggregate reports are essential to any successful DMARC deployment for a Domain Owner. DMARC aggregate reports, which are defined in [RFC9990], contain valuable data for the Domain Owner, showing sources of mail using the Author Domain.
DMARC 集約レポートの適切な使用と分析は、ドメイン所有者に対する DMARC 導入を成功させるために不可欠です。[RFC9990] で定義されている DMARC 集約レポートには、作成者ドメインを使用するメールのソースを示す、ドメイン所有者にとって貴重なデータが含まれています。
Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC Policy Record. For best results, Domain Owners usually start with "p=none" (see Section 5.1.5) with the "rua" tag containing a URI that references the mailbox created in the previous step. This is commonly referred to as putting the Author Domain into Monitoring Mode (Section 3.2.12). If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain.
SPF、DKIM、および集計レポート メールボックスがすべて配置されたら、DMARC ポリシー レコードを公開します。最良の結果を得るために、ドメイン所有者は通常、前の手順で作成したメールボックスを参照する URI を含む「rua」タグを含む「p=none」(セクション 5.1.5 を参照) で始めます。これは一般に、作成者ドメインを監視モードにすることと呼ばれます (セクション 3.2.12)。組織ドメインが作成者ドメインと異なる場合は、組織ドメインに対してもレコードを公開する必要があります。
The reason for starting at "p=none" is to ensure that nothing's been missed in the initial SPF and DKIM deployments. In all but the most trivial setups, a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there. Starting at "p=none", therefore, takes advantage of DMARC's aggregate reporting function, with the Domain Owner using the reports to audit its own mail streams' authentication configurations.
「p=none」から開始する理由は、最初の SPF および DKIM の展開で何も欠落していないことを確認するためです。最も簡単なセットアップを除くすべての場合、ドメイン所有者はここのサーバーを見落としたり、そこにあるサードパーティの送信契約に気づかなかったりする可能性があります。したがって、「p=none」から開始すると、DMARC の集約レポート機能が利用され、ドメイン所有者はそのレポートを使用して自身のメール ストリームの認証構成を監査します。
While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just the physical creation of that mailbox. Many third-party services exist that will process DMARC aggregate reports, or the Domain Owner can create its own set of tools. No matter which method is chosen, the ability to consume these reports and parse the data contained in them will go a long way to ensuring a successful deployment.
人間が集計レポートを読むことは可能ですが、レポートは機械で解析することが推奨されるような形式になっているため、メールボックスの設定には、単にメールボックスを物理的に作成するだけではありません。DMARC 集約レポートを処理するサードパーティ サービスが多数存在するほか、ドメイン所有者が独自のツール セットを作成することもできます。どの方法を選択する場合でも、これらのレポートを使用してレポートに含まれるデータを解析できる機能は、展開を確実に成功させるために大いに役立ちます。
DMARC aggregate reports can reveal to the Domain Owner mail streams using the Author Domain but not passing DMARC validation checks. These mail streams may be a combination of illegitimate uses of the domain, such as spoofing or other attempted abuse, and legitimate uses, as in the case of a mail stream created by an agent of the Domain Owner but one that is not passing due to Authenticated Identifiers being unaligned or missing entirely. For such legitimate uses, these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy (Section 3.2.8) of Enforcement (Section 3.2.9) for the Author Domain.
DMARC 集約レポートは、作成者ドメインを使用しているが DMARC 検証チェックに合格していないメール ストリームをドメイン所有者に明らかにすることができます。これらのメール ストリームは、スプーフィングやその他の悪用の試みなどのドメインの不正な使用と、ドメイン所有者のエージェントによって作成されたメール ストリームが、認証された識別子が調整されていない、または完全に欠落しているために通過しない場合のような、正当な使用の組み合わせである可能性があります。このような正当な使用の場合、ドメイン所有者が作成者ドメインに対するドメイン所有者評価ポリシー (セクション 3.2.8) または施行 (セクション 3.2.9) を公開しようとする前に、これらの欠点に対処しなければなりません。
Once the Domain Owner is satisfied that it is properly authenticating all of its mail, then it is time to decide if it is appropriate to change its Domain Owner Assessment Policy to Enforcement (Section 3.2.9). Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail, and the decision on which "p" value to use will depend on its needs.
ドメイン所有者がすべてのメールを適切に認証していることに満足したら、ドメイン所有者評価ポリシーを強制に変更することが適切かどうかを決定します (セクション 3.2.9)。メール送信の頻度によっては、ドメイン所有者がすべてのメールを適切に認証していると確信できる状態に達するまでに、DMARC 集約レポートを使用して何ヶ月もかかる場合があり、どの「p」値を使用するかはそのニーズに応じて決定されます。
In making this decision, it is important to understand the interoperability issues involved and problems that can result for mailing lists and for delivery of legitimate mail. Those issues are discussed in detail in Section 7.4
この決定を行う際には、関連する相互運用性の問題と、メーリング リストや正規のメールの配信に生じる可能性のある問題を理解することが重要です。これらの問題については、セクション 7.4 で詳しく説明します。
Large, complex organizations frequently adopt a decentralized model for DNS management, whereby management of a subtree of the namespace is delegated to a local department by the central IT organization. In such situations, the "psd" tag makes it possible for those local departments to declare any arbitrary node in their subtree as an Organizational Domain. This would be accomplished by publishing a DMARC Policy Record at that node with the "psd" tag set to "n". The reasons that departments might declare their own Organizational Domains include a desire to have different policy settings or reporting URIs than the DMARC Policy Record published for the apex domain.
大規模で複雑な組織は、DNS 管理に分散モデルを採用することが多く、名前空間のサブツリーの管理は中央の IT 組織によってローカル部門に委任されます。このような状況では、「psd」タグを使用すると、ローカル部門がサブツリー内の任意のノードを組織ドメインとして宣言できるようになります。これは、「psd」タグを「n」に設定してそのノードで DMARC ポリシー レコードを公開することによって実現されます。部門が独自の組織ドメインを宣言する理由には、頂点ドメインに対して公開された DMARC ポリシー レコードとは異なるポリシー設定またはレポート URI を使用したいという要望が含まれます。
Such configurations would work in theory, and they might involve domain names with many labels, reflecting the structure of the organization, for example:
このような構成は理論上は機能し、組織の構造を反映する多くのラベルを持つドメイン名が含まれる可能性があります。次に例を示します。
* Apex domain (DMARC Policy Record published here): example.com
* Apex ドメイン (ここで公開される DMARC ポリシー レコード): example.com
* Zone cut domain (DMARC Policy Record with "psd=n" published here): b.c.d.e.f.g.example.com
* ゾーン カット ドメイン (ここで公開されている「psd=n」の DMARC ポリシー レコード): b.c.d.e.f.g.example.com
* Author Domain: mail.a.b.c.d.e.f.g.example.com
* 作成者のドメイン: mail.a.b.c.d.e.f.g.example.com
However, Domain Owners should be aware that due to the anti-abuse protections built into the DNS Tree Walk (Section 4.10), the DMARC Policy Record published at the zone cut domain in this example will never be discovered. A Mail Receiver performing a Tree Walk would only perform queries for these names:
ただし、ドメイン所有者は、DNS ツリー ウォーク (セクション 4.10) に組み込まれた悪用防止保護により、この例のゾーン カット ドメインで公開された DMARC ポリシー レコードは決して検出されないことに注意する必要があります。ツリー ウォークを実行するメール受信者は、次の名前のクエリのみを実行します。
* _dmarc.mail.a.b.c.d.e.f.g.example.com
* _dmarc.mail.a.b.c.d.e.f.g.example.com
* _dmarc.c.d.e.f.g.example.com
* _dmarc.c.d.e.f.g.example.com
* _dmarc.d.e.f.g.example.com
* _dmarc.d.e.f.g.example.com
* _dmarc.e.f.g.example.com
* _dmarc.e.f.g.example.com
* _dmarc.f.g.example.com
* _dmarc.f.g.example.com
* _dmarc.g.example.com
* _dmarc.g.example.com
* _dmarc.example.com
* _dmarc.example.com
* _dmarc.com
* _dmarc.com
To avoid this circumstance, Domain Owners wishing to have a specific DMARC Policy Record applied to a given Author Domain (Section 3.2.2) longer than eight labels MUST publish a DMARC Policy Record at that domain's location in the DNS namespace, as such records are always queried by Mail Receivers that participate in DMARC before the Tree Walk begins. In the above example, this would mean publishing a DMARC Policy Record at the name "_dmarc.mail.a.b.c.d.e.f.g.example.com.".
この状況を回避するには、ラベルが 8 つを超える特定の DMARC ポリシー レコードを特定の作成者ドメイン (セクション 3.2.2) に適用したいドメイン所有者は、DNS 名前空間内のそのドメインの場所で DMARC ポリシー レコードを公開しなければなりません。そのようなレコードは、ツリー ウォークが開始される前に DMARC に参加するメール受信者によって常にクエリされるためです。上記の例では、これは DMARC ポリシー レコードを「_dmarc.mail.a.b.c.d.e.f.g.example.com.」という名前で公開することを意味します。
In addition to the DMARC Domain Owner actions, if a PSO (Section 3.2.16) publishes a DMARC Policy Record, it MUST include the "psd" tag (see Section 4.7) with a value of "y" ("psd=y").
DMARC ドメイン所有者のアクションに加えて、PSO (セクション 3.2.16) が DMARC ポリシー レコードを発行する場合、値が「y」(「psd=y」) の「psd」タグ (セクション 4.7 を参照) を含めなければなりません (MUST)。
Mail Receivers (Section 3.2.11) wishing to fully participate in DMARC will apply the DMARC mechanism to inbound email messages when a DMARC Policy Record (Section 3.2.6) exists that applies to the Author Domain (Section 3.2.2) and will send aggregate feedback reports to Domain Owners that request them. Mail Receivers might also send failure reports to Domain Owners that request them. The following sections describe how to achieve this.
DMARC への完全参加を希望するメール受信者 (セクション 3.2.11) は、作成者ドメイン (セクション 3.2.2) に適用される DMARC ポリシー レコード (セクション 3.2.6) が存在する場合、受信電子メール メッセージに DMARC メカニズムを適用し、集約フィードバック レポートを要求するドメイン所有者に送信します。メール受信者は、要求したドメイン所有者に失敗レポートを送信することもあります。次のセクションでは、これを実現する方法について説明します。
The steps for applying the DMARC mechanism to an email message can take place during the SMTP transaction and should do so if the Mail Receiver plans to honor Domain Owner Assessment Policies (Section 3.2.8) that are at the Enforcement (Section 3.2.9) state.
電子メール メッセージに DMARC メカニズムを適用する手順は、SMTP トランザクション中に実行できます。メール受信者が施行 (セクション 3.2.9) 状態にあるドメイン所有者評価ポリシー (セクション 3.2.8) を順守する予定がある場合は、そうする必要があります。
Many Mail Receivers perform one or both of the underlying Authentication Mechanisms (Section 4.3) on inbound messages even in cases where no DMARC Policy Record exists for the Author Domain of a given message, or where the Mail Receiver is not participating in DMARC. Nothing in this section is intended to imply that the underlying authentication mechanisms should only be performed by Mail Receivers participating in DMARC.
多くのメール受信者は、特定のメッセージの作成者ドメインに DMARC ポリシー レコードが存在しない場合や、メール受信者が DMARC に参加していない場合でも、受信メッセージに対して基盤となる認証メカニズム (セクション 4.3) の一方または両方を実行します。このセクションのいかなる内容も、基礎となる認証メカニズムが DMARC に参加しているメール受信者によってのみ実行されるべきであることを示唆するものではありません。
Once the email message has been transmitted to the Mail Receiver, the Mail Receiver extracts the domain in the RFC5322.From header field as the Author Domain. If the domain is a U-label, the domain MUST be converted to an A-label, as described in Section 2.3 of [RFC5890], for further processing.
電子メール メッセージがメール受信者に送信されると、メール受信者は RFC5322.From ヘッダー フィールド内のドメインを作成者ドメインとして抽出します。ドメインが U ラベルの場合、[RFC5890] のセクション 2.3 で説明されているように、さらなる処理のためにドメインを A ラベルに変換しなければなりません (MUST)。
If zero or more than one domain is extracted from the RFC5322.From header field, then DMARC validation is not possible and the process terminates. In the case where more than one domain is retrieved, the Mail Receiver MAY choose to go forward with DMARC validation anyway. See Section 11.5 for further discussion.
RFC5322.From ヘッダー フィールドからゼロまたは複数のドメインが抽出された場合、DMARC 検証は不可能となり、プロセスは終了します。複数のドメインが取得された場合、メール受信者はいずれにしても DMARC 検証を続行することを選択してもよい(MAY)。詳細については、セクション 11.5 を参照してください。
If precisely one Author Domain exists for the message, then perform the step described in "DMARC Policy Discovery" (Section 4.10.1) to determine if the DMARC mechanism applies. If a DMARC Policy Record (Section 3.2.6) is not discovered during this step, then the DMARC mechanism does not apply and DMARC validation terminates for the message.
メッセージに対して作成者ドメインが 1 つだけ存在する場合は、「DMARC ポリシーの検出」(セクション 4.10.1) で説明されている手順を実行して、DMARC メカニズムが適用されるかどうかを判断します。このステップ中に DMARC ポリシー レコード (セクション 3.2.6) が検出されない場合、DMARC メカニズムは適用されず、メッセージの DMARC 検証は終了します。
For each authentication mechanism underlying DMARC, perform the required check to determine if an Authenticated Identifier (Section 3.2.1) exists for the message if such check has not already been performed. Results from each check must be preserved for later use as follows:
DMARC の基礎となる認証メカニズムごとに、必要なチェックを実行して、メッセージに認証済み識別子 (セクション 3.2.1) が存在するかどうかを確認します (そのようなチェックがまだ実行されていない場合)。各チェックの結果は、次のように後で使用できるように保存する必要があります。
* For SPF, the preserved results MUST include "pass" or "fail". If the result is "fail", it SHOULD include information about the reasons for failure, if available. The results MUST further include the domain name used to complete the SPF check.
* SPF の場合、保存された結果には「合格」または「失敗」が含まれなければなりません。結果が「失敗」の場合、可能であれば、失敗の理由に関する情報を含めるべきです(SHOULD)。結果には、SPF チェックを完了するために使用されたドメイン名がさらに含まれなければなりません。
* For DKIM signature validation checks, for each signature checked, the results MUST include "pass" or "fail". If the result is "fail", it SHOULD include information about the reasons for failure. The results MUST further include the value of the "d" and "s" tags from each checked DKIM signature.
* DKIM 署名検証チェックでは、チェックされた各署名の結果に「合格」または「失敗」が含まれなければなりません。結果が「失敗」の場合、失敗の理由に関する情報を含めるべきです(SHOULD)。結果には、チェックされた各 DKIM 署名の「d」タグと「s」タグの値がさらに含まれなければなりません (MUST)。
For each Authenticated Identifier found in the message, the Mail Receiver checks to see if the Authenticated Identifier is aligned (Section 4.10.2) with the Author Domain.
メール受信者は、メッセージ内で見つかった認証済み識別子ごとに、認証済み識別子が作成者ドメインと一致しているかどうかを確認します (セクション 4.10.2)。
If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.
1 つ以上の認証された識別子が作成者ドメインと一致する場合、メッセージは DMARC メカニズムのチェックに合格したと見なされます。
If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.
ドメインに認証された識別子が存在しない場合、または作成者ドメインと一致する認証された識別子がない場合、メッセージは DMARC メカニズムのチェックに失敗したとみなされます。
Email messages that fail the DMARC mechanism check are handled in accordance with the Mail Receiver's local policies. These local policies may take into account the Domain Owner Assessment Policy for the Author Domain at the Mail Receiver's discretion.
DMARC メカニズムのチェックに失敗した電子メール メッセージは、メール受信者のローカル ポリシーに従って処理されます。これらのローカル ポリシーでは、メール受信者の裁量で、作成者ドメインのドメイン所有者評価ポリシーが考慮される場合があります。
If one or more DNS queries required to perform DMARC validation on the message do not complete due to temporary or permanent DNS errors, the message cannot be considered to pass or fail the DMARC mechanism check. In such cases, the Domain Owner Assessment Policy cannot be applied to the message, and any other handling decisions for the message are left to the discretion of the Mail Receiver.
メッセージの DMARC 検証を実行するために必要な 1 つ以上の DNS クエリが、一時的または永続的な DNS エラーにより完了しない場合、メッセージは DMARC メカニズム チェックに合格または不合格であるとは見なされません。このような場合、ドメイン所有者評価ポリシーをメッセージに適用することはできず、メッセージに対するその他の処理の決定はメール受信者の裁量に任されます。
See Section 7.2 for further discussion of topics regarding rejecting messages.
メッセージの拒否に関するトピックの詳細については、セクション 7.2 を参照してください。
If the Mail Receiver intends to send aggregate feedback reports and/ or failure reports, then results obtained from the application of the DMARC mechanism by the Mail Receiver MUST be preserved for eventual presentation back to the Domain Owner in the form of such reports. Section 4.7 and [RFC9990] discuss aggregate feedback reports.
メール受信者が集約フィードバック レポートや失敗レポートを送信する場合、メール受信者による DMARC メカニズムの適用から得られた結果は、最終的にそのようなレポートの形式でドメイン所有者に返されるように保存しなければなりません (MUST)。セクション 4.7 と [RFC9990] では、集約フィードバックレポートについて説明しています。
To ensure maximum usefulness for DMARC across the email ecosystem, Mail Receivers SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours. Such reports provide Domain Owners with insight into all mail streams using Author Domains under the Domain Owner's control and aid the Domain Owner in determining whether and when to transition from Monitoring Mode (Section 3.2.12) to Enforcement (Section 3.2.9).
電子メール エコシステム全体で DMARC の有用性を最大限に高めるために、メール受信者は少なくとも 24 時間に 1 回の頻度で集計レポートを生成し、送信する必要があります (SHOULD)。このようなレポートは、ドメイン所有者に、ドメイン所有者の制御下にある作成者ドメインを使用するすべてのメール ストリームに関する洞察を提供し、ドメイン所有者が監視モード (セクション 3.2.12) から強制 (セクション 3.2.9) に移行するかどうか、またいつ移行するかを決定するのに役立ちます。
The most common reasons for a Mail Receiver to opt out of sending aggregate reports include resource constraints, local policy against sharing data, and concerns about user privacy.
メール受信者が集計レポートの送信をオプトアウトする最も一般的な理由には、リソースの制約、データ共有に対するローカル ポリシー、ユーザーのプライバシーへの懸念などが含まれます。
Per-message failure reports can be useful sources of information for a Domain Owner, either for debugging deployments or in analyzing attacks, and so Mail Receivers MAY choose to send them. Experience has shown, however, that Mail Receivers rightly concerned about protecting user privacy have either chosen to heavily redact the information in such reports (which can hinder their usefulness) or not send them at all. See [RFC9991] for further information.
メッセージごとの失敗レポートは、ドメイン所有者にとって、展開のデバッグや攻撃の分析に役立つ情報源となるため、メール受信者はレポートの送信を選択してもよい(MAY)。しかし、経験上、メール受信者はユーザーのプライバシー保護を当然のことながら、そのようなレポートの情報を大幅に編集するか（有用性が損なわれる可能性がある）、まったく送信しないことを選択していることがわかっています。詳細については、[RFC9991] を参照してください。
The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver.
メッセージの最終的な処理は常にローカル ポリシーの問題であり、メール受信者の裁量に任されています。
A DMARC pass for a message indicates only that the use of the Author Domain (Section 3.2.2) has been validated for that message as authorized by the Domain Owner (Section 3.2.7). Such authorization does not carry an explicit or implicit value assertion about that message or the Domain Owner, and Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check. Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled abuse.
メッセージの DMARC パスは、そのメッセージに対する作成者ドメイン (セクション 3.2.2) の使用がドメイン所有者 (セクション 3.2.7) によって承認されたものとして検証されていることのみを示します。このような承認には、そのメッセージまたはドメイン所有者に関する明示的または暗黙的な値の表明は含まれておらず、メール受信者は、たとえ DMARC 検証チェックに合格したとしてもメッセージを拒否または隔離することを選択できます (MAY)。メール受信者は、DMARC 対応の悪用の可能性に対抗するために、悪用防止テクノロジーを維持することが推奨されます。
Mail Receivers MAY choose to accept email that fails the DMARC validation check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960] and in Section 7.4 of this document, it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject" but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar.
メール受信者は、公開されたドメイン所有者評価ポリシーが「拒否」であっても、DMARC 検証チェックに失敗した電子メールを受け入れることを選択できます (MAY)。特に、[RFC7960] とこの文書のセクション 7.4 で説明されている考慮事項のため、メール受信者は公開された「拒否」ポリシーだけを理由にメッセージを拒否すべきではなく、DMARC が記述できない方法で送信された正当なメッセージの拒否、メーリング リストの運用への損害などの状況を回避するために他の知識と分析を適用することが重要です。
If a Mail Receiver chooses not to honor the published Domain Owner Assessment Policy to improve interoperability among mail systems, it may increase the likelihood of accepting abusive mail. At a minimum, Mail Receivers SHOULD add the Authentication-Results header field (see [RFC8601]), and it is RECOMMENDED when delivering messages that fail the DMARC validation check.
メール受信者がメール システム間の相互運用性を向上させるために公開されたドメイン所有者評価ポリシーを遵守しないことを選択した場合、不正メールを受け入れる可能性が高まる可能性があります。少なくとも、メール受信者は Authentication-Results ヘッダー フィールド ([RFC8601] を参照) を追加する必要があります (SHOULD)。DMARC 検証チェックに失敗したメッセージを配信する場合は、これが推奨されます。
When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing, they 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 defined in [RFC9990].
メール受信者がメッセージ処理中に公開されたドメイン所有者評価ポリシーから逸脱した場合、フィードバックレポートを通じて、具体的には[RFC9990]で定義されている集約レポートの「PolicyOverride」機能を使用して、逸脱の事実とその理由をドメイン所有者に提供すべきである(SHOULD)。
To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" MUST NOT modify existing mail handling processes.
ドメイン所有者が既存のメール処理に影響を与えることなく DMARC フィードバックを受信できるようにするために、検出された「p=none」ポリシーは既存のメール処理プロセスを変更してはなりません (MUST NOT)。
DMARC feedback is described in [RFC9990].
DMARC フィードバックは [RFC9990] で説明されています。
As an operational note for PSOs, feedback for non-existent domains can be desirable and useful, just as it can be for Organizational Domains. Therefore, both such entities should consider including "rua=" tags in any DMARC Policy Records they publish for themselves. See Section 10 for discussion of privacy considerations.
PSO の運用上の注意点として、組織ドメインの場合と同様に、存在しないドメインに対するフィードバックは望ましいものであり、役立つ場合があります。したがって、このようなエンティティはどちらも、自らが公開する DMARC ポリシー レコードに「rua=」タグを含めることを検討する必要があります。プライバシーに関する考慮事項については、セクション 10 を参照してください。
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 extensive network ranges. Domain Owners (Section 3.2.7) 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 Policy Record. Furthermore, Domain Owners should periodically review their SPF records to ensure that the authorization conveyed by the records matches the domain's current needs.
DMARC は本質的に SPF ポリシー レコードのセマンティクスを変更するものではありませんが、歴史的にそのようなポリシーの適用が緩かったため、多くの場合、多くの広範なネットワーク範囲を含む非常に広範なレコードが公開されてきました。ドメイン所有者 (セクション 3.2.7) は、DMARC ポリシー レコードを公開する前に、SPF レコードを注意深く確認して、ドメイン所有者に代わって送信することがどのネットワークに許可されているかを理解することを強くお勧めします。さらに、ドメイン所有者は SPF レコードを定期的に確認して、レコードによって伝えられる承認がドメインの現在のニーズと一致していることを確認する必要があります。
SPF was intended to be implemented early in the SMTP transaction, meaning it's possible for a message to fail SPF validation prior to any message content being transmitted, and so some Mail Receiver architectures might implement SPF in advance of any DMARC operations. This means that an SPF hard fail ("-") prefix on a sender's SPF mechanism, such as "-all", could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place, if the message fails SPF authentication checks. Domain Owners choosing to use "-all" to terminate SPF records should be aware of this and should understand that messages that might otherwise pass DMARC due to an aligned DKIM-Authenticated Identifier (Section 4.4.1) could be rejected solely due to an SPF fail. Moreover, messages rejected early in the SMTP transaction will never appear in aggregate DMARC reports, as the transaction will never proceed to the DATA phase, and so the RFC5322.From domain will never be revealed and its DMARC policy will never be discovered. Domain Owners and Mail Receivers (Section 3.2.11) can consult [M3SPF] and [M3AUTH] for more discussion of the topic and best practices regarding publishing SPF records and when to reject based solely on SPF failure.
SPF は SMTP トランザクションの早い段階で実装されることを目的としていました。つまり、メッセージ コンテンツが送信される前にメッセージが SPF 検証に失敗する可能性があるため、一部の Mail Receiver アーキテクチャでは DMARC 操作の前に SPF を実装する場合があります。これは、送信者の SPF メカニズムにある SPF ハード フェイル (「-」) プレフィックス (「-all」など) により、メッセージが SPF 認証チェックに失敗した場合、DMARC 処理が行われる前に、SMTP トランザクションの早い段階でメッセージが拒否される可能性があることを意味します。SPF レコードを終了するために "-all" を使用することを選択したドメイン所有者は、これを認識し、整列された DKIM 認証識別子 (セクション 4.4.1) により DMARC を通過する可能性があるメッセージが、SPF の失敗だけが原因で拒否される可能性があることを理解する必要があります。さらに、SMTP トランザクションの初期段階で拒否されたメッセージは、トランザクションが DATA フェーズに進むことがないため、集約 DMARC レポートに表示されることはありません。そのため、RFC5322.From ドメインが公開されることはなく、その DMARC ポリシーが検出されることもありません。ドメイン所有者とメール受信者 (セクション 3.2.11) は、SPF レコードの公開に関するトピックとベスト プラクティス、および SPF の失敗のみに基づいていつ拒否するかに関する詳細な議論について、[M3SPF] および [M3AUTH] を参照できます。
The DMARC mechanism calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification [RFC3464], since fraudulent messages caught and rejected using the DMARC mechanism would then result in the annoying generation of such failure reports that go back to the RFC5321.MailFrom address.
DMARC メカニズムでは、特定の状況下で SMTP セッション中にメッセージを拒否する必要があります。これは、DMARC メカニズムを使用して不正なメッセージが捕捉され拒否されると、RFC5321.MailFrom アドレスに戻るような迷惑なエラー レポートが生成されるため、配信ステータス通知 [RFC3464] を生成するよりも望ましい方法です。
This synchronous rejection is typically done in one of two ways:
この同期拒否は通常、次の 2 つの方法のいずれかで行われます。
* A "full rejection", wherein the SMTP server issues a 5xy reply code to the DATA command as an indication to the SMTP client that the transaction failed; the SMTP client is then responsible for generating a notification that delivery failed (see Section 4.2.5 of [RFC5321]).
* 「完全拒否」。SMTP サーバーは、トランザクションが失敗したことを SMTP クライアントに示すために、DATA コマンドに対して 5xy 応答コードを発行します。SMTP クライアントは、配信が失敗したという通知を生成する責任を負います ([RFC5321] のセクション 4.2.5 を参照)。
* 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 discards the message with no further action.
* 「サイレント破棄」。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 Mail Receiver (Section 3.2.11) might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. For example:
後者の場合、SMTP 拒否を行うときに明確なヒントを提供すると、問題の解決に役立ちます。メール受信者 (セクション 3.2.11) は、返信テキストのどこかに「DMARC」という単語を使用して、拒否の理由を平文で示す場合があります。例えば：
550 5.7.1 Email rejected per DMARC policy for example.com
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.
多くのシステムは、SMTP 応答テキストをスキャンして、拒否の性質を判断できます。したがって、機械で検出可能な拒否の理由を提供すると、拒否の原因となっている問題に自動システムで適切に対処できるようになります。
If a Mail Receiver elects to defer delivery due to the inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code.
メール受信者が DMARC ポリシーを取得または適用できないために配信を延期することを選択した場合、これは 4xy SMTP 応答コードを使用して行うのが最適です。
DMARC limits which end-to-end scenarios can achieve a "pass" result.
DMARC は、「合格」結果を達成できるエンドツーエンドのシナリオを制限します。
Because DMARC relies on SPF [RFC7208] and/or DKIM [RFC6376] to achieve a "pass", their limitations also apply.
DMARC は「パス」を達成するために SPF [RFC7208] や DKIM [RFC6376] に依存しているため、それらの制限も適用されます。
Issues specific to the use of policy mechanisms alongside DKIM are further discussed in [RFC6377], particularly Section 5.2.
DKIM と併用したポリシーメカニズムの使用に特有の問題については、[RFC6377]、特にセクション 5.2 でさらに議論されています。
Mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a "pass" result. A Domain Owner can use DMARC aggregate reports to identify this mail and take steps to address authentication shortcomings.
認可された独立したサードパーティによって送信されるメールは、識別子アライメントを使用して送信されない可能性があり、これも「合格」結果を妨げます。ドメイン所有者は、DMARC 集約レポートを使用してこのメールを特定し、認証の問題に対処するための措置を講じることができます。
As discussed in "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows" [RFC7960], the use of "p=reject" can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet.
「ドメインベースのメッセージ認証、レポート、および適合性 (DMARC) と間接電子メール フロー間の相互運用性の問題」[RFC7960] で説明されているように、「p=reject」の使用は、「同窓会転送者」、役割ベースの電子メール エイリアス、インターネット上のメーリング リストなどの間接メッセージ フローと互換性がなく、相互運用性の問題を引き起こす可能性があります。
As an example of this, a bank might send only targeted messages to account holders. Those account holders might have given their bank addresses such as "jones@alumni.example.edu" (an address that relays the messages to another address with a real mailbox) or "finance@association.example" (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, as the incoming IP address will be that of "example.edu" or "association.example" and not an IP address authorized by the originating RFC5321.MailFrom domain. DKIM signatures will generally remain valid in these relay situations.
この例として、銀行は、対象を絞ったメッセージのみを口座保有者に送信する場合があります。これらの口座所有者は、「jones@alumni.example.edu」（実際のメールボックスを使用して別のアドレスにメッセージを中継するアドレス）や「finance@association.example」（協会の現在の財務責任者に対して同様の中継を行う役割ベースのアドレス）などの銀行アドレスを指定している可能性があります。このようなメールが実際の受信者のメールボックスに配信される場合、受信 IP アドレスは「example.edu」または「association.example」の IP アドレスであり、発信元の RFC5321.MailFrom ドメインによって許可された IP アドレスではないため、RFC5321.MailFrom アドレスが中継 MTA によって書き換えられない限り、SPF チェックに失敗する可能性が高くなります。DKIM 署名は通常、このような中継状況でも有効なままです。
It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.
したがって、「p=reject」を公開するドメインは、SPF のみに依存して DMARC パスを保護してはならず、有効な DKIM 署名をメッセージに適用しなければならないことが重要です。
In the case of domains that have general users who send routine email, those that publish a Domain Owner Assessment Policy (Section 3.2.8) of "p=reject" are likely to create significant interoperability issues. In particular, if users in such domains post messages to mailing lists on the Internet, those messages can cause significant operational problems for the mailing lists and for the subscribers to those lists, as explained below and in [RFC7960].
日常的な電子メールを送信する一般ユーザーがいるドメインの場合、「p=reject」のドメイン所有者評価ポリシー (セクション 3.2.8) を公開しているドメインでは、重大な相互運用性の問題が発生する可能性があります。特に、そのようなドメインのユーザーがインターネット上のメーリング リストにメッセージを投稿する場合、以下および [RFC7960] で説明するように、それらのメッセージはメーリング リストとそのリストの加入者に重大な運用上の問題を引き起こす可能性があります。
It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject". Any such domains wishing to publish "p=reject" SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results. Domains that choose to publish "p=reject" SHOULD implement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered.
したがって、メーリング リストにメッセージを投稿する可能性のあるユーザーをホストするドメインは、「p=reject」のドメイン所有者評価ポリシーを公開すべきではないことが重要です。「p=reject」を公開したいそのようなドメインは、最初にドメインの DMARC 集約レポート データを利用して、ユーザーへの影響の可能性を判断する必要があります。最初に少なくとも 1 か月間「p=none」を公開し、続いて同じ長期間「p=quarantine」を公開し、メッセージの処理結果を比較する必要があります。「p=reject」を公開することを選択したドメインは、ユーザーがインターネットのメーリング リストに投稿しないポリシーを実装するか、メーリング リストへの参加が妨げられる可能性があることをユーザーに通知する必要があります。
As noted in Section 5.4, Mail Receivers (Section 3.2.11) need to apply more analysis than just DMARC validation in their disposition of incoming messages. An example of the consequences of honoring a Domain Owner Assessment Policy of "p=reject" without further analysis is that rejecting messages that have been relayed by a mailing list can cause the Mail Receiver's users to have their subscriptions to that mailing list canceled by the list software's automated handling of such rejections -- it looks to the list manager as though the recipient's email address is no longer working, so the address is automatically unsubscribed. An example of this scenario, albeit with DKIM Author Domain Signing Practices (ADSP) rather than DMARC, can be found in Section 5.2 of [RFC6377].
セクション 5.4 で述べたように、メール受信者 (セクション 3.2.11) は、受信メッセージの処理において DMARC 検証だけでなく、さらに多くの分析を適用する必要があります。さらなる分析を行わずに「p=reject」のドメイン所有者評価ポリシーを尊重した場合の結果の例としては、メーリング リストによって中継されたメッセージを拒否すると、メール受信者のユーザーがそのような拒否をリスト ソフトウェアで自動的に処理することによってメーリング リストへの登録がキャンセルされる可能性があります。リスト管理者には、受信者の電子メール アドレスが機能しなくなったかのように見えるため、アドレスは自動的に登録解除されます。このシナリオの例は、DMARC ではなく DKIM Author Domain Signing Practices (ADSP) を使用しているにもかかわらず、[RFC6377] のセクション 5.2 にあります。
It is therefore critical that Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. "Other knowledge and analysis" here might refer to observed sending patterns for properly authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were "p=quarantine" rather than "p=reject".
したがって、メール受信者は、送信ドメインによる「p=reject」ポリシーのみに基づいて受信メッセージを拒否してはいけないことが重要です。メール受信者は、他の知識や分析とともに、DMARC ポリシーを処理決定の一部として使用する必要があります。ここでの「その他の知識と分析」とは、送信ドメイン、コンテンツ フィルタリングなどを使用して適切に認証されたメールについて観察された送信パターンを指す場合があります。他の知識や分析がない場合、メール受信者は、そのような失敗したメールをポリシーが「p=reject」ではなく「p=quarantine」であるかのように扱わなければなりません（MUST）。
Failure to understand and abide by these considerations can cause legitimate, sometimes important, email to be rejected; can cause operational damage to mailing lists throughout the Internet; and can result in trouble-desk calls and complaints from the Mail Receiver's employees, customers, and clients.
これらの考慮事項を理解して遵守しないと、正当な、場合によっては重要な電子メールが拒否される可能性があります。インターネット全体のメーリング リストに運用上の損害を与える可能性があります。その結果、メール受信者の従業員、顧客、クライアントからトラブルデスクへの電話や苦情が発生する可能性があります。
In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider the effect of DMARC policies on their users' indirect mail, and it is unlikely that any advice in this document will change that. As a result, mail forwarded through mailing lists with unmodified From: header lines is frequently rejected due to a "p=reject" policy.
実際には、このアドバイスにもかかわらず、間接メール フローを受信するときに緩和手法を適用しているメール受信者はほとんどなく、ユーザーの間接メールに対する DMARC ポリシーの影響を考慮している組織もほとんどありません。また、このドキュメントのアドバイスがそれを変える可能性はほとんどありません。その結果、From: ヘッダー行が変更されていないメーリング リストを通じて転送されたメールは、「p=reject」ポリシーにより頻繁に拒否されます。
In the ten years since large consumer mail systems started publishing p=reject policies, mailing list software has all adopted workarounds to make the From: header line DMARC aligned. Some simply use the list's address, while others do per-address modifications intended to be reversible or to allow mail to be forwarded back to the original author, e.g., bob@example.com turned into bob=example.com@user.somelist.example. While these workarounds are far from ideal, they are firmly established and list operators treat them as a fact of life.
大規模な消費者メール システムが p=reject ポリシーを公開し始めてから 10 年間、メーリング リスト ソフトウェアはすべて、From: ヘッダー行 DMARC を揃えるための回避策を採用してきました。単純にリストのアドレスを使用するものもあれば、元に戻せることを目的とした、または元の作成者にメールを転送できるようにすることを目的としてアドレスごとに変更を行うものもあります (例: bob@example.com を bob=example.com@user.somelist.example に変更する)。これらの回避策は理想とはほど遠いものの、しっかりと確立されており、リスト管理者はこれらを現実のものとして扱います。
Mail developers have been trying for a decade to invent technical methods to allow mailing lists to continue to work without modifying the From: header line, with a prominent example being the Authenticated Received Chain (ARC) protocol described in [RFC8617]. While work continues, as of this document's publication, none of the methods have become widely used. Should such a technical method achieve widespread adoption in the future, this document can be updated to reflect that.
メール開発者は、From: ヘッダー行を変更せずにメーリング リストが機能し続けることを可能にする技術的方法を発明するために 10 年にわたって努力してきました。その顕著な例は、[RFC8617] で説明されている Authenticated Received Chain (ARC) プロトコルです。作業は続けられていますが、この文書の公開時点では、どの方法も広く使用されるようになっていません。このような技術的手法が将来的に広く採用されるようになった場合、このドキュメントはそれを反映するように更新される可能性があります。
This document describes the DMARC mechanism and allows Domain Owners and Mail Receivers some leeway in deciding which parts of the mechanism to implement. This section summarizes the requirements for full participation in DMARC, either by Domain Owners or by Mail Receivers.
この文書は DMARC メカニズムについて説明しており、ドメイン所有者とメール受信者がメカニズムのどの部分を実装するかを決定する自由度を与えます。このセクションでは、ドメイン所有者またはメール受信者が DMARC に完全に参加するための要件を要約します。
In order to fully participate in DMARC, Domain Owners:
DMARC に完全に参加するには、ドメイン所有者は次のことを行います。
* MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain.
* 作成者ドメインと識別子が一致する SPF 認証された識別子を生成するようにメールを送信しなければなりません。
* MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.
* 作成者ドメインと識別子が一致する DKIM 認証済み識別子を生成する DKIM 署名ドメインを持つメールを送信しなければなりません。
* MUST set up a mailbox to receive aggregate reports and collect and analyze those reports.
* 集約レポートを受信し、それらのレポートを収集および分析するには、メールボックスをセットアップしなければなりません。
* MUST publish a DMARC Policy Record for the Author Domain and the Organizational Domain, if it differs from the Author Domain.
* 作成者ドメインと組織ドメインが作成者ドメインと異なる場合は、そのドメインの DMARC ポリシー レコードを公開しなければなりません。
* MUST NOT rely solely on SPF for a DMARC pass if the DMARC policy for the Author Domain is "p=reject".
* 作成者ドメインの DMARC ポリシーが「p=reject」の場合、DMARC パスの SPF だけに依存してはなりません (MUST NOT)。
In order to fully participate in DMARC, Mail Receivers:
DMARC に完全に参加するには、メール受信者は次のことを行います。
* MUST check for the existence of a DMARC Policy Record for the Author Domain of an inbound mail message to determine if the DMARC mechanism applies to that message.
* DMARC メカニズムがそのメッセージに適用されるかどうかを判断するには、受信メール メッセージの作成者ドメインの DMARC ポリシー レコードの存在を確認しなければなりません (MUST)。
* MUST determine if Authenticated Identifiers exist for the message and preserve the results of those checks for future use in reporting if the DMARC mechanism applies to the message.
* 認証された識別子がメッセージに存在するかどうかを判断し、DMARC メカニズムがメッセージに適用されるかどうかをレポートする際に将来使用できるように、それらのチェックの結果を保存しなければなりません (MUST)。
* MUST conduct necessary Identifier Alignment checks if the DMARC mechanism applies for the message and Authenticated Identifiers exist.
* DMARC メカニズムがメッセージに適用され、認証された識別子が存在するかどうか、必要な識別子アラインメント チェックを実行しなければなりません (MUST)。
* MUST use the information from the checks for Authenticated Identifiers to determine if the DMARC validation result is "pass" or "fail" for the message.
* 認証された識別子のチェックからの情報を使用して、メッセージの DMARC 検証結果が「合格」か「失敗」かを判断しなければなりません。
* MUST support the "mailto:" URI for sending requested reports.
* 要求されたレポートを送信するために「mailto:」URI をサポートしなければなりません。
* SHOULD send aggregate reports on at least a daily basis.
* 少なくとも毎日、集計レポートを送信すべきです。
* MUST NOT reject messages solely on the basis of a "p=reject" policy for the Author Domain.
* 作成者ドメインの「p=reject」ポリシーのみに基づいてメッセージを拒否してはなりません。
This section describes actions completed by IANA.
このセクションでは、IANA によって完了されたアクションについて説明します。
The properties of an email message to be evaluated by an email authentication method have been registered by IANA in the "Email Authentication Methods" registry within the "Email Authentication Parameters" registry group.
電子メール認証方法によって評価される電子メール メッセージのプロパティは、IANA によって「電子メール認証パラメーター」レジストリ グループ内の「電子メール認証方法」レジストリに登録されています。
Each registration includes the authentication method; the specification that defines the authentication method; the property type (ptype), which is one of the ptype values from the entries in the "Email Authentication Property Types" registry in this same registry group; the property; the value for that property; the status of the property, which is one of "active" or "deprecated"; and its version. The designated expert needs to confirm that the provided specification adequately describes the property and the method for its evaluation and clearly presents how they would be used within the DMARC context by Domain Owners and Mail Receivers.
各登録には認証方法が含まれます。認証方法を定義する仕様。プロパティ タイプ (ptype)。これは、同じレジストリ グループ内の「電子メール認証プロパティ タイプ」レジストリのエントリの ptype 値の 1 つです。財産。そのプロパティの値。プロパティのステータス。「アクティブ」または「非推奨」のいずれか。とそのバージョン。指定された専門家は、提供された仕様がプロパティとその評価方法を適切に説明しており、ドメイン所有者とメール受信者が DMARC コンテキスト内でそれらをどのように使用するかを明確に示していることを確認する必要があります。
IANA has changed the registration procedure from Expert Review to Specification Required [RFC8126] and has listed this document as an additional reference for the registry. IANA has updated the registry as follows:
IANA は登録手順を専門家レビューから仕様要求 [RFC8126] に変更し、この文書をレジストリの追加参考資料としてリストしました。IANA はレジストリを次のように更新しました。
+======+============+======+========+===============+======+=======+
|Method| Definition |ptype |Property| Value |Status|Version|
+======+============+======+========+===============+======+=======+
|dmarc | RFC 9989 |header|from | The domain |active|1 |
| | | | | portion of | | |
| | | | | the | | |
| | | | | RFC5322.From | | |
| | | | | header field | | |
+------+------------+------+--------+---------------+------+-------+
|dmarc | RFC 9989 |policy|dmarc | The evaluated |active|1 |
| | | | | DMARC policy | | |
| | | | | applied / to | | |
| | | | | be applied | | |
| | | | | after policy | | |
| | | | | options have | | |
| | | | | been | | |
| | | | | processed. | | |
| | | | | Must be | | |
| | | | | "none", | | |
| | | | | "quarantine", | | |
| | | | | or "reject". | | |
+------+------------+------+--------+---------------+------+-------+
Table 3: Email Authentication Methods Registry Update
表 3: 電子メール認証方法レジストリの更新
Result codes for DMARC are registered with IANA in the "Email Authentication Result Names" registry within "Email Authentication Parameters" registry group.
DMARC の結果コードは、IANA の「電子メール認証パラメーター」レジストリ グループ内の「電子メール認証結果名」レジストリに登録されます。
Each registration includes the auth method; the code; the specification that defines the code; and the code's status, which is one of "active" or "deprecated". Note that the "Description" field is included here solely for the reader's reference and does not appear in the IANA registry. The designated expert needs to confirm that the provided specification adequately describes the result code and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
各登録には認証方法が含まれます。コード;コードを定義する仕様。コードのステータス (「アクティブ」または「非推奨」のいずれか)。「説明」フィールドは読者の参照のためにのみここに含まれており、IANA レジストリには表示されないことに注意してください。指定された専門家は、提供された仕様が結果コードを適切に説明しており、ドメイン所有者とメール受信者が DMARC コンテキスト内でそのコードをどのように使用するかを明確に示していることを確認する必要があります。
IANA has changed the registration procedure from Expert Review to Specification Required [RFC8126] and has listed this document as an additional reference for the registry. IANA has updated the registry as follows, replacing references to [RFC7489] with references to this document:
IANA は登録手順を専門家レビューから仕様要求 [RFC8126] に変更し、この文書をレジストリの追加参考資料としてリストしました。IANA はレジストリを次のように更新し、[RFC7489] への参照をこの文書への参照に置き換えました。
+===========+===========+===============+========+==================+
| Auth | Code | Specification | Status | Description |
| Method(s) | | | | |
+===========+===========+===============+========+==================+
| dmarc | fail | RFC 9989 | active | A DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain, but no |
| | | | | Authenticated |
| | | | | Identifier with |
| | | | | Identifier |
| | | | | Alignment |
| | | | | exists |
+-----------+-----------+---------------+--------+------------------+
| dmarc | none | RFC 9989 | active | No DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain |
+-----------+-----------+---------------+--------+------------------+
| dmarc | pass | RFC 9989 | active | A DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain, and an |
| | | | | Authenticated |
| | | | | Identifier with |
| | | | | Identifier |
| | | | | Alignment |
| | | | | exists |
+-----------+-----------+---------------+--------+------------------+
| dmarc | permerror | RFC 9989 | active | An error |
| | | | | occurred during |
| | | | | DMARC |
| | | | | evaluation that |
| | | | | is |
| | | | | unrecoverable, |
| | | | | such as the |
| | | | | retrieval of an |
| | | | | improperly |
| | | | | formatted DMARC |
| | | | | Policy Record. |
| | | | | A later attempt |
| | | | | is unlikely to |
| | | | | produce a final |
| | | | | result |
+-----------+-----------+---------------+--------+------------------+
| dmarc | temperror | RFC 9989 | active | An error |
| | | | | occurred during |
| | | | | DMARC |
| | | | | evaluation that |
| | | | | is likely |
| | | | | transient in |
| | | | | nature, such as |
| | | | | a DNS server |
| | | | | being |
| | | | | temporarily |
| | | | | unreachable. A |
| | | | | later attempt |
| | | | | might produce a |
| | | | | final result |
+-----------+-----------+---------------+--------+------------------+
Table 4: Email Authentication Result Names Registry Update
表 4: 電子メール認証結果名レジストリの更新
Names of tags used in DMARC Policy Records as part of "tag-value" pairs are registered with IANA in the "DMARC Tags" registry within the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group.
「タグと値」のペアの一部として DMARC ポリシー レコードで使用されるタグの名前は、IANA の「ドメインベースのメッセージ認証、レポート、および適合 (DMARC)」レジストリ グループ内の「DMARC タグ」レジストリに登録されます。
Entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [RFC8126]. Each registration includes the tag name, the specification that defines the tag, the status of the tag, and a brief description of the tag. The designated expert needs to confirm that the provided specification adequately describes the tag and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers. The "status" column is one of the following:
エントリは、[RFC8126] に従って要求される仕様の条件を満たす方法で文書化された値に対してのみ割り当てられます。各登録には、タグ名、タグを定義する仕様、タグのステータス、およびタグの簡単な説明が含まれます。指定された専門家は、提供された仕様がタグを適切に説明し、ドメイン所有者とメール受信者が DMARC コンテキスト内でタグを使用する方法を明確に示していることを確認する必要があります。「ステータス」列は次のいずれかです。
* "active", meaning the tag is in use in current implementations, and its specifications is expected to be stable
* 「アクティブ」。タグが現在の実装で使用されており、その仕様が安定していることが期待されることを意味します。
* "experimental", meaning the tag is relatively new and may be in use in some current implementations but not in others, and its specification is not expected to be stable
* 「実験的」は、タグが比較的新しく、現在の実装の一部では使用されている可能性がありますが、他の実装では使用されていない可能性があり、その仕様が安定するとは予想されていないことを意味します。
* "historic", meaning the tag is considered deprecated and is not expected to be in use in any current implementation
* 「歴史的」、タグが非推奨とみなされ、現在の実装で使用されることが予想されていないことを意味します
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 仕様に追加されたタグは、以前の仕様に準拠した実装によって処理されるときに既存のレコードのセマンティクスが変更されるのを避けるためのものです。
IANA has listed this document (rather than [RFC7489]) as the reference for the registry. IANA has updated the registry as follows, including the addition of the new "t" registration:
IANA は、この文書を ([RFC7489] ではなく) レジストリの参照としてリストしました。IANA は、新しい「t」登録の追加を含め、レジストリを次のように更新しました。
+=======+===========+==========+====================================+
| Tag | Reference | Status | Description |
| Name | | | |
+=======+===========+==========+====================================+
| adkim | RFC 9989 | active | DKIM Identifier Alignment |
| | | | mode |
+-------+-----------+----------+------------------------------------+
| aspf | RFC 9989 | active | SPF Identifier Alignment |
| | | | mode |
+-------+-----------+----------+------------------------------------+
| fo | RFC 9989 | active | Failure reporting options |
+-------+-----------+----------+------------------------------------+
| np | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy for non- |
| | | | existent subdomains |
+-------+-----------+----------+------------------------------------+
| p | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy |
+-------+-----------+----------+------------------------------------+
| pct | [RFC7489] | historic | Sampling rate |
+-------+-----------+----------+------------------------------------+
| psd | RFC 9989 | active | Indicates whether the DMARC |
| | | | Policy Record is published |
| | | | by a Public Suffix Domain |
+-------+-----------+----------+------------------------------------+
| rf | [RFC7489] | historic | Failure reporting format(s) |
+-------+-----------+----------+------------------------------------+
| ri | [RFC7489] | historic | Aggregate Reporting |
| | | | interval |
+-------+-----------+----------+------------------------------------+
| rua | RFC 9989 | active | Reporting URI(s) for DMARC |
| | | | aggregate feedback reports |
+-------+-----------+----------+------------------------------------+
| ruf | RFC 9989 | active | Reporting URI(s) for |
| | | | message-specific DMARC |
| | | | failure reports |
+-------+-----------+----------+------------------------------------+
| sp | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy for |
| | | | subdomains |
+-------+-----------+----------+------------------------------------+
| t | RFC 9989 | active | DMARC policy test mode |
+-------+-----------+----------+------------------------------------+
| v | RFC 9989 | active | DMARC specification version |
+-------+-----------+----------+------------------------------------+
Table 5: DMARC Tags Registry Update
表 5: DMARC タグ レジストリの更新
Names of DMARC failure reporting formats are registered with IANA in the "DMARC Report Formats" registry within the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group.
DMARC 障害レポート形式の名前は、IANA の「Domain-based Message Authentication, Reporting, and Conformance (DMARC)」レジストリ グループ内の「DMARC Report Formats」レジストリに登録されています。
Entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [RFC8126]. In addition to a reference to a permanent specification, each registration includes the format name, the format's status, and a brief description of the format. 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. The "status" column is one of the following:
エントリは、[RFC8126] に従って要求される仕様の条件を満たす方法で文書化された値に対してのみ割り当てられます。永続的な仕様への参照に加えて、各登録にはフォーマット名、フォーマットのステータス、およびフォーマットの簡単な説明が含まれます。指定された専門家は、提供された仕様がレポート形式を適切に説明し、ドメイン所有者とメール受信者が DMARC コンテキスト内でどのように使用するかを明確に示していることを確認する必要があります。「ステータス」列は次のいずれかです。
* "active", meaning the format is in use in current implementations, and its specifications is expected to be stable
* 「アクティブ」。形式が現在の実装で使用されており、仕様が安定していることが期待されることを意味します。
* "experimental", meaning the format is relatively new and may be in use in some current implementations but not in others, and its specification is not expected to be stable
* 「実験的」、形式が比較的新しく、現在の一部の実装では使用されている可能性がありますが、他の実装では使用されていない可能性があり、その仕様が安定するとは予想されていないことを意味します。
* "historic", meaning the format is considered deprecated and is not expected to be in use in any current implementation
* 「歴史的」、形式が非推奨とみなされ、現在の実装で使用される予定がないことを意味します。
IANA has listed this document (rather than [RFC7489]) as the reference for the registry. IANA has updated the registry as follows:
IANA は、この文書を ([RFC7489] ではなく) レジストリの参照としてリストしました。IANA はレジストリを次のように更新しました。
+========+===========+========+==================================+
| Format | Reference | Status | Description |
| Name | | | |
+========+===========+========+==================================+
| afrf | RFC 9989 | active | Authentication Failure Reporting |
| | | | Format (see [RFC6591]) |
+--------+-----------+--------+----------------------------------+
Table 6: DMARC Report Formats Registry Update
表 6: DMARC レポート形式レジストリの更新
The names of DNS Resource Records (RRs) beginning with an underscore character that are globally scoped (as per [RFC8552]) are registered with IANA in the "Underscored and Globally Scoped DNS Node Names" registry within the "Domain Name System (DNS) Parameters" registry group.
([RFC8552] に従って) グローバルにスコープ設定されたアンダースコア文字で始まる DNS リソース レコード (RR) の名前は、IANA の「ドメイン ネーム システム (DNS) パラメーター」レジストリ グループ内の「アンダースコア付きおよびグローバル スコープの DNS ノード名」レジストリに登録されます。
In addition to a reference to a permanent specification, each registration contains the DNS RR type and Node Name. The designated expert needs to confirm that the provided specification adequately describes the Node Name and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.
永続的な仕様への参照に加えて、各登録には DNS RR タイプとノード名が含まれます。指定された専門家は、提供された仕様がノード名を適切に説明しており、ドメイン所有者とメール受信者が DMARC コンテキスト内でノード名をどのように使用するかを明確に示していることを確認する必要があります。
IANA has updated the reference for following entry to point to this document (instead of [RFC7489]):
IANA は、([RFC7489] の代わりに) この文書を指すように、次のエントリのリファレンスを更新しました。
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| TXT | _dmarc | RFC 9989 |
+---------+------------+-----------+
Table 7: Underscored and Globally Scoped DNS Node Names Registry Update
表 7: 下線付きおよびグローバル スコープの DNS ノード名のレジストリ更新
This section discusses issues specific to private data that may be included if DMARC reports are requested. Issues associated with sending aggregate reports and failure reports are addressed in [RFC9990] and [RFC9991], respectively.
このセクションでは、DMARC レポートが要求された場合に含まれる可能性があるプライベート データに特有の問題について説明します。集計レポートと失敗レポートの送信に関連する問題は、それぞれ [RFC9990] と [RFC9991] で対処されています。
Aggregate reports may, particularly for small organizations, provide some limited insight into email sending patterns. As an example, in a small organization, an aggregate report from a particular domain may be sufficient to make the Report Consumer aware of sensitive personal or business information. If setting a "rua" tag in a DMARC Policy Record, the reporting address needs controls appropriate to the organizational requirements to mitigate any risk associated with receiving and handling reports.
集計レポートは、特に小規模な組織の場合、電子メール送信パターンに関する限定的な洞察を提供する場合があります。たとえば、小規模な組織では、特定のドメインからの集約レポートは、レポート利用者に機密の個人情報やビジネス情報を知らせるのに十分な場合があります。DMARC ポリシー レコードに「rua」タグを設定する場合、レポートの受信と処理に関連するリスクを軽減するために、レポート アドレスには組織の要件に適した制御が必要です。
In the case of "rua" requests for multi-organizational PSDs, additional information leakage considerations exist. Multi-organizational PSDs that do not mandate DMARC use by registrants risk exposure of private data of registrant domains if they include the "rua" tag in their DMARC Policy Record.
複数組織の PSD に対する「rua」リクエストの場合、追加の情報漏洩に関する考慮事項が存在します。登録者による DMARC の使用を義務付けていない複数組織の PSD では、DMARC ポリシー レコードに「rua」タグが含まれている場合、登録者ドメインの個人データが漏洩する危険があります。
Failure reports do provide insight into email sending patterns, including specific users. If requesting failure reports, data management controls are needed to support appropriate management of this information. The additional details available through failure reports (relative to aggregate reports) can drive a need for additional controls. As an example, a company may be legally restricted from receiving data related to a specific subsidiary. Before requesting failure reports, any such data spillage risks have to be addressed through data management controls or publishing DMARC Policy Records for relevant subdomains to prevent reporting on data related to their emails.
障害レポートは、特定のユーザーを含む電子メール送信パターンに関する洞察を提供します。障害レポートを要求する場合は、この情報の適切な管理をサポートするデータ管理コントロールが必要です。障害レポート (集計レポートと比較して) を通じて追加の詳細が得られるため、追加の制御の必要性が高まる可能性があります。たとえば、企業は特定の子会社に関連するデータの受信を法的に制限される場合があります。障害レポートをリクエストする前に、データ管理制御を通じて、または電子メールに関連するデータのレポートを防ぐために関連するサブドメインの DMARC ポリシー レコードを公開することで、このようなデータ流出リスクに対処する必要があります。
Due to the nature of the email contents that may be shared through failure reports, most Mail Receivers refuse to send them out of privacy concerns. Out-of-band agreements between Report Consumers and Mail Receivers may be required to address these concerns.
失敗レポートを通じて共有される電子メールの内容の性質上、ほとんどのメール受信者はプライバシー上の懸念からメールの送信を拒否します。これらの懸念に対処するには、レポート利用者とメール受信者の間で帯域外の合意が必要になる場合があります。
DMARC Policy Records for multi-organizational PSDs MUST NOT include the "ruf" tag.
複数組織の PSD の DMARC ポリシー レコードには、「ruf」タグを含めてはなりません。
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 で使用される認証方法のセキュリティに関する考慮事項は、参照によりここに組み込まれます。
Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTA that is authorized to do so. SPF policies map domain names to sets of authorized MTAs (see Section 11.4 of [RFC7208]). Validated DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record.
DMARC の基礎となる電子メール認証方法は両方とも、電子メールが送信を許可された MTA によって送信されたことをある程度保証します。SPF ポリシーは、ドメイン名を承認された MTA のセットにマッピングします ([RFC7208] のセクション 11.4 を参照)。検証された DKIM 署名は、公開された DKIM キー レコードと一致する秘密キーにアクセスする MTA によって電子メールが送信されたことを示します。
Whenever mail is sent, there is a risk that an overly permissive source may send mail that will receive a DMARC "pass" result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC "pass" results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for DMARC validation failures.
メールが送信されるたびに、過度に寛容な送信元が、実際にはドメイン所有者が意図していない DMARC「合格」結果を受け取るメールを送信する危険性があります。これらの結果は、メッセージが何らかの形で本物であることを示すために DMARC の「合格」結果をシステムが解釈するときに問題を引き起こす可能性があります。また、このような不正な送信者が、DMARC 検証失敗に対するドメイン所有者の意図したメッセージ処理を回避することもできます。
To avoid this risk, one must ensure that no unauthorized source can add DKIM signatures to the domain's mail or transmit mail that will evaluate as an SPF "pass" result. Nonetheless, if a Domain Owner wishes to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the "?" qualifier on the SPF record mechanism associated with that source. The DMARC Working Group had a lively discussion about possibly eliminating SPF entirely as an underlying authentication mechanism for DMARC, but consensus was not reached, and the suggestion to use the "?" qualifier for permissive sources is presented here instead.
このリスクを回避するには、無許可の送信元がドメインのメールに DKIM 署名を追加したり、SPF「合格」結果として評価されるメールを送信したりできないようにする必要があります。それにもかかわらず、ドメイン所有者がドメインの SPF レコードに許容的なソースを含めたい場合は、「?」を使用してそのソースを DMARC の考慮から除外できます。そのソースに関連付けられた SPF レコード メカニズムの修飾子。DMARC ワーキング グループでは、DMARC の基礎となる認証メカニズムとして SPF を完全に削除する可能性について活発な議論が行われましたが、合意に達せず、「?」を使用するという提案が出されています。代わりに、寛容なソースの修飾子がここに表示されます。
URIs published in DNS TXT records are well-understood possible targets for an attack. Specifications such as [RFC1035] and [RFC2142] either expose or cause the exposure of email addresses that could be flooded by an attacker, for example. Records found in the DNS such as MX, NS, and others 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. This all means that Domain Owners will need to harden these addresses against various attacks, including but not limited to:
DNS TXT レコードで公開された URI は、攻撃の対象となる可能性があることがよく知られています。[RFC1035] や [RFC2142] などの仕様は、攻撃者によってフラッドされる可能性のある電子メール アドレスを公開するか、公開する原因となります。MX、NS などの DNS で見つかったレコードは、潜在的な攻撃先をアドバタイズします。「www」などの一般的な DNS 名は、特定のサービスが見つかる場所を明確に識別し、標的型サービス拒否攻撃や侵入攻撃の宛先となります。これはすべて、ドメイン所有者が次のようなさまざまな攻撃に対してこれらのアドレスを強化する必要があることを意味します。
* high-volume denial-of-service attacks;
* 大量のサービス拒否攻撃。
* deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities; and
* 解析または処理の脆弱性を特定または悪用することを目的とした、不正なレポートの意図的な作成。そして
* 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.
* 侵害された既知のメール受信者からの虚偽のデータの可能性を含む、送信者または報告対象ドメインのフィールドに対する虚偽の主張を含むレポートの意図的な作成。
The DMARC mechanism and its underlying authentication mechanisms (SPF and DKIM) depend on the security of the DNS. Examples of how hostile parties can have an adverse impact on DNS traffic include:
DMARC メカニズムとその基礎となる認証メカニズム (SPF および DKIM) は、DNS のセキュリティに依存します。敵対的な当事者が DNS トラフィックに悪影響を与える可能性がある例は次のとおりです。
* If they can snoop on DNS traffic, they can get an idea of who is receiving mail using the domain(s) in question.
* DNS トラフィックを盗み見ることができれば、問題のドメインを使用してメールを誰が受信しているかを知ることができます。
* If they can block outgoing or reply DNS messages, they can prevent systems from discovering senders' DMARC policies.
* 発信または応答 DNS メッセージをブロックできれば、システムが送信者の DMARC ポリシーを検出するのを防ぐことができます。
* If they can send forged response packets, they can make aligned mail appear unaligned or vice versa.
* 偽造された応答パケットを送信できる場合、整列されたメールが整列されていないように見せたり、その逆を行うことができます。
None of these threats are unique to DMARC, and they can be addressed using a variety of techniques including, but not limited to, the following:
これらの脅威はいずれも DMARC に固有のものではなく、次のようなさまざまな手法を使用して対処できます。
* Signing DNS records with Domain Name System Security Extensions (DNSSEC) [RFC9364], which enables recipients to validate the integrity of DNS data and detect and discard forged responses.
* Domain Name System Security Extensions (DNSSEC) [RFC9364] を使用して DNS レコードに署名すると、受信者は DNS データの整合性を検証し、偽造された応答を検出して破棄できます。
* DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can mitigate snooping and forged responses.
* DNS over TLS [RFC7858] または DNS over HTTPS [RFC8484] は、スヌーピングや応答の偽造を軽減できます。
An increasingly common attack in messaging abuse is the presentation of false information in the display name portion of the RFC5322.From header 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.
メッセージングの悪用でますます一般的になっている攻撃は、RFC5322.From ヘッダー フィールドの表示名部分に虚偽の情報を提示することです。たとえば、その名前が正当に使用されているとエンド ユーザーを騙すことを目的として、そのフィールドの電子メール アドレスが任意のアドレスまたはドメイン名である一方で、表示名によく知られた名前 (人物、ブランド、役割など) が含まれている可能性があります。
Such attacks, known as display name attacks, are out of scope for DMARC.
表示名攻撃として知られるこのような攻撃は、DMARC の対象外です。
The declaration in Section 5.3.1 and elsewhere in this document that messages that do not contain precisely one RFC5322.From domain are outside the scope of this document exposes an attack vector that must be taken into consideration.
セクション 5.3.1 およびこの文書の他の場所で、RFC5322.From ドメインを 1 つだけ含まないメッセージはこの文書の範囲外であるという宣言は、考慮する必要がある攻撃ベクトルを明らかにしています。
Because such messages are outside the scope of this document, an attacker can craft messages with multiple RFC5322.From domains, including the spoofed domain, in an effort to bypass DMARC validation and get the fraudulent message to be displayed by the victim's Mail User Agent (MUA) with the spoofed domain successfully shown to the victim. In those cases where such messages are not rejected due to other reasons (for example, many such messages would violate the requirement described in [RFC5322] that there be precisely one From: header field), care must be taken by the Mail Receiver to recognize such messages as the threats they might be and handle them appropriately.
このようなメッセージはこの文書の範囲外であるため、攻撃者は、DMARC 検証をバイパスし、偽装ドメインを正常に表示した状態で被害者のメール ユーザー エージェント (MUA) によって不正なメッセージが表示されるようにするために、偽装ドメインを含む複数の RFC5322.From ドメインを使用してメッセージを作成する可能性があります。このようなメッセージが他の理由で拒否されない場合 (たとえば、そのようなメッセージの多くは、From: ヘッダー フィールドが 1 つだけ存在するという [RFC5322] で説明されている要件に違反します)、メール受信者はそのようなメッセージを脅威である可能性があるとして認識し、適切に処理するように注意する必要があります。
The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. Experience has shown that most such messages are abusive and/or unwanted by their recipients, and given this fact, a Mail Receiver may make a negative disposition decision for the message prior to and instead of its being subjected to DMARC processing. However, in a case where a Mail Receiver requires that the message be subject to DMARC validation, a recommended approach as per [RFC7489] is to apply the DMARC mechanism to each domain found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. Such an approach might prove useful for a small number of Author Domains, but it is possible that applying such logic to messages with a large number of domains (where "large" is defined by each Mail Receiver) will expose the Mail Receiver to a form of denial-of-service attack. Limiting the number of Author Domains processed will avoid this risk. If not all Author Domains are processed, then the DMARC evaluation is incomplete.
構文的に有効な複数値の RFC5322.From フィールドの場合には、特定の課題が生じます。経験上、そのようなメッセージのほとんどは、受信者にとって悪用および/または望ましくないものであることがわかっており、この事実を考慮すると、メール受信者は、DMARC 処理の対象となる前に、またはその代わりに、メッセージに対して否定的な処分決定を下す可能性があります。ただし、メール受信者がメッセージが DMARC 検証を受けることを要求する場合、[RFC7489] で推奨されるアプローチは、RFC5322.From フィールドで見つかった各ドメインに作成者ドメインとして DMARC メカニズムを適用し、失敗したチェックの中で選択された最も厳格なポリシーを適用することです。このようなアプローチは、少数の作成者ドメインには役立つかもしれませんが、そのようなロジックを多数のドメイン (「大規模」は各メール受信者によって定義されます) を持つメッセージに適用すると、メール受信者が一種のサービス拒否攻撃にさらされる可能性があります。処理される作成者ドメインの数を制限すると、このリスクを回避できます。すべての作成者ドメインが処理されていない場合、DMARC 評価は不完全です。
To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. To accommodate special cases, such as a need to get reports about domains that cannot actually receive mail, Section 3 of [RFC9990] describes a DNS-based mechanism for validating approved external reporting.
悪意のある者による悪用を避けるために、レポート アドレスは通常、レポートが要求されているドメイン内にある必要があります。実際にはメールを受信できないドメインに関するレポートを取得する必要があるなどの特殊なケースに対応するために、[RFC9990] のセクション 3 では、承認された外部レポートを検証するための 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 [RFC9364] is advisable if this is a concern.
実際の電子メールの内容が障害レポートに表示される可能性があるため、「ruf」タグで示されるアドレスは個人データとみなされる可能性のある詳細情報を受信することに注意してください。したがって、URI によって、「rua」タグで見つかったものよりも侵入を試みる魅力的なターゲットが存在することが特定されました。さらに、対象ドメインの DNS を攻撃して、障害データが攻撃者のシステムに不正にルーティングされるようにすることは、魅力的な可能性があります。これが懸念される場合は、DNSSEC [RFC9364] の導入をお勧めします。
This document encourages the use of secure transport mechanisms to prevent the loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms SHOULD be avoided.
この文書は、そのような送信を監視できる第三者への個人データの損失を防ぐために、安全な転送メカニズムの使用を奨励します。暗号化されていないメカニズムは避けるべきです(SHOULD)。
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.
特に、元々暗号化されているか他の方法で保護されていたメッセージが、安全に送信されていないレポートに表示される可能性があり、個人情報が漏洩する可能性があります。
The DMARC mechanism allows both DKIM- and SPF-Authenticated Identifiers (Section 4.4) to validate authorized use of an Author Domain (Section 3.2.2) on behalf of a Domain Owner (Section 3.2.7). If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain of the Organizational Domain, the subdomain can be used to generate email that achieves a DMARC pass on behalf of the Organizational Domain.
DMARC メカニズムにより、DKIM と SPF の両方の認証識別子 (セクション 4.4) が、ドメイン所有者 (セクション 3.2.7) に代わって作成者ドメイン (セクション 3.2.2) の使用が許可されていることを検証できます。悪意のあるユーザーまたは気づいていないユーザーが、組織ドメインのサブドメインの SPF レコードまたは DKIM セレクター レコードの制御を取得できる場合、そのサブドメインを使用して、組織ドメインに代わって DMARC パスを達成する電子メールを生成できます。
A scenario such as this could occur under the following conditions:
このようなシナリオは、次の状況で発生する可能性があります。
* A DMARC Policy Record exists for the domain "example.com", such that "example.com" is an Organizational Domain.
* DMARC ポリシー レコードはドメイン「example.com」に対して存在します。つまり、「example.com」は組織ドメインです。
* An attacker controls DNS for the domain "evil.example.com" and publishes an SPF record for that domain.
* 攻撃者はドメイン「evil.example.com」の DNS を制御し、そのドメインの SPF レコードを公開します。
* The attacker sends email with the RFC5322.From header field containing "foo@example.com" and an SPF-Authenticated Identifier of "evil.example.com".
* 攻撃者は、RFC5322.From ヘッダー フィールドに「foo@example.com」と SPF 認証識別子「evil.example.com」を含む電子メールを送信します。
Although this email was not authorized by the Domain Owner, it can produce a DMARC pass because the SPF-Authenticated Identifier ("evil.example.com") has Identifier Alignment with the Author Domain ("example.com").
この電子メールはドメイン所有者によって承認されていませんが、SPF 認証された識別子 (「evil.example.com」) が作成者ドメイン (「example.com」) と識別子を調整しているため、DMARC パスを生成できます。
The Organizational Domain Owner should be careful not to delegate control of subdomains if this is an issue and consider using the strict alignment (Section 3.2.10.2) option if appropriate.
組織のドメイン所有者は、これが問題となる場合はサブドメインの制御を委任しないように注意し、必要に応じて厳密な調整 (セクション 3.2.10.2) オプションの使用を検討する必要があります。
DMARC evaluation for relaxed alignment is also highly sensitive to errors in determining the Organizational Domain if the Author Domain does not have a published DMARC Policy Record (Section 3.2.6). If an incorrectly selected Organizational Domain is a parent of the correct Organizational Domain, then relaxed alignment could potentially allow a malicious sender to send mail that achieves a DMARC pass verdict. This potential exists for both the legacy [RFC7489] and current methods for determining the Organizational Domain; the latter is described in Section 4.10.2.
緩和された調整のための DMARC 評価も、作成者ドメインに公開された DMARC ポリシー レコード (セクション 3.2.6) がない場合、組織ドメインを決定する際のエラーの影響を非常に受けやすくなります。誤って選択された組織ドメインが正しい組織ドメインの親である場合、調整が緩和されると、悪意のある送信者が DMARC パス判定を達成するメールを送信できる可能性があります。この可能性は、組織ドメインを決定する従来の [RFC7489] 方法と現在の方法の両方に存在します。後者についてはセクション 4.10.2 で説明します。
The following example illustrates this possibility:
次の例は、この可能性を示しています。
* Mail is sent with an Author Domain of "a.mail.example.com" and Authenticated Identifiers of "mail.example.com".
* メールは「a.mail.example.com」の作成者ドメインと「mail.example.com」の認証済み識別子を使用して送信されます。
* There is no DMARC Policy Record published at "_dmarc.a.mail.example.com".
* 「_dmarc.a.mail.example.com」で公開されている DMARC ポリシー レコードはありません。
* There is one published at "_dmarc.mail.example.com" and this is intended to be the Organizational Domain for this message.
* 1 つは「_dmarc.mail.example.com」で公開されており、これはこのメッセージの組織ドメインとなることを目的としています。
* There is also a DMARC Policy Record published at "_dmarc.example.com", with default alignment (relaxed).
* 「_dmarc.example.com」で公開されている、デフォルトの配置 (緩和) の DMARC ポリシー レコードもあります。
* An attacker is able to send mail with the Author Domain of "evil.example.com" and an Authenticated Identifier of "mail.example.com".
* 攻撃者は、作成者ドメインが「evil.example.com」、認証済み識別子が「mail.example.com」のメールを送信できます。
In this scenario, if a Mail Receiver incorrectly determines the Organizational Domain to be "example.com", then the attacker's mail will pass DMARC validation checks.
このシナリオでは、メール受信者が組織ドメインを「example.com」と誤って判断した場合、攻撃者のメールは DMARC 検証チェックに合格します。
This issue is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email.
この問題は、厳密な調整を使用し、組織の電子メールで使用されるすべての作成者ドメインに対して明示的な DMARC ポリシー レコードを公開することによって完全に回避されます。
For cases where strict alignment is not appropriate, this issue can be mitigated by the Domain Owner periodically checking (perhaps weekly or whatever frequency might be appropriate for a given organization's operational needs) the DMARC Policy Records, if any, of PSDs (Section 3.2.15) above the Organizational Domain in the DNS tree (and for legacy [RFC7489], checking that appropriate PSL entries remain present). If a PSD publishes a DMARC Policy Record without the appropriate "psd=y" tag, Organizational Domain owners can add "psd=n" to their Organizational Domain's DMARC Policy Record so that the PSD's DMARC Policy Record will not be incorrectly interpreted to indicate that the PSD is the Organizational Domain.
厳密な調整が適切でない場合、この問題は、ドメイン所有者が DNS ツリー内の組織ドメインの上にある PSD (セクション 3.2.15) の DMARC ポリシー レコード (存在する場合) を定期的に (おそらく毎週、または特定の組織の運用ニーズに応じて適切な頻度で) チェックすることで軽減できます (レガシー [RFC7489] の場合は、適切な PSL エントリが存在するかどうかをチェックします)。PSD が適切な「psd=y」タグなしで DMARC ポリシー レコードを公開する場合、組織ドメインの所有者は、PSD の DMARC ポリシー レコードが PSD が組織ドメインであることを示すように誤って解釈されないように、組織ドメインの DMARC ポリシー レコードに「psd=n」を追加できます。
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/info/rfc4343>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the
Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
April 2012, <https://www.rfc-editor.org/info/rfc6591>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012,
<https://www.rfc-editor.org/info/rfc6651>.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
<https://www.rfc-editor.org/info/rfc6652>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>.
[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,
Reporting, and Conformance (DMARC) Aggregate Reporting",
RFC 9990, DOI 10.17487/RFC9990, May 2026,
<https://www.rfc-editor.org/info/rfc9990>.
[RFC9991] Jones, S., Ed. and A. Vesely, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC) Failure
Reporting", RFC 9991, DOI 10.17487/RFC9991, May 2026,
<https://www.rfc-editor.org/info/rfc9991>.
[M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Email Authentication Recommended Best
Practices",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg-email-authentication-recommended-best-practices-
09-2020.pdf>.
[M3SPF] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Best Practices for Managing SPF
Records",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg_managing-spf_records-2017-08.pdf>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003,
<https://www.rfc-editor.org/info/rfc3464>.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
DOI 10.17487/RFC4870, May 2007,
<https://www.rfc-editor.org/info/rfc4870>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc8617>.
[RFC9091] Kitterman, S. and T. Wicinski, Ed., "Experimental Domain-
Based Message Authentication, Reporting, and Conformance
(DMARC) Extension for Public Suffix Domains", RFC 9091,
DOI 10.17487/RFC9091, July 2021,
<https://www.rfc-editor.org/info/rfc9091>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
This section documents some design decisions made in the development of DMARC. Specifically addressed here are some suggestions that were considered but not included in the design, with explanatory text regarding the decision.
このセクションでは、DMARC の開発時に行われた設計上の決定について説明します。ここでは、検討されたものの設計には含まれなかったいくつかの提案と、決定に関する説明文を具体的に取り上げます。
S/MIME, or Secure Multipurpose Internet Mail Extensions [RFC8551], is a standard for encrypting and signing 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 [RFC8551]) は、メッセージ内の 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 (PKI), which means that distribution of keys used to validate 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) という重大な問題もあります。これは、署名の検証に使用されるキーの配布を組み込む必要があることを意味します。多くの場合、これだけでも大きな問題となります。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 are both 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 instruct Mail 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 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 [RFC4870], but on evolution to DKIM, this property was removed.
いくつかのメッセージ認証の取り組みでは、メーリング リストなどによるコンテンツの再メールを示す適切な方法として標準が示しているため、Sender ヘッダー フィールドで対象の識別子をチェックすることが提案されています。ごく最近では、これは DomainKeys [RFC4870] のプロトコル レベルのオプションでしたが、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 the 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. ユーザー保護の主なアプローチは、メッセージが表示されるときにユーザーに何が表示されるかを考慮することです。Sender フィールドが存在する場合、そのコンテンツをどうするかに関して MUA 間で一貫した動作はありません。したがって、送信者識別子のチェックをサポートするということは、エンド ユーザーが実際に見ることのない識別子にポリシーを適用することを意味し、DMARC が好む識別子を含む送信者フィールドを単純に偽造することによって、エンド ユーザーに対する攻撃のベクトルを作成する可能性があります。
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 validation algorithm in terms of which policy is to be applied and when.
3. 複数の方法でポリシーを検出できるようにすると、どのポリシーをいつ適用するかという点で、DMARC 検証アルゴリズムに許容できない曖昧さが生じます。
The presence of the "np" tag in this specification seemingly implies that there would be an agreed-upon standard for determining a domain's existence.
この仕様における「np」タグの存在は、ドメインの存在を決定するための合意された標準が存在することを暗示しているようです。
Since the DMARC mechanism is focused on email, one might think that the definition of "resolvable" in [RFC5321] applies. Using that definition, only names that resolve to MX RRs, A RRs, or AAAA RRs are deemed to be resolvable and to exist in the DNS. This is a common practice among Mail Receivers to determine whether or not to accept a mail message before performing other more expensive processing.
DMARC メカニズムは電子メールに焦点を当てているため、[RFC5321] の「解決可能」の定義が適用されると考える人もいるかもしれません。その定義を使用すると、MX RR、A RR、または AAAA RR に解決される名前のみが解決可能であり、DNS に存在するとみなされます。これは、他のより高価な処理を実行する前にメール メッセージを受け入れるかどうかを決定するための、メール受信者の間での一般的な方法です。
The DMARC mechanism makes no such requirement for the existence of specific DNS RRs in order for a domain to exist; instead, if any RR exists for a domain, then the domain exists. To use the terminology from [RFC2308], an "NXDOMAIN" response (rcode "Name Error") to a DNS query means that the domain name does not exist, while a "NODATA" response (rcode "NOERROR") means that the given RR type queried for does not exist, but the domain name does.
DMARC メカニズムでは、ドメインが存在するために特定の DNS RR が存在する必要はありません。代わりに、ドメインに RR が存在する場合、そのドメインは存在します。[RFC2308] の用語を使用すると、DNS クエリに対する "NXDOMAIN" 応答 (rcode "Name Error") はドメイン名が存在しないことを意味し、"NODATA" 応答 (rcode "NOERROR") はクエリされた指定された RR タイプは存在しないが、ドメイン名は存在することを意味します。
Furthermore, in keeping with [RFC8020], if a query for a name returns NXDOMAIN, then not only does the name not exist, every name below it in the DNS hierarchy also does not exist.
さらに、[RFC8020] に従って、名前のクエリが NXDOMAIN を返した場合、その名前が存在しないだけでなく、DNS 階層内でその下にあるすべての名前も存在しません。
An earlier informational version of the DMARC mechanism [RFC7489] noted that 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. That version further mentioned suggestions that have been made that attempt to glean such information from SOA or NS RRs, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries.
DMARC メカニズムの以前の情報バージョン [RFC7489] では、任意のドメイン名から「レコードのドメイン」、つまりドメイン レジストラに実際に登録されたドメインを特定できる方法が DNS には提供されていないと記載されています。このバージョンではさらに、SOA または NS RR からそのような情報を収集しようとする提案についても言及されていますが、DNS の分割が常に管理境界で行われるわけではないため、これらも完全に信頼できるものではありません。
That previous version posited that one could "climb the tree" to find the Organizational Domain but expressed concern that an attacker could exploit this for a denial-of-service attack through sending a high number of messages, each with a relatively large number of nonsense labels, causing a Mail Receiver to perform a large number of DNS queries in search of a DMARC Policy Record. This version defines a method for performing a DNS Tree Walk (Section 4.10) and further mitigates the risk of the denial-of-service attack by expressly limiting the number of DNS queries to execute regardless of the number of labels in the domain name.
以前のバージョンでは、組織ドメインを見つけるために「ツリーに登る」ことができると想定していましたが、攻撃者がこれを悪用して、それぞれに比較的多数の意味のないラベルが付いた大量のメッセージを送信し、メール受信者が DMARC ポリシー レコードを検索するために大量の DNS クエリを実行させることにより、サービス拒否攻撃に悪用する可能性があると懸念を表明しました。このバージョンでは、DNS ツリー ウォーク (セクション 4.10) を実行する方法が定義されており、ドメイン名のラベルの数に関係なく、実行する DNS クエリの数を明示的に制限することで、サービス拒否攻撃のリスクがさらに軽減されます。
Readers curious about the previous method for Organizational Domain Discovery are directed to Section 3.2 of [RFC7489].
組織ドメイン検出の以前の方法に興味のある読者は、[RFC7489] のセクション 3.2 を参照してください。
An earlier informational version of the DMARC mechanism [RFC7489] included a "pct" tag and specified all integers from 0 to 100 inclusive as valid values for the tag. The intent of the tag was to provide Domain Owners with a method to gradually change their preferred Domain Owner Assessment Policy (the "p" tag) from "none" to "quarantine" or from "quarantine" to "reject" by requesting the stricter treatment for just a percentage of messages that produced DMARC results of "fail".
DMARC メカニズムの以前の情報バージョン [RFC7489] には、「pct」タグが含まれており、タグの有効な値として 0 から 100 までのすべての整数が指定されていました。このタグの目的は、DMARC 結果が「失敗」となったメッセージの一部に対してより厳格な処理を要求することで、ドメイン所有者が優先するドメイン所有者評価ポリシー (「p」タグ) を「なし」から「隔離」、または「隔離」から「拒否」に段階的に変更する方法を提供することでした。
Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another. The default value was easily implemented, as it required no special processing on the part of the Mail Receiver, while the value of 0 took on unintended significance as a value used by some intermediaries and mailbox providers as an indicator to deviate from standard handling of the message, usually by rewriting the RFC5322.From header field in an effort to avoid DMARC failures downstream.
運用経験から、指定された値が 0 または 100 (デフォルト) でない限り、「pct」タグは通常正確に適用されず、他の値の不正確さは実装ごとに大きく異なることがわかりました。デフォルト値は、メール受信側で特別な処理を必要としないため、簡単に実装できました。一方、値 0 は、通常、ダウンストリームでの DMARC エラーを回避するために RFC5322.From ヘッダー フィールドを書き換えることにより、メッセージの標準処理から逸脱する指標として一部の仲介者やメールボックス プロバイダーによって使用される値として意図しない重要性を持ちました。
These custom actions when the "pct" tag was set to 0 proved valuable to the email community. In particular, header field rewriting by an intermediary meant that a Domain Owner's aggregate reports could reveal to the Domain Owner how much of its traffic was routing through intermediaries that don't rewrite the RFC5322.From header field. Such information wasn't explicit in the aggregate reports received; rather, sussing it out required work on the part of the Domain Owner to compare aggregate reports from before and after the "p" value was changed and "pct=0" was included in the DMARC Policy Record, but the data was there. Consequently, knowing how much mail was subject to possible DMARC failure due to a lack of RFC5322.From header field rewriting by intermediaries could assist the Domain Owner in choosing whether to move from Monitoring Mode (Section 3.2.12) to Enforcement (Section 3.2.9). Armed with this knowledge, the Domain Owner could make an informed decision regarding subjecting its mail traffic to possible DMARC failures based on the Domain Owner's tolerance for such things.
「pct」タグが 0 に設定されている場合のこれらのカスタム アクションは、電子メール コミュニティにとって価値があることが証明されました。特に、仲介者によるヘッダー フィールドの書き換えは、ドメイン所有者の集計レポートにより、RFC5322.From ヘッダー フィールドを書き換えない仲介者を介してルーティングされているトラフィックの量をドメイン所有者に明らかにできることを意味します。このような情報は、受け取った集計レポートでは明示されていませんでした。むしろ、それを突き止めるには、ドメイン所有者側で、「p」値が変更され、「pct=0」が DMARC ポリシー レコードに含まれる前後の集計レポートを比較する作業が必要でしたが、データはそこにありました。その結果、仲介者による RFC5322.From ヘッダー フィールドの書き換えの欠如により、どの程度のメールが DMARC 障害の可能性を受けたかを知ることは、ドメイン所有者が監視モード (セクション 3.2.12) から強制 (セクション 3.2.9) に移行するかどうかを選択するのに役立つ可能性があります。この知識があれば、ドメイン所有者は、そのようなことに対するドメイン所有者の許容度に基づいて、メール トラフィックを DMARC 障害にさらす可能性について、十分な情報に基づいた決定を下すことができます。
Because of the value provided by "pct=0" to Domain Owners, it was logical to keep this functionality in the protocol; at the same time, it didn't make sense to support a tag named "pct" that had only two valid values. This version of the DMARC mechanism, therefore, introduces the "t" tag as shorthand for "testing", with the valid values of "y" and "n", which are meant to be analogous in their application by mailbox providers and intermediaries to the "pct" tag values "0" and "100", respectively.
「pct=0」によってドメイン所有者に提供される値のため、この機能をプロトコルに保持するのは論理的でした。同時に、有効な値が 2 つしかない「pct」という名前のタグをサポートするのは意味がありません。したがって、このバージョンの DMARC メカニズムでは、「testing」の短縮形として「t」タグが導入され、有効な値は「y」と「n」になります。これらは、メールボックス プロバイダーや仲介者によるアプリケーションにおいて、それぞれ「pct」タグの値「0」と「100」に類似することを意図しています。
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 header fields and relevant SMTP commands are shown, as message bodies are not considered when conducting DMARC checks.
次の例は、DMARC メカニズムによる識別子のアラインメントの使用法を示しています。DMARC チェックを実行する際にはメッセージ本文は考慮されないため、簡潔にするために、メッセージ ヘッダー フィールドと関連する SMTP コマンドのみが示されています。
The following SPF examples assume that SPF produces a passing result. Alignment cannot exist if SPF does not produce a passing result.
次の SPF の例は、SPF が合格する結果を生成することを前提としています。SPF が合格結果を生成しない場合、アライメントは存在できません。
Example 1: SPF in Strict 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 domain and the Author Domain are identical. Thus, the identifiers are in strict alignment.
この場合、RFC5321.MailFrom ドメインと作成者ドメインは同一です。したがって、識別子は厳密に一致しています。
Example 2: SPF in Relaxed Alignment:
例 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 Author Domain (example.com) is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in relaxed alignment because they both have the same Organizational Domain (example.com).
この場合、作成者ドメイン (example.com) は RFC5321.MailFrom ドメインの親です。したがって、両方の識別子が同じ組織ドメイン (example.com) を持っているため、これらの識別子は緩和された配置になります。
Example 3: No SPF Identifier 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 domain is neither the same as, a parent of, nor a child of the Author Domain. Thus, the identifiers are not in alignment.
この場合、RFC5321.MailFrom ドメインは、作成者ドメインと同じでも、その親でも、子でもありません。したがって、識別子は一致していません。
The examples below assume that the DKIM signatures pass validation. Alignment cannot exist with a DKIM signature that does not validate.
以下の例では、DKIM 署名が検証に合格すると想定しています。検証されていない DKIM 署名では、アライメントは存在できません。
Example 1: DKIM in Strict 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" tag and the Author Domain have identical DNS domains. Thus, the identifiers are in strict alignment.
この場合、DKIM の「d」タグと作成者ドメインは同一の DNS ドメインを持ちます。したがって、識別子は厳密に一致しています。
Example 2: DKIM in Relaxed Alignment:
例 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" tag includes a DNS domain that is a parent of the Author Domain. Thus, the identifiers are in relaxed alignment, as they have the same Organizational Domain (example.com).
この場合、DKIM 署名の「d」タグには、作成者ドメインの親である DNS ドメインが含まれています。したがって、識別子は同じ組織ドメイン (example.com) を持っているため、緩和された配置になります。
Example 3: No DKIM Identifier Alignment:
例 3: DKIM 識別子のアライメントなし:
DKIM-Signature: v=1; ...; d=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 DKIM signature's "d" tag includes a DNS domain that is neither the same as, a parent of, nor a child of the Author Domain. Thus, the identifiers are not in alignment.
この場合、DKIM 署名の「d」タグには、作成者ドメインと同じでも、その親でも、子でもない 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 DMARC Policy Record for the Domain Owner's Organizational Domain.
DMARC の使用を希望するドメイン所有者は、すでに SPF と DKIM を展開してテストしておく必要があります。次のステップは、ドメイン所有者の組織ドメインの DMARC ポリシー レコードを公開することです。
The Domain Owner for "example.com" has deployed SPF and DKIM on its messaging infrastructure. The Domain Owner wishes to begin using DMARC with a policy that will solicit aggregate feedback from Mail Receivers without affecting how the messages are processed in order to:
「example.com」のドメイン所有者は、メッセージング インフラストラクチャに SPF と DKIM を展開しました。ドメイン所有者は、次の目的で、メッセージの処理方法に影響を与えることなく、メール受信者からの集約フィードバックを求めるポリシーで DMARC の使用を開始したいと考えています。
* Confirm that its legitimate messages are authenticating correctly
* 正当なメッセージが正しく認証されていることを確認します
* Validate that all authorized message sources have implemented authentication measures
* すべての承認されたメッセージ ソースが認証手段を実装していることを検証する
* Determine how many messages from other sources would be affected by publishing a Domain Owner Assessment Policy at Enforcement
* 施行時にドメイン所有者評価ポリシーを公開することによって影響を受ける他のソースからのメッセージの数を決定する
The Domain Owner accomplishes this by constructing a DMARC Policy Record indicating that:
ドメイン所有者は、以下を示す DMARC ポリシー レコードを構築することでこれを実現します。
* The version of DMARC being used is "DMARC1" ("v=DMARC1;")
* 使用されているDMARCのバージョンは「DMARC1」(「v=DMARC1;」)です。
* Mail Receivers should not alter how they treat these messages because of this DMARC Policy Record ("p=none")
* メール受信者は、この DMARC ポリシー レコード (「p=none」) を理由に、これらのメッセージの処理方法を変更しないでください。
* Aggregate feedback reports are sent via email to the address "dmarc-feedback@example.com" ("rua=mailto:dmarc-feedback@example.com")
* 集計フィードバック レポートは、電子メールでアドレス「dmarc-フィードバック@example.com」（「rua=mailto:dmarc-フィードバック@example.com」）に送信されます。
* All messages from this Organizational Domain are subject to this policy (no "t" tag present, so the default of "n" applies)
* この組織ドメインからのすべてのメッセージは、このポリシーの対象になります (「t」タグが存在しないため、デフォルトの「n」が適用されます)
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 Policy Record for the domain example.com
_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. To diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.
前の例のドメイン所有者は、集約レポートを使用して、DKIM がまだ正しく実装されていない一部のメッセージング システムを検出しましたが、依然として定期的な認証エラーが発生しています。これらの断続的な問題を診断するために、認証エラーが発生したときにメッセージごとのエラー レポートを要求したいと考えています。
Not all Mail 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 failure report format [RFC9991] meets the Domain Owner's needs in this scenario.
すべてのメール受信者がそのような要求を受け入れるわけではありませんが、ドメイン所有者は、受信したレポートはすべて、この記録の公開を正当化するのに十分役立つと考えています。デフォルトのメッセージごとの障害レポート形式 [RFC9991] は、このシナリオにおけるドメイン所有者のニーズを満たします。
The Domain Owner accomplishes this by adding the following to its DMARC Policy Record from Appendix B.2.1:
ドメイン所有者は、付録 B.2.1 の DMARC ポリシー レコードに次の内容を追加することでこれを実現します。
* Per-message failure reports are sent via email to the address "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
* メッセージごとの失敗レポートは、電子メールでアドレス「auth-reports@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 Policy Record for the domain example.com
_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 serve as a Report Consumer. Again, not all Mail Receivers will honor this request, but those that do MUST implement additional checks to validate that the third party authorizes reception of failure reports on behalf of this domain.
前の例のドメイン所有者は同じポリシーを維持していますが、今度はサードパーティをレポート コンシューマとして機能させることを希望しています。繰り返しますが、すべてのメール受信者がこの要求を受け入れるわけではありませんが、この要求を受け入れるメール受信者は、サードパーティがこのドメインに代わって障害レポートの受信を許可していることを検証する追加のチェックを実装しなければなりません (MUST)。
The Domain Owner needs to alter its DMARC Policy Record from Appendix B.2.2 as follows:
ドメイン所有者は、付録 B.2.2 の DMARC ポリシー レコードを次のように変更する必要があります。
* Per-message failure reports are sent via email to the address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth-reports@thirdparty.example.net")
* メッセージごとの失敗レポートは、電子メールでアドレス「auth-reports@thirdparty.example.net」（「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 Policy Record for the domain example.com
_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 Mail Receivers MUST implement additional checks as described in Section 3 of [RFC9990]. To pass these additional checks, the Report Consumer's Domain Owner will need to publish an additional DMARC Policy Record as follows:
「ruf」タグで使用されるアドレスは、このレコードが公開される組織ドメインの外にあるため、準拠するメール受信者は、[RFC9990] のセクション 3 に記載されている追加のチェックを実装しなければなりません (MUST)。これらの追加チェックに合格するには、レポート利用者のドメイン所有者は、次のように追加の DMARC ポリシー レコードを公開する必要があります。
* Given the DMARC Policy Record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the Report Consumer will need to publish a TXT RR at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1;" to authorize receipt of the reports.
* ドメイン所有者によって「_dmarc.example.com」で公開された DMARC ポリシー レコードがある場合、レポート コンシューマの DNS 管理者は、値「v=DMARC1;」を使用して TXT RR を「example.com._report._dmarc.thirdparty.example.net」で公開する必要があります。レポートの受信を承認するため。
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):
このようなレコードを公開するには、DNS 管理者 (example.net など) が適切なゾーン ファイル (従来のゾーン ファイル形式に従って) に次のようなエントリを作成します。
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
example.com._report._dmarc IN TXT "v=DMARC1;"
The third-party Report Consumer can also publish "rua" and "ruf" tags in order to override the specific address published by example.com with a different address in the same third-party domain. This may be necessary if the third-party Report Consumer has changed its email address or wants to guard against typos in the DMARC Policy Record of the Author Domain. Intermediaries and other third parties should refer to Section 3 of [RFC9990] for the full details of this mechanism.
サードパーティのレポート コンシューマは、example.com によって公開された特定のアドレスを同じサードパーティ ドメイン内の別のアドレスで上書きするために、「rua」タグと「ruf」タグを公開することもできます。これは、サードパーティのレポート利用者が電子メール アドレスを変更した場合、または作成者ドメインの DMARC ポリシー レコードのタイプミスを防ぎたい場合に必要になる場合があります。仲介者およびその他の第三者は、このメカニズムの詳細については [RFC9990] のセクション 3 を参照する必要があります。
The third-party Report Consumer accomplishes this by adding the following to its DMARC Policy Record from Appendix B.2.3:
サードパーティのレポート コンシューマは、付録 B.2.3 の DMARC ポリシー レコードに以下を追加することでこれを実現します。
* The override address for aggregate reports is "aggregate-reports@thirdparty.example.net" ("rua=mailto:aggregate-reports@thirdparty.example.net")
* 集計レポートの上書きアドレスは「aggregate-reports@thirdparty.example.net」 (「rua=mailto:aggregate-reports@thirdparty.example.net」) です。
* The override address for failure reports is "failure-reports@thirdparty.example.net" ("ruf=mailto:failure-reports@thirdparty.example.net")
* 障害レポートの上書きアドレスは「failure-reports@thirdparty.example.net」（「ruf=mailto:failure-reports@thirdparty.example.net」）です。
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):
このようなレコードを公開するには、DNS 管理者 (example.net など) が適切なゾーン ファイル (従来のゾーン ファイル形式に従って) に次のようなエントリを作成します。
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
; Override destination mailboxes
example.com._report._dmarc IN TXT (
"v=DMARC1; "
"rua=mailto:aggregate-reports@thirdparty.example.net; "
"ruf=mailto:failure-reports@thirdparty.example.net" )
In this case, only the "ruf" tag is actually overridden, because in the previous example, failure reporting is the only reporting type that was directed to the third-party Report Consumer.
この場合、実際には「ruf」タグのみがオーバーライドされます。これは、前の例では、障害レポートがサードパーティのレポート コンシューマに送信された唯一のレポート タイプであるためです。
The Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services. It now wishes to express a handling preference for messages from this subdomain that fail DMARC validation to indicate to participating Mail Receivers that use of this domain is not valid.
ドメイン所有者は、メッセージング サービスの運用前テストに使用されるサブドメインに SPF と DKIM を実装しました。ここでは、DMARC 検証に失敗したこのサブドメインからのメッセージの処理設定を表現し、参加しているメール受信者にこのドメインの使用が無効であることを示したいと考えています。
As a first step, it will express that it considers messages using this subdomain that fail DMARC validation to be suspicious. The goal here will be to enable examination of messages sent to mailboxes hosted by participating Mail Receivers as a method for troubleshooting any existing authentication issues. Aggregate feedback reports will be sent to a mailbox within the Organizational Domain and to a mailbox at a Report Consumer selected and authorized to receive them by the Domain Owner.
最初のステップとして、DMARC 検証に失敗したこのサブドメインを使用するメッセージを疑わしいとみなすことを表明します。ここでの目標は、既存の認証問題をトラブルシューティングする方法として、参加しているメール受信者によってホストされているメールボックスに送信されたメッセージを検査できるようにすることです。集約フィードバック レポートは、組織ドメイン内のメールボックスと、ドメイン所有者によって選択され受信を許可されたレポート コンシューマのメールボックスに送信されます。
The Domain Owner will accomplish this by constructing a DMARC Policy Record indicating that:
ドメイン所有者は、以下を示す DMARC ポリシー レコードを構築することでこれを実現します。
* The version of DMARC being used is "DMARC1" ("v=DMARC1;")
* 使用されているDMARCのバージョンは「DMARC1」(「v=DMARC1;」)です。
* It is applied only to this subdomain (the DMARC Policy Record is published at "_dmarc.test.example.com" and not "_dmarc.example.com")
* このサブドメインにのみ適用されます (DMARC ポリシー レコードは、「_dmarc.example.com」ではなく「_dmarc.test.example.com」で公開されます)
* Mail Receivers are advised that the Domain Owner considers messages that fail to authenticate to be suspicious ("p=quarantine")
* メール受信者には、ドメイン所有者が認証に失敗したメッセージを疑わしいものと見なすことが通知されます (「p=quarantine」)。
* Aggregate feedback reports are sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net" ("rua=mailto:dmarc-feedback@example.com, mailto:example-tld-test@thirdparty.example.net")
* 集計フィードバック レポートは、電子メール経由でアドレス「dmarc-フィードバック@example.com」および「example-tld-test@thirdparty.example.net」（「rua=mailto:dmarc-フィードバック@example.com、mailto:example-tld-test@thirdparty.example.net」）に送信されます。
* The Domain Owner desires only that an actor performing a DMARC validation check apply any special handling rules it might have in place, such as rewriting the RFC53322.From header field; the Domain Owner is testing its setup at this point and so does not want the Domain Owner Assessment Policy to be applied ("t=y").
* ドメイン所有者は、DMARC 検証チェックを実行するアクターが、RFC53322.From ヘッダー フィールドの書き換えなど、独自に設定されている特別な処理ルールを適用することだけを望みます。ドメイン所有者はこの時点でセットアップをテストしているため、ドメイン所有者評価ポリシーの適用を望んでいません (「t=y」)。
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 Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net; "
"t=y" )
Once enough time has passed to allow for collecting enough reports to give the Domain Owner confidence that all authorized email sent using the subdomain is properly authenticating and passing DMARC validation checks, then the Domain Owner can update the DMARC Policy Record to indicate that it considers validation failures to be a clear indication that use of the subdomain is not valid. It would do this by altering the record to advise Mail Receivers of its position on such messages ("p=reject") and removing the testing flag ("t=y").
サブドメインを使用して送信されたすべての承認された電子メールが適切に認証され、DMARC 検証チェックに合格しているという確信をドメイン所有者に与えるのに十分なレポートを収集できる十分な時間が経過すると、ドメイン所有者は DMARC ポリシー レコードを更新して、検証の失敗をサブドメインの使用が無効であることを示す明確な兆候と見なすことを示すことができます。これは、メール受信者にそのようなメッセージに関する位置を通知するようにレコードを変更し (「p=reject」)、テスト フラグを削除する (「t=y」) ことによって行われます。
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 Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=reject; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net" )
A Mail Receiver that wants to participate in 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 Consumers).
DMARC に参加したいメール受信者は、すでに SPF と DKIM をチェックしており、さまざまな電子メール処理段階から関連情報を収集して、ドメイン所有者に (おそらくレポート コンシューマー経由で) フィードバックを提供する機能を備えている必要があります。
An optimal DMARC-enabled Mail Receiver performs validation and Identifier Alignment checking during the SMTP [RFC5321] conversation.
最適な DMARC 対応のメール受信者は、SMTP [RFC5321] 会話中に検証と識別子の整合チェックを実行します。
Before 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 Record lookup.
3. DMARC ポリシー レコードのルックアップ。
The presence of an Author Domain DMARC Policy 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 Policy 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 Policy 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 Policy Record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"
In the above sample, the SPF-Authenticated Identifier and the DKIM-Authenticated Identifier both align with the Author Domain. The Mail Receiver considers the above email to pass the DMARC check, avoiding the "reject" policy that is requested to be applied to email that fails the DMARC validation check.
上記のサンプルでは、SPF 認証識別子と DKIM 認証識別子の両方が作成者ドメインと一致しています。メール受信者は、上記の電子メールが DMARC チェックに合格したものとみなし、DMARC 検証チェックに失敗した電子メールに適用するように要求される「拒否」ポリシーを回避します。
If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the Domain Owner Assessment Policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner Assessment 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 Assessment Policy.
認証された識別子が作成者ドメインと一致しない場合、メール受信者はドメイン所有者評価ポリシーを適用します。ただし、このアクションが実行される前に、メール受信者は外部情報を参照して、ドメイン所有者評価ポリシーをオーバーライドできます。たとえば、この特定の電子メールが既知の信頼できるフォワーダー (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 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 チェックで合格メッセージが得られた場合、Mail Receiver は電子メールの処理を続行し、おそらく DMARC チェックの結果をドメイン レピュテーション クエリなどの追加の処理モジュールへの入力として使用します。
Before exiting DMARC-specific processing, the Mail Receiver checks to see if the Author Domain DMARC Policy Record requests reporting based on an Authentication Failure Reporting Format (AFRF). If so, then the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC Policy Record.
DMARC 固有の処理を終了する前に、メール受信者は、作成者ドメインの 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 unnecessary if the Domain Owner has not requested aggregate reports, i.e., no "rua" tag was found in the policy record.
DMARC 固有の処理の終了時に、Mail Receiver は DMARC 処理の結果を (ログ記録またはデータ ストアへの直接挿入を通じて) キャプチャします。取得した情報は、ドメイン所有者が利用するためのフィードバックを構築するために使用されます。ドメイン所有者が集約レポートを要求していない場合、つまりポリシー レコード内に「rua」タグが見つからなかった場合、これは不要です。
If an Author Domain has no DMARC Policy Record, a Mail Receiver uses a Tree Walk to find the DMARC Policy.
作成者ドメインに DMARC ポリシー レコードがない場合、メール受信者はツリー ウォークを使用して DMARC ポリシーを見つけます。
If the DMARC Policy Record allows relaxed alignment and the SPF- or DKIM-Authenticated Identifiers are different from the Author Domain, a Mail Receiver uses a Tree Walk to discover the respective Organizational Domains to determine Identifier Alignment.
DMARC ポリシー レコードで緩和された配置が許可されており、SPF または DKIM で認証された識別子が作成者ドメインと異なる場合、メール受信者はツリー ウォークを使用してそれぞれの組織ドメインを検出し、識別子の配置を決定します。
A Mail Receiver receives an email with:
メール受信者は次の内容の電子メールを受信します。
* Author Domain: example.com
* 著者ドメイン: example.com
* RFC5321.MailFrom Domain: example.com
* RFC5321.MailFrom ドメイン: example.com
* DKIM-Authenticated Identifier: signing.example.com
* DKIM 認証済み識別子: signed.example.com
In this example, "_dmarc.example.com" and "_dmarc.signing.example.com" both have DMARC Policy Records, while "_dmarc.com" does not. If SPF or DKIM yield "pass" results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment is relaxed, then the Tree Walk is performed to determine the Organizational Domain for each.
この例では、「_dmarc.example.com」と「_dmarc.signing.example.com」は両方とも DMARC ポリシー レコードを持っていますが、「_dmarc.com」は持っていません。SPF または DKIM が「合格」結果をもたらした場合でも、DMARC パスをサポートするように調整する必要があります。すべてのドメインが同じではないため、調整が緩和されている場合は、ツリー ウォークが実行されてそれぞれの組織ドメインが決定されます。
To determine the Organizational Domain for the Author Domain, query "_dmarc.example.com" and "_dmarc.com"; "example.com" is the last element of the DNS tree with a DMARC Policy Record, so it is the Organizational Domain for "example.com".
作成者ドメインの組織ドメインを特定するには、「_dmarc.example.com」と「_dmarc.com」をクエリします。「example.com」は DMARC ポリシー レコードを持つ DNS ツリーの最後の要素であるため、「example.com」の組織ドメインになります。
For the RFC5321.MailFrom domain, the Organizational Domain already found for "example.com" is "example.com", so SPF is aligned.
RFC5321.MailFrom ドメインの場合、「example.com」に対してすでに見つかった組織ドメインは「example.com」であるため、SPF は調整されます。
To determine the Organizational Domain for the DKIM-Authenticated Identifier, query "_dmarc.signing.example.com", "_dmarc.example.com", and "_dmarc.com". Both "signing.example.com" and "example.com" have DMARC Policy Records, but "example.com" is the highest element in the tree with a DMARC Policy Record (it has the fewest labels), so "example.com" is the Organizational Domain. Since this is also the Organizational Domain for the Author Domain, DKIM is aligned for relaxed alignment.
DKIM 認証識別子の組織ドメインを特定するには、「_dmarc.signing.example.com」、「_dmarc.example.com」、および「_dmarc.com」をクエリします。「signing.example.com」と「example.com」の両方に DMARC ポリシー レコードがありますが、「example.com」は DMARC ポリシー レコードを持つツリーの最上位の要素 (ラベルが最も少ない) であるため、「example.com」が組織ドメインになります。これは作成者ドメインの組織ドメインでもあるため、DKIM は緩和された調整を行うように調整されます。
Since both SPF and DKIM are aligned, they can be used to determine if the message has a DMARC "pass" result. If the result is not "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. In this case, since the RFC5322.From domain has a DMARC Policy Record, that is the policy domain.
SPF と DKIM は両方とも調整されているため、メッセージの DMARC 結果が「合格」かどうかを判断するために使用できます。結果が「合格」でない場合、ポリシー ドメインの DMARC ポリシー レコードを使用して適切なポリシーが決定されます。この場合、RFC5322.From ドメインには DMARC ポリシー レコードがあるため、それがポリシー ドメインになります。
A Mail Receiver receives an email with:
メール受信者は次の内容の電子メールを受信します。
* Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com
* 著者ドメイン: a.b.c.d.e.f.g.h.i.jk.k.example.com
* RFC5321.MailFrom Domain: example.com
* RFC5321.MailFrom ドメイン: example.com
* DKIM-Authenticated Identifier: signing.example.com
* DKIM 認証済み識別子: signed.example.com
Both "_dmarc.example.com" and "_dmarc.signing.example.com" have DMARC Policy Records, while "_dmarc.com" does not. If SPF or DKIM yield "pass" results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment is relaxed, then the Tree Walk is performed to determine the Organizational Domain for each.
「_dmarc.example.com」と「_dmarc.signing.example.com」は両方とも DMARC ポリシー レコードを持っていますが、「_dmarc.com」は持っていません。SPF または DKIM が「合格」結果をもたらした場合でも、DMARC パスをサポートするように調整する必要があります。すべてのドメインが同じではないため、調整が緩和されている場合は、ツリー ウォークが実行されてそれぞれの組織ドメインが決定されます。
To determine the Organizational Domain for the Author Domain, query "_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com"; then query "_dmarc.g.h.i.j.k.example.com" (skipping the intermediate names); then query "_dmarc.h.i.j.k.example.com", "_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "_dmarc.k.example.com", "_dmarc.example.com", and "_dmarc.com". None of "a.b.c.d.e.f.g.h.i.j.k.example.com", "g.h.i.j.k.example.com", "h.i.j.k.example.com", "i.j.k.example.com", "j.k.example.com", or "k.example.com" have a DMARC Policy Record.
作成者ドメインの組織ドメインを特定するには、「_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com」をクエリします。次に、「_dmarc.g.h.i.j.k.example.com」をクエリします (中間名はスキップします)。次に、「_dmarc.h.i.j.k.example.com」、「_dmarc.i.j.k.example.com」、「_dmarc.j.k.example.com」、「_dmarc.k.example.com」、「_dmarc.example.com」、「_dmarc.com」をクエリします。「a.b.c.d.e.f.g.h.i.j.k.example.com」、「g.h.i.j.k.example.com」、「h.i.j.k.example.com」、「i.j.k.example.com」、「j.k.example.com」、「k.example.com」のいずれにも DMARC ポリシー レコードはありません。
Since "example.com" is the last element of the DNS tree with a DMARC Policy Record, it is the Organizational Domain for "a.b.c.d.e.f.g.h.i.j.k.example.com".
「example.com」は DMARC ポリシー レコードを持つ DNS ツリーの最後の要素であるため、「a.b.c.d.e.f.g.h.i.j.k.example.com」の組織ドメインになります。
For the RFC5321.MailFrom domain, the Organizational Domain already found for "example.com" is "example.com". SPF is aligned.
RFC5321.MailFrom ドメインの場合、「example.com」に対してすでに見つかった組織ドメインは「example.com」です。SPFは調整されています。
For the DKIM-Authenticated Identifier, query "_dmarc.signing.example.com", "_dmarc.example.com", and "_dmarc.com". Both "signing.example.com" and "example.com" have DMARC Policy Records, but "example.com" is the highest element in the tree with a DMARC Policy Record, so "example.com" is the Organizational Domain. Since this is also the Organizational Domain for the Author Domain, DKIM is aligned for relaxed alignment.
DKIM 認証識別子については、「_dmarc.signing.example.com」、「_dmarc.example.com」、および「_dmarc.com」をクエリします。「signing.example.com」と「example.com」の両方に DMARC ポリシー レコードがありますが、「example.com」は DMARC ポリシー レコードを持つツリーの最上位要素であるため、「example.com」が組織ドメインになります。これは作成者ドメインの組織ドメインでもあるため、DKIM は緩和された調整を行うように調整されます。
Since both SPF and DKIM are aligned, they can be used to determine if the message has a DMARC "pass" result. If the results for both are not "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. In this case, the Author Domain does not have a DMARC Policy Record, so the policy domain is the highest element in the DNS tree with a DMARC Policy Record, example.com.
SPF と DKIM は両方とも調整されているため、メッセージの DMARC 結果が「合格」かどうかを判断するために使用できます。両方の結果が「合格」でない場合、ポリシー ドメインの DMARC ポリシー レコードを使用して、適切なポリシーが決定されます。この場合、作成者ドメインには DMARC ポリシー レコードがないため、ポリシー ドメインは、DMARC ポリシー レコード (example.com) を持つ DNS ツリーの最上位の要素になります。
In rare cases, a PSD publishes a DMARC Policy Record with a "psd" tag, which the Tree Walk must take into account.
まれに、PSD が「psd」タグを含む DMARC ポリシー レコードを発行することがあります。これを Tree Walk が考慮する必要があります。
A Mail Receiver receives an email with:
メール受信者は次の内容の電子メールを受信します。
* Author Domain: giant.bank.example
* 著者ドメイン：giant.bank.example
* RFC5321.MailFrom Domain: mail.giant.bank.example
* RFC5321.MailFrom ドメイン: mail.giant.bank.example
* DKIM-Authenticated Identifier: mail.mega.bank.example
* DKIM 認証済み識別子: mail.mega.bank.example
In this case, "_dmarc.bank.example" has a DMARC Policy Record that includes the "psd=y" tag, and "_dmarc.example" does not have a DMARC Policy Record. While "_dmarc.giant.bank.example" has a DMARC Policy Record without a "psd" tag, "_dmarc.mega.bank.example" and "_dmarc.mail.mega.bank.example" have no DMARC Policy Records.
この場合、「_dmarc.bank.example」には「psd=y」タグを含む DMARC ポリシー レコードがあり、「_dmarc.example」には DMARC ポリシー レコードがありません。「_dmarc.giant.bank.example」には「psd」タグのない DMARC ポリシー レコードがありますが、「_dmarc.mega.bank.example」と「_dmarc.mail.mega.bank.example」には DMARC ポリシー レコードがありません。
Since the three domains are all different, Tree Walks find their Organizational Domains to see which are aligned.
3 つのドメインはすべて異なるため、Tree Walks は組織ドメインを見つけて、どれが一致しているかを確認します。
For the Author Domain "giant.bank.example", the Tree Walk finds both the DMARC Policy Record at "_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.example" and stops because of the "psd=y" flag. The Organizational Domain is "giant.bank.example" because it is the domain directly below the one with "psd=y". Since the Organizational Domain has a DMARC Policy Record, it is also the policy domain.
作成者ドメイン「giant.bank.example」の場合、ツリー ウォークは「_dmarc.giant.bank.example」の DMARC ポリシー レコードと「_dmarc.bank.example」の DMARC ポリシー レコードの両方を検出し、「psd=y」フラグが原因で停止します。組織ドメインは、「psd=y」の直下のドメインであるため、「giant.bank.example」となります。組織ドメインには DMARC ポリシー レコードがあるため、ポリシー ドメインでもあります。
For the RFC5321.MailFrom domain "mail.giant.bank.example", the Tree Walk finds no DMARC Policy Record at "_dmarc.mail.giant.bank.example" but does find both the DMARC Policy Record at "_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.example" and stops because of the "psd=y" flag. Again, the Organizational Domain is "giant.bank.example" because it is the domain directly below the one with "psd=y". Since this is the same Organizational Domain as the Author Domain, SPF is aligned.
RFC5321.MailFrom ドメイン「mail.giant.bank.example」の場合、Tree Walk は「_dmarc.mail.giant.bank.example」で DMARC ポリシー レコードを検出しませんが、「_dmarc.giant.bank.example」で DMARC ポリシー レコードを検出し、次に「_dmarc.bank.example」で DMARC ポリシー レコードを検出し、「psd=y」フラグのために停止します。ここでも、組織ドメインは「giant.bank.example」です。これは、「psd=y」のドメインの直下のドメインであるためです。これは作成者ドメインと同じ組織ドメインであるため、SPF は調整されます。
For the DKIM-Authenticated Identifier "mail.mega.bank.example", the Tree Walk finds no DMARC Policy Records at "_dmarc.mail.mega.bank.example" or "_dmarc.mega.bank.example", then finds the DMARC Policy Record at "_dmarc.bank.example", and stops because of the "psd=y" flag. The Organizational Domain is "mega.bank.example", so DKIM is not aligned.
DKIM 認証識別子「mail.mega.bank.example」の場合、ツリー ウォークは「_dmarc.mail.mega.bank.example」または「_dmarc.mega.bank.example」で DMARC ポリシー レコードを見つけられませんでしたが、「_dmarc.bank.example」で DMARC ポリシー レコードを見つけ、「psd=y」フラグのために停止します。組織ドメインは「mega.bank.example」であるため、DKIM は調整されていません。
Since SPF is aligned, it can be used to determine if the message has a DMARC "pass" result. If the result is not "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy.
SPF は調整されているため、メッセージの DMARC 結果が「合格」かどうかを判断するために使用できます。結果が「合格」でない場合、ポリシー ドメインの DMARC ポリシー レコードを使用して適切なポリシーが決定されます。
Aggregate feedback is consumed by Domain Owners to enable their understanding of how a given domain is being processed by the Mail Receiver. Aggregate reporting data on emails that pass all underlying authentication checks is used by Domain Owners to validate that their 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 validate ongoing authentication practices of the third party.
集約フィードバックはドメイン所有者によって消費され、特定のドメインがメール受信者によってどのように処理されているかを理解できるようになります。すべての基礎となる認証チェックに合格した電子メールに関する集計レポート データは、ドメイン所有者によって認証方法が正確であることを検証するために使用されます。たとえば、サードパーティがドメイン所有者に代わって送信している場合、ドメイン所有者は集約レポート データを使用して、サードパーティの進行中の認証慣行を検証できます。
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 produce an Authenticated Identifier, 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 the 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 if the mail that is failing the checks was generated by or on behalf of the Domain Owner. Data regarding failing authentication checks can also allow the Domain Owner to come to an understanding of how its domain is being misused.
基礎となる認証チェックがすべて失敗した電子メールのデータは、ドメイン所有者のドメインがメール受信者でどのように受信されているかに関するベースラインの可視性を提供します。この可視性に基づいて、チェックに失敗したメールがドメイン所有者によって、またはドメイン所有者に代わって生成されたものである場合、ドメイン所有者は、検出されていない電子メール ソース全体に認証テクノロジの展開を開始できます。認証チェックの失敗に関するデータにより、ドメイン所有者はドメインがどのように悪用されているかを理解することもできます。
This document is intended to render [RFC7489] obsolete. As one might guess, that means there are significant differences between [RFC7489] and this document. This section will summarize those changes.
この文書は、[RFC7489] を廃止することを目的としています。ご想像のとおり、これは [RFC7489] とこの文書の間に大きな違いがあることを意味します。このセクションでは、それらの変更を要約します。
[RFC7489] was not the product of any IETF work stream but was instead published into the RFC Series by the Independent Submissions Editor and classified as an Informational RFC.
[RFC7489] は IETF 作業ストリームの成果物ではなく、Independent Submissions Editor によって RFC シリーズとして公開され、情報 RFC として分類されました。
This document, by contrast, is an Internet Standards Track document.
対照的に、この文書は Internet Standards Track 文書です。
The following changes were made to the "Terminology and Definitions" section.
「用語と定義」セクションに次の変更が加えられました。
These terms were added:
次の用語が追加されました。
* Domain Owner Assessment Policy
* ドメイン所有者評価ポリシー
* Enforcement
* 執行
* Monitoring Mode
* 監視モード
* Non-existent Domains
* 存在しないドメイン
* Public Suffix Domain (PSD)
* パブリック サフィックス ドメイン (PSD)
* Public Suffix Operator (PSO)
* パブリックサフィックス演算子 (PSO)
* PSO-Controlled Domain Names
* PSO 制御のドメイン名
These definitions were updated:
これらの定義が更新されました。
* Organizational Domain
* 組織ドメイン
* Report Receiver (renamed to Report Consumer)
* レポート レシーバー (レポート コンシューマーに名前変更)
The algorithms for DMARC policy discovery and for determining the Organizational Domain have been changed. Specifically, reliance on a PSL has been replaced by a technique called a "DNS Tree Walk", and the methodology for the DNS Tree Walk is explained in detail in this document.
DMARC ポリシーの検出と組織ドメインの決定のアルゴリズムが変更されました。具体的には、PSL への依存は「DNS ツリー ウォーク」と呼ばれる技術に置き換えられており、DNS ツリー ウォークの方法論についてはこのドキュメントで詳細に説明されています。
The DNS Tree Walk also incorporates PSD policy discovery, which was introduced in [RFC9091]. That RFC was an Experimental RFC, and the results of that experiment were that the RFC was not implemented as written. Instead, this document redefines the algorithm for PSD policy discovery and thus obsoletes [RFC9091]. Specifically, the DNS Tree Walk defined in this document obviates the need for a PSD DMARC registry, and that PSD DMARC registry is what made [RFC9091] an Experimental RFC.
DNS Tree Walk には、[RFC9091] で導入された PSD ポリシー検出も組み込まれています。その RFC は実験的な RFC であり、その実験の結果は、RFC が書かれたとおりに実装されていないということでした。代わりに、この文書は PSD ポリシー検出のアルゴリズムを再定義するため、[RFC9091] は廃止されます。具体的には、この文書で定義されている DNS Tree Walk は PSD DMARC レジストリの必要性を排除し、その PSD DMARC レジストリが [RFC9091] を実験的 RFC にしたものです。
These algorithm changes introduce the possibility of interoperability issues where a Domain Owner expects a DMARC Policy Record or an Organizational Domain to be identified by the Tree Walk process, but a Mail Receiver using an implementation of DMARC based on [RFC7489] and relying on a PSL might arrive at a different answer.
これらのアルゴリズムの変更により、ドメイン所有者は DMARC ポリシー レコードまたは組織ドメインが Tree Walk プロセスによって識別されることを期待しているものの、[RFC7489] に基づいた DMARC の実装を使用し、PSL に依存しているメール受信者が異なる答えに到達する可能性があるという相互運用性の問題が発生する可能性が生じます。
This issue is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email.
この問題は、厳密な調整を使用し、組織の電子メールで使用されるすべての作成者ドメインに対して明示的な DMARC ポリシー レコードを公開することによって完全に回避されます。
Discussion of both aggregate and failure reporting has been moved to separate documents dedicated to the topics.
集計レポートと障害レポートの両方についての説明は、そのトピック専用の別のドキュメントに移動されました。
In addition, the ability to specify a maximum report size in the DMARC URI has been removed.
さらに、DMARC URI で最大レポート サイズを指定する機能が削除されました。
Several tags have been added to the "DMARC Policy Record Format" section of this document since [RFC7489] was published, and at the same time, several others were removed.
[RFC7489] が公開されて以来、この文書の「DMARC ポリシー レコード形式」セクションにいくつかのタグが追加され、同時に他のいくつかのタグが削除されました。
np:
np:
Policy for non-existent domains (imported from [RFC9091]).
存在しないドメインのポリシー ([RFC9091] からインポート)。
psd:
psd:
Flag indicating whether a domain is a PSD.
ドメインが PSD であるかどうかを示すフラグ。
t:
t:
Replacement for some "pct" tag functionality. See Appendix A.6 for further discussion.
一部の「pct」タグ機能の置き換え。詳細については、付録 A.6 を参照してください。
pct:
pct:
Tag requesting application of the DMARC policy to only a percentage of messages. See Appendix A.6 for discussion.
メッセージの一部のみに DMARC ポリシーを適用することを要求するタグ。議論については、付録 A.6 を参照してください。
rf:
rf:
Tag specifying requested format of failure reports.
失敗レポートの要求された形式を指定するタグ。
ri
リ
Tag specifying requested interval between aggregate reports.
集計レポート間の要求された間隔を指定するタグ。
[RFC7489] only had two paragraphs in its "Domain Owner Actions" section, and while the content of those paragraphs was correct, it was minimalist in its approach to providing guidance to Domain Owners on just how to implement DMARC.
[RFC7489] の「ドメイン所有者のアクション」セクションには 2 つの段落しかなく、それらの段落の内容は正しいものの、DMARC の実装方法についてドメイン所有者にガイダンスを提供するというアプローチは最小限のものでした。
This document provides much more detail and explanatory text to a Domain Owner, focusing not just on what to do to implement DMARC but also on the reasons for each step and the repercussions of each decision.
この文書は、DMARC を実装するために何をすべきかだけでなく、各ステップの理由と各決定の影響にも焦点を当て、ドメイン所有者にさらに詳細な説明文を提供します。
In particular, this document makes explicit that domains for general-purpose email SHOULD NOT deploy a DMARC policy of "p=reject". See Section 7.4 for further discussion of this topic.
特に、この文書では、汎用電子メールのドメインは「p=reject」の DMARC ポリシーを展開すべきではないことを明示しています。このトピックの詳細については、セクション 7.4 を参照してください。
In the cases where a DMARC Policy Record specifies multiple destinations for either aggregate reports or failure reports, [RFC7489] stated:
DMARC ポリシー レコードが集約レポートまたは失敗レポートのいずれかに対して複数の宛先を指定する場合、[RFC7489] では次のように述べられています。
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.
受信者はレポートの送信先となる URI の数に制限を課してもよい（MAY）が、少なくとも 2 つに送信する機能をサポートしなければならない（MUST）。
Section 4.6 of this document includes this text:
この文書のセクション 4.6 には次のテキストが含まれています。
A report SHOULD be sent to each listed URI provided in the DMARC Policy Record.
レポートは、DMARC ポリシー レコードで提供されるリストされた各 URI に送信されるべきです (SHOULD)。
One of the appendices in [RFC7489], specifically Appendix A.5, has been removed from the text with this update. The appendix was titled "Issues with ADSP in Operation", and it contained a list of issues associated with ADSP that influenced the direction of DMARC. The ADSP protocol was moved to "Historic" status in 2013 and working group consensus was that such a discussion of ADSP's influence on DMARC was no longer relevant.
[RFC7489] の付録の 1 つ、特に付録 A.5 は、この更新で本文から削除されました。付録のタイトルは「運用中の ADSP に関する問題」で、DMARC の方向性に影響を与えた ADSP に関連する問題のリストが含まれていました。ADSP プロトコルは 2013 年に「歴史的」ステータスに移行し、ワーキング グループのコンセンサスは、DMARC に対する ADSP の影響に関するそのような議論はもはや適切ではないということでした。
This document and its companion documents ([RFC9990] and [RFC9991]) address the following errata filed against [RFC7489] since that document's publication in March, 2015. More details on each of these can be found at <https://www.rfc-editor.org/ errata_search.php?rfc=7489>.
この文書とその関連文書 ([RFC9990] および [RFC9991]) は、2015 年 3 月に文書が公開されて以来、[RFC7489] に対して提出された以下の正誤表に対処しています。これらのそれぞれの詳細については、<https://www.rfc-editor.org/ errata_search.php?rfc=7489> を参照してください。
See <https://www.rfc-editor.org/errata/eid5365>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid5365>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid5371>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid5371>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid5440>. This erratum references several mentions in [RFC7489] of the "v=" tag from the Domain Owner Assessment Policy and/or its value, specifically mentions that were not, but should have been, "v=DMARC1;". Some of those mentions are preserved in this document, and those mentions have been addressed as per the erratum. The rest have moved to [RFC9990] and are addressed there.
<https://www.rfc-editor.org/errata/eid5440>を参照してください。この正誤表は、ドメイン所有者評価ポリシーの "v=" タグおよび/またはその値に関する [RFC7489] のいくつかの記述を参照しており、具体的には、"v=DMARC1;" ではなかったが、そうすべきであったとの記述があります。これらの言及の一部はこの文書に保存されており、それらの言及は正誤に従って対処されています。残りは [RFC9990] に移動されており、そこで扱われています。
See <https://www.rfc-editor.org/errata/eid6439>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid6439>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid5221>. The regular expression pattern for IP addresses has been removed from this document and from [RFC9990].
<https://www.rfc-editor.org/errata/eid5221>を参照してください。IP アドレスの正規表現パターンは、この文書および [RFC9990] から削除されました。
See <https://www.rfc-editor.org/errata/eid5229>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid5229>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid5495>. This erratum is in reference to the description of the process documented in [RFC7489] for the applicable DMARC policy for an email message. The process for doing this has drastically changed in this document, and so the text identified in this erratum no longer exists.
<https://www.rfc-editor.org/errata/eid5495>を参照してください。この正誤表は、電子メール メッセージに適用される DMARC ポリシーについて [RFC7489] に文書化されたプロセスの説明を参照しています。このドキュメントではこれを行うプロセスが大幅に変更されたため、この正誤表で特定されたテキストは存在しません。
See <https://www.rfc-editor.org/errata/eid6485>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid6485>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid6729>. This erratum is in reference to a search of the PSL as part of finding a DMARC Policy Record (a.k.a., Domain Owner Assessment Policy). The PSL is no longer relied upon for this practice, and the text at issue has been removed from this document.
<https://www.rfc-editor.org/errata/eid6729>を参照してください。このエラッタは、DMARC ポリシー レコード (別名、ドメイン所有者評価ポリシー) の検索の一部としての PSL の検索に関するものです。PSL はこの慣行には依存しなくなり、問題となっている文章はこの文書から削除されました。
See <https://www.rfc-editor.org/errata/eid7099>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid7099>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid7100>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid7100>を参照してください。この正誤表は [RFC9990] で対処されています。
See <https://www.rfc-editor.org/errata/eid7835>. This erratum is in reference to the description of the process documented in [RFC7489] for the applicable DMARC policy for an email message. The process for doing this has drastically changed in this document, and so the text identified in this erratum no longer exists.
<https://www.rfc-editor.org/errata/eid7835>を参照してください。この正誤表は、電子メール メッセージに適用される DMARC ポリシーについて [RFC7489] に文書化されたプロセスの説明を参照しています。このドキュメントではこれを行うプロセスが大幅に変更されたため、この正誤表で特定されたテキストは存在しません。
See <https://www.rfc-editor.org/errata/eid7865>. The regular expression pattern for IP addresses has been removed from this document and from [RFC9990].
<https://www.rfc-editor.org/errata/eid7865>を参照してください。IP アドレスの正規表現パターンは、この文書および [RFC9990] から削除されました。
See <https://www.rfc-editor.org/errata/eid5151>. This erratum is in reference to the Introduction section of [RFC7489]. That section has been substantially rewritten in this document, and the text at issue for this erratum no longer exists.
<https://www.rfc-editor.org/errata/eid5151>を参照してください。この正誤表は、[RFC7489] の「はじめに」セクションを参照しています。このセクションはこの文書で大幅に書き直されており、この正誤表で問題となっているテキストは存在しません。
See <https://www.rfc-editor.org/errata/eid5774>. This erratum is addressed in [RFC9990].
<https://www.rfc-editor.org/errata/eid5774>を参照してください。この正誤表は [RFC9990] で対処されています。
A great deal of the content from [RFC7489] was preserved in this document, but much of it was subject to minor editing and the reordering of sections, or both.
[RFC7489] の内容の大部分はこの文書に保存されていますが、その多くは軽微な編集とセクションの並べ替え、またはその両方の対象となっています。
The reworking of the DMARC mechanism specified in [RFC7489] is the result of contributions from many participants in the DMARC Working Group. Although the contributors are too numerous to mention, significant contributions were made by Kurt Andersen, Laura Atkins, Seth Blank, Alex Brotman, Dave Crocker, Douglas E. Foster, Ned Freed, Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy, Barry Leiba, Alessandro Vesely, and Tim Wicinski.
[RFC7489] で規定されている DMARC メカニズムの改訂は、DMARC Working Group の多くの参加者からの貢献の結果です。貢献者は多すぎて言及できませんが、Kurt Andersen、Laura Atkins、Seth Blank、Alex Brotman、Dave Crocker、Douglas E. Foster、Ned Freed、Mike Hammer、Steven M. Jones、Scott Kitterman、Murray S. Kucherawy、Barry Leiba、Alessandro Vesely、Tim Wicinski によって重要な貢献が行われました。
The authors and contributors also recognize that this document would not have been possible without the work done by those who had a hand in producing [RFC7489]. The Acknowledgements section from that document is preserved in full below.
著者と寄稿者はまた、[RFC7489] の作成に携わった人々の働きなしにはこの文書は不可能だったことを認識しています。この文書の謝辞セクションの全文を以下に保存します。
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 <https://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 および独立投稿編集者に提出されたこの文書の草案は、非公式の業界コンソーシアム DMARC.org (<https://dmarc.org> を参照) による長期にわたる取り組みの結果です。参加企業には、Agari、American Greetings、AOL、バンク オブ アメリカ、Cloudmark、Comcast、Facebook、Fidelity Investments、Google、JPMorgan Chase & Company、LinkedIn、Microsoft、Netease、PayPal、ReturnPath、The Trusted Domain Project、Yahoo! が含まれます。貢献者や支援者は枚挙にいとまがありませんが、J. トレント・アダムス、マイケル・アドキンス、モニカ・チュー、デイブ・クロッカー、ティム・ドレーゲン、スティーブ・ジョーンズ、フランク・マーティン、ブレット・マクダウェル、ポール・ミッドジェンらによる注目すべき個人の貢献が挙げられます。寄稿者はまた、J.D. Falk によって初期に提供された貴重な意見と指導に感謝したいと考えています。
Additional contributions within the IETF context were made by Kurt Andersen, 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 に関する追加の貢献は、Kurt Andersen、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、Stephen J. Turnbull によって行われました。
Todd M. Herr (editor)
Valimail
Email: todd@someguyinva.com
John Levine (editor)
Standcore LLC
Email: standards@standcore.com