Diff: draft-dmarc-base-00-02.txt - draft-kucherawy-dmarc-base-00.txt (original) (raw)

< draft-dmarc-base-00-02.txt

draft-kucherawy-dmarc-base-00.txt >

DMARC.org M. Kucherawy, Ed.

Network Working Group M. Kucherawy, Ed.

Cloudmark

Internet-Draft March 31, 2013

March 30, 2012

Intended status: Standards Track

Expires: October 2, 2013

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

draft-kucherawy-dmarc-base-00

Abstract

The email ecosystem currently lacks a cohesive mechanism through

which email senders and receivers can make use of multiple

authentication protocols in an attempt to establish reliable domain

identifiers. This lack of cohesion prevents receivers from providing

domain-specific feedback to senders regarding the accuracy of

authentication deployments. Inaccurate authentication deployments

preclude receivers from safely taking deterministic action against

skipping to change at page 2, line 5

skipping to change at page 1, line 37

policies and preferences for message validation, disposition, and

reporting with predictable and accurate results.

The enclosed proposal is not intended to introduce mechanisms that

provide elevated delivery privilege of authenticated email. The

proposal presents a mechanism for policy distribution that enables a

continuum of increasingly strict handling of messages that fail

multiple authentication checks, from no action, through silent

reporting, up to message rejection.

Status of this Memo

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet-

Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 2, 2013.

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. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Table of Contents

1. License . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1. License . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Towards An Authenticated Future . . . . . . . . . . . . . 7

2.3. Towards An Authenticated Future . . . . . . . . . . . . . 8

2.4. Experiment Team . . . . . . . . . . . . . . . . . . . . . 8

2.4. Experiment Team . . . . . . . . . . . . . . . . . . . . . 9

3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 8

3.1. High-Level Requirements . . . . . . . . . . . . . . . . . 9

3.2. Security Dependencies . . . . . . . . . . . . . . . . . . 9

3.2. Security Dependencies . . . . . . . . . . . . . . . . . . 10

3.3. DMARC Discovery Requirements . . . . . . . . . . . . . . 9

3.3. DMARC Discovery Requirements . . . . . . . . . . . . . . 10

3.4. Detailed Requirements . . . . . . . . . . . . . . . . . . 10

3.4. Detailed Requirements . . . . . . . . . . . . . . . . . . 11

3.5. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . 12

3.5. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . 13

4. Terminology and Definitions . . . . . . . . . . . . . . . . . 13

4. Terminology and Definitions . . . . . . . . . . . . . . . . . 14

4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 16

4.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 15

4.2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1. DKIM-authenticated Identifiers . . . . . . . . . . . 16

4.3. Identifier Alignment . . . . . . . . . . . . . . . . . . 16

4.2.2. SPF-authenticated Identifiers . . . . . . . . . . . . 16

4.3.1. DKIM-authenticated Identifiers . . . . . . . . . . . 17

4.2.3. Alignment and Extension Technologies . . . . . . . . 17

4.3.2. SPF-authenticated Identifiers . . . . . . . . . . . . 18

5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.3. Alignment and Extension Technologies . . . . . . . . 18

6. DMARC Policy Record . . . . . . . . . . . . . . . . . . . . . 18

5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 18

6. DMARC Policy Record . . . . . . . . . . . . . . . . . . . . . 19

6.2. General Record Format . . . . . . . . . . . . . . . . . . 19

6.1. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 19

6.3. Formal Definition . . . . . . . . . . . . . . . . . . . . 21

6.2. General Record Format . . . . . . . . . . . . . . . . . . 20

7. Policy Enforcement Considerations . . . . . . . . . . . . . . 23

6.3. Formal Definition . . . . . . . . . . . . . . . . . . . . 23

8. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 23

7. Policy Enforcement Considerations . . . . . . . . . . . . . . 25

8.1. Feedback Considerations . . . . . . . . . . . . . . . . . 23

7.1. Policy Fallback Mechanism . . . . . . . . . . . . . . . . 26

8.2. Verifying External Destinations . . . . . . . . . . . . . 24

8. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 26

8.3. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 25

8.1. Feedback Considerations . . . . . . . . . . . . . . . . . 26

8.4. Failure Reports . . . . . . . . . . . . . . . . . . . . . 26

8.2. Verifying External Destinations . . . . . . . . . . . . . 26

9. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . . 26

8.3. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 28

10. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . . 27

8.4. Failure Reports . . . . . . . . . . . . . . . . . . . . . 30

11. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 29

8.4.1. Reporting Format Update . . . . . . . . . . . . . . . 30

11.1. Extract Author Domain . . . . . . . . . . . . . . . . . . 29

8.5. Failure Reports . . . . . . . . . . . . . . . . . . . . . 31

11.2. Determine Handling Policy . . . . . . . . . . . . . . . . 29

9. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . . 31

11.3. Message Sampling . . . . . . . . . . . . . . . . . . . . 30

10. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . . 33

11.4. Store Results of DMARC Processing . . . . . . . . . . . . 30

11. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 34

12. Feedback Mechanism . . . . . . . . . . . . . . . . . . . . . . 31

11.1. Extract Author Domain . . . . . . . . . . . . . . . . . . 34

12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 31

11.2. Determine Handling Policy . . . . . . . . . . . . . . . . 34

12.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31

11.3. Message Sampling . . . . . . . . . . . . . . . . . . . . 35

12.2.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 32

11.4. Store Results of DMARC Processing . . . . . . . . . . . . 36

12.2.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 33

12. Feedback Mechanism . . . . . . . . . . . . . . . . . . . . . . 36

12.2.3. Other Methods . . . . . . . . . . . . . . . . . . . . 33

12.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 37

12.2.4. Error Reports . . . . . . . . . . . . . . . . . . . . 33

12.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 37

13. Minimum Implementations . . . . . . . . . . . . . . . . . . . 34

12.2.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 37

14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35

12.2.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 39

14.1. Authentication-Results Method Registry Update . . . . . . 35

12.2.3. Other Methods . . . . . . . . . . . . . . . . . . . . 39

14.2. Authentication-Results Result Registry Update . . . . . . 35

12.2.4. Error Reports . . . . . . . . . . . . . . . . . . . . 39

14.3. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 36

13. Minimum Implementations . . . . . . . . . . . . . . . . . . . 40

14.4. DMARC Report Format Registry . . . . . . . . . . . . . . 37

14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41

15. Security Considerations . . . . . . . . . . . . . . . . . . . 38

14.1. Authentication-Results Method Registry Update . . . . . . 41

15.1. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . 38

14.2. Authentication-Results Result Registry Update . . . . . . 41

15.2. Display Name Attacks . . . . . . . . . . . . . . . . . . 39

14.3. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 42

15.3. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 39

14.4. DMARC Report Format Registry . . . . . . . . . . . . . . 43

15.4. Issues Specific to SPF . . . . . . . . . . . . . . . . . 40

15. Security Considerations . . . . . . . . . . . . . . . . . . . 44

15.5. DNS Load . . . . . . . . . . . . . . . . . . . . . . . . 40

15.1. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . 44

15.6. External Reporting Addresses . . . . . . . . . . . . . . 41

15.2. Display Name Attacks . . . . . . . . . . . . . . . . . . 45

15.7. Feedback Loops . . . . . . . . . . . . . . . . . . . . . 41

15.3. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 45

15.8. Rejecting Messages . . . . . . . . . . . . . . . . . . . 42

15.4. Issues Specific to SPF . . . . . . . . . . . . . . . . . 46

15.9. Capacity Planning . . . . . . . . . . . . . . . . . . . . 42

15.5. DNS Load . . . . . . . . . . . . . . . . . . . . . . . . 46

15.10. Privacy Considerations . . . . . . . . . . . . . . . . . 43

15.6. External Reporting Addresses . . . . . . . . . . . . . . 47

15.10.1. Data Exposure Considerations . . . . . . . . . . . . 43

15.7. Feedback Loops . . . . . . . . . . . . . . . . . . . . . 47

15.10.2. Report Recipients . . . . . . . . . . . . . . . . . . 44

15.8. Rejecting Messages . . . . . . . . . . . . . . . . . . . 48

15.10.3. Report Generators . . . . . . . . . . . . . . . . . . 44

15.9. Capacity Planning . . . . . . . . . . . . . . . . . . . . 49

15.10.4. Secure Protocols . . . . . . . . . . . . . . . . . . 44

15.10. Privacy Considerations . . . . . . . . . . . . . . . . . 49

15.11. Identifier Alignment Considerations . . . . . . . . . . . 44

15.10.1. Data Exposure Considerations . . . . . . . . . . . . 49

16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45

15.10.2. Report Recipients . . . . . . . . . . . . . . . . . . 50

16.1. Normative References . . . . . . . . . . . . . . . . . . 45

15.10.3. Report Generators . . . . . . . . . . . . . . . . . . 50

16.2. Informative References . . . . . . . . . . . . . . . . . 46

15.10.4. Secure Protocols . . . . . . . . . . . . . . . . . . 50

Appendix A. Technology Considerations . . . . . . . . . . . . . . 47

15.11. Identifier Alignment Considerations . . . . . . . . . . . 51

A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47

15.12. DNS Security . . . . . . . . . . . . . . . . . . . . . . 51

A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 48

16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 48

16.1. Normative References . . . . . . . . . . . . . . . . . . 51

A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 49

16.2. Informative References . . . . . . . . . . . . . . . . . 53

A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 49

Appendix A. Technology Considerations . . . . . . . . . . . . . . 54

A.6. Organizational Domain Discovery Issues . . . . . . . . . 50

A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 51

A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 55

Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 51

A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 55

B.1. Identifier Alignment examples . . . . . . . . . . . . . . 51

A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 56

B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 51

A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 56

B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 52

A.6. Organizational Domain Discovery Issues . . . . . . . . . 57

B.2. Domain Owner example . . . . . . . . . . . . . . . . . . 53

A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 58

B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 53

Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 58

B.1. Identifier Alignment examples . . . . . . . . . . . . . . 58

B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 58

B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 59

B.2. Domain Owner example . . . . . . . . . . . . . . . . . . 60

B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 61

B.2.2. Entire Domain, Monitoring Only, Per-Message

Reports . . . . . . . . . . . . . . . . . . . . . . . 54

Reports . . . . . . . . . . . . . . . . . . . . . . . 62

B.2.3. Per-Message Forensic Reports Directed to Third

B.2.3. Per-Message Failure Reports Directed to Third

Party . . . . . . . . . . . . . . . . . . . . . . . . 55

Party . . . . . . . . . . . . . . . . . . . . . . . . 62

B.2.4. Sub-Domain, Sampling, and Multiple Aggregate

Report URIs . . . . . . . . . . . . . . . . . . . . . 56

Report URIs . . . . . . . . . . . . . . . . . . . . . 64

B.2.5. Third Party Sender and Identifier Alignment . . . . . 58

B.2.5. Third Party Sender and Identifier Alignment . . . . . 65

B.2.6. Sub-Domain Policy, Reporting Interval . . . . . . . . 59

B.2.6. Sub-Domain Policy, Reporting Interval . . . . . . . . 66

B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 60

B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 67

B.3.1. SMTP-time Processing . . . . . . . . . . . . . . . . 60

B.3.1. SMTP-time Processing . . . . . . . . . . . . . . . . 67

B.3.2. Real-time Feedback Processing . . . . . . . . . . . . 62

B.3.2. Real-time Feedback Processing . . . . . . . . . . . . 69

B.4. Utilization of Aggregate Feedback example . . . . . . . . 62

B.4. Utilization of Aggregate Feedback example . . . . . . . . 69

B.5. mailto Transport example . . . . . . . . . . . . . . . . 62

B.5. mailto Transport example . . . . . . . . . . . . . . . . 70

B.6. https Transport example . . . . . . . . . . . . . . . . . 63

B.6. https Transport example . . . . . . . . . . . . . . . . . 71

Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 64

Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 71

Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 69

Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 77

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70

Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 77

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78

1. License

As of the date shown at the top right of this page, the Contributors

have made this Specification available under the Open Web Foundation

Contributor License Agreement Version 1.0, which is available at:

http://www.dmarc.org/cla.html

You can review the signed copies of the Open Web Foundation

Contributor License Agreement Version 1.0 for this Specification at:

skipping to change at page 5, line 39

skipping to change at page 6, line 39

ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING

AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING

NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS

BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

2. Introduction

For years, various receivers have tried to protect senders who are

known to authenticate their outbound email from phishing by using

[DKIM] and/or [SPF] results to detect and block unauthorized email.

At the same time, senders have leveraged SPF-authorized and DKIM-

(A detailed discussion of the threats these systems attempt to

signed messages to achieve domain-level email authentication.

address can be found in [DKIM-THREATS].) At the same time, senders

However, a broadly accepted mechanism to assert domain-specific

have leveraged SPF-authorized and DKIM-signed messages to achieve

message-disposition policies, or to request reporting of same, has

domain-level email authentication. However, a broadly accepted

been lacking.

mechanism to assert domain-specific message-disposition policies, or

to request reporting of same, has been lacking.

The fundamental idea behind these approaches is that if a sender

authenticates all legitimate outbound mail using the authentication

protocols SPF and DKIM, then receivers can quarantine or reject

unauthenticated mail purporting to be from that sender. 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.

This memo defines Domain-based Message Authentication, Reporting and

Compliance (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 encourages senders and receivers to collaborate by monitoring

skipping to change at page 10, line 24

skipping to change at page 11, line 26

3.4. Detailed Requirements

DMARC's specification requirements, in detail:

1. The RFC5322.From domain is the identifier used for all message

validation operations, as it is the single identifier in the

message likely to be visible to the user.

2. Senders can specify a "strict" or "relaxed" mode in terms of

enforcing identifier checks (see Section 4.2). In "strict"

enforcing identifier checks (see Section 4.3). In "strict"

mode, all identifiers from authentication systems upon which

DMARC is predicated must match the RFC5322.From domain. In

"relaxed" mode, the organizational domains (see Section 4) must

match. The "relaxed" mode shall be the default.

3. A sender's policy must be discoverable via DNS queries.

4. It must be possible to specify reject or quarantine policies

when none of the underlying authentication systems succeed.

skipping to change at page 10, line 50

skipping to change at page 12, line 5

the organizational domain itself.

7. Message disposition requests via DMARC override those requested

by any other public mechanism.

8. Senders should be able to specify a percentage of their messages

to which their policies should be applied, with the rest

unaffected, in order to experiment and to understand and

minimize deployment risk.

9. Receivers should endeavour to reject or quarantine email if the

9. Reporting configuration in DMARC should override any such

RFC5322.From purports to be from a domain that appears to be

either non-existent or incapable of receiving mail.

Reporting configuration in DMARC should override any such

options specified by DKIM or SPF or extensions to them.

The sender must be able to to specify independent reporting
The sender must be able to to specify independent reporting

addresses for failed message reporting and aggregate data feeds.

The aggregate report must contain enough information for the
The aggregate report must contain enough information for the

report consumer to re-calculate DMARC disposition based on the

published policy, message dispositon, and SPF, DKIM, and

identifier alignment results.

The aggregate report must still contain data for each sender
The aggregate report must still contain data for each sender

subdomain separately from mail from the sender's organizational

domain, even if no subdomain policy is applied. The report must

indicate any policy applied to subdomains.

It must be possible to specify a minimum reporting interval.
It must be possible to specify a minimum reporting interval.

Reporting sites should make a best effort to accommodate that

request.

The sender can specify a time-to-live for policy records.
The sender can specify a time-to-live for policy records.
The sender can indicate which domains under its control never
The sender can indicate which domains under its control never

send email, either by omitting them from the DNS entirely or by

declaring specific use of DKIM and SPF that no email will ever

fulfill.

The sending and receiving domains should be included in the
The sending and receiving domains should be included in the

aggregate report.

The policy request and the one applied (if different) should be
The policy request and the one applied (if different) should be

included in the aggregate report.

The number of successful authentications should be included in
The number of successful authentications should be included in

the aggregate report.

The report should be generated based on all messages even if
The report should be generated based on all messages even if

filtering agents such as anti-virus or anti-spam engines

ultimately block delivery.

For real-time reporting of failed messages, including a [URI] to
For real-time reporting of failed messages, including a [URI] to

identify phishing sites and diagnostics on DKIM and SPF failures

will be recommended.

Static conformance requirements shall be documented to enable
Static conformance requirements shall be documented to enable

testing programs to help ensure consitency of results. (This

testing programs to help ensure consistency of results. (This

will be done in a separate Best Current Practices document.)

Aggregate reports should communicate DMARC message disposition
Aggregate reports should communicate DMARC message disposition

regardless of any subsequent action that affects message

disposition or delivery.

The mechanism overall should be flexible enough to swap in or
The mechanism overall should be flexible enough to swap in or

out any authentication technology.

Tags throughout the specification part of this document indicate

conformance to the above requirements. For example "{R1}" indicates

a component of the protocol that addresses requirement #1 in the list

above.

3.5. Out Of Scope

Items specifically not in scope for this work include:

skipping to change at page 13, line 37

skipping to change at page 14, line 37

to some third party. This memo 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: Authentication technologies allow

evaluation agents to associate email with domain-level

identifiers. Domain-level identifiers that are established using

authentication technologies are referred to as "Authenticated

Identifiers". The following Authenticated Identifiers are

Identifiers". See Section 4.1 for details about the supported

considered in this document:

mechanisms.

* [DKIM] provides a domain-level identifier in the content of the

"d=" tag of a validated signature.

* [SPF] can authenticate the domain found in an [SMTP] MAIL

command.

Cousin Domain: A DNS domain that, when rendered by a Mail User Agent

(MUA), looks similar to, or can lead users to believe the domain

is associated with, another name. For instance, "vendor5.example"

would be a Cousin Domain of "vendors.example". This is a common

tool in a homograph attack.

Domain Owner: The 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.

skipping to change at page 15, line 9

skipping to change at page 16, line 8

label from the subject domain. This new name is the

Organizational Domain.

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.1. Summary

4.1. Authentication Mechanisms

The following Authenticated Identifiers are supported in the current

version of DMARC:

o [DKIM], which provides a domain-level identifier in the content of

the "d=" tag of a validated signature.

o [SPF], which can authenticate the domain found in an [SMTP] MAIL

command.

4.2. Summary

DMARC's filtering component is based on whether or not SPF or DKIM

can provide an authenticated -- and relevant -- identifier for any

given message. Messages that purport to be from a Domain Owner's

domain and arrive from servers that are not authorized by SPF and do

not contain an appropriate DKIM signature can be affected by DMARC

policies.

DMARC's feedback component involves the collection of information

pertaining to received messages, in the aggregate, for periodic

reporting back 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 which fail

SPF and/or DKIM. Per-message reports are useful for forensic use in

SPF and/or DKIM. Per-message failure reports are useful for forensic

debugging deployments (if messages can be determined to be legitimate

use in debugging deployments (if messages can be determined to be

albeit failing authentication) or in analyzing attacks. The

legitimate albeit failing authentication) or in analyzing attacks.

capability for such services is enabled by DMARC but defined in other

The capability for such services is enabled by DMARC but defined in

referenced material.

other referenced material.

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.

4.2. Identifier Alignment

4.3. Identifier Alignment

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] authenticates the domain that appears in the

while [SPF] authenticates either the domain that appears in the

RFC5321.MailFrom portion of [SMTP]. The DMARC mechanism introduces

RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if

the concept of Identifier Alignment to address the possible

the RFC5321.MailFrom is null (in the case of Delivery Status

discrepancy of Authenticated Identifiers supplied by underlying

Notifications). The DMARC mechanism introduces the concept of

authentication technologies.

Identifier Alignment to address the possible discrepancy of

Authenticated Identifiers supplied by underlying authentication

technologies.

DMARC uses the RFC5322.From domain to tie together Authenticated

Identifiers {R1}. The selection of the RFC5322.From domain as the

central identity of the DMARC mechanism is due to the ubiquity of

this identity and the behavior of most MUAs to represent the

RFC5322.From field as the originator of the message and to render

some or all of this header's content to end users.

To be considered "in alignment" for the purposes of the DMARC

mechanism, implementors MUST observe the considerations described in

the following sections. Domain names in this context are to be

compared in a case-insensitive manner, per [DNS-CASE].

4.2.1. DKIM-authenticated Identifiers

It is important to note that identity alignment cannot occur with a

message that is not valid per [MAIL], particularly one with a

malformed or absent RFC5322.From field. Handling of such cases is

left to the discretion of the Mail Receiver.

4.3.1. DKIM-authenticated Identifiers

DMARC provides the option of applying DKIM in a strict mode or a

relaxed mode {R2}.

In relaxed mode, the Organizational Domain of 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. In

strict mode, only an exact match is considered to produce identifier

alignment.

skipping to change at page 16, line 39

skipping to change at page 18, line 7

suffix lists, and therefore cannot be an Organizational Domain.

Identifier alignment is required to prevent abuse by phishers that

send DKIM-signed email using an arbitrary "d=" domain (such as a

Cousin Domain) to pass authentication checks.

Note that a single email can contain multiple DKIM signatures,

raising the possibility of processing multiple signatures in an

attempt to establish an "in alignment" result.

4.2.2. SPF-authenticated Identifiers

4.3.2. SPF-authenticated Identifiers

DMARC provides the option of applying SPF in a strict mode or a

relaxed mode {R2}.

In relaxed mode, the [SPF]-authenticated RFC5321.MailFrom (commonly

In relaxed mode, the [SPF]-authenticated domain and RFC5322.From

called the "envelope sender") domain and RFC5322.From domain must

domain must have the same Organizational Domain. In strict mode,

have the same Organizational Domain. In strict mode, only an exact

only an exact DNS domain match is considered to produce identifier

DNS domain match is considered to produce identifier alignment.

alignment.

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.

4.2.3. Alignment and Extension Technologies

4.3.3. Alignment and Extension Technologies

If DMARC is extended to include the use of other authentication

mechanisms, the extensions will need to allow for domain identifier

extraction so that alignment against the RFC5322.From domain can be

extraction so that alignment with the RFC5322.From domain can be

verified.

5. Policy

DMARC policies are published by Domain Owners and applied by Mail

Receivers.

A Domain Owner advertises DMARC participation by adding a DNS TXT

record (described in Section 6) {R3, R15, R16} to one or more sending

domains under its direct or indirect control (e.g. operated by a

skipping to change at page 18, line 16

skipping to change at page 19, line 29

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 records are stored in the DNS for three key engineering

DMARC records are stored in the DNS for two key engineering reasons:

reasons:

Wildcarding: DNS natively supports wildcarding, enabling child

domains to inherit parent domain policy easily.

Overrides: DMARC records published at child domains explicitly

override extant parent policy.

Efficiency: DNS caching is a common practice, reducing operational

overhead of a new DNS-based mechanism.

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.

6.1. DMARC URIs

[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 either of the two report types that are

the destination for the two report types that are supported.

supported.

The place such URIs are specified (see Section 6.2) allows a list of

these to be provided, to be tried in order until one of them

these to be provided. A report is to be sent to each listed URI.

successfully receives the report. The list of URIs is separated by

Mail Receivers MAY impose a limit on the number of URIs that receive

commas (ASCII 0x2C).

reports, but MUST support at least two. The list of URIs is

separated by commas (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 semi-colon.

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.

skipping to change at page 19, line 30

skipping to change at page 20, line 41

processed; unknown tags MUST be ignored. To avoid version

compatibility issues, tags added to the DMARC specification SHOULD

NOT change the semantics of existing records when processed by

implementations conforming to prior specifications.

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

adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or

not strict DKIM identifier alignment is required by the Domain

Owner. If and only if the value of the string is "s", strict mode

is in use. See Section 4.2.1 for details.

is in use. See Section 4.3.1 for details.

aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether or

not strict SPF identifier alignment is required by the Domain

Owner. If and only if the value of the string is "s", strict mode

is in use. See Section 4.2.2 for details.

is in use. See Section 4.3.2 for details.

p: Requested Mail Receiver policy (plain-text; REQUIRED). Indicates

fo: Failure reporting options (plain-text; OPTIONAL, default "0"))

the policy to be enacted by the Receiver at the request of the

Provides requested options for generation of failure reports.

Domain Owner. Policy applies to the domain queried and to sub-

Report generators MAY choose to adhere to the requested options.

domains unless sub-domain policy is explicitly described using the

This tag's content MUST be ignored if a "ruf" tag (below) is not

"sp" tag. Possible values are as follows:

also specified. The value of this tag is a colon-separated list

of characters that indicate failure reporting options as follows:

0: Generate a DMARC failure report if all underlying

authentication mechanisms failed to produce an aligned "pass"

result.

1: Generate a DMARC failure report if any underlying

authentication mechanism failed to produce 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].

s: Generate an SPF failure report if the message failed SPF

evaluation, regardless of its alignment. SPF-specific

reporting is described in [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 sub-domains unless sub-domain 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 8.2). Possible values are as follows:

none: {R5} The Domain Owner requests no specific action be taken

regarding delivery of messages.

quarantine: {R4} The Domain Owner wishes to have email that fails

the DMARC mechanism check to 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: {R4} 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 15.8 for some

discussion of SMTP rejection methods and their implications.

pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL;

default is 100). {R8} Percentage of messages from the DNS domain's

mail stream to which the DMARC mechanism 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 slowly roll out

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.

experimenting with strong authentication-based mechanisms. See

Section 7.1 for details.

rf: Format to be used for message-specific forensic information

rf: Format to be used for message-specific failure reports (comma-

reports (comma-separated plain-text list of values; OPTIONAL;

separated plain-text list of values; OPTIONAL; default "afrf").

default "afrf"). The value of this tag is a list of one or more

The value of this tag is a list of one or more report formats as

report formats as requested by the Domain Owner to be used when a

requested by the Domain Owner to be used when a message fails both

message fails both [SPF] and [DKIM] tests to report details of the

[SPF] and [DKIM] tests to report details of the individual

individual failure. The values MUST be present in the registry of

failure. The values MUST be present in the registry of reporting

reporting formats defined in Section 14; a Mail Receiver observing

formats defined in Section 14; a Mail Receiver observing a

a different value SHOULD ignore it, or MAY ignore the entire DMARC

different value SHOULD ignore it, or MAY ignore the entire DMARC

record. Initial default values are "afrf" (defined in [AFRF]) and

"iodef" (defined in [IODEF]).

"iodef" (defined in [IODEF]). See Section 8.4 for details.

ri: Interval requested between aggregate reports (plain-text, 32-bit

unsigned integer; OPTIONAL; default 86400). {R14} 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.

skipping to change at page 21, line 5

skipping to change at page 22, line 42

list delimiter or an OPTIONAL size limit. Section 8.2 discusses

considerations that apply when the domain name of a URI differs

from that of the domain advertising the policy. See Section 15.6

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 8.3.

ruf: Addresses to which message-specific forensic information is to

ruf: Addresses to which message-specific failure information is to

be reported (comma-separated plain-text list of DMARC URIs;

OPTIONAL). {R11} If present, the Domain Owner is requesting Mail

Receivers to send detailed forensic reports about messages that

Receivers to send detailed failure reports about messages that

fail [SPF] and/or [DKIM] evaluation. The format of the message to

fail the DMARC evaluation in specific ways (see the "fo" tag

be generated MUST follow that specified in the "rf" tag.

above). The format of the message to be generated MUST follow

Section 8.2 discusses considerations that apply when the domain

that specified in the "rf" tag. Section 8.2 discusses

name of a URI differs from that of the domain advertising the

considerations that apply when the domain name of a URI differs

policy. A Mail Receiver MUST implement support for a "mailto:"

from that of the domain advertising the policy. A Mail Receiver

URI, i.e. the ability to send a DMARC report via electronic mail.

MUST implement support for a "mailto:" URI, i.e. the ability to

If not provided, Mail Receivers MUST NOT generate forensic

send a DMARC report via electronic mail. If not provided, Mail

reports. See Section 15.6 for additional considerations.

Receivers MUST NOT generate failure reports. See Section 15.6 for

additional considerations.

sp: {R6} Requested Mail Receiver policy for 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.

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.

Note that addition of a new tag into the registered list of tags does

A DMARC policy record MUST comply with the formal specification found

not itself require a new version of DMARC to be generated (with a

in Section 6.3 in that the "v" and "p" tags MUST be present and MUST

corresponding change to the "v" tag's value), but a change to any

appear in that order. Unknown tags MUST be ignored. Syntax errors

existing tags does require a new version of DMARC.

in the remainder of the record SHOULD be discarded in favour 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.3. Formal Definition

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

dmarc-record = dmarc-version dmarc-sep

dmarc-request

[dmarc-request]

[dmarc-sep dmarc-srequest]

[dmarc-sep dmarc-auri]

[dmarc-sep dmarc-furi]

[dmarc-sep dmarc-adkim]

[dmarc-sep dmarc-aspf]

[dmarc-sep dmarc-ainterval]

[dmarc-sep dmarc-rfmt]

[dmarc-sep dmarc-percent]

[dmarc-sep]

; components other than dmarc-version and

; dmarc-request may appear in any order

dmarc-sep = *WSP %3b *WSP

dmarc-version = "v" *WSP "=DMARC1"

dmarc-version = %x76 *WSP "=" %x44.4d.41.52.43

dmarc-sep = *WSP %3b *WSP

dmarc-request = %x70 *WSP "=" *WSP ( "none" /

dmarc-request = "p" *WSP "=" *WSP ( "none" /

"quarantine" / "reject" )

dmarc-srequest = %x73.70 *WSP "=" *WSP ( "none" /

dmarc-srequest = "sp" *WSP "=" *WSP ( "none" /

"quarantine" / "reject" )

dmarc-auri = %x72.75.61 *WSP "=" *WSP

dmarc-auri = "rua" *WSP "=" *WSP

dmarc-uri *(*WSP "," *WSP dmarc-uri)

dmarc-ainterval = %x72.69 *WSP "=" *WSP

dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT

dmarc-furi = %x72.75.66 *WSP "=" *WSP

dmarc-furi = "ruf" *WSP "=" *WSP

dmarc-uri *(*WSP "," *WSP dmarc-uri)

dmarc-rfmt = %x72.66 *WSP "=" *WSP

dmarc-rfmt = "rf" *WSP "=" *WSP

( "afrf" / "iodef" )

dmarc-percent = %x70.63.74 *WSP "=" *WSP

dmarc-percent = "pct" *WSP "=" *WSP

1*3DIGIT

dmarc-adkim = %x61.64.6b.69.6d *WSP "=" *WSP

dmarc-adkim = "adkim" *WSP "=" *WSP

( "r" / "s" )

dmarc-aspf = %x61.73.70.66 *WSP "=" *WSP

dmarc-aspf = "aspf" *WSP "=" *WSP

( "r" / "s" )

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.

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.

Tag and value matching is case-insensitive.

7. Policy Enforcement Considerations

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.

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 SHOULD make a best effort not to increase the

policy. Mail Receivers need to make a best effort not to increase

likelihood of phishing if it chooses not to reject, against policy.

the likelihood of phishing if it chooses not to 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, as described in Section 2.3 of [IDNA].

Mail Receivers are not obligated to report reject or quarantine

policy actions in aggregate feedback reports that are not due to

DMARC policy, but are instead the result of local policy. If local

policy information is exposed, abusers can gain insight into the

effectiveness and delivery rates of spam campaigns.

DMARC-compliant Mail Receivers MUST disregard any mail directive

DMARC-compliant Mail Receivers SHOULD disregard any mail directive

discovered as part of an authentication mechanism (e.g., ADSP, SPF)

where a DMARC policy is also discovered. {R7} Mail Receivers SHOULD

where a DMARC policy is also discovered that specifies a policy other

also implement reporting instructions of DMARC in place of any

than "none". {R7} To enable Domain Owners to receive DMARC feedback

extensions to SPF or DKIM that might enable such reporting. {R10}

without impacting existing mail processing, discovered policies of

"p=none" SHOULD NOT modify existing mail disposition processing.

Note that some Mail Receivers may reject email based upon SPF policy

mechanisms before email enters DMARC-specific processing.

Mail Receivers SHOULD also implement reporting instructions of DMARC

in place of any extensions to SPF or DKIM that might enable such

reporting. {R10}

7.1. Policy Fallback Mechanism

If the "pct" tag is present in a policy record, application of policy

is done on a selective basis. The stated percentage of messages that

fail the DMARC test MUST be subjected to whatever policy is selected

by the "p" or "sp" tag (if present). Those that are not thus

selected MUST instead be subjected to the next policy lower in terms

of severity. In decreasing order of severity, the policies are

"reject", "quarantine", and "none".

For example, in the presence of "pct=50" in the DMARC policy record

for "example.com", half of the mesages with "example.com" in the

RFC5322.From field which fail the DMARC test would be subjected to

"reject" action, and the remainder subjected to "quarantine" action.

8. DMARC Feedback

The DMARC mechanism requires highly accurate authentication

deployments to allow Mail Receivers to safely and scalably enforce

Domain Owner policies. 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.

skipping to change at page 24, line 29

skipping to change at page 27, line 13

When a Mail Receiver discovers a DMARC policy in the DNS, and the

domain at which that record was discovered is not identical to the

host part of the authority component of a [URI] specified in the

"rua" or "ruf" tag, the following verification steps SHOULD be taken:

1. Extract the host portion of the authority component of the URI.

Call this the "destination host".

2. Prepend the string "_report._dmarc".

3. Prepend the domain name from which the policy was retrieved.

3. Prepend the domain name from which the policy was retrieved,

after conversion to an A-label if needed.

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.

5. If the result includes no TXT resource records or multiple TXT

5. For each record returned, parse the result as a series of

resource records, a positive determination of the external

"tag=value" pairs, i.e., the same overall format as the policy

reporting relationship cannot be made; stop.

record (see Section 6.3). In particular, the "v=DMARC1" tag is

mandatory and MUST appear first in the list. Discard any that do

not pass this test.

6. Parse the result, if any, as a series of "tag=value" pairs, i.e.,

6. If the result includes no TXT resource records that pass basic

the same overall format as the policy record. In particular, the

parsing, a positive determination of the external reporting

"v=DMARC1" tag is mandatory and MUST appear first in the list.

relationship cannot be made; stop.

If at least that tag is present and the record overall is

syntactically valid per Section 6.3, then the external reporting

arrangement was authorized by the destination ADMD.

7. If a "rua" or "ruf" tag is thus discovered, replace the

7. If at least one TXT resource record remains in the set after

parsing, then the external reporting arrangement was authorized

by the destination ADMD.

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.

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

skipping to change at page 26, line 24

skipping to change at page 29, line 16

o The policy requested by the Domain Owner and the policy actually

applied (if different) {R18}

o The number of successful authentications {R19}

o The counts of messages based on all messages received even if

their delivery is ultimately blocked by other filtering agents

{R20}

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 a single aggregate report for such a reporting period

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 generate multiple reports for the same period, one for each

published policy occurring during the reporting period;

o generate a report whose end time occurs when the updated policy

was detected, regardless of any requested report interval.

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 incongruous 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; et cetera. 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.

8.4. Failure Reports

Message-specific authentication-failure-related forensic reporting

When a Domain Owner requests failure reports for the purpose of

can be used to identify problems with Domain-Owner-controlled

forensic analysis, and the Mail Receiver is willing to provide such

infrastructure and to investigate the sources and causes of failing

reports, the Mail Receiver generates and sends a message using the

messages. They might also be used to aid investigations into the

format described in [AFRF]. This document updates the AFRF format as

sources and objectives of fraudulent messages.

described in Section 8.4.1.

The destination(s) and nature of the reports are defined by the "fo"

and "ruf" tags as defined in Section 6.2.

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 which 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:

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

messages;

o store reports for a period of time before sending them, allowing

detection, collection, and reporting of like incidents;

o apply rate limiting, such as a maximum number of reports per

minute that will be generated (and the remainder discarded).

8.4.1. Reporting Format Update

[AFRF] is updated to include the following changes:

1. Section 3.2 is updated to indicate that a DMARC failure report

includes the following ARF header fields, with the indicated

normative requirement levels:

* Identity-Alignment (REQUIRED; defined below)

* Delivery-Result (OPTIONAL)

* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the

message was signed by DKIM)

* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL

if the message was signed by DKIM)

* SPF-DNS (REQUIRED)

2. Section 3.2 is updated to define the "Identity-Alignment" field

as containing a comma-separated list of authentication mechanism

names that produced an aligned identity, or the keyword "none" if

none did. ABNF:

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. Section 3.3 is updated to add Authentication Failure Type

"dmarc", 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.

8.5. Failure Reports

Message-specific authentication-failure-related reporting can be used

to identify problems with Domain-Owner-controlled infrastructure and

to investigate the sources and causes of failing messages. They

might also be used to aid investigations into the sources and

objectives of fraudulent messages.

The format for these reports is defined in either [AFRF] or [IODEF]

depending on the value found in the "rf" tag of the DMARC record (or

depending on the value found in the "ruf" tag of the DMARC record (or

its default).

These reports SHOULD include the "call-to-action" URI(s) from inside

messages that failed to authenticate. {R21}

9. Policy Discovery

As stated above, the DMARC mechanism utilizes DNS TXT records to

advertise policy. Policy discovery is accomplished similar to the

way SPF records are discovered. Important differences are discussed

skipping to change at page 27, line 41

skipping to change at page 32, line 48

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.

If the RFC5322.From domain does not exist in the DNS, Mail Receivers

SHOULD direct the receiving SMTP server to reject the message {R9}.

The choice of mechanism for such rejection and the implications of

those choices are discussed in Section 11 and Section 15.8.

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").

10. Domain Owner Actions

To implement the DMARC mechanism, Domain Owners perform the actions

enumerated in this section. For a trial operation, a Domain Owner

might at first deploy DMARC to cover only a subdomain.

1. Deploy authentication technologies [DKIM] (see also

[DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF].

2. Align identifiers; i.e., audit internal systems so that mail

skipping to change at page 29, line 15

skipping to change at page 34, line 28

Therefore, Domain Owners SHOULD include "mailto" URIs at the end of

the lists of URIs they publish.

11. Mail Receiver Actions

This section describes receiver actions in the DMARC environment.

11.1. Extract Author Domain

The domain in the RFC5322.From field is extracted as the domain to be

evaluated by DMARC.

evaluated by DMARC. If the domain is encoded with UTF-8, the domain

name must be converted to an A-label for further processing.

A message bearing multiple RFC5322.From identifiers is ambiguous

under DMARC. This includes messages with multiple RFC5322.From

fields (which is also forbidden under [MAIL]) and a message with a

single RFC5322.From field containing multiple entities. Such

single RFC5322.From field containing multiple entities. There can

messages SHOULD be rejected. If they are not, they MUST be ignored

also be From: fields that contain no meaningful values, such as

with respect to all DMARC processing, as reliable alignment of

RFC5322's "group" syntax. Such messages SHOULD be rejected. If they

verified identifiers with what the end user will actually see cannot

are not, the Mail Receiver can either ignore the message entirely

be positively determined.

with respect to DMARC processing, or evaluate DMARC against all

identifiers. In this latter case, it is important to consider the

set of identifiers that will ultimately be shown to end users, since

ensuring the legitimate use of those identifiers is at the heart of

DMARC's goal. This requires an understanding of the end user

environment, the specification of which is outside of the scope of

this document.

11.2. Determine Handling Policy

To arrive at a policy disposition for an individual message, Mail

Receivers MUST perform the following actions or their semantic

equivalents. The first four steps 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.

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

2. Query the DNS for a DMARC policy record. Continue if one is

found, or abort DMARC evaluation otherwise. See Section 9 for

details.

3. Perform DKIM signature verification checks. A single email may

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 all DKIM signatures that successfully

validated.

4. Perform SPF validation checks. The results of this step are

passed to the remainder of the algorithm and MUST include the

domain name from the RFC5321.MailFrom if SPF evaluation returned

domain name used to complete the SPF check if evaluation returned

a "pass" result.

5. Conduct identifier alignment checks. With authentication checks

and policy discovery performed, the Mail Receiver checks if

Authenticated Identifiers fall into alignment as decribed in

Section 4. 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.

skipping to change at page 30, line 24

skipping to change at page 35, line 44

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.2 for details.

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.

Handling of messages for which SPF and/or DKIM evaluation encounters

a DNS error is left to the discretion of the Mail Receiver. Further

discussion is available in Section 9.

11.3. Message Sampling

Attention must be paid to the possible presence of the "pct" tag in

the DMARC policy record. If the tag is present, 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.

skipping to change at page 31, line 46

skipping to change at page 37, line 25

12.2. Transport

Where the URI specified in an "rua" tag does not specify otherwise, a

Mail Receiver generating a feedback report SHOULD apply 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

included a size limitation exceeded by the generated report (after

compression and after any encoding required by the particular

transport mechanism) MUST NOT be used.

transport mechanism) MUST NOT be used. An attempt MUST be made to

deliver an aggregate report to every remaining URI.

If transport is not possible because the services advertised by the

published URIs are not able to accept reports (e.g., the URI refers

to a service that is unreachable, or all provided URIs specify size

limits exceeded by the generated record), the Mail Receiver SHOULD

send a short report (see Section 12.2.4) 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.

12.2.1. Email

In the case of a "mailto" URI, the Mail Receiver SHOULD communicate

reports using the method described in [STARTTLS].

The message generated by the Mail Receiver must be a [MIME] formatted

[MAIL] message. 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 contained within a ZIP file.

The aggregate data MUST be an XML file subjected to GZIP compression.

The aggregate data MUST be present using the media type "application/

zip", and the filenames SHOULD be constructed using the following

gzip", and the filenames SHOULD be constructed using the following

ABNF:

filename = receiver "!" policy-domain "!" begin-timestamp "!"

end-timestamp "." extension

end-timestamp [ "!" unique-id ] "." extension

unique-id = token

; "token" is imported from [MIME]

receiver = domain

; imported from [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" / "zip"

extension = "xml" / "gzip"

For the ZIP file itself, the extension MUST be "zip"; for the XML

For the GZIP file itself, the extension MUST be "gz"; for the XML

report, the extension MUST be "xml".

"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 ADMD.

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. That is, the message comprising the report should be

mechanism, thereby resulting in an aligned "pass" (see Section 4.3).

DKIM-signed and originate from a source for which an SPF test would

This practice minimizes the risk of report consumers processing

pass. This practice minimizes the risk of report consumers

fraudulent reports.

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 RFC6376

%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"

1*FWS domain-name 1*FWS

%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"

skipping to change at page 33, line 32

skipping to change at page 39, line 29

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 12.2.4 for further

discussion.

12.2.2. HTTP

Where an "http" or "https" method is requested in a Domain Owner's

URI list, the Mail Receiver MAY encode the data using the

"application/zip" media type or MAY send the Appendix C data

"application/gzip" media type ([GZIP]) or MAY send the Appendix C

uncompressed or unencoded.

data uncompressed or unencoded.

The header portion of the POST or PUT request SHOULD contain a

Subject field as described in Section 12.2.1.

HTTP permits the use of Content-Transfer-Encoding to upload gzip

content using the POST or PUT instruction after translating the

content to 7-bit ASCII.

12.2.3. Other Methods

Other registered URI schemes may be explicitly supported in later

versions.

12.2.4. Error Reports

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

skipping to change at page 37, line 18

skipping to change at page 43, line 18

+----------+-------------+---------+------------------------------+