[要約] RFC 7489、つまりDomain-based Message Authentication, Reporting, and Conformance (DMARC)は、電子メールの偽装を防ぐためのフレームワークです。この標準は、SPF(Sender Policy Framework)とDKIM(DomainKeys Identified Mail)の検証結果を利用して、ドメイン所有者がどのようにそのドメインから送信されたメールを処理すべきかを示すポリシーを公開できるようにします。DMARCは、メール送信者と受信者の間での信頼性を高め、フィッシングやその他の詐欺的なメールの防止に役立ちます。関連するRFCには、SPFを定義するRFC 7208と、DKIMを定義するRFC 6376があります。

Independent Submission                                 M. Kucherawy, Ed.
Request for Comments: 7489
Category: Informational                                   E. Zwicky, Ed.
ISSN: 2070-1721                                                   Yahoo!
                                                              March 2015

Domain-based Message Authentication, Reporting, and Conformance (DMARC)




Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.


Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.


DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

DMARCは、認証された電子メールの昇格された配信特権を生成または奨励しません。 DMARCはポリシー配信のメカニズムであり、認証チェックに失敗したメッセージをますます厳格に処理できるようにします。アクションのないものから、配信の変更、メッセージの拒否まで、さまざまです。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7489.


Copyright Notice


Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents


   1. Introduction ....................................................3
   2. Requirements ....................................................5
      2.1. High-Level Goals ...........................................5
      2.2. Out of Scope ...............................................6
      2.3. Scalability ................................................6
      2.4. Anti-Phishing ..............................................7
   3. Terminology and Definitions .....................................7
      3.1. Identifier Alignment .......................................8
      3.2. Organizational Domain .....................................11
   4. Overview .......................................................12
      4.1. Authentication Mechanisms .................................12
      4.2. Key Concepts ..............................................12
      4.3. Flow Diagram ..............................................13
   5. Use of RFC5322.From ............................................15
   6. Policy .........................................................15
      6.1. DMARC Policy Record .......................................16
      6.2. DMARC URIs ................................................16
      6.3. General Record Format .....................................17
      6.4. Formal Definition .........................................21
      6.5. Domain Owner Actions ......................................22
      6.6. Mail Receiver Actions .....................................23
      6.7. Policy Enforcement Considerations .........................27
   7. DMARC Feedback .................................................28
      7.1. Verifying External Destinations ...........................28
      7.2. Aggregate Reports .........................................30
      7.3. Failure Reports ...........................................36
   8. Minimum Implementations ........................................37
   9. Privacy Considerations .........................................38
      9.1. Data Exposure Considerations ..............................38
      9.2. Report Recipients .........................................39
   10. Other Topics ..................................................39
      10.1. Issues Specific to SPF ...................................39
      10.2. DNS Load and Caching .....................................40
      10.3. Rejecting Messages .......................................40
      10.4. Identifier Alignment Considerations ......................41
      10.5. Interoperability Issues ..................................41
   11. IANA Considerations ...........................................42
      11.1. Authentication-Results Method Registry Update ............42
      11.2. Authentication-Results Result Registry Update ............42
      11.3. Feedback Report Header Fields Registry Update ............44
      11.4. DMARC Tag Registry .......................................44
      11.5. DMARC Report Format Registry .............................45
   12. Security Considerations .......................................46
      12.1. Authentication Methods ...................................46
      12.2. Attacks on Reporting URIs ................................46
      12.3. DNS Security .............................................47
      12.4. Display Name Attacks .....................................47
      12.5. External Reporting Addresses .............................48
      12.6. Secure Protocols .........................................48
   13. References ....................................................49
      13.1. Normative References .....................................49
      13.2. Informative References ...................................50
   Appendix A. Technology Considerations .............................52
     A.1. S/MIME .....................................................52
     A.2. Method Exclusion ...........................................53
     A.3. Sender Header Field ........................................53
     A.4. Domain Existence Test ......................................54
     A.5. Issues with ADSP in Operation ..............................54
     A.6. Organizational Domain Discovery Issues .....................55
   Appendix B. Examples ..............................................56
     B.1. Identifier Alignment Examples ..............................56
     B.2. Domain Owner Example .......................................58
     B.3. Mail Receiver Example  .....................................63
     B.4. Utilization of Aggregate Feedback: Example .................64
     B.5. mailto Transport Example ...................................65
   Appendix C. DMARC XML Schema ......................................66
   Acknowledgements ..................................................73
   Authors' Addresses ................................................73
1. Introduction
1. はじめに

The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail ([DKIM]) provide domain-level authentication. They enable cooperating email receivers to detect mail authorized to use the domain name, which can permit differential handling. (A detailed discussion of the threats these systems attempt to address can be found in [DKIM-THREATS].) However, there has been no single widely accepted or publicly available mechanism to communication of domain-specific message-handling policies for receivers, or to request reporting of authentication and disposition of received mail. Absent the ability to obtain feedback reports, originators who have implemented email authentication have difficulty determining how effective their authentication is. As a consequence, use of authentication failures to filter mail typically does not succeed.

Sender Policy Framework([SPF])とDomainKeys Identified Mail([DKIM])は、ドメインレベルの認証を提供します。これらは、協力する電子メール受信者がドメイン名の使用を許可されたメールを検出できるようにし、これにより、差分処理が可能になります。 (これらのシステムが対処しようとする脅威の詳細な説明は、[DKIM-THREATS]で見つけることができます。)しかし、受信者のドメイン固有のメッセージ処理ポリシーの通信に対して広く受け入れられているか、公開されている単一のメカニズムはありません。受信したメールの認証と処分の報告を要求する。フィードバックレポートを取得する機能がないと、メール認証を実装した発信者は、認証がどれほど効果的であるかを判断することが困難になります。結果として、メールのフィルタリングに認証エラーを使用すると、通常は成功しません。

Over time, one-on-one relationships were established between select senders and receivers with privately communicated means to assert policy and receive message traffic and authentication disposition reporting. Although these ad hoc practices have been generally successful, they require significant manual coordination between parties, and this model does not scale for general use on the Internet.


This document defines Domain-based Message Authentication, Reporting, and Conformance (DMARC), a mechanism by which email operators leverage existing authentication and policy advertisement technologies to enable both message-stream feedback and enforcement of policies against unauthenticated email.


DMARC allows Domain Owners and receivers to collaborate by:


1. Providing receivers with assertions about Domain Owners' policies

1. ドメイン所有者のポリシーに関するアサーションをレシーバーに提供する

2. Providing feedback to senders so they can monitor authentication and judge threats

2. 送信者にフィードバックを提供して、認証を監視し、脅威を判断できるようにする

The basic outline of DMARC is as follows:


1. Domain Owners publish policy assertions about domains via the DNS.

1. ドメイン所有者は、DNSを介してドメインに関するポリシーアサーションを公開します。

2. Receivers compare the RFC5322.From address in the mail to the SPF and DKIM results, if present, and the DMARC policy in DNS.

2. 受信者は、メールのRFC5322.FromアドレスをSPFおよびDKIM結果(存在する場合)と比較し、DNSのDMARCポリシーを比較します。

3. These receivers can use these results to determine how the mail should be handled.

3. これらの受信者はこれらの結果を使用して、メールの処理方法を決定できます。

4. The receiver sends reports to the Domain Owner or its designee about mail claiming to be from their domain.

4. 受信者は、ドメインの所有者またはその指定者に、ドメインからのものであると主張するメールに関するレポートを送信します。

Security terms used in this document are defined in [SEC-TERMS].


DMARC differs from previous approaches to policy advertisement (e.g., [SPF] and [ADSP]) in that:


o Authentication technologies are:

o 認証テクノロジーは次のとおりです。

1. decoupled from any technology-specific policy mechanisms, and

1. テクノロジー固有のポリシーメカニズムから切り離されている

2. used solely to establish reliable per-message domain-level identifiers.

2. 信頼できるメッセージごとのドメインレベルの識別子を確立するためにのみ使用されます。

o Multiple authentication technologies are used to:

o 複数の認証技術は、次の目的で使用されます。

1. reduce the impact of transient authentication errors

1. 一時的な認証エラーの影響を減らす

2. reduce the impact of site-specific configuration errors and deployment gaps

2. サイト固有の構成エラーと展開ギャップの影響を軽減する

3. enable more use cases than any individual technology supports alone

3. 個々のテクノロジーが単独でサポートするよりも多くのユースケースを可能にします

o Receiver-generated feedback is supported, allowing senders to establish confidence in authentication practices.

o 受信者が生成したフィードバックがサポートされているため、送信者は認証手法に自信を確立できます。

o The domain name extracted from a message's RFC5322.From field is the primary identifier in the DMARC mechanism. This identifier is used in conjunction with the results of the underlying authentication technologies to evaluate results under DMARC.

o メッセージのRFC5322.Fromフィールドから抽出されたドメイン名は、DMARCメカニズムの主要な識別子です。この識別子は、DMARCでの結果を評価するために、基盤となる認証技術の結果と組み合わせて使用​​されます。

Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 10.


2. Requirements
2. 必要条件

Specification of DMARC is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope.


2.1. High-Level Goals
2.1. 高レベルの目標

DMARC has the following high-level goals:


o Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain.

o ドメイン所有者が認証失敗の優先処理を主張できるようにします。これは、ドメイン内でオーサーシップをしていると主張するメッセージに対してです。

o Allow Domain Owners to verify their authentication deployment.

o ドメイン所有者が認証の導入を確認できるようにします。

o Minimize implementation complexity for both senders and receivers, as well as the impact on handling and delivery of legitimate messages.

o 送信者と受信者の両方の実装の複雑さ、および正当なメッセージの処理と配信への影響を最小限に抑えます。

o Reduce the amount of successfully delivered spoofed email.

o なりすましメールの配信に成功しました。

o Work at Internet scale.

o インターネット規模で働く。

2.2. Out of Scope
2.2. 範囲外

Several topics and issues are specifically out of scope for the initial version of this work. These include the following:


o different treatment of messages that are not authenticated versus those that fail authentication;

o 認証されていないメッセージと認証に失敗したメッセージの扱いが異なります。

o evaluation of anything other than RFC5322.From;

o RFC5322.From以外の評価;

o multiple reporting formats;

o 複数のレポート形式。

o publishing policy other than via the DNS;

o DNS以外の公開ポリシー。

o reporting or otherwise evaluating other than the last-hop IP address;

o ラストホップIPアドレス以外のレポートまたはその他の評価;

o attacks in the RFC5322.From field, also known as "display name" attacks;

o RFC5322.Fromフィールドの攻撃。「表示名」攻撃とも呼ばれます。

o authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and

o ドメイン以外のエンティティの認証。DMARCはSPFとDKIMに基づいて構築されているため、ドメインを認証します。そして

o content analysis.

o 内容分析。

2.3. Scalability
2.3. スケーラビリティ

Scalability is a major issue for systems that need to operate in a system as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.


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.


2.4. Anti-Phishing
2.4. 対詐欺

DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions). One of the primary uses of this kind of spoofed mail is phishing (enticing users to provide information by pretending to be the legitimate service requesting the information). Thus, DMARC is significantly informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures.


Although DMARC can only be used to combat specific forms of exact-domain spoofing directly, the DMARC mechanism has been found to be useful in the creation of reliable and defensible message streams.


DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent email. In particular, it does not address the use of visually similar domain names ("cousin domains") or abuse of the RFC5322.From human-readable <display-name>.


3. Terminology and Definitions
3. 用語と定義

This section defines terms used in the rest of the document.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。

Readers are encouraged to be familiar with the contents of [EMAIL-ARCH]. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner could, via the messaging security mechanisms on which DMARC is based, delegate the ability to send mail as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing.


The following terms are also used:


Authenticated Identifiers: Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers". See Section 4.1 for details about the supported mechanisms.


Author Domain: The domain name of the apparent author, as extracted from the RFC5322.From field.


Domain Owner: An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH]. It can also refer to delegates, such as Report Receivers, when those are outside of their immediate management domain.


Identifier Alignment: When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment.


Mail Receiver: The entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Mail Transport Agents (MTAs).


Organizational Domain: The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., "example.com", where "com" is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2.

組織ドメイン:ドメイン名登録事業者に登録されたドメイン。より正確な方法が存在しない場合、登録されたドメイン名がトップレベルのDNSドメインと1つのコンポーネント(たとえば、「example.com」、「com "はトップレベルドメインです)。組織ドメインは、セクション3.2にあるアルゴリズムを適用して決定されます。

Report Receiver: An operator that receives reports from another operator implementing the reporting mechanism described in this document. Such an operator might be receiving reports about its own messages, or reports about messages related to another operator. This term applies collectively to the system components that receive and process these reports and the organizations that operate them.


3.1. Identifier Alignment
3.1. 識別子の配置

Email authentication technologies authenticate various (and disparate) aspects of an individual message. For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] can authenticate either the domain that appears in the RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/ HELO domain, or both. These may be different domains, and they are typically not visible to the end user.

電子メール認証技術は、個々のメッセージのさまざまな(そして異なる)側面を認証します。たとえば、[DKIM]はメッセージに署名を付けたドメインを認証し、[SPF]は[SMTP]のRFC5321.MailFrom(MAIL FROM)部分にあるドメインまたはRFC5321.EHLO / HELOドメインを認証できます。 、 または両方。これらは異なるドメインである可能性があり、通常、エンドユーザーには表示されません。

DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier. The RFC5322.From domain was selected as the central identity of the DMARC mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users.

DMARCは、RFC5322.Fromドメインの使用を、認証済み識別子と一致する(一致する)ことを要求することによって認証します。 RFC5322.FromドメインはDMARCメカニズムの中心的なアイデンティティとして選択されました。これは必須のメッセージヘッダーフィールドであり、したがって準拠メッセージに存在することが保証されており、ほとんどのメールユーザーエージェント(MUA)がRFC5322.Fromフィールドを発信元として表しているためです。メッセージの一部として、このヘッダーフィールドのコンテンツの一部またはすべてをエンドユーザーに表示します。

Thus, this field is the one used by end users to identify the source of the message and therefore is a prime target for abuse. Many high-profile email sources, such as email service providers, require that the sending agent have authenticated before email can be generated. Thus, for these mailboxes, the mechanism described in this document provides recipient end users with strong evidence that the message was indeed originated by the agent they associate with that mailbox, if the end user knows that these various protections have been provided.


Domain names in this context are to be compared in a case-insensitive manner, per [DNS-CASE].


It is important to note that Identifier Alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed, absent, or repeated RFC5322.From field, since in that case there is no reliable way to determine a DMARC policy that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid RFC5322 message object, and handling of such non-compliant cases is outside of the scope of this specification. Further discussion of this can be found in Section 6.6.1.


Each of the underlying authentication technologies that DMARC takes as input yields authenticated domains as their outputs when they succeed. From the perspective of DMARC, each can be operated in a "strict" mode or a "relaxed" mode. A Domain Owner would normally select strict mode if it wanted Mail Receivers to apply DMARC processing only to messages bearing an RFC5322.From domain exactly matching the domains those mechanisms will verify. Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains.

DMARCが入力として使用する基盤となる認証テクノロジはそれぞれ、成功したときに認証済みドメインを出力として生成します。 DMARCの観点から見ると、それぞれを「厳密」モードまたは「緩和」モードで操作できます。ドメインオーナーは通常、RFC5322が付いたメッセージにのみメールレシーバーがDMARC処理を適用するようにしたい場合、ストリクトモードを選択します。オペレーターが検証済みドメインのサブドメインを持つメッセージフローにも影響を与えたい場合は、リラックスモードを使用できます。

3.1.1. DKIM-Authenticated Identifiers
3.1.1. DKIMで認証された識別子

DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed. (Note that these are not related to DKIM's "simple" and "relaxed" canonicalization modes.) In relaxed mode, the Organizational Domains of both the [DKIM]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment.

DMARCは、DKIM認証の結果に基づいて、IDアラインメントを厳密または緩和することを許可します。 (これらはDKIMの「シンプル」および「リラックス」正規化モードとは関係がないことに注意してください。)リラックスモードでは、両方の[DKIM]認証済み署名ドメインの組織ドメイン(の「d =」タグの値から取得)署名)とRFC5322.Fromドメインの署名は、識別子が整合していると見なされる場合、等しくなければなりません。厳密モードでは、両方の完全修飾ドメイン名(FQDN)間の完全一致のみが、識別子の整列を生成すると見なされます。

To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address.

たとえば、リラックスモードで、検証されたDKIM署名が「example.com」の「d =」ドメインで正常に検証され、RFC5322.Fromアドレスが「alerts@news.example.com」である場合、DKIM「d = "ドメインとRFC5322.Fromドメインは"整合 "していると見なされます。厳密モードでは、「d =」ドメインがアドレスのFQDNと正確に一致しないため、このテストは失敗します。

However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result, as "com" should appear on all public suffix lists (see Appendix A.6.1) and therefore cannot be an Organizational Domain.

ただし、「d = com」の値を持つDKIMシグネチャは、「com」がすべてのパブリックサフィックスリスト(付録A.6.1を参照)に表示される必要があるため、組織ドメインになることができないため、「整列」結果を決して許可しません。

Identifier Alignment is required because a message can bear a valid signature from any domain, including domains used by a mailing list or even a bad actor. Therefore, merely bearing a valid signature is not enough to infer authenticity of the Author Domain.


Note that a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies.


3.1.2. SPF-Authenticated Identifiers
3.1.2. SPF-Authenticated Identifiers

DMARC permits Identifier Alignment, based on the result of an SPF authentication, to be strict or relaxed.


In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.


Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier.

[SPF]による「純粋なSPF」実装がその識別子をチェックする場合でも、RFC5321.HELO IDは通常DMARCのコンテキストでは使用されません(それ以外の場合はnullのリバースパスを「偽造」する必要がある場合を除く)。

For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode.

たとえば、メッセージが「cbg.bounces.example.com」のRFC5321.MailFromドメインでSPFチェックに合格し、RFC5322.Fromフィールドのアドレス部分に「payments@example.com」が含まれている場合、認証済みのRFC5321。 MailFromドメイン識別子とRFC5322.Fromドメインは、緩和モードでは「整合」していると見なされますが、厳密モードでは考慮されません。

3.1.3. Alignment and Extension Technologies
3.1.3. 調整および拡張テクノロジー

If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified.


3.2. Organizational Domain
3.2. 組織ドメイン

The Organizational Domain is determined using the following algorithm:


1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list.

1. 「パブリックサフィックス」リスト、つまり登録用に予約されているDNSドメイン名のリストを取得します。一部の国のトップレベルドメイン(TLD)は特定の登録要件を設けています。たとえば、英国では会社の登録を「.co.uk」に配置しています。 「.com」などの他のTLDは、トップレベルDNSドメインのIANAレジストリに表示されます。公開サフィックスリストは、これらすべての結合です。付録A.6.1には、公開サフィックスリストの取得に関する説明が含まれています。

2. Break the subject DNS domain name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "example.com", "com" would be label 1 and "example" would be label 2.

2. 対象のDNSドメイン名を「n」の順序付けられたラベルのセットに分割します。これらのラベルには右から左に番号を付けます。たとえば、「example.com」の場合、「com」はラベル1、「example」はラベル2になります。

3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x".

3. パブリックサフィックスリストで、対象のDNSドメインで見つかったラベルの最大数と一致する名前を検索します。その数を "x"とします。

4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the "x+1"th label from the subject domain. This new name is the Organizational Domain.

4. パブリックサフィックスリストから一致する名前を使用し、サブジェクトドメインからの「x + 1」番目のラベルにプレフィックスを付けて、新しいDNSドメイン名を作成します。この新しい名前は組織ドメインです。

Thus, since "com" is an IANA-registered TLD, a subject domain of "a.b.c.d.example.com" would have an Organizational Domain of "example.com".


The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.


4. Overview
4. 概観

This section provides a general overview of the design and operation of the DMARC environment.


4.1. Authentication Mechanisms
4.1. 認証メカニズム

The following mechanisms for determining Authenticated Identifiers are supported in this version of DMARC:


o [DKIM], which provides a domain-level identifier in the content of the "d=" tag of a validated DKIM-Signature header field.

o [DKIM]。検証されたDKIM-Signatureヘッダーフィールドの「d =」タグのコンテンツにドメインレベルの識別子を提供します。

o [SPF], which can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes MAIL FROM processing for cases in which the MAIL command has a null path.

o [SPF]。[SMTP] HELO / EHLOコマンドで見つかったドメイン(HELO ID)と、SMTP MAILコマンドで見つかったドメイン(MAIL FROM ID)の両方を認証できます。 DMARCは、MAIL FROM IDのSPF認証の結果を使用します。 [SPF]のセクション2.4は、MAILコマンドにnullパスがある場合のMAIL FROM処理について説明しています。

4.2. Key Concepts
4.2. 主要な概念

DMARC policies are published by the Domain Owner, and retrieved by the Mail Receiver during the SMTP session, via the DNS.


DMARC's filtering function is based on whether the RFC5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a DMARC policy is published for the domain name found in the RFC5322.From field, and that domain name is not validated through SPF or DKIM, the disposition of that message can be affected by that DMARC policy when delivered to a participating receiver.

DMARCのフィルタリング機能は、RFC5322.FromフィールドドメインがSPFまたはDKIMからの認証済みドメイン名と整合(一致)しているかどうかに基づいています。 RFC5322.Fromフィールドにあるドメイン名に対してDMARCポリシーが公開され、そのドメイン名がSPFまたはDKIMを通じて検証されない場合、そのメッセージの処理は、参加している受信者に配信されるときにそのDMARCポリシーの影響を受ける可能性があります。

It is important to note that the authentication mechanisms employed by DMARC authenticate only a DNS domain and do not authenticate the local-part of any email address identifier found in a message, nor do they validate the legitimacy of message content.


DMARC's feedback component involves the collection of information about received messages claiming to be from the Organizational Domain for periodic aggregate reports to the Domain Owner. The parameters and format for such reports are discussed in later sections of this document.


A DMARC-enabled Mail Receiver might also generate per-message reports that contain information related to individual messages that fail SPF and/or DKIM. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [AFRF].


A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:


1. produces a "pass" result, and

1. 「合格」結果を生成し、

2. produces that result based on an identifier that is in alignment, as defined in Section 3.

2. セクション3で定義されているように、整列している識別子に基づいてその結果を生成します。

4.3. Flow Diagram
4.3. フロー図
    | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
    +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    ^            ^        .
        |                                    **************        .
        V                                                 *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
     | sMTA |------->( other MTAs )----->| rMTA |         *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
                                            |             * ........
                                            |             * .
                                            V             * .
                                     +-----------+        V V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

MSA = Mail Submission Agent MDA = Mail Delivery Agent

MSA =メール送信エージェントMDA =メール配信エージェント

The above diagram shows a simple flow of messages through a DMARC-aware system. Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to the supported message authentication schemes, and asterisk lines indicate data exchange between message-handling modules and message authentication modules. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.

上の図は、DMARC対応システムを介したメッセージの単純なフローを示しています。実線は実際のメッセージフローを示し、点線はサポートされているメッセージ認証スキームに関連するメッセージポリシーを取得するために使用されるDNSクエリを含み、アスタリスク線はメッセージ処理モジュールとメッセージ認証モジュール間のデータ交換を示します。 「sMTA」は送信MTA、「rMTA」は受信MTAです。

In essence, the steps are as follows:


1. Domain Owner constructs an SPF policy and publishes it in its DNS database as per [SPF]. Domain Owner also configures its system for DKIM signing as described in [DKIM]. Finally, Domain Owner publishes via the DNS a DMARC message-handling policy.

1. ドメイン所有者はSPFポリシーを作成し、[SPF]に従ってDNSデータベースに公開します。ドメイン所有者は、[DKIM]で説明されているように、DKIM署名用にシステムを構成します。最後に、ドメイン所有者はDNSを介してDMARCメッセージ処理ポリシーを公開します。

2. Author generates a message and hands the message to Domain Owner's designated mail submission service.

2. 作成者はメッセージを生成し、ドメイン所有者の指定したメール送信サービスにメッセージを渡します。

3. Submission service passes relevant details to the DKIM signing module in order to generate a DKIM signature to be applied to the message.

3. 送信サービスは、メッセージに適用されるDKIM署名を生成するために、関連する詳細をDKIM署名モジュールに渡します。

4. Submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s).

4. 送信サービスは、署名されたメッセージを指定のトランスポートサービスに中継して、目的の受信者にルーティングします。

5. Message may pass through other relays but eventually arrives at a recipient's transport service.

5. メッセージは他のリレーを通過する可能性がありますが、最終的には受信者のトランスポートサービスに到着します。

6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which requires queries to the Author Domain's DNS data (when identifiers are aligned; see below).

6. 受信者配信サービスは、必要なデータをそれぞれのモジュールに渡すことにより、SPFおよびDKIM認証チェックを実行します。各モジュールには、作成者ドメインのDNSデータへのクエリが必要です(識別子が揃っている場合。以下を参照)。

7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)

7. これらの結果は、作者のドメインとともにDMARCモジュールに渡されます。 DMARCモジュールは、そのドメインのDNSからポリシーを取得しようとします。見つからない場合、DMARCモジュールは組織ドメインを決定し、DNSからポリシーを取得する試みを繰り返します。 (これについては、セクション6.6.3で詳しく説明します。)

8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail") and can optionally cause one of two kinds of reports to be generated (not shown).

8. ポリシーが見つかると、作成者のドメインとSPFおよびDKIMの結果が組み合わされてDMARCポリシーの結果(「合格」または「不合格」)が生成され、オプションで2種類のレポートのいずれかが生成されます(示されています)。

9. Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown).

9. 受信者トランスポートサービスは、メッセージを受信者の受信トレイに配信するか、DMARCの結果に基づいて他のローカルポリシーアクションを実行します(図には示されていません)。

10. When requested, Recipient transport service collects data from the message delivery session to be used in providing feedback (see Section 7).

10. 要求されると、受信者トランスポートサービスはメッセージ配信セッションからデータを収集して、フィードバックの提供に使用します(セクション7を参照)。

5. Use of RFC5322.From
5. RFC5322.Fromの使用

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.


Several points suggest that it is the most correct and safest thing to do in this context:


o Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present.

o メッセージ自体の一部であるすべての識別子の中で、これが存在することが保証されている唯一のものです。

o It seems the best choice of an identifier on which to focus, as most MUAs display some or all of the contents of that field in a manner strongly suggesting those data as reflective of the true originator of the message.

o ほとんどのMUAは、メッセージの真の発信者を反映するものとしてそれらのデータを強く示唆する方法でそのフィールドの内容の一部またはすべてを表示するので、焦点を合わせる識別子の最良の選択のようです。

The absence of a single, properly formed RFC5322.From field renders the message invalid. Handling of such a message is outside of the scope of this specification.


Since the sorts of mail typically protected by DMARC participants tend to only have single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 with respect to the expected syntax of this field. See Section 6.6 for details.


6. Policy
6. 方針

DMARC policies are published by Domain Owners and applied by Mail Receivers.


A Domain Owner advertises DMARC participation of one or more of its domains by adding a DNS TXT record (described in Section 6.1) to those domains. In doing so, Domain Owners make specific requests of Mail Receivers regarding the disposition of messages purporting to be from one of the Domain Owner's domains and the provision of feedback about those messages.

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

A Domain Owner may choose not to participate in DMARC evaluation by Mail Receivers. In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result.


A Mail Receiver implementing the DMARC mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner's published DMARC policy when a message fails the DMARC test. Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).


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

Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". Similarly, a Mail Receiver wishing to query for DMARC preferences regarding mail with an RFC5322.From domain of "example.com" would issue a TXT query to the DNS for the subdomain of "_dmarc.example.com". The DNS-located DMARC preference data will hereafter be called the "DMARC record".

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

DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS, for obtaining simple parametric information. It uses an established method of storing the information, associated with the target domain name, namely an isolated TXT record that is restricted to the DMARC context. Use of the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.


Per [DNS], a TXT record can comprise several "character-string" objects. Where this is the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string.



[URI] defines a generic syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner specifies the destination for the two report types that are supported.

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

The place such URIs are specified (see Section 6.3) allows a list of these to be provided. A report is normally sent to each listed URI in the order provided by the Domain Owner. Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two. The list of URIs is separated by commas (ASCII 0x2C).

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

Each URI can have associated with it a maximum report size that may be sent to it. This is accomplished by appending an exclamation point (ASCII 0x21), followed by a maximum-size indication, before a separating comma or terminating semicolon.

各URIには、送信できる最大レポートサイズを関連付けることができます。これは、感嘆符(ASCII 0x21)を追加し、その後に最大サイズを示すことにより、コンマを区切るか、セミコロンで終了します。

Thus, a DMARC URI is a URI within which any commas or exclamation points are percent-encoded per [URI], followed by an OPTIONAL exclamation point and a maximum-size specification, and, if there are additional reporting URIs in the list, a comma and the next URI.

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

For example, the URI "mailto:reports@example.com!50m" would request that a report be sent via email to "reports@example.com" so long as the report payload does not exceed 50 megabytes.


A formal definition is provided in Section 6.4.


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

DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].

DMARCレコードは、DKIM [DKIM]で定義されたDNSベースのキーレコードの拡張可能な「タグ値」構文に従います。

Section 11 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored.


The following tags are introduced as the initial valid DMARC tags:


adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. See Section 3.1.1 for details. Valid values are as follows:

adkim:(plain-text; OPTIONAL;デフォルトは "r"です。)ドメイン所有者が厳密なDKIM識別子調整モードを必要とするかどうかを示します。詳細については、セクション3.1.1を参照してください。有効な値は次のとおりです。

r: relaxed mode


s: strict mode


aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. See Section 3.1.2 for details. Valid values are as follows:

aspf:(plain-text; OPTIONAL;デフォルトは "r"です。)ドメイン所有者が厳密なSPF識別子調整モードを必要とするか緩和するかを示します。詳細については、セクション3.1.2を参照してください。有効な値は次のとおりです。

r: relaxed mode


s: strict mode


fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:

fo:障害レポートオプション(プレーンテキスト、オプション、デフォルトは「0」)障害レポートの生成に必要なオプションを提供します。レポートジェネレーターは、要求されたオプションに従うことを選択できます。 「下記」のrufタグも指定されていない場合、このタグのコンテンツは無視する必要があります。このタグの値は、次のように、障害報告オプションを示す、コロンで区切られた文字のリストです。

0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.


1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.


d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [AFRF-DKIM].

d:アライメントに関係なく、メッセージに評価に失敗した署名が含まれている場合は、DKIM障害レポートを生成します。 DKIM固有のレポートについては、[AFRF-DKIM]で説明されています。

s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF].

s:メッセージが整列に関係なくSPF評価に失敗した場合、SPF障害レポートを生成します。 SPF固有のレポートについては、[AFRF-SPF]で説明されています。

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows:


none: The Domain Owner requests no specific action be taken regarding delivery of messages.


quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".


reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.

reject:ドメイン所有者は、DMARCメカニズムチェックに失敗したメールをメール受信者が拒否することを望んでいます。拒否は、SMTPトランザクション中に発生する必要があります(SHOULD)。 SMTP拒否方法とその影響については、セクション10.3を参照してください。

pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The purpose of the "pct" tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of "all or nothing" is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. See Section 6.6.4 for details. Note that random selection based on this percentage, such as the following pseudocode, is adequate:

pct:(0から100までのプレーンテキスト整数、オプション、オプション、デフォルトは100)。 DMARCポリシーが適用されるドメイン所有者のメールストリームからのメッセージの割合。ただし、これはDMARCで生成されたレポートには適用しないでください。これらのレポートはすべて、妨げられずに送受信する必要があります。 「pct」タグの目的は、ドメイン所有者がDMARCメカニズムの遅いロールアウトの実施を実施できるようにすることです。 「オールオアナッシング」の見込みは、多くの組織が強力な認証ベースのメカニズムを試すことを妨げていると認識されています。詳細については、セクション6.6.4を参照してください。次の擬似コードのように、このパーセンテージに基づくランダム選択が適切であることに注意してください。

if (random mod 100) < pct then selected = true else selected = false

if(random mod 100)<pct then selected = true else selected = false

rf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both [SPF] and [DKIM] tests to report details of the individual failure. The values MUST be present in the registry of reporting formats defined in Section 11; a Mail Receiver observing a different value SHOULD ignore it or MAY ignore the entire DMARC record. For this version, only "afrf" (the auth-failure report type defined in [AFRF]) is presently supported. See Section 7.3 for details. For interoperability, the Authentication Failure Reporting Format (AFRF) MUST be supported.

rf:メッセージ固有の障害レポートに使用される形式(コロンで区切られた値の平文リスト、オプション、デフォルトは "afrf")。このタグの値は、メッセージが[SPF]と[DKIM]の両方のテストに失敗して個々の失敗の詳細を報告するときに使用される、ドメイン所有者から要求された1つ以上のレポート形式のリストです。値は、セクション11で定義されているレポート形式のレジストリに存在している必要があります。別の値を監視するメールレシーバーはそれを無視するか、DMARCレコード全体を無視する必要があります。このバージョンでは、「afrf」([AFRF]で定義されているauth-failureレポートタイプ)のみが現在サポートされています。詳細については、セクション7.3を参照してください。相互運用性のために、認証失敗報告形式(AFRF)をサポートする必要があります。

ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis.

ri:集約レポート間で要求される間隔(プレーンテキストの32ビット符号なし整数、オプション、デフォルトは86400)。要求された秒数以下で区切られた集約レポートを生成するためのレシーバーへの要求を示します。 DMARC実装は、日次レポートを提供できなければならず、要求されたときに時間別レポートを提供できなければなりません(SHOULD)。ただし、日次レポート以外はベストエフォートベースで対応できると理解されています。

rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma or exclamation point that is part of such a DMARC URI MUST be encoded per Section 2.1 of [URI] so as to distinguish it from the list delimiter or an OPTIONAL size limit. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 12.5 for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate aggregate feedback reports. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in Section 7.2.

rua:集約フィードバックの送信先アドレス(DMARC URIのコンマ区切りのプレーンテキストリスト。オプション)。このようなDMARC URIの一部であるコンマまたは感嘆符は、[URI]のセクション2.1に従ってエンコードして、リストの区切り文字またはオプションのサイズ制限と区別する必要があります。セクション7.1では、URIのドメイン名がポリシーをアドバタイズするドメインのドメイン名と異なる場合に適用される考慮事項について説明します。その他の考慮事項については、セクション12.5を参照してください。任意の有効なURIを指定できます。メールレシーバーは、「mailto:」URIのサポート、つまり電子メールを介してDMARCレポートを送信する機能を実装する必要があります。提供されない場合、メール受信者は集約フィードバックレポートを生成してはなりません(MUST NOT)。メールレシーバーでサポートされていないURIは無視する必要があります。集計フィードバックレポートの形式については、セクション7.2で説明しています。

ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag above). The format of the message to be generated MUST follow the format specified for the "rf" tag. Section 7.1 discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate failure reports. See Section 12.5 for additional considerations.

ruf:メッセージ固有の障害情報が報告されるアドレス(DMARC URIのコンマ区切りのプレーンテキストリスト。オプション)。存在する場合、ドメイン所有者は、特定の方法でDMARC評価に失敗したメッセージに関する詳細な失敗レポートを送信するようにメールレシーバーに要求しています(上記の「fo」タグを参照)。生成されるメッセージの形式は、「rf」タグに指定された形式に従う必要があります。セクション7.1では、URIのドメイン名がポリシーをアドバタイズするドメインのドメイン名と異なる場合に適用される考慮事項について説明します。メールレシーバーは、「mailto:」URIのサポート、つまり電子メールを介してDMARCレポートを送信する機能を実装する必要があります。指定しない場合、メール受信者は失敗レポートを生成してはなりません(MUST NOT)。その他の考慮事項については、セクション12.5を参照してください。

sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3.


v: Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1". The value of this tag MUST match precisely; if it does not or it is absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list.

v:バージョン(プレーンテキスト、必須)。取得したレコードをDMARCレコードとして識別します。 「DMARC1」の値が必要です。このタグの値は正確に一致する必要があります。存在しない場合や存在しない場合は、取得したレコード全体を無視する必要があります。リストの最初のタグでなければなりません。

A DMARC policy record MUST comply with the formal specification found in Section 6.4 in that the "v" and "p" tags MUST be present and MUST appear in that order. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright.


Note that given the rules of the previous paragraph, addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC.


6.4. Formal Definition
6.4. 正式な定義

The formal definition of the DMARC format, using [ABNF], is as follows:


     dmarc-uri       = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
                       ; "URI" is imported from [URI]; commas (ASCII
                       ; 0x2C) and exclamation points (ASCII 0x21)
                       ; MUST be encoded; the numeric portion MUST fit
                       ; within an unsigned 64-bit integer
     dmarc-record    = dmarc-version dmarc-sep
                       [dmarc-sep dmarc-srequest]
                       [dmarc-sep dmarc-auri]
                       [dmarc-sep dmarc-furi]
                       [dmarc-sep dmarc-adkim]
                       [dmarc-sep dmarc-aspf]
                       [dmarc-sep dmarc-ainterval]
                       [dmarc-sep dmarc-fo]
                       [dmarc-sep dmarc-rfmt]
                       [dmarc-sep dmarc-percent]
                       ; components other than dmarc-version and
                       ; dmarc-request may appear in any order
     dmarc-version   = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
     dmarc-sep       = *WSP %x3b *WSP
     dmarc-request   = "p" *WSP "=" *WSP
                       ( "none" / "quarantine" / "reject" )
     dmarc-srequest  = "sp" *WSP "=" *WSP
                       ( "none" / "quarantine" / "reject" )
     dmarc-auri      = "rua" *WSP "=" *WSP
                       dmarc-uri *(*WSP "," *WSP dmarc-uri)
     dmarc-furi      = "ruf" *WSP "=" *WSP
                       dmarc-uri *(*WSP "," *WSP dmarc-uri)
     dmarc-adkim     = "adkim" *WSP "=" *WSP
                       ( "r" / "s" )
     dmarc-aspf      = "aspf" *WSP "=" *WSP
                       ( "r" / "s" )
     dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT
     dmarc-fo        = "fo" *WSP "=" *WSP
                       ( "0" / "1" / "d" / "s" )
                       *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))
     dmarc-rfmt      = "rf"  *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
                       ; registered reporting formats only
     dmarc-percent   = "pct" *WSP "=" *WSP

"Keyword" is imported from Section 4.1.2 of [SMTP].


A size limitation in a dmarc-uri, if provided, is interpreted as a count of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the number is presumed to be a basic byte count. Note that the units are considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc.

dmarc-uriのサイズ制限は、指定されている場合、オプションの単位サイズが続く単位の数として解釈されます(キロバイトの場合は「k」、メガバイトの場合は「m」、ギガバイトの場合は「g」、テラバイトの場合は「t」) 。単位がない場合、その数は基本的なバイト数と見なされます。単位は2の累乗と見なされることに注意してください。キロバイトは2 ^ 10、メガバイトは2 ^ 20などです。

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

To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both.


DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate.


Authentication technologies are discussed in [DKIM] (see also [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF].


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

This section describes receiver actions in the DMARC environment.


6.6.1. Extract Author Domain
6.6.1. 著者ドメインを抽出

The domain in the RFC5322.From field is extracted as the domain to be evaluated by DMARC. If the domain is encoded with UTF-8, the domain name must be converted to an A-label, as described in Section 2.3 of [IDNA], for further processing.


In order to be processed by DMARC, a message typically needs to contain exactly one RFC5322.From domain (a single From: field with a single domain in it). Not all messages meet this requirement, and handling of them is outside of the scope of this document. Typical exceptions, and the way they have been historically handled by DMARC participants, are as follows:


o Messages with multiple RFC5322.From fields are typically rejected, since that form is forbidden under RFC 5322 [MAIL];

o RFC5322.Fromフィールドが複数あるメッセージは、RFC 5322 [メール]でそのフォームが禁止されているため、通常は拒否されます。

o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format;

o 複数のアドレス(つまり、評価される複数のドメイン名)を含む単一のRFC5322.Fromフィールドを持つメッセージは、通常DMARCによって保護される種類のメールではこの形式を使用しないため、通常は拒否されます。

o Messages that have no RFC5322.From field at all are typically rejected, since that form is forbidden under RFC 5322 [MAIL];

o RFC5322.Fromフィールドがまったくないメッセージは、RFC 5322 [メール]でそのフォームが禁止されているため、通常は拒否されます。

o Messages with an RFC5322.From field that contains no meaningful domains, such as RFC 5322 [MAIL]'s "group" syntax, are typically ignored.

o RFC 5322 [MAIL]の「グループ」構文など、意味のあるドメインを含まないRFC5322.Fromフィールドを持つメッセージは、通常無視されます。

The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail.


6.6.2. Determine Handling Policy
6.6.2. 取り扱い方針の決定

To arrive at a policy for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps.


The steps are as follows:


1. Extract the RFC5322.From domain from the message (as above).

1. RFC5322.Fromドメインをメッセージから抽出します(上記のとおり)。

2. Query the DNS for a DMARC policy record. Continue if one is found, or terminate DMARC evaluation otherwise. See Section 6.6.3 for details.

2. DNSにDMARCポリシーレコードを照会します。見つかった場合は続行するか、そうでない場合はDMARC評価を終了します。詳細については、セクション6.6.3を参照してください。

3. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature.

3. DKIM署名検証チェックを実行します。 1つのメールに複数のDKIM署名が含まれる場合があります。このステップの結果は、アルゴリズムの残りの部分に渡され、チェックされた各DKIM署名からの「d =」タグの値を含める必要があります。

4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check.

4. SPF検証チェックを実行します。このステップの結果は残りのアルゴリズムに渡され、SPFチェックを完了するために使用されるドメイン名を含める必要があります。

5. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures.

5. 識別子の配置チェックを実施します。認証チェックとポリシー検出が実行されると、メールレシーバーは、セクション3で説明されているように、認証済み識別子が整合しているかどうかを確認します。1つ以上の認証済み識別子がRFC5322.Fromドメインと整合している場合、メッセージはDMARCメカニズムチェック。他のすべての条件(認証の失敗、識別子の不一致)は、DMARCメカニズムチェックの失敗と見なされます。

6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details.

6. ポリシーを適用します。 DMARCメカニズムのチェックに失敗したメールは、ドメイン所有者の検出されたDMARCポリシーに従って破棄されます。詳細については、セクション6.3を参照してください。

Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a Message Receiver not to consider the results of that underlying authentication protocol at all.


DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them fail due to a temporary error, the Receiver evaluating the message is unable to conclude that the DMARC mechanism had a permanent failure; they therefore cannot apply the advertised DMARC policy. When otherwise appropriate, Receivers MAY send feedback reports regarding temporary errors.


Handling of messages for which SPF and/or DKIM evaluation encounter a permanent DNS error is left to the discretion of the Mail Receiver.


6.6.3. Policy Discovery
6.6.3. ポリシーの発見

As stated above, the DMARC mechanism uses DNS TXT records to advertise policy. Policy discovery is accomplished via a method similar to the method used for SPF records. This method, and the important differences between DMARC and SPF mechanisms, are discussed below.

上記のように、DMARCメカニズムはDNS TXTレコードを使用してポリシーをアドバタイズします。ポリシーの検出は、SPFレコードに使用される方法と同様の方法で行われます。この方法と、DMARCメカニズムとSPFメカニズムの重要な違いについて、以下で説明します。

To balance the conflicting requirements of supporting wildcarding, allowing subdomain policy overrides, and limiting DNS query load, the following DNS lookup scheme is employed:


1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322.From domain in the message. A possibly empty set of records is returned.

1. メール受信者は、メッセージ内のRFC5322.Fromドメインにあるものと一致するDNSドメインのDMARC TXTレコードをDNSに照会する必要があります。空のレコードセットが返されます。

2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.

2. DMARCの現在のバージョンを識別する「v =」タグで始まらないレコードは破棄されます。

3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned.

3. セットが現在空の場合、メールレシーバーは、メッセージ内のRFC5322.Fromドメイン(異なる場合)の代わりに、組織ドメインと一致するDNSドメインでDMARC TXTレコードをDNSに照会する必要があります。このレコードには、組織ドメインのサブドメインに対してアサートされるポリシーを含めることができます。空のレコードセットが返されます。

4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded.

4. DMARCの現在のバージョンを識別する「v =」タグで始まらないレコードは破棄されます。

5. If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message.

5. 残りのセットに複数のレコードが含まれている場合、またはレコードが含まれていない場合、ポリシー検出は終了し、DMARC処理はこのメッセージに適用されません。

6. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" tag that is not valid, then:

6. 取得したポリシーレコードに有効な「p」タグが含まれていない場合、または無効な「sp」タグが含まれている場合は、次のようになります。

1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing;

1. 「rua」タグが存在し、構文的に有効なレポートURIが少なくとも1つ含まれている場合、メールレシーバーは、有効な「v」タグと「p = none」を含むレコードが取得されたかのように動作し、処理を続行する必要があります。

2. otherwise, the Mail Receiver applies no DMARC processing to this message.

2. それ以外の場合、メールレシーバーはこのメッセージにDMARC処理を適用しません。

If the set produced by the mechanism above contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC mechanism to the message.

上記のメカニズムによって生成されたセットにDMARCポリシーレコードが含まれていない場合(つまり、一時的なDNSエラーではなく、そのようなレコードがないことを示す場合)、メールレシーバーはDMARCメカニズムをメッセージに適用しないでください(SHOULD NOT)。

Handling of DNS errors when querying for the DMARC policy record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed").

DMARCポリシーレコードのクエリ時のDNSエラーの処理は、メールレシーバーの裁量に任されています。たとえば、メールフローの中断を最小限に抑えるために、一時的なエラーによってメッセージが配信される(「フェールオープン」)か、メッセージが一時的に拒否される(つまり、SMTP 4yx応答)場合があります。状態がおそらくクリアされた後、MTAは再試行して、DMARCの明確な結論に到達できるようにします(「フェイルクローズ」)。

6.6.4. Message Sampling
6.6.4. メッセージのサンプリング

If the "pct" tag is present in the policy record, the Mail Receiver MUST NOT enact the requested policy ("p" tag or "sp" tag") on more than the stated percent of the totality of affected messages. However, regardless of whether or not the "pct" tag is present, the Mail Receiver MUST include all relevant message data in any reports produced.

「pct」タグがポリシーレコードに存在する場合、メールレシーバーは、要求されたポリシー(「p」タグまたは「sp」タグ)を、影響を受けるメッセージの総数の指定されたパーセントを超えて制定してはなりません(MUST NOT)。 「pct」タグが存在するかどうかに関係なく、メールレシーバーは、生成されるレポートにすべての関連メッセージデータを含める必要があります。

If email is subject to the DMARC policy of "quarantine", the Mail Receiver SHOULD quarantine the message. If the email is not subject to the "quarantine" policy (due to the "pct" tag), the Mail Receiver SHOULD apply local message classification as normal.


If email is subject to the DMARC policy of "reject", the Mail Receiver SHOULD reject the message (see Section 10.3). If the email is not subject to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies. This behavior allows Domain Owners to experiment with progressively stronger policies without relaxing existing policy.


Mail Receivers implement "pct" via statistical mechanisms that achieve a close approximation to the requested percentage and provide a representative sample across a reporting period.


6.6.5. Store Results of DMARC Processing
6.6.5. DMARC処理の結果の保存

The results of Mail Receiver-based DMARC processing should be stored for eventual presentation back to the Domain Owner in the form of aggregate feedback reports. Sections 6.3 and 7.2 discuss aggregate feedback.


6.7. Policy Enforcement Considerations
6.7. ポリシー施行の考慮事項

Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism check. The DMARC mechanism does not inform Mail Receivers whether an email stream is "good". Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled criminal campaigns.

メール受信者は、電子メールがDMARCメカニズムチェックに合格した場合でも、電子メールを拒否または隔離することを選択できます。 DMARCメカニズムは、メールストリームが「良好」であるかどうかをメール受信者に通知しません。メールレシーバーは、DMARC対応の犯罪キャンペーンの可能性に対抗するために、乱用防止テクノロジーを維持することをお勧めします。

Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. Mail Receivers need to make a best effort not to increase the likelihood of accepting abusive mail if they choose not to comply with a Domain Owner's reject, against policy. At a minimum, addition of the Authentication-Results header field (see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing mail is done. When this is done, the DNS domain name thus recorded MUST be encoded as an A-label.


Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. They are not required to report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns.


Final disposition of a message is always a matter of local policy. An operator that wishes to favor DMARC policy over SPF policy, for example, will disregard the SPF policy, since enacting an SPF-determined rejection prevents evaluation of DKIM; DKIM might otherwise pass, satisfying the DMARC evaluation. There is a trade-off to doing so, namely acceptance and processing of the entire message body in exchange for the enhanced protection DMARC provides.


DMARC-compliant Mail Receivers typically disregard any mail-handling directive discovered as part of an authentication mechanism (e.g., Author Domain Signing Practices (ADSP), SPF) where a DMARC record is also discovered that specifies a policy other than "none". Deviating from this practice introduces inconsistency among DMARC operators in terms of handling of the message. However, such deviation is not proscribed.

DMARC準拠のメールレシーバーは通常、「なし」以外のポリシーを指定するDMARCレコードも検出される認証メカニズム(たとえば、Author Domain Signing Practices(ADSP)、SPF)の一部として検出されたメール処理ディレクティブを無視します。この方法から逸脱すると、メッセージの処理に関してDMARCオペレーター間で不整合が生じます。ただし、そのような逸脱は禁止されていません。

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.

ドメイン所有者が既存のメール処理に影響を与えずにDMARCフィードバックを受信できるようにするには、「p = none」の検出されたポリシーで既存のメール処理を変更しないでください。

Mail Receivers SHOULD also implement reporting instructions of DMARC, even in the absence of a request for DKIM reporting [AFRF-DKIM] or SPF reporting [AFRF-SPF]. Furthermore, the presence of such requests SHOULD NOT affect DMARC reporting.


7. DMARC Feedback
7. DMARCフィードバック

Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies.


7.1. Verifying External Destinations
7.1. 外部宛先の確認

It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them.


Without checks, this would allow a bad actor to publish a DMARC policy record that requests that reports be sent to a victim address, and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.


When a Mail Receiver discovers a DMARC policy in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken:

メールレシーバーがDNSでDMARCポリシーを検出し、そのレコードが検出された組織ドメインが、「rua」または「」で指定された[URI]の権限コンポーネントのホスト部分の組織ドメインと同一でない場合ruf "タグ、次の検証手順を実行する必要があります。

1. Extract the host portion of the authority component of the URI. Call this the "destination host", as it refers to a Report Receiver.

1. URIの権限コンポーネントのホスト部分を抽出します。レポートレシーバーを指すため、これを「宛先ホスト」と呼びます。

2. Prepend the string "_report._dmarc".

2. 文字列「_report._dmarc」を先頭に追加します。

3. Prepend the domain name from which the policy was retrieved, after conversion to an A-label if needed.

3. 必要に応じてAラベルに変換した後、ポリシーの取得元のドメイン名を付加します。

4. Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later.

4. 構成された名前でTXTレコードのDNSを照会します。このリクエストの結果がなんらかの一時的なDNSエラー(タイムアウトなど)である場合、メールレシーバーは一時的に配信を失敗させて、後で検証テストを繰り返すことができます。

5. For each record returned, parse the result as a series of "tag=value" pairs, i.e., the same overall format as the policy record (see Section 6.4). In particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list. Discard any that do not pass this test.

5. 返された各レコードについて、結果を一連の「tag = value」ペアとして解析します。つまり、ポリシーレコードと同じ全体形式です(6.4項を参照)。特に、「v = DMARC1」タグは必須であり、リストの最初に出現する必要があります。このテストに合格しないものはすべて破棄します。

6. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.

6. 結果に基本的な解析を通過するTXTリソースレコードが含まれていない場合、外部レポートの関係を明確に判断できません。やめる。

7. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Receiver.

7. 解析後に少なくとも1つのTXTリソースレコードがセットに残っている場合、外部レポートの配置はレポートレシーバーによって承認されました。

8. If a "rua" or "ruf" tag is thus discovered, replace the corresponding value extracted from the domain's DMARC policy record with the one found in this record. This permits the Report Receiver to override the report destination. However, to prevent loops or indirect abuse, the overriding URI MUST use the same destination host from the first step.

8. 「rua」または「ruf」タグがこのように検出された場合は、ドメインのDMARCポリシーレコードから抽出された対応する値を、このレコードで見つかった値に置き換えます。これにより、レポートレシーバーはレポートの宛先を上書きできます。ただし、ループや間接的な悪用を防ぐために、オーバーライドするURIは最初のステップと同じ宛先ホストを使用する必要があります。

For example, if a DMARC policy query for "blue.example.com" contained "rua=mailto:reports@red.example.net", the host extracted from the latter ("red.example.net") does not match "blue.example.com", so this procedure is enacted. A TXT query for "blue.example.com._report._dmarc.red.example.net" is issued. If a single reply comes back containing a tag of "v=DMARC1", then the relationship between the two is confirmed. Moreover, "red.example.net" has the opportunity to override the report destination requested by "blue.example.com" if needed.

たとえば、「blue.example.com」のDMARCポリシークエリに「rua = mailto:reports@red.example.net」が含まれている場合、後者から抽出されたホスト(「red.example.net」)は「 blue.example.com "なので、この手順が実行されます。 「blue.example.com._report._dmarc.red.example.net」のTXTクエリが発行されます。 「v = DMARC1」のタグを含む単一の応答が返された場合、2つの間の関係が確認されます。さらに、「red.example.net」は、必要に応じて「blue.example.com」によって要求されたレポートの宛先を上書きする機会があります。

Where the above algorithm fails to confirm that the external reporting was authorized by the Report Receiver, the URI MUST be ignored by the Mail Receiver generating the report. Further, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI.


A Report Receiver publishes such a record in its DNS if it wishes to receive reports for other domains.


A Report Receiver that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.

任意のドメインのレポートを受信するレポートレシーバーは、ワイルドカードDNSレコードを使用できます。たとえば、少なくとも「v = DMARC1」を含む「* ._ report._dmarc.example.com」のTXTリソースレコードは、example.comが任意のドメインのDMARCレポートを受信する用意があることを確認します。

If the Report Receiver is overcome by volume, it can simply remove the confirming DNS record. However, due to positive caching, the change could take as long as the time-to-live (TTL) on the record to go into effect.


A Mail Receiver might decide not to enact this procedure if, for example, it relies on a local list of domains for which external reporting addresses are permitted.


7.2. Aggregate Reports
7.2. 集計レポート

The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into:


o authentication results,

o 認証結果、

o corrective action that needs to be taken by Domain Owners, and

o ドメイン所有者が行う必要がある是正措置

o the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers.

o メール受信者が処理するメールストリームに対するドメイン所有者DMARCポリシーの影響。

Aggregate DMARC feedback provides visibility into real-world email streams that Domain Owners need to make informed decisions regarding the publication of DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forged mail receivers are getting, they can make better decisions about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently.


Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not.


The format for these reports is defined in Appendix C.


The report SHOULD include the following data:


o The DMARC policy discovered and applied, if any

o DMARCポリシーが発見され、適用された場合、

o The selected message disposition

o 選択したメッセージの処理

o The identifier evaluated by SPF and the SPF result, if any

o SPFによって評価された識別子とSPF結果(ある場合)

o The identifier evaluated by DKIM and the DKIM result, if any

o DKIMによって評価された識別子と、DKIMの結果(ある場合)

o For both DKIM and SPF, an indication of whether the identifier was in alignment

o DKIMとSPFの両方で、識別子が整列していたかどうかの指標

o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy

o 明示的なサブドメインポリシーがない場合でも、送信者の組織ドメインからのメールとは別に、各ドメイン所有者のサブドメインのデータ

o Sending and receiving domains

o ドメインの送受信

o The policy requested by the Domain Owner and the policy actually applied (if different)

o ドメイン所有者が要求したポリシーと実際に適用されたポリシー(異なる場合)

o The number of successful authentications

o 成功した認証の数

o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents

o 配信が他のフィルターエージェントによって最終的にブロックされた場合でも、受信したすべてのメッセージに基づくメッセージの数

Note that Domain Owners or their agents may change the published DMARC policy for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following:


o generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element;

o レポートに「policy_published」要素が1つしか含まれていない場合でも、そのようなレポート期間に、古いポリシーに基づくメッセージの性質を含む単一の集約レポート、または2つのポリシーの混合を生成します。

o generate multiple reports for the same period, one for each published policy occurring during the reporting period;

o レポート期間中に発生した公開されたポリシーごとに1つ、同じ期間の複数のレポートを生成します。

o generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval.

o 要求されたレポート間隔に関係なく、更新されたポリシーが検出されたときに終了時間が発生するレポートを生成します。

Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. Therefore, it is the responsibility of report consumers and Domain Owners to be aware of this situation and allow for such mixed reports during the propagation of the new policy to Mail Receivers.


Aggregate reports are most useful when they all cover a common time period. By contrast, correlation of these reports from multiple generators when they cover incongruent time periods is difficult or impossible. Report generators SHOULD, wherever possible, adhere to hour boundaries for the reporting period they are using. For example, starting a per-day report at 00:00; starting per-hour reports at 00:00, 01:00, 02:00; etc. Report generators using a 24-hour report period are strongly encouraged to begin that period at 00:00 UTC, regardless of local timezone or time of report production, in order to facilitate correlation.

集計レポートは、すべてが共通の期間をカバーしている場合に最も役立ちます。対照的に、一致しない期間をカバーする場合、複数のジェネレーターからのこれらのレポートの相関は困難または不可能です。レポートジェネレーターは、可能な限り、使用しているレポート期間の時間境界を遵守する必要があります(SHOULD)。たとえば、日別レポートを00:00に開始します。 1時間ごとのレポートを00:00、01:00、02:00に開始します。相関を容易にするために、24時間のレポート期間を使用するレポートジェネレーターは、ローカルタイムゾーンやレポート作成の時刻に関係なく、00:00 UTCにその期間を開始することを強くお勧めします。

A Mail Receiver discovers reporting requests when it looks up a DMARC policy record that corresponds to an RFC5322.From domain on received mail. The presence of the "rua" tag specifies where to send feedback.

メールレシーバーは、受信したメールのRFC5322.Fromドメインに対応するDMARCポリシーレコードを検索するときに、レポート要求を検出します。 「rua」タグの存在は、フィードバックの送信先を指定します。

7.2.1. Transport
7.2.1. 輸送

Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism.


The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.


If transport is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver SHOULD send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent.

公開されたURIによってアドバタイズされたサービスがレポートを受け入れることができないためにトランスポートが不可能である場合(たとえば、URIが到達不能なサービスを参照しているか、提供されたすべてのURIが生成されたレコードが超過するサイズ制限を指定している)、メールレシーバーはSHOULDレポートが利用可能であるが送信できなかったことを示す短いレポート(セクション7.2.2を参照)を送信します。メールレシーバーはそのデータをキャッシュして後で再試行するか、送信できなかったデータを破棄する場合があります。 Email Eメール

The message generated by the Mail Receiver MUST be a [MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part).


The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type "application/ gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The filename is typically constructed using the following ABNF:

集計データは、GZIP圧縮を行う必要があるXMLファイルである必要があります。圧縮の適用を拒否すると、レポートが大きくなりすぎて受信者が処理できなくなる場合があります(一般的に観察される受信者の制限は10メガバイトです)。圧縮を行うと、一部の計算コストでレポートを受け入れる可能性が高くなります。集約データは、圧縮されている場合は[application / gzip]([GZIP]を参照)、それ以外の場合は "text / xml"のメディアタイプを使用して存在する必要があります(SHOULD)。ファイル名は通常、次のABNFを使用して作成されます。

     filename = receiver "!" policy-domain "!" begin-timestamp
                "!" end-timestamp [ "!" unique-id ] "." extension
     unique-id = 1*(ALPHA / DIGIT)

receiver = domain ; imported from [MAIL]

レシーバー=ドメイン; [MAIL]からインポート

     policy-domain   = domain
     begin-timestamp = 1*DIGIT
                       ; seconds since 00:00:00 UTC January 1, 1970
                       ; indicating start of the time range contained
                       ; in the report
     end-timestamp = 1*DIGIT
                     ; seconds since 00:00:00 UTC January 1, 1970
                     ; indicating end of the time range contained
                     ; in the report
     extension = "xml" / "xml.gz"

The extension MUST be "xml" for a plain XML file, or "xml.gz" for an XML file compressed using GZIP.


"unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner.


For example, this is a possible filename for the gzip file of a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example":



No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest.


Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports.


The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF:


     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d. ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     msg-id                          ; from RFC 5322

The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver.

最初のドメイン名は、レポートが生成されたDNSドメイン名を示します。 2番目のドメイン名は、レポートを生成するメールレシーバーを表すDNSドメイン名を示します。フィールドのReport-ID:部分の目的は、ドメイン所有者がメール受信者によって送信される可能性のある重複レポートを識別して無視できるようにすることです。

For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is line-wrapped as allowed by [MAIL]:

たとえば、これはメールレシーバー「mail.receiver.example」からドメインオーナー「example.com」へのレポートの可能なサブジェクトフィールドです。 [MAIL]で許可されているとおりに改行されます。

     Subject: Report Domain: example.com
         Submitter: mail.receiver.example
         Report-ID: <2002.02.15.1>

This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. See Section 7.2.2 for further discussion.

このトランスポートメカニズムでは、フィードバックデータのサイズがジェネレーターまたはコンシューマーのいずれかの最大許容添付ファイルサイズを超えると、問題が発生する可能性があります。詳細については、セクション7.2.2を参照してください。 Other Methods その他の方法

The specification as written allows for the addition of other registered URI schemes to be supported in later versions.


7.2.2. Error Reports
7.2.2. エラー報告

When a Mail Receiver is unable to complete delivery of a report via any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD generate an error message. An attempt MUST be made to send this report to all listed "mailto" URIs, and it MAY also be sent to any or all other listed URIs.


The error report MUST be formatted per [MIME]. A text/plain part MUST be included that contains field-value pairs such as those found in Section 2 of [DSN]. The fields required, which may appear in any order, are as follows:

エラーレポートは[MIME]ごとにフォーマットする必要があります。 [DSN]のセクション2にあるようなフィールドと値のペアを含むテキスト/プレーン部分を含める必要があります。必要なフィールドは次のとおりです。順序は任意です。

Report-Date: A [MAIL]-formatted date expression indicating when the transport failure occurred.


Report-Domain: The domain-name about which the failed report was generated.


Report-ID: The Report-ID: that the report tried to use.


Report-Size: The size, in bytes, of the report that was unable to be sent. This MUST represent the number of bytes that the Mail Receiver attempted to send. Where more than one transport system was attempted, the sizes may be different; in such cases, separate error reports MUST be generated so that this value matches the actual attempt that was made.


Submitter: The domain-name representing the Mail Receiver that generated, but was unable to submit, the report.


Submitting-URI: The URI(s) to which the Mail Receiver tried, but failed, to submit the report.


An additional text/plain part MAY be included that gives a human-readable explanation of the above and MAY also include a URI that can be used to seek assistance.


7.3. Failure Reports
7.3. 障害レポート

Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Whether the failure is due to an infrastructure problem or the message is inauthentic, failure reports also provide more information about the failed message than is available in an aggregate report.


These reports SHOULD include any URI(s) from the message that failed authentication. These reports SHOULD include as much of the message and message header as is reasonable to support the Domain Owner's investigation into what caused the message to fail authentication and track down the sender.


When a Domain Owner requests failure reports for the purpose of forensic analysis, and the Mail Receiver is willing to provide such reports, the Mail Receiver generates and sends a message using the format described in [AFRF]; this document updates that reporting format, as described in Section 7.3.1.


The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3.


Where multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them.


An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([ARF]). Various aggregation techniques are possible, including the following:


o only send a report to the first recipient of multi-recipient messages;

o 複数の受信者メッセージの最初の受信者にのみレポートを送信します。

o store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents;

o レポートを送信する前に一定期間保存し、同様のインシデントの検出、収集、およびレポートを可能にします。

o apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).

o 生成される1分あたりの最大レポート数などのレート制限を適用します(残りは破棄されます)。

7.3.1. Reporting Format Update
7.3.1. レポート形式の更新

Operators implementing this specification also implement an augmented version of [AFRF] as follows:


1. A DMARC failure report includes the following ARF header fields, with the indicated normative requirement levels:

1. DMARC障害レポートには、次のARFヘッダーフィールドが含まれ、指定された規範的な要件レベルが含まれます。

* Identity-Alignment (REQUIRED; defined below)

* Identity-Alignment(必須、以下で定義)

* Delivery-Result (OPTIONAL)

* 配信結果(オプション)

* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the message was signed by DKIM)

* DKIM-Domain、DKIM-Identity、DKIM-Selector(メッセージがDKIMによって署名された場合は必須)

* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if the message was signed by DKIM)

* DKIM-Canonicalized-Header、DKIM-Canonicalized-Body(メッセージがDKIMによって署名されている場合はオプション)


* SPF-DNS(必須)

2. The "Identity-Alignment" field is defined to contain a comma-separated list of authentication mechanism names that produced an aligned identity, or the keyword "none" if none did. ABNF:

2. 「Identity-Alignment」フィールドは、アラインされたIDを生成した認証メカニズム名のコンマ区切りのリスト、または何もしなかった場合はキーワード「none」を含むように定義されています。 ABNF:

id-align = "Identity-Alignment:" [CFWS] ( "none" / dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) [CFWS]

id-align = "Identity-Alignment:" [CFWS]( "none" / dmarc-method *([CFWS] "、" [CFWS] dmarc-method))[CFWS]

     dmarc-method = ( "dkim" / "spf" )
                    ; each may appear at most once in an id-align

3. Authentication Failure Type "dmarc" is defined, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator MAY also independently produce an AFRF message for any or all of the underlying authentication methods.

3. 認証失敗タイプ "dmarc"が定義されています。これは、認証メカニズムの一部またはすべてが整列された識別子の生成に失敗したために失敗レポートが生成されるときに使用されます。失敗レポートジェネレーターは、基礎となる認証方法のいずれかまたはすべてに対してAFRFメッセージを個別に生成する場合があることに注意してください。

8. Minimum Implementations
8. 最小実装

A minimum implementation of DMARC has the following characteristics:


o Is able to send and/or receive reports at least daily;

o 少なくとも毎日、レポートを送受信できます。

o Is able to send and/or receive reports using "mailto" URIs;

o 「mailto」URIを使用してレポートを送受信できます。

o Other than in exceptional circumstances such as resource exhaustion, can generate or accept a report up to ten megabytes in size;

o リソースの枯渇などの例外的な状況以外では、最大10メガバイトのレポートを生成または受け入れることができます。

o If acting as a Mail Receiver, fully implements the provisions of Section 6.6.

o メールレシーバーとして機能する場合、セクション6.6の規定を完全に実装します。

9. Privacy Considerations
9. プライバシーに関する考慮事項

This section discusses security issues specific to private data that may be included in the interactions that are part of DMARC.


9.1. Data Exposure Considerations
9.1. データ公開に関する考慮事項

Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the identifiers involved in DMARC validation.


Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. Domain Owners are able to analyze individual reports and attempt to determine root causes of authentication mechanism failures, gain insight into misconfigurations or other problems with email and network infrastructure, or inspect messages for insight into abusive practices.


Both report types may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [AFRF] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient.


Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed.


When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.


Disclosure of information about the messages is being requested by the entity generating the email in the first place, i.e., the Domain Owner and not the Mail Receiver, so this may not fit squarely within existing privacy policy provisions. For some providers, aggregate reporting and failed-message reporting are viewed as a function similar to complaint reporting about spamming or phishing and are treated similarly under the privacy policy. Report generators (i.e., Mail Receivers) are encouraged to review their reporting limitations under such policies before enabling DMARC reporting.


9.2. Report Recipients
9.2. 受信者を報告

A DMARC record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting.


Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party.


10. Other Topics
10. その他のトピック

This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record.


10.1. Issues Specific to SPF
10.1. SPFに固有の問題

Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many large network ranges. Domain Owners are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC record.


Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.

一部のレシーバーアーキテクチャは、DMARC操作の前にSPFを実装する場合があります。これは、「-all」などの送信者のSPFメカニズムの「-」接頭辞により、拒否が処理の早い段階で有効になり、DMARC処理が行われる前にメッセージが拒否される可能性があることを意味します。 「-all」を使用することを選択するオペレーターは、これに注意する必要があります。

10.2. DNS Load and Caching
10.2. DNSの負荷とキャッシュ

DMARC policies are communicated using the DNS and therefore inherit a number of considerations related to DNS caching. The inherent conflict between freshness and the impact of caching on the reduction of DNS-lookup overhead should be considered from the Mail Receiver's point of view. Should Domain Owners publish a DNS record with a very short TTL, Mail Receivers can be provoked through the injection of large volumes of messages to overwhelm the Domain Owner's DNS. Although this is not a concern specific to DMARC, the implications of a very short TTL should be considered when publishing DMARC policies.


Conversely, long TTLs will cause records to be cached for long periods of time. This can cause a critical change to DMARC parameters advertised by a Domain Owner to go unnoticed for the length of the TTL (while waiting for DNS caches to expire). Avoiding this problem can mean shorter TTLs, with the potential problems described above. A balance should be sought to maintain responsiveness of DMARC preference changes while preserving the benefits of DNS caching.

逆に、TTLが長いと、レコードが長期間キャッシュされます。これにより、ドメイン所有者によってアドバタイズされたDMARCパラメータに重大な変更が加えられ、TTLの長さの間(DNSキャッシュの期限が切れるのを待っている間)気付かれない可能性があります。この問題を回避すると、TTLが短くなり、上記の潜在的な問題が発生する可能性があります。 DNSキャッシュの利点を維持しながら、DMARC設定変更の応答性を維持するためにバランスをとる必要があります。

10.3. Rejecting Messages
10.3. メッセージを拒否する

This proposal calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification ([DSN]), since fraudulent messages caught and rejected using DMARC would then result in annoying generation of such failure reports that go back to the RFC5321.MailFrom address.

この提案では、特定の状況下でSMTPセッション中にメッセージを拒否する必要があります。 DMARCを使用して不正なメッセージがキャッチおよび拒否されると、RFC5321.MailFromアドレスに戻るような失敗レポートが生成されるため、これは配信ステータス通知([DSN])の生成よりも望ましい方法です。

This synchronous rejection is typically done in one of two ways:


o Full rejection, wherein the SMTP server issues a 5xy reply code as an indication to the SMTP client that the transaction failed; the SMTP client is then responsible for generating notification that delivery failed (see Section 4.2.5 of [SMTP]).

o 完全な拒否。SMTPサーバーは、5xy応答コードを、トランザクションが失敗したことをSMTPクライアントに示すものとして発行します。 SMTPクライアントは、配信が失敗したという通知の生成を担当します([SMTP]のセクション4.2.5を参照)。

o A "silent discard", wherein the SMTP server returns a 2xy reply code implying to the client that delivery (or, at least, relay) was successfully completed, but then simply discarding the message with no further action.

o 「サイレント破棄」。SMTPサーバーが2xy応答コードを返し、配信(または少なくともリレー)が正常に完了したことを意味しますが、その後は何もせず単にメッセージを破棄します。

Each of these has a cost. For instance, a silent discard can help to prevent backscatter, but it also effectively means that the SMTP server has to be programmed to give a false result, which can confound external debugging efforts.


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.


In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A receiver might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. Many systems are able to scan the SMTP reply text to determine the nature of the rejection. Thus, providing a machine-detectable reason for rejection allows the problems causing rejections to be properly addressed by automated systems. For example:


550 5.7.1 Email rejected per DMARC policy for example.com

550 5.7.1 example.comのDMARCポリシーに従ってメールが拒否されました

If a Mail Receiver elects to defer delivery due to inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code.

メール受信者がDMARCポリシーを取得または適用できないために配信を延期することを選択した場合、これは4xy SMTP応答コードで行うのが最善です。

10.4. Identifier Alignment Considerations
10.4. 識別子の配置に関する考慮事項

The DMARC mechanism allows both DKIM and SPF-authenticated identifiers to authenticate email on behalf of a Domain Owner and, possibly, on behalf of different subdomains. If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain, the subdomain can be used to generate DMARC-passing email on behalf of the Organizational Domain.


For example, an attacker who controls the SPF record for "evil.example.com" can send mail with an RFC5322.From field containing "foo@example.com" that can pass both authentication and the DMARC check against "example.com".

たとえば、「evil.example.com」のSPFレコードを制御する攻撃者は、「foo.example.com」を含むRFC5322.Fromフィールドを使用してメールを送信し、「example.com」に対する認証とDMARCチェックの両方を通過させることができます。 。

The Organizational Domain administrator should be careful not to delegate control of subdomains if this is an issue, and to consider using the "strict" Identifier Alignment option if appropriate.


10.5. Interoperability Issues
10.5. 相互運用性の問題

DMARC limits which end-to-end scenarios can achieve a "pass" result.


Because DMARC relies on [SPF] and/or [DKIM] to achieve a "pass", their limitations also apply.


Additional DMARC constraints occur when a message is processed by some Mediators, such as mailing lists. Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost. These transformations may conform to standards but will still prevent a DMARC "pass".


In addition to Mediators, mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a "pass" result.


Issues specific to the use of policy mechanisms alongside DKIM are further discussed in [DKIM-LISTS], particularly Section 5.2.


11. IANA Considerations
11. IANAに関する考慮事項

This section describes actions completed by IANA.


11.1. Authentication-Results Method Registry Update
11.1. 認証結果メソッドレジストリの更新

IANA has added the following to the "Email Authentication Methods" registry:

IANAは、「Email Authentication Methods」レジストリに以下を追加しました。

Method: dmarc


Defined: RFC 7489

定義済み:RFC 7489

ptype: header


Property: from


Value: the domain portion of the RFC5322.From field


Status: active


Version: 1


11.2. Authentication-Results Result Registry Update
11.2. 認証結果の結果のレジストリの更新

IANA has added the following in the "Email Authentication Result Names" registry:

IANAは、「Email Authentication Result Names」レジストリに以下を追加しました。

Code: none


Existing/New Code: existing




Auth Method: dmarc (added) Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted.


Status: active


Code: pass


Existing/New Code: existing




Auth Method: dmarc (added)


Meaning: A DMARC policy record was published for the aligned identifier, and at least one of the authentication mechanisms passed.


Status: active


Code: fail


Existing/New Code: existing




Auth Method: dmarc (added)


Meaning: A DMARC policy record was published for the aligned identifier, and none of the authentication mechanisms passed.


Status: active


Code: temperror


Existing/New Code: existing




Auth Method: dmarc (added)


Meaning: A temporary error occurred during DMARC evaluation. A later attempt might produce a final result.


Status: active Code: permerror


Existing/New Code: existing




Auth Method: dmarc (added)


Meaning: A permanent error occurred during DMARC evaluation, such as encountering a syntactically incorrect DMARC record. A later attempt is unlikely to produce a final result.


Status: active


11.3. Feedback Report Header Fields Registry Update
11.3. フィードバックレポートのヘッダーフィールドレジストリの更新

The following has been added to the "Feedback Report Header Fields" registry:


Field Name: Identity-Alignment


Description: indicates whether the message about which a report is being generated had any identifiers in alignment as defined in RFC 7489

説明:レポートが生成されているメッセージに、RFC 7489で定義されている識別子と一致するものがあるかどうかを示します

Multiple Appearances: No


Related "Feedback-Type": auth-failure


Reference: RFC 7489

リファレンス:RFC 7489

Status: current


11.4. DMARC Tag Registry
11.4. DMARCタグレジストリ

A new registry tree called "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" has been created. Within it, a new sub-registry called the "DMARC Tag Registry" has been created.

「ドメインベースのメッセージ認証、レポート、および適合性(DMARC)パラメータ」と呼ばれる新しいレジストリツリーが作成されました。その中に、「DMARC Tag Registry」と呼ばれる新しいサブレジストリが作成されました。

Names of DMARC tags must be registered with IANA in this new sub-registry. New entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [IANA-CONSIDERATIONS]. Each registration must include the tag name; the specification that defines it; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the new tag and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.


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.


The initial set of entries in this registry is as follows:


    | Tag Name | Reference   | Status  | Description                  |
    |  adkim   |  RFC 7489   | current | DKIM alignment mode          |
    |   aspf   |  RFC 7489   | current | SPF alignment mode           |
    |    fo    |  RFC 7489   | current | Failure reporting options    |
    |     p    |  RFC 7489   | current | Requested handling policy    |
    |    pct   |  RFC 7489   | current | Sampling rate                |
    |    rf    |  RFC 7489   | current | Failure reporting format(s)  |
    |    ri    |  RFC 7489   | current | Aggregate Reporting interval |
    |    rua   |  RFC 7489   | current | Reporting URI(s) for         |
    |          |             |         | aggregate data               |
    |    ruf   |  RFC 7489   | current | Reporting URI(s) for         |
    |          |             |         | failure data                 |
    |    sp    |  RFC 7489   | current | Requested handling policy    |
    |          |             |         | for subdomains               |
    |     v    |  RFC 7489   | current | Specification version        |
11.5. DMARC Report Format Registry
11.5. DMARCレポート形式レジストリ

Also within "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters", a new sub-registry called "DMARC Report Format Registry" has been created.


Names of DMARC failure reporting formats must be registered with IANA in this registry. New entries are assigned only for values that satisfy the definition of Specification Required, per


[IANA-CONSIDERATIONS]. In addition to a reference to a permanent specification, each registration must include the format name; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the report format and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.


The initial entry in this registry is as follows:


    | Format | Reference   | Status  | Description                 |
    |  Name  |             |         |                             |
    | afrf   |  RFC 7489   | current | Authentication Failure      |
    |        |             |         | Reporting Format (see       |
    |        |             |         | [AFRF])                     |
12. Security Considerations
12. セキュリティに関する考慮事項

This section discusses security issues and possible remediations (where available) for DMARC.


12.1. Authentication Methods
12.1. 認証方法

Security considerations from the authentication methods used by DMARC are incorporated here by reference.


12.2. Attacks on Reporting URIs
12.2. レポートURIへの攻撃

URIs published in DNS TXT records are well-understood possible targets for attack. Specifications such as [DNS] and [ROLES] either expose or cause the exposure of email addresses that could be flooded by an attacker, for example; MX, NS, and other records found in the DNS advertise potential attack destinations; common DNS names such as "www" plainly identify the locations at which particular services can be found, providing destinations for targeted denial-of-service or penetration attacks.

DNS TXTレコードで公開されたURIは、よく理解された攻撃の標的である可能性があります。 [DNS]や[ROLES]などの仕様は、たとえば、攻撃者によってフラッディングされる可能性がある電子メールアドレスを公開するか、または公開します。 DNSにあるMX、NS、およびその他のレコードは、潜在的な攻撃の宛先をアドバタイズします。 「www」などの一般的なDNS名は、特定のサービスが見つかる場所を明確に識別し、標的型のサービス拒否攻撃または侵入攻撃の宛先を提供します。

Thus, Domain Owners will need to harden these addresses against various attacks, including but not limited to:


o high-volume denial-of-service attacks;

o 大量のサービス拒否攻撃。

o deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities;

o 解析または処理の脆弱性を特定または悪用することを目的とした、不正なレポートの意図的な作成。

o deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.

o 提出者または報告されたドメインのフィールドに対する虚偽のクレームを含むレポートの意図的な構築。侵害されたが既知のメール受信者からの虚偽のデータの可能性を含みます。

12.3. DNS Security
12.3. DNSセキュリティ

The DMARC mechanism and its underlying technologies (SPF, DKIM) depend on the security of the DNS. To reduce the risk of subversion of the DMARC mechanism due to DNS-based exploits, serious consideration should be given to the deployment of DNSSEC in parallel with the deployment of DMARC by both Domain Owners and Mail Receivers.

DMARCメカニズムとその基盤となるテクノロジー(SPF、DKIM)は、DNSのセキュリティに依存しています。 DNSベースのエクスプロイトによるDMARCメカニズムの破壊のリスクを減らすには、ドメイン所有者とメールレシーバーの両方によるDMARCの展開と並行してDNSSECを展開することを真剣に検討する必要があります。

Publication of data using DNSSEC is relevant to Domain Owners and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers.

DNSSECを使用したデータの公開は、ドメイン所有者およびサードパーティのレポートレシーバーに関連しています。 DNSSEC対応の解決は、メール受信者とレポート受信者に関連しています。

12.4. Display Name Attacks
12.4. 表示名攻撃

A common attack in messaging abuse is the presentation of false information in the display-name portion of the RFC5322.From field. For example, it is possible for the email address in that field to be an arbitrary address or domain name, while containing a well-known name (a person, brand, role, etc.) in the display name, intending to fool the end user into believing that the name is used legitimately. The attack is predicated on the notion that most common MUAs will show the display name and not the email address when both are available.


Generally, display name attacks are out of scope for DMARC, as further exploration of possible defenses against these attacks needs to be undertaken.


There are a few possible mechanisms that attempt mitigation of these attacks, such as the following:


o If the display name is found to include an email address (as specified in [MAIL]), execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally. However, this addresses only a very specific attack space, and spoofers can easily circumvent it by simply not using an email address in the display name. There are also known cases of legitimate uses of an email address in the display name with a domain different from the one in the address portion, e.g.,

o 表示名に([MAIL]で指定された)メールアドレスが含まれていることが判明した場合は、最初に発見されたドメイン名ではなく、そこにあるドメイン名に対してDMARCメカニズムを実行します。ただし、これは非常に特定の攻撃スペースにのみ対応しており、スプーファーは表示名に電子メールアドレスを使用しないだけで簡単に回避できます。アドレス部分のドメインとは異なるドメインを使用して、表示名に電子メールアドレスを合法的に使用する既知のケースもあります。たとえば、

        From: "user@example.org via Bug Tracker" <support@example.com>

o In the MUA, only show the display name if the DMARC mechanism succeeds. This too is easily defeated, as an attacker could arrange to pass the DMARC tests while fraudulently using another domain name in the display name.

o MUAでは、DMARCメカニズムが成功した場合にのみ表示名を表示します。攻撃者が表示名に別のドメイン名を不正に使用している間にDMARCテストに合格するように手配できるため、これも簡単に破られます。

o In the MUA, only show the display name if the DMARC mechanism passes and the email address thus validated matches one found in the receiving user's list of known addresses.

o MUAでは、DMARCメカニズムに合格し、このように検証された電子メールアドレスが受信ユーザーの既知のアドレスのリストにあるアドレスと一致する場合にのみ、表示名を表示します。

12.5. External Reporting Addresses
12.5. 外部報告アドレス

To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. In order to accommodate special cases such as a need to get reports about domains that cannot actually receive mail, Section 7.1 describes a DNS-based mechanism for verifying approved external reporting.


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.


Where possible, external reporting is best achieved by having the report be directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination.


Note that the addresses shown in the "ruf" tag receive more information that might be considered private data, since it is possible for actual email content to appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the "rua" tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of [DNSSEC] is advisable if this is a concern.


The verification mechanism presented in Section 7.1 is currently not mandatory ("MUST") but strongly recommended ("SHOULD"). It is possible that it would be elevated to a "MUST" by later security review.


12.6. Secure Protocols
12.6. 安全なプロトコル

This document encourages use of secure transport mechanisms to prevent loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms should be avoided.


In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information.


13. References
13. 参考文献
13.1. Normative References
13.1. 引用文献

[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[ABNF] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/ rfc5234>。

[AFRF] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012, <http://www.rfc-editor.org/info/rfc6591>.

[AFRF] Fontana、H。、「Abuse Reporting Formatを使用した認証失敗の報告」、RFC 6591、2012年4月、<http://www.rfc-editor.org/info/rfc6591>。

[AFRF-DKIM] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012, <http://www.rfc-editor.org/info/rfc6651>.

[AFRF-DKIM] Kucherawy、M。、「Extensions to DomainKeys Identified Mail(DKIM)for Failure Reporting」、RFC 6651、2012年6月、<http://www.rfc-editor.org/info/rfc6651>。

[AFRF-SPF] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012, <http://www.rfc-editor.org/info/rfc6652>.

[AFRF-SPF] Kitterman、S。、「Sender Policy Framework(SPF)Authentication Failure Reporting Using a Abuse Reporting Format」、RFC 6652、2012年6月、<http://www.rfc-editor.org/info/rfc6652> 。

[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/ info/rfc6376>.

[DKIM] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail(DKIM)Signatures」、STD 76、RFC 6376、2011年9月、<http:/ /www.rfc-editor.org/ info / rfc6376>。

[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。

[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006, <http://www.rfc-editor.org/info/rfc4343>.

[DNS-CASE] Eastlake 3rd、D。、「ドメインネームシステム(DNS)の大文字と小文字の区別の明確化」、RFC 4343、2006年1月、<http://www.rfc-editor.org/info/rfc4343>。

[GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, August 2012, <http://www.rfc-editor.org/info/rfc6713>.

[GZIP] Levine、J。、「The 'application / zlib' and 'application / gzip' Media Types」、RFC 6713、2012年8月、<http://www.rfc-editor.org/info/rfc6713>。

[IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.

[IDNA] Klensin、J。、「Internationalized Domain Names for Applications(IDNA):Definitions and Document Framework」、RFC 5890、2010年8月、<http://www.rfc-editor.org/info/rfc5890>。

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.

[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.

[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions(MIME)Part One:Format of Internet Message Bodies」、RFC 2045、1996年11月、<http://www.rfc-editor.org/info / rfc2045>。

[SEC-TERMS] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.

[SEC-TERMS] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。

[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。

[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.

[SPF]キッターマンS.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク(SPF)、バージョン1」、RFC 7208、2014年4月、<http://www.rfc-editor.org/info/rfc7208> 。

[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier(URI):Generic Syntax」、STD 66、RFC 3986、2005年1月、<http://www.rfc- editor.org/info/rfc3986>。

13.2. Informative References
13.2. 参考引用

[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009, <http://www.rfc-editor.org/info/rfc5617>.

[ADSP] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「DomainKeys Identified Mail(DKIM)Author Domain Signing Practices(ADSP)」、RFC 5617、2009年8月、<http:// www.rfc-editor.org/info/rfc5617>。

[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010, <http://www.rfc-editor.org/info/rfc5965>.

[ARF] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能なフォーマット」、RFC 5965、2010年8月、<http://www.rfc-editor.org/info/rfc5965 >。

[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.

[AUTH-RESULTS] Kucherawy、M.、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7001、2013年9月、<http://www.rfc-editor.org/info/rfc7001>。

[Best-Guess-SPF] Kitterman, S., "Sender Policy Framework: Best guess record (FAQ entry)", May 2010, <http://www.openspf.org/FAQ/Best_guess_record>.

[Best-Guess-SPF] Kitterman、S。、「Sender Policy Framework:Best guess record(FAQ entry)」、2010年5月、<http://www.openspf.org/FAQ/Best_guess_record>。

[DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010, <http://www.rfc-editor.org/info/rfc5863>.

[DKIM-DEPLOYMENT] Hansen、T.、Siegel、E.、Hallam-Baker、P。、およびD. Crocker、「DomainKeys Identified Mail(DKIM)Development、Deployment、and Operations」、RFC 5863、2010年5月、<http ://www.rfc-editor.org/info/rfc5863>。

[DKIM-LISTS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011, <http://www.rfc-editor.org/info/rfc6377>.

[DKIM-LISTS] Kucherawy、M。、「DomainKeys Identified Mail(DKIM)and Mailing Lists」、BCP 167、RFC 6377、2011年9月、<http://www.rfc-editor.org/info/rfc6377>。

[DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009, <http://www.rfc-editor.org/info/rfc5585>.

[DKIM-OVERVIEW] Hansen、T.、Crocker、D。、およびP. Hallam-Baker、「DomainKeys Identified Mail(DKIM)Service Overview」、RFC 5585、2009年7月、<http://www.rfc-editor。 org / info / rfc5585>。

[DKIM-THREATS] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006, <http://www.rfc-editor.org/info/rfc4686>.

[DKIM-THREATS] Fenton、J。、「Analysis of Motivating DomainKeys Identified Mail(DKIM)」、RFC 4686、2006年9月、<http://www.rfc-editor.org/info/rfc4686>。

[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[DNSSEC] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Introduction and Requirements」、RFC 4033、2005年3月、<http://www.rfc -editor.org/info/rfc4033>。

[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>.

[DSN] Moore、K。およびG. Vaudreuil、 "An Extensible Message Format for Delivery Status Notifications"、RFC 3464、2003年1月、<http://www.rfc-editor.org/info/rfc3464>。

[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.

[メールアーク] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月、<http://www.rfc-editor.org/info/rfc5598>。

[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[IANA-CONSIDERATIONS] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/ rfc5226>。

[ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997, <http://www.rfc-editor.org/info/rfc2142>.

[役割] Crocker、D。、「Common Services、Roles、およびFunctionsのメールボックス名」、RFC 2142、1997年5月、<http://www.rfc-editor.org/info/rfc2142>。

Appendix A. Technology Considerations

This section documents some design decisions that were made in the development of DMARC. Specifically, addressed here are some suggestions that were considered but not included in the design. This text is included to explain why they were considered and not included in this version.


A.1. S / MIME

S/MIME, or Secure Multipurpose Internet Mail Extensions, is a standard for encryption and signing of MIME data in a message. This was suggested and considered as a third security protocol for authenticating the source of a message.

S / MIME(Secure Multipurpose Internet Mail Extensions)は、メッセージ内のMIMEデータの暗号化と署名の標準です。これは、メッセージのソースを認証するための3番目のセキュリティプロトコルとして提案および検討されました。

DMARC is focused on authentication at the domain level (i.e., the Domain Owner taking responsibility for the message), while S/MIME is really intended for user-to-user authentication and encryption. This alone appears to make it a bad fit for DMARC's goals.

DMARCはドメインレベルでの認証(つまり、ドメインオーナーがメッセージを担当する)に重点を置いていますが、S / MIMEは実際にはユーザー間の認証と暗号化を目的としています。これだけでも、DMARCの目標に適合しないようです。

S/MIME also suffers from the heavyweight problem of Public Key Infrastructure, which means that distribution of keys used to verify signatures needs to be incorporated. In many instances, this alone is a showstopper. There have been consistent promises that PKI usability and deployment will improve, but these have yet to materialize. DMARC can revisit this choice after those barriers are addressed.

S / MIMEは、公開鍵インフラストラクチャの大きな問題にも悩まされています。つまり、署名の検証に使用される鍵の配布を組み込む必要があります。多くの場合、これだけでも大成功です。 PKIの使いやすさと展開が改善されるという一貫した約束がありましたが、これらはまだ実現していません。 DMARCは、これらの障壁に対処した後、この選択を再検討できます。

S/MIME has extensive deployment in specific market segments (government, for example) but does not enjoy similar widespread deployment over the general Internet, and this shows no signs of changing. DKIM and SPF both are deployed widely over the general Internet, and their adoption rates continue to be positive.

S / MIMEは特定の市場セグメント(政府など)で広範囲に展開されていますが、一般的なインターネット上で同様の広範囲に展開されておらず、これは変化の兆候を示していません。 DKIMとSPFはどちらも一般的なインターネット上で広く展開されており、その採用率は引き続き好調です。

Finally, experiments have shown that including S/MIME support in the initial version of DMARC would neither cause nor enable a substantial increase in the accuracy of the overall mechanism.

最後に、実験により、DMARCの初期バージョンにS / MIMEサポートが含まれていても、メカニズム全体の精度が大幅に向上することはありません。

A.2. Method Exclusion
A.2. メソッドの除外

It was suggested that DMARC include a mechanism by which a Domain Owner could tell Message Receivers not to attempt validation by one of the supported methods (e.g., "check DKIM, but not SPF").


Specifically, consider a Domain Owner that has deployed one of the technologies, and that technology fails for some messages, but such failures don't cause enforcement action. Deploying DMARC would cause enforcement action for policies other than "none", which would appear to exclude participation by that Domain Owner.

具体的には、テクノロジーの1つを導入したドメインオーナーについて考えてみましょう。そのテクノロジーは一部のメッセージで失敗しますが、そのような失敗は強制措置の原因にはなりません。 DMARCを展開すると、「なし」以外のポリシーが適用され、そのドメイン所有者による参加が除外されたように見えます。

The DMARC development team evaluated the idea of policy exception mechanisms on several occasions and invariably concluded that there was not a strong enough use case to include them. The specific target audience for DMARC does not appear to have concerns about the failure modes of one or the other being a barrier to DMARC's adoption.

DMARC開発チームは、いくつかの状況でポリシー例外メカニズムのアイデアを評価し、それらを含めるのに十分な強力なユースケースがないと常に結論付けました。 DMARCの特定の対象者は、一方または他方の障害モードがDMARCの採用の障害となっていることに懸念を抱いているようには見えません。

In the scenario described above, the Domain Owner has a few options:


1. Tighten up its infrastructure to minimize the failure modes of the single deployed technology.

1. インフラストラクチャを強化して、単一のデプロイされたテクノロジーの障害モードを最小限に抑えます。

2. Deploy the other supported authentication mechanism, to offset the failure modes of the first.

2. 最初の失敗モードを相殺するために、サポートされている他の認証メカニズムをデプロイします。

3. Deploy DMARC in a reporting-only mode.

3. DMARCをレポート専用モードで展開します。

A.3. Sender Header Field
A.3. 送信者ヘッダーフィールド

It has been suggested in several message authentication efforts that the Sender header field be checked for an identifier of interest, as the standards indicate this as the proper way to indicate a re-mailing of content such as through a mailing list. Most recently, it was a protocol-level option for DomainKeys, but on evolution to DKIM, this property was removed.


The DMARC development team considered this and decided not to include support for doing so, for the following reasons:


1. The main user protection approach is to be concerned with what the user sees when a message is rendered. There is no consistent behavior among MUAs regarding what to do with the content of the Sender field, if present. Accordingly, supporting checking of the Sender identifier would mean applying policy to an identifier the end user might never actually see, which can create a vector for attack against end users by simply forging a Sender field containing some identifier that DMARC will like.


2. Although it is certainly true that this is what the Sender field is for, its use in this way is also unreliable, making it a poor candidate for inclusion in the DMARC evaluation algorithm.

2. これがSenderフィールドの目的であることは確かですが、この方法での使用も信頼できないため、DMARC評価アルゴリズムに含める候補としては不十分です。

3. Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC evaluation algorithm in terms of which policy is to be applied and when.

3. ポリシーを検出する複数の方法を許可すると、どのポリシーをいつ適用するかという点で、DMARC評価アルゴリズムに許容できないあいまいさが生じます。

A.4. Domain Existence Test
A.4. ドメインの存在テスト

A common practice among MTA operators, and indeed one documented in [ADSP], is a test to determine domain existence prior to any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated and assuming that the domain is nonexistent if it could be determined that no such records were published for that domain name.


The original pre-standardization version of this protocol included a mandatory check of this nature. It was ultimately removed, as the method's error rate was too high without substantial manual tuning and heuristic work. There are indeed use cases this work needs to address where such a method would return a negative result about a domain for which reporting is desired, such as a registered domain name that never sends legitimate mail and thus has none of these records present in the DNS.

このプロトコルの元の事前標準化バージョンには、この性質の必須チェックが含まれていました。手作業による調整やヒューリスティックな作業を行わなければメソッドのエラー率が高すぎるため、最終的には削除されました。確かに、この作業が対処する必要があるユースケースがあり、そのようなメソッドが、報告が必要なドメインについて否定的な結果を返す場合があります。たとえば、正当なメールを送信せず、DNSにこれらのレコードが存在しない登録済みドメイン名などです。 。

A.5. Issues with ADSP in Operation
A.5. 運用中のADSPに関する問題

DMARC has been characterized as a "super-ADSP" of sorts.


Contributors to DMARC have compiled a list of issues associated with ADSP, gained from operational experience, that have influenced the direction of DMARC:


1. ADSP has no support for subdomains, i.e., the ADSP record for example.com does not explicitly or implicitly apply to subdomain.example.com. If wildcarding is not applied, then spammers can trivially bypass ADSP by sending from a subdomain with no ADSP record.

1. ADSPはサブドメインをサポートしていません。つまり、example.comのADSPレコードは明示的または暗黙的にsubdomain.example.comに適用されません。ワイルドカードが適用されていない場合、スパマーはADSPレコードのないサブドメインから送信することにより、ADSPを簡単にバイパスできます。

2. Nonexistent subdomains are explicitly out of scope in ADSP. There is nothing in ADSP that states receivers should simply reject mail from NXDOMAINs regardless of ADSP policy (which of course allows spammers to trivially bypass ADSP by sending email from nonexistent subdomains).

2. ADSPでは、存在しないサブドメインは明示的に範囲外です。 ADSPのポリシーに関係なく、受信者はNXDOMAINからのメールを単に拒否する必要があると述べているADSPには何もありません(もちろん、スパマーは存在しないサブドメインから電子メールを送信してADSPを簡単にバイパスできます)。

3. ADSP has no operational advice on when to look up the ADSP record.

3. ADSPは、ADSPレコードを検索するタイミングに関する運用上のアドバイスはありません。

4. ADSP has no support for using SPF as an auxiliary mechanism to DKIM.

4. ADSPは、DKIMの補助メカニズムとしてSPFを使用することをサポートしていません。

5. ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the receiver should apply the policy. This is important for large-volume senders.

5. ADSPは遅いロールアウトをサポートしていません。つまり、受信者がポリシーを適用する必要がある電子メールの割合を構成する方法はありません。これは、大量の送信者にとって重要です。

6. ADSP has no explicit support for an intermediate phase where the receiver quarantines (e.g., sends to the recipient's "spam" folder) rather than rejects the email.

6. ADSPは、電子メールを拒否するのではなく、受信者が隔離する(たとえば、受信者の「スパム」フォルダーに送信する)中間フェーズを明示的にサポートしていません。

7. The binding between the "From" header domain and DKIM is too tight for ADSP; they must match exactly.

7. "From"ヘッダードメインとDKIMの間のバインドは、ADSPには強すぎます。それらは完全に一致する必要があります。

A.6. Organizational Domain Discovery Issues
A.6. 組織ドメインの検出の問題

Although protocols like ADSP are useful for "protecting" a specific domain name, they are not helpful at protecting subdomains. If one wished to protect "example.com" by requiring via ADSP that all mail bearing an RFC5322.From domain of "example.com" be signed, this would "protect" that domain; however, one could then craft an email whose RFC5322.From domain is "security.example.com", and ADSP would not provide any protection. One could use a DNS wildcard, but this can undesirably interfere with other DNS activity; one could add ADSP records as fraudulent domains are discovered, but this solution does not scale and is a purely reactive measure against abuse.

ADSPのようなプロトコルは特定のドメイン名を「保護」するのに役立ちますが、サブドメインの保護には役立ちません。 「example.com」のRFC5322.Fromドメインを持つすべてのメールに署名することをADSP経由で要求することにより「example.com」を保護したい場合、これはそのドメインを「保護」します。ただし、RFC5322.Fromドメインが「security.example.com」である電子メールを作成でき、ADSPは保護を提供しません。 DNSワイルドカードを使用することもできますが、これは他のDNSアクティビティを妨害する可能性があります。不正なドメインが発見されたときにADSPレコードを追加することもできますが、このソリューションは拡張されず、悪用に対する純粋な対処法です。

The DNS does not provide a method by which the "domain of record", or the domain that was actually registered with a domain registrar, can be determined given an arbitrary domain name. Suggestions have been made that attempt to glean such information from SOA or NS resource records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries.


When seeking domain-specific policy based on an arbitrary domain name, one could "climb the tree", dropping labels off the left end of the name until the root is reached or a policy is discovered, but then one could craft a name that has a large number of nonsense labels; this would cause a Mail Receiver to attempt a large number of queries in search of a policy record. Sending many such messages constitutes an amplified denial-of-service attack.

任意のドメイン名に基づいてドメイン固有のポリシーを探す場合、「ツリーを登る」ことができ、ルートに到達するかポリシーが検出されるまで名前の左端からラベルをドロップしますが、次のような名前を作成できます多数のナンセンスラベル。これにより、Mail Receiverはポリシーレコードを検索するために多数のクエリを試行します。このようなメッセージを多数送信すると、サービス拒否攻撃が増幅されます。

The Organizational Domain mechanism is a necessary component to the goals of DMARC. The method described in Section 3.2 is far from perfect but serves this purpose reasonably well without adding undue burden or semantics to the DNS. If a method is created to do so that is more reliable and secure than the use of a public suffix list, DMARC should be amended to use that method as soon as it is generally available.


A.6.1. Public Suffix Lists
A.6.1. 公開サフィックスリスト

A public suffix list for the purposes of determining the Organizational Domain can be obtained from various sources. The most common one is maintained by the Mozilla Foundation and made public at <http://publicsuffix.org>. License terms governing the use of that list are available at that URI.

組織ドメインを決定するためのパブリックサフィックスリストは、さまざまなソースから取得できます。最も一般的なものは、Mozilla Foundationによって管理され、<http://publicsuffix.org>で公開されています。そのリストの使用を規定するライセンス条項は、そのURIで入手できます。

Note that if operators use a variety of public suffix lists, interoperability will be difficult or impossible to guarantee.


Appendix B. Examples

This section illustrates both the Domain Owner side and the Mail Receiver side of a DMARC exchange.


B.1. Identifier Alignment Examples
B.1. 識別子の配置の例

The following examples illustrate the DMARC mechanism's use of Identifier Alignment. For brevity's sake, only message headers are shown, as message bodies are not considered when conducting DMARC checks.


B.1.1. SPF
B.1.1. SPF

The following SPF examples assume that SPF produces a passing result.


Example 1: SPF in alignment:


        MAIL FROM: <sender@example.com>
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the RFC5321.MailFrom parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.


Example 2: SPF in alignment (parent):


        MAIL FROM: <sender@child.example.com>
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the RFC5322.From parameter includes a DNS domain that is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in alignment if relaxed SPF mode is requested by the Domain Owner, and not in alignment if strict SPF mode is requested.


Example 3: SPF not in alignment:


        MAIL FROM: <sender@example.net>
        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the RFC5321.MailFrom parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.


B.1.2. DKIM
B.1.2. DKIM

The examples below assume that the DKIM signatures pass verification. Alignment cannot exist with a DKIM signature that does not verify.


Example 1: DKIM in alignment:


        DKIM-Signature: v=1; ...; d=example.com; ...
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the DKIM "d=" parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment.

この場合、DKIMの「d =」パラメーターとRFC5322.Fromフィールドには同じDNSドメインがあります。したがって、識別子は一致しています。

Example 2: DKIM in alignment (parent):


        DKIM-Signature: v=1; ...; d=example.com; ...
        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the DKIM signature's "d=" parameter includes a DNS domain that is a parent of the RFC5322.From domain. Thus, the identifiers are in alignment for relaxed mode, but not for strict mode.

この場合、DKIM署名の「d =」パラメーターには、RFC5322.Fromドメインの親であるDNSドメインが含まれます。したがって、識別子はリラックスモードでは整列しますが、厳密モードでは整列しません。

Example 3: DKIM not in alignment:


        DKIM-Signature: v=1; ...; d=sample.net; ...
        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

In this case, the DKIM signature's "d=" parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment.

この場合、DKIM署名の「d =」パラメーターには、RFC5322.Fromドメインと同じでも親でもないDNSドメインが含まれます。したがって、識別子は一致していません。

B.2. Domain Owner Example
B.2. ドメイン所有者の例

A Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM. The next step is to publish a DNS record that advertises a DMARC policy for the Domain Owner's Organizational Domain.


B.2.1. Entire Domain, Monitoring Only
B.2.1. ドメイン全体、監視のみ

The owner of the domain "example.com" has deployed SPF and DKIM on its messaging infrastructure. The owner wishes to begin using DMARC with a policy that will solicit aggregate feedback from receivers without affecting how the messages are processed, in order to:


o Confirm that its legitimate messages are authenticating correctly

o 正当なメッセージが正しく認証されていることを確認します

o Verify that all authorized message sources have implemented authentication measures

o 承認されたすべてのメッセージソースに認証手段が実装されていることを確認する

o Determine how many messages from other sources would be affected by a blocking policy

o ブロッキングポリシーの影響を受ける他のソースからのメッセージの数を決定する

The Domain Owner accomplishes this by constructing a policy record indicating that:


o The version of DMARC being used is "DMARC1" ("v=DMARC1")

o 使用されているDMARCのバージョンは "DMARC1"( "v = DMARC1")です。

o Receivers should not alter how they treat these messages because of this DMARC policy record ("p=none")

o このDMARCポリシーレコードのため、受信者はこれらのメッセージの処理方法を変更しないでください( "p = none")

o Aggregate feedback reports should be sent via email to the address "dmarc-feedback@example.com" ("rua=mailto:dmarc-feedback@example.com")

o 集計フィードバックレポートは、電子メールでアドレス "dmarc-feedback@example.com"( "rua = mailto:dmarc-feedback@example.com")に送信する必要があります

o All messages from this Organizational Domain are subject to this policy (no "pct" tag present, so the default of 100% applies)

o この組織ドメインからのすべてのメッセージはこのポリシーの対象になります(「pct」タグが存在しないため、デフォルトの100%が適用されます)

The DMARC policy record might look like this when retrieved using a common command-line tool:


     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

To publish such a record, the DNS administrator for the Domain Owner creates an entry like the following in the appropriate zone file (following the conventional zone file format):


; DMARC record for the domain example.com


     _dmarc  IN TXT ( "v=DMARC1; p=none; "
                      "rua=mailto:dmarc-feedback@example.com" )
B.2.2. Entire Domain, Monitoring Only, Per-Message Reports
B.2.2. ドメイン全体、監視のみ、メッセージごとのレポート

The Domain Owner from the previous example has used the aggregate reporting to discover some messaging systems that had not yet implemented DKIM correctly, but they are still seeing periodic authentication failures. In order to diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.


Not all Receivers will honor such a request, but the Domain Owner feels that any reports it does receive will be helpful enough to justify publishing this record. The default per-message report format ([AFRF]) meets the Domain Owner's needs in this scenario.


The Domain Owner accomplishes this by adding the following to its policy record from Appendix B.2:


o Per-message failure reports should be sent via email to the address "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")

o メッセージごとの障害レポートは、電子メールでアドレス "auth-reports@example.com"( "ruf = mailto:auth-reports@example.com")に送信する必要があります

The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):


     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;

To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):


; DMARC 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" )
B.2.3. Per-Message Failure Reports Directed to Third Party
B.2.3. サードパーティに送信されるメッセージごとの障害レポート

The Domain Owner from the previous example is maintaining the same policy but now wishes to have a third party receive and process the per-message failure reports. Again, not all Receivers will honor this request, but those that do may implement additional checks to validate that the third party wishes to receive the failure reports for this domain.


The Domain Owner needs to alter its policy record from Appendix B.2.2 as follows:


o Per-message failure reports should be sent via email to the address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth-reports@thirdparty.example.net")

o メッセージごとの障害レポートは、電子メールでアドレス "auth-reports@thirdparty.example.net"( "ruf = mailto:auth-reports@thirdparty.example.net")に送信する必要があります

The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):


     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;

To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):


; DMARC 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 Receivers will implement additional checks as described in Section 7.1 of this document. In order to pass these additional checks, the third party will need to publish an additional DNS record as follows:


o Given the DMARC record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the third party will need to publish a TXT resource record at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1".

o ドメイン所有者が「_dmarc.example.com」で発行したDMARCレコードを前提として、サードパーティのDNS管理者は、TXTリソースレコードを「example.com._report._dmarc.thirdparty.example.net」で次のように発行する必要があります。値 "v = DMARC1"。

The resulting DNS record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):


% dig +short TXT example.com._report._dmarc.thirdparty.example.net "v=DMARC1"

%dig +短いTXT example.com._report._dmarc.thirdparty.example.net "v = DMARC1"

To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):


; zone file for thirdparty.example.net ; Accept DMARC failure reports on behalf of example.com

; thirdparty.example.netのゾーンファイル。 example.comに代わってDMARC障害レポートを受け入れる

example.com._report._dmarc IN TXT "v=DMARC1"

example.com._report._dmarc IN TXT "v = DMARC1"

Intermediaries and other third parties should refer to Section 7.1 for the full details of this mechanism.


B.2.4. Subdomain, Sampling, and Multiple Aggregate Report URIs
B.2.4. サブドメイン、サンプリング、および複数の集約レポートURI

The Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services. It now wishes to request that participating receivers act to reject messages from this subdomain that fail to authenticate.


As a first step, it will ask that a portion (1/4 in this example) of failing messages be quarantined, enabling examination of messages sent to mailboxes hosted by participating receivers. Aggregate feedback reports will be sent to a mailbox within the Organizational Domain, and to a mailbox at a third party selected and authorized to receive same by the Domain Owner. Aggregate reports sent to the third party are limited to a maximum size of ten megabytes.


The Domain Owner will accomplish this by constructing a policy record indicating that:


o The version of DMARC being used is "DMARC1" ("v=DMARC1")

o 使用されているDMARCのバージョンは "DMARC1"( "v = DMARC1")です。

o It is applied only to this subdomain (record is published at "_dmarc.test.example.com" and not "_dmarc.example.com")

o このサブドメインにのみ適用されます(レコードは「_dmarc.test.example.com」で公開され、「_ dmarc.example.com」では公開されません)

o Receivers should quarantine messages from this Organizational Domain that fail to authenticate ("p=quarantine")

o 受信者は、認証に失敗したこの組織ドメインからのメッセージを隔離する必要があります( "p = quarantine")

o Aggregate feedback reports should be sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net", with the latter subjected to a maximum size limit ("rua=mailto:dmarc-feedback@ example.com,mailto:tld-test@thirdparty.example.net!10m")

o 集計フィードバックレポートは、メールで「dmarc-feedback@example.com」と「example-tld-test@thirdparty.example.net」のアドレスに送信する必要があります。後者には最大サイズの制限(「rua = mailto: dmarc-feedback @ example.com、mailto:tld-test@thirdparty.example.net!10m ")

o 25% of messages from this Organizational Domain are subject to action based on this policy ("pct=25")

o この組織ドメインからのメッセージの25%は、このポリシーに基づいてアクションの対象になります( "pct = 25")

The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):


     % dig +short TXT _dmarc.test.example.com
     "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
      mailto:tld-test@thirdparty.example.net!10m; pct=25"

To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file:


; DMARC record for the domain example.com


     _dmarc IN  TXT  ( "v=DMARC1; p=quarantine; "
                       "mailto:tld-test@thirdparty.example.net!10m; "
                       "pct=25" )
B.3. Mail Receiver Example
B.3. メール受信者の例

A Mail Receiver that wants to use DMARC should already be checking SPF and DKIM, and possess the ability to collect relevant information from various email-processing stages to provide feedback to Domain Owners (possibly via Report Receivers).


B.3.1. Processing of SMTP Time
B.3.1. SMTP時間の処理

An optimal DMARC-enabled Mail Receiver performs authentication and Identifier Alignment checking during the [SMTP] conversation.


Prior to returning a final reply to the DATA command, the Mail Receiver's MTA has performed:


1. An SPF check to determine an SPF-authenticated Identifier.

1. SPFで認証された識別子を決定するためのSPFチェック。

2. DKIM checks that yield one or more DKIM-authenticated Identifiers.

2. 1つ以上のDKIM認証済み識別子を生成するDKIMチェック。

3. A DMARC policy lookup.

3. DMARCポリシーの検索。

The presence of an Author Domain DMARC record indicates that the Mail Receiver should continue with DMARC-specific processing before returning a reply to the DATA command.


Given a DMARC record and the set of Authenticated Identifiers, the Mail Receiver checks to see if the Authenticated Identifiers align with the Author Domain (taking into consideration any strict versus relaxed options found in the DMARC record).


For example, the following sample data is considered to be from a piece of email originating from the Domain Owner of "example.com":


     Author Domain: example.com
     SPF-authenticated Identifier: mail.example.com
     DKIM-authenticated Identifier: example.com
     DMARC record:
       "v=DMARC1; p=reject; aspf=r;

In the above sample, both the SPF-authenticated Identifier and the DKIM-authenticated Identifier align with the Author Domain. The Mail Receiver considers the above email to pass the DMARC check, avoiding the "reject" policy that is to be applied to email that fails to pass the DMARC check.


If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the DMARC-record-specified policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner's policy.


The Mail Receiver is now ready to reply to the DATA command. If the DMARC check yields that the message is to be rejected, then the Mail Receiver replies with a 5xy code to inform the sender of failure. If the DMARC check cannot be resolved due to transient network errors, then the Mail Receiver replies with a 4xy code to inform the sender as to the need to reattempt delivery later. If the DMARC check yields a passing message, then the Mail Receiver continues on with email processing, perhaps using the result of the DMARC check as an input to additional processing modules such as a domain reputation query.

これで、メールレシーバーはDATAコマンドに応答する準備ができました。 DMARCチェックでメッセージが拒否されることが判明した場合、メール受信者は5xyコードで応答して送信者に失敗を通知します。一時的なネットワークエラーが原因でDMARCチェックを解決できない場合、メールレシーバーは4xyコードで応答し、後で配信を再試行する必要があることを送信者に通知します。 DMARCチェックで合格メッセージが生成された場合、メールレシーバーは、おそらくドメインレピュテーションクエリなどの追加処理モジュールへの入力としてDMARCチェックの結果を使用して、電子メール処理を続行します。

Before exiting DMARC-specific processing, the Mail Receiver checks to see if the Author Domain DMARC record requests AFRF-based reporting. If so, then the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC record.

DMARC固有の処理を終了する前に、Mail Receiverは、Author Domain DMARCレコードがAFRFベースのレポートを要求しているかどうかを確認します。その場合、メールレシーバーは、DMARCレコードで提供されるレポートアドレスにAFRFを送信できます。

At the exit of DMARC-specific processing, the Mail Receiver captures (through logging or direct insertion into a data store) the result of DMARC processing. Captured information is used to build feedback for Domain Owner consumption. This is not necessary if the Domain Owner has not requested aggregate reports, i.e., no "rua" tag was found in the policy record.


B.4. Utilization of Aggregate Feedback: Example
B.4. 集計フィードバックの利用:例

Aggregate feedback is consumed by Domain Owners to verify a Domain Owner's understanding of how the Domain Owner's domain is being processed by the Mail Receiver. Aggregate reporting data on emails that pass all DMARC-supporting authentication checks is used by Domain Owners to verify that authentication practices remain accurate. For example, if a third party is sending on behalf of a Domain Owner, the Domain Owner can use aggregate report data to verify ongoing authentication practices of the third party.


Data on email that only partially passes underlying authentication checks provides visibility into problems that need to be addressed by the Domain Owner. For example, if either SPF or DKIM fails to pass, the Domain Owner is provided with enough information to either directly correct the problem or understand where authentication-breaking changes are being introduced in the email transmission path. If authentication-breaking changes due to email transmission path cannot be directly corrected, then the Domain Owner at least maintains an understanding of the effect of DMARC-based policies upon the Domain Owner's email.


Data on email that fails all underlying authentication checks provides baseline visibility on how the Domain Owner's domain is being received at the Mail Receiver. Based on this visibility, the Domain Owner can begin deployment of authentication technologies across uncovered email sources. Additionally, the Domain Owner may come to an understanding of how its domain is being misused.


B.5. mailto Transport Example
B.5. mailtoトランスポートの例

A DMARC record can contain a "mailto" reporting address, such as:




A sample aggregate report from the Mail Receiver at mail.receiver.example follows:


     DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
     From: dmarc-reporting@mail.receiver.example
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: dmarc-feedback@example.com
     Subject: Report Domain: example.com
         Submitter: mail.receiver.example
         Report-ID: <2002.02.15.1>
     MIME-Version: 1.0
     Content-Type: multipart/alternative;
     Content-Language: en-us

This is a multipart message in MIME format.


     Content-Type: text/plain; charset="us-ascii"
     Content-Transfer-Encoding: 7bit
     This is an aggregate report from mail.receiver.example.
     Content-Type: application/gzip
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment;

<gzipped content of report>



Not shown in the above example is that the Mail Receiver's feedback should be authenticated using SPF. Also, the value of the "filename" MIME parameter is wrapped for printing in this specification but would normally appear as one continuous string.


Appendix C. DMARC XML Schema
付録C. DMARC XMLスキーマ

The following is the proposed initial schema for producing XML-formatted aggregate reports as described in this document.


NOTE: Per the definition of XML, unless otherwise specified in the schema below, the minOccurs and maxOccurs values for each element are set to 1.


   <?xml version="1.0"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   <!-- The time range in UTC covered by messages in this report,
        specified in seconds since epoch. -->
   <xs:complexType name="DateRangeType">
       <xs:element name="begin" type="xs:integer"/>
       <xs:element name="end" type="xs:integer"/>
   <!-- Report generator metadata. -->
   <xs:complexType name="ReportMetadataType">
       <xs:element name="org_name" type="xs:string"/>
       <xs:element name="email" type="xs:string"/>
       <xs:element name="extra_contact_info" type="xs:string"
       <xs:element name="report_id" type="xs:string"/>
       <xs:element name="date_range" type="DateRangeType"/>
       <xs:element name="error" type="xs:string" minOccurs="0"
   <!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
   <xs:simpleType name="AlignmentType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="r"/>
       <xs:enumeration value="s"/>
   <!-- The policy actions specified by p and sp in the
        DMARC record. -->
   <xs:simpleType name="DispositionType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="quarantine"/>
       <xs:enumeration value="reject"/>
   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
   <!-- The DMARC-aligned authentication result. -->
   <xs:simpleType name="DMARCResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
   <!-- Reasons that may affect DMARC disposition or execution
        thereof. -->
   <xs:simpleType name="PolicyOverrideType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="forwarded"/>
       <xs:enumeration value="sampled_out"/>
       <xs:enumeration value="trusted_forwarder"/>
       <xs:enumeration value="mailing_list"/>
       <xs:enumeration value="local_policy"/>
       <xs:enumeration value="other"/>
   <!-- How do we allow report generators to include new
        classes of override reasons if they want to be more
        specific than "other"? -->
   <xs:complexType name="PolicyOverrideReason">
       <xs:element name="type" type="PolicyOverrideType"/>
       <xs:element name="comment" type="xs:string"
   <!-- Taking into account everything else in the record,
        the results of applying DMARC. -->
   <xs:complexType name="PolicyEvaluatedType">
       <xs:element name="disposition" type="DispositionType"/>
       <xs:element name="dkim" type="DMARCResultType"/>
       <xs:element name="spf" type="DMARCResultType"/>
       <xs:element name="reason" type="PolicyOverrideReason"
                   minOccurs="0" maxOccurs="unbounded"/>
   <!-- Credit to Roger L. Costello for IPv4 regex
             018018.html -->
   <!-- Credit to java2s.com for IPv6 regex
             IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
   <xs:simpleType name="IPAddress">
     <xs:restriction base="xs:string">
       <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
   <xs:complexType name="RowType">
       <!-- The connecting IP. -->
       <xs:element name="source_ip" type="IPAddress"/>
       <!-- The number of matching messages. -->
       <xs:element name="count" type="xs:integer"/>
       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name="policy_evaluated"
   <xs:complexType name="IdentifierType">
       <!-- The envelope recipient domain. -->
       <xs:element name="envelope_to" type="xs:string"
       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"
       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"
   <!-- DKIM verification result, according to RFC 7001
        Section 2.6.1. -->
   <xs:simpleType name="DKIMResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
       <xs:enumeration value="policy"/>
       <xs:enumeration value="neutral"/>
       <xs:enumeration value="temperror"/>
       <xs:enumeration value="permerror"/>
   <xs:complexType name="DKIMAuthResultType">
       <!-- The "d=" parameter in the signature. -->
       <xs:element name="domain" type="xs:string"
       <!-- The "s=" parameter in the signature. -->
       <xs:element name="selector" type="xs:string"
       <!-- The DKIM verification result. -->
       <xs:element name="result" type="DKIMResultType"
       <!-- Any extra information (e.g., from
            Authentication-Results). -->
       <xs:element name="human_result" type="xs:string"
   <!-- SPF domain scope. -->
   <xs:simpleType name="SPFDomainScope">
     <xs:restriction base="xs:string">
       <xs:enumeration value="helo"/>
       <xs:enumeration value="mfrom"/>
   <!-- SPF result. -->
   <xs:simpleType name="SPFResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="neutral"/>
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
       <xs:enumeration value="softfail"/>
       <!-- "TempError" commonly implemented as "unknown". -->
       <xs:enumeration value="temperror"/>
       <!-- "PermError" commonly implemented as "error". -->
       <xs:enumeration value="permerror"/>
   <xs:complexType name="SPFAuthResultType">
       <!-- The checked domain. -->
       <xs:element name="domain" type="xs:string" minOccurs="1"/>
       <!-- The scope of the checked domain. -->
       <xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
       <!-- The SPF verification result. -->
       <xs:element name="result" type="SPFResultType"
   <!-- This element contains DKIM and SPF results, uninterpreted
        with respect to DMARC. -->
   <xs:complexType name="AuthResultType">
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
   <!-- This element contains all the authentication results that
        were evaluated by the receiving system for the given set of
        messages. -->
   <xs:complexType name="RecordType">
       <xs:element name="row" type="RowType"/>
       <xs:element name="identifiers" type="IdentifierType"/>
       <xs:element name="auth_results" type="AuthResultType"/>
   <!-- Parent -->
   <xs:element name="feedback">
         <xs:element name="version"
         <xs:element name="report_metadata"
         <xs:element name="policy_published"
         <xs:element name="record" type="RecordType"

Descriptions of the PolicyOverrideTypes:


forwarded: The message was relayed via a known forwarder, or local heuristics identified the message as likely having been forwarded. There is no expectation that authentication would pass.


local_policy: The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.


mailing_list: Local heuristics determined that the message arrived via a mailing list, and thus authentication of the original message was not expected to succeed.


other: Some policy exception not covered by the other entries in this list occurred. Additional detail can be found in the PolicyOverrideReason's "comment" field.


sampled_out: The message was exempted from application of policy by the "pct" setting in the DMARC policy record.


trusted_forwarder: Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.


The "version" for reports generated per this specification MUST be the value 1.0.




DMARC and the draft version of this document submitted to the Independent Submission Editor were the result of lengthy efforts by an informal industry consortium: DMARC.org (see <http://dmarc.org>). Participating companies included Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although the contributors and supporters are too numerous to mention, notable individual contributions were made by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. The contributors would also like to recognize the invaluable input and guidance that was provided early on by J.D. Falk.

DMARCとこのドキュメントのドラフトバージョンは、Independent Submission Editorに提出され、非公式の業界コンソーシアムであるDMARC.org(<http://dmarc.org>を参照)による長い努力の結果です。参加企業には、Agari、American Greetings、AOL、バンクオブアメリカ、Cloudmark、Comcast、Facebook、Fidelity Investments、Google、JPMorgan Chase&Company、LinkedIn、Microsoft、Netease、PayPal、ReturnPath、Trusted Domain Project、Yahoo!などがあります。貢献者と支持者は多すぎて言及することはできませんが、注目すべき個人の貢献は、J。トレントアダムス、マイケルアドキンス、モニカチュー、デイブクロッカー、ティムドレーゲン、スティーブジョーンズ、フランクマーティン、ブレットマクダウェル、およびポールミッドゲンによって行われました。寄稿者はまた、J.D。フォークによって早期に提供された貴重なインプットとガイダンスを認めたいと考えています。

Additional contributions within the IETF context were made by Kurt Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.

IETFコンテキスト内での追加の貢献は、カートアンダーソン、マイケルジャックアッセル、レバーストウ、アンベネット、ジムフェントン、J。ゴメス、マイクジョーンズ、スコットキッターマン、エリオットリア、ジョンレバイン、S。ムーネサミー、ロルフゾンネフェルド、ヘンリーティムスによって行われました。 、そしてスティーブン・J・ターンブル。

Authors' Addresses


Murray S. Kucherawy (editor)


   EMail: superuser@gmail.com

Elizabeth Zwicky (editor) Yahoo!


   EMail: zwicky@yahoo-inc.com