< 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) Domain-based Message Authentication, Reporting and Conformance (DMARC)
draft-kucherawy-dmarc-base-00
Abstract Abstract
The email ecosystem currently lacks a cohesive mechanism through The email ecosystem currently lacks a cohesive mechanism through
which email senders and receivers can make use of multiple which email senders and receivers can make use of multiple
authentication protocols in an attempt to establish reliable domain authentication protocols in an attempt to establish reliable domain
identifiers. This lack of cohesion prevents receivers from providing identifiers. This lack of cohesion prevents receivers from providing
domain-specific feedback to senders regarding the accuracy of domain-specific feedback to senders regarding the accuracy of
authentication deployments. Inaccurate authentication deployments authentication deployments. Inaccurate authentication deployments
preclude receivers from safely taking deterministic action against 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 policies and preferences for message validation, disposition, and
reporting with predictable and accurate results. reporting with predictable and accurate results.
The enclosed proposal is not intended to introduce mechanisms that The enclosed proposal is not intended to introduce mechanisms that
provide elevated delivery privilege of authenticated email. The provide elevated delivery privilege of authenticated email. The
proposal presents a mechanism for policy distribution that enables a proposal presents a mechanism for policy distribution that enables a
continuum of increasingly strict handling of messages that fail continuum of increasingly strict handling of messages that fail
multiple authentication checks, from no action, through silent multiple authentication checks, from no action, through silent
reporting, up to message rejection. 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.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 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 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 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 1. License
As of the date shown at the top right of this page, the Contributors As of the date shown at the top right of this page, the Contributors
have made this Specification available under the Open Web Foundation have made this Specification available under the Open Web Foundation
Contributor License Agreement Version 1.0, which is available at: Contributor License Agreement Version 1.0, which is available at:
http://www.dmarc.org/cla.html http://www.dmarc.org/cla.html
You can review the signed copies of the Open Web Foundation You can review the signed copies of the Open Web Foundation
Contributor License Agreement Version 1.0 for this Specification at: 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 ANY KIND WITH RESPECT TO THIS SPECIFICATION OR ITS GOVERNING
AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING
NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2. Introduction 2. Introduction
For years, various receivers have tried to protect senders who are For years, various receivers have tried to protect senders who are
known to authenticate their outbound email from phishing by using known to authenticate their outbound email from phishing by using
[DKIM] and/or [SPF] results to detect and block unauthorized email. [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 The fundamental idea behind these approaches is that if a sender
authenticates all legitimate outbound mail using the authentication authenticates all legitimate outbound mail using the authentication
protocols SPF and DKIM, then receivers can quarantine or reject protocols SPF and DKIM, then receivers can quarantine or reject
unauthenticated mail purporting to be from that sender. Over time, unauthenticated mail purporting to be from that sender. Over time,
one-on-one relationships were established between select senders and one-on-one relationships were established between select senders and
receivers with privately communicated means to assert policy and receivers with privately communicated means to assert policy and
receive message traffic and authentication disposition reporting. receive message traffic and authentication disposition reporting.
Although these ad hoc practices have been generally successful, they Although these ad hoc practices have been generally successful, they
require significant manual coordination between parties. require significant manual coordination between parties.
This memo defines Domain-based Message Authentication, Reporting and This memo defines Domain-based Message Authentication, Reporting and
Compliance (DMARC), a mechanism by which email operators leverage Compliance (DMARC), a mechanism by which email operators leverage
existing authentication and policy advertisement technologies to existing authentication and policy advertisement technologies to
enable both message-stream feedback and enforcement of policies enable both message-stream feedback and enforcement of policies
against unauthenticated email. against unauthenticated email.
DMARC encourages senders and receivers to collaborate by monitoring 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 3.4. Detailed Requirements
DMARC's specification requirements, in detail: DMARC's specification requirements, in detail:
1. The RFC5322.From domain is the identifier used for all message 1. The RFC5322.From domain is the identifier used for all message
validation operations, as it is the single identifier in the validation operations, as it is the single identifier in the
message likely to be visible to the user. message likely to be visible to the user.
2. Senders can specify a "strict" or "relaxed" mode in terms of 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 mode, all identifiers from authentication systems upon which
DMARC is predicated must match the RFC5322.From domain. In DMARC is predicated must match the RFC5322.From domain. In
"relaxed" mode, the organizational domains (see Section 4) must "relaxed" mode, the organizational domains (see Section 4) must
match. The "relaxed" mode shall be the default. match. The "relaxed" mode shall be the default.
3. A sender's policy must be discoverable via DNS queries. 3. A sender's policy must be discoverable via DNS queries.
4. It must be possible to specify reject or quarantine policies 4. It must be possible to specify reject or quarantine policies
when none of the underlying authentication systems succeed. 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. the organizational domain itself.
7. Message disposition requests via DMARC override those requested 7. Message disposition requests via DMARC override those requested
by any other public mechanism. by any other public mechanism.
8. Senders should be able to specify a percentage of their messages 8. Senders should be able to specify a percentage of their messages
to which their policies should be applied, with the rest to which their policies should be applied, with the rest
unaffected, in order to experiment and to understand and unaffected, in order to experiment and to understand and
minimize deployment risk. 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.
10. Reporting configuration in DMARC should override any such
options specified by DKIM or SPF or extensions to them. options specified by DKIM or SPF or extensions to them.
11. The sender must be able to to specify independent reporting 10. The sender must be able to to specify independent reporting
addresses for failed message reporting and aggregate data feeds. addresses for failed message reporting and aggregate data feeds.
12. The aggregate report must contain enough information for the 11. The aggregate report must contain enough information for the
report consumer to re-calculate DMARC disposition based on the report consumer to re-calculate DMARC disposition based on the
published policy, message dispositon, and SPF, DKIM, and published policy, message dispositon, and SPF, DKIM, and
identifier alignment results. identifier alignment results.
13. The aggregate report must still contain data for each sender 12. The aggregate report must still contain data for each sender
subdomain separately from mail from the sender's organizational subdomain separately from mail from the sender's organizational
domain, even if no subdomain policy is applied. The report must domain, even if no subdomain policy is applied. The report must
indicate any policy applied to subdomains. indicate any policy applied to subdomains.
14. It must be possible to specify a minimum reporting interval. 13. It must be possible to specify a minimum reporting interval.
Reporting sites should make a best effort to accommodate that Reporting sites should make a best effort to accommodate that
request. request.
15. The sender can specify a time-to-live for policy records. 14. The sender can specify a time-to-live for policy records.
16. The sender can indicate which domains under its control never 15. The sender can indicate which domains under its control never
send email, either by omitting them from the DNS entirely or by send email, either by omitting them from the DNS entirely or by
declaring specific use of DKIM and SPF that no email will ever declaring specific use of DKIM and SPF that no email will ever
fulfill. fulfill.
17. The sending and receiving domains should be included in the 16. The sending and receiving domains should be included in the
aggregate report. aggregate report.
18. The policy request and the one applied (if different) should be 17. The policy request and the one applied (if different) should be
included in the aggregate report. included in the aggregate report.
19. The number of successful authentications should be included in 18. The number of successful authentications should be included in
the aggregate report. the aggregate report.
20. The report should be generated based on all messages even if 19. The report should be generated based on all messages even if
filtering agents such as anti-virus or anti-spam engines filtering agents such as anti-virus or anti-spam engines
ultimately block delivery. ultimately block delivery.
21. For real-time reporting of failed messages, including a [URI] to 20. For real-time reporting of failed messages, including a [URI] to
identify phishing sites and diagnostics on DKIM and SPF failures identify phishing sites and diagnostics on DKIM and SPF failures
will be recommended. will be recommended.
22. Static conformance requirements shall be documented to enable 21. 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.) will be done in a separate Best Current Practices document.)
23. Aggregate reports should communicate DMARC message disposition 22. Aggregate reports should communicate DMARC message disposition
regardless of any subsequent action that affects message regardless of any subsequent action that affects message
disposition or delivery. disposition or delivery.
24. The mechanism overall should be flexible enough to swap in or 23. The mechanism overall should be flexible enough to swap in or
out any authentication technology. out any authentication technology.
Tags throughout the specification part of this document indicate Tags throughout the specification part of this document indicate
conformance to the above requirements. For example "{R1}" indicates conformance to the above requirements. For example "{R1}" indicates
a component of the protocol that addresses requirement #1 in the list a component of the protocol that addresses requirement #1 in the list
above. above.
3.5. Out Of Scope 3.5. Out Of Scope
Items specifically not in scope for this work include: 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 to some third party. This memo does not address the distinctions
among such roles; the reader is encouraged to become familiar with among such roles; the reader is encouraged to become familiar with
that material before continuing. that material before continuing.
The following terms are also used: The following terms are also used:
Authenticated Identifiers: Authentication technologies allow Authenticated Identifiers: Authentication technologies allow
evaluation agents to associate email with domain-level evaluation agents to associate email with domain-level
identifiers. Domain-level identifiers that are established using identifiers. Domain-level identifiers that are established using
authentication technologies are referred to as "Authenticated 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 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 (MUA), looks similar to, or can lead users to believe the domain
is associated with, another name. For instance, "vendor5.example" is associated with, another name. For instance, "vendor5.example"
would be a Cousin Domain of "vendors.example". This is a common would be a Cousin Domain of "vendors.example". This is a common
tool in a homograph attack. tool in a homograph attack.
Domain Owner: The entity or organization that "owns" a DNS domain. Domain Owner: The entity or organization that "owns" a DNS domain.
The term "owns" here indicates that the entity or organization The term "owns" here indicates that the entity or organization
being referenced holds the registration of that DNS domain. 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 label from the subject domain. This new name is the
Organizational Domain. Organizational Domain.
Thus, since "com" is an IANA-registered TLD, a subject domain of Thus, since "com" is an IANA-registered TLD, a subject domain of
"a.b.c.d.example.com" would have an Organizational Domain of "a.b.c.d.example.com" would have an Organizational Domain of
"example.com". "example.com".
The process of determining a suffix is currently a heuristic one. The process of determining a suffix is currently a heuristic one.
No list is guaranteed to be accurate or current. 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 DMARC's filtering component is based on whether or not SPF or DKIM
can provide an authenticated -- and relevant -- identifier for any can provide an authenticated -- and relevant -- identifier for any
given message. Messages that purport to be from a Domain Owner's 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 domain and arrive from servers that are not authorized by SPF and do
not contain an appropriate DKIM signature can be affected by DMARC not contain an appropriate DKIM signature can be affected by DMARC
policies. policies.
DMARC's feedback component involves the collection of information DMARC's feedback component involves the collection of information
pertaining to received messages, in the aggregate, for periodic pertaining to received messages, in the aggregate, for periodic
reporting back to the Domain Owner. The parameters and format for reporting back to the Domain Owner. The parameters and format for
such reports are discussed in later sections of this document. such reports are discussed in later sections of this document.
A DMARC-enabled Mail Receiver might also generate per-message reports A DMARC-enabled Mail Receiver might also generate per-message reports
that contain information related to individual messages which fail 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 It is important to note that the authentication mechanisms employed
by DMARC authenticate only a DNS domain, and do not authenticate the by DMARC authenticate only a DNS domain, and do not authenticate the
local-part of any email address identifier found in a message. 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 Email authentication technologies authenticate various (and
disparate) aspects of an individual message. For example, [DKIM] disparate) aspects of an individual message. For example, [DKIM]
authenticates the domain that affixed a signature to the message, 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 DMARC uses the RFC5322.From domain to tie together Authenticated
Identifiers {R1}. The selection of the RFC5322.From domain as the Identifiers {R1}. The selection of the RFC5322.From domain as the
central identity of the DMARC mechanism is due to the ubiquity of central identity of the DMARC mechanism is due to the ubiquity of
this identity and the behavior of most MUAs to represent the this identity and the behavior of most MUAs to represent the
RFC5322.From field as the originator of the message and to render RFC5322.From field as the originator of the message and to render
some or all of this header's content to end users. some or all of this header's content to end users.
To be considered "in alignment" for the purposes of the DMARC To be considered "in alignment" for the purposes of the DMARC
mechanism, implementors MUST observe the considerations described in mechanism, implementors MUST observe the considerations described in
the following sections. Domain names in this context are to be the following sections. Domain names in this context are to be
compared in a case-insensitive manner, per [DNS-CASE]. 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 DMARC provides the option of applying DKIM in a strict mode or a
relaxed mode {R2}. relaxed mode {R2}.
In relaxed mode, the Organizational Domain of the [DKIM]- In relaxed mode, the Organizational Domain of the [DKIM]-
authenticated signing domain (taken from the value of the "d=" tag in 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 the signature) and that of the RFC5322.From domain must be equal. In
strict mode, only an exact match is considered to produce identifier strict mode, only an exact match is considered to produce identifier
alignment. 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. suffix lists, and therefore cannot be an Organizational Domain.
Identifier alignment is required to prevent abuse by phishers that Identifier alignment is required to prevent abuse by phishers that
send DKIM-signed email using an arbitrary "d=" domain (such as a send DKIM-signed email using an arbitrary "d=" domain (such as a
Cousin Domain) to pass authentication checks. Cousin Domain) to pass authentication checks.
Note that a single email can contain multiple DKIM signatures, Note that a single email can contain multiple DKIM signatures,
raising the possibility of processing multiple signatures in an raising the possibility of processing multiple signatures in an
attempt to establish an "in alignment" result. 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 DMARC provides the option of applying SPF in a strict mode or a
relaxed mode {R2}. 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 For example, if a message passes an SPF check with an
RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
portion of the RFC5322.From field contains "payments@example.com", portion of the RFC5322.From field contains "payments@example.com",
the Authenticated RFC5321.MailFrom domain identifier and the the Authenticated RFC5321.MailFrom domain identifier and the
RFC5322.From domain are considered to be "in alignment" in relaxed RFC5322.From domain are considered to be "in alignment" in relaxed
mode, but not in strict mode. 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 If DMARC is extended to include the use of other authentication
mechanisms, the extensions will need to allow for domain identifier 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. verified.
5. Policy 5. Policy
DMARC policies are published by Domain Owners and applied by Mail DMARC policies are published by Domain Owners and applied by Mail
Receivers. Receivers.
A Domain Owner advertises DMARC participation by adding a DNS TXT A Domain Owner advertises DMARC participation by adding a DNS TXT
record (described in Section 6) {R3, R15, R16} to one or more sending 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 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 Domain Owner DMARC preferences are stored as DNS TXT records in
subdomains named "_dmarc". For example, the Domain Owner of subdomains named "_dmarc". For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at "example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com". Similarly, a Mail Receiver wishing to query "_dmarc.example.com". Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an RFC5322.From domain of 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 "example.com" would issue a TXT query to the DNS for the subdomain of
"_dmarc.example.com". The DNS-located DMARC preference data will "_dmarc.example.com". The DNS-located DMARC preference data will
hereafter be called the "DMARC record". 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 Overrides: DMARC records published at child domains explicitly
override extant parent policy. override extant parent policy.
Efficiency: DNS caching is a common practice, reducing operational Efficiency: DNS caching is a common practice, reducing operational
overhead of a new DNS-based mechanism. overhead of a new DNS-based mechanism.
Per [DNS], a TXT record can comprise several "character-string" Per [DNS], a TXT record can comprise several "character-string"
objects. Where this is the case, the module performing DMARC objects. Where this is the case, the module performing DMARC
evaluation MUST concatenate these strings by joining together the evaluation MUST concatenate these strings by joining together the
objects in order and parsing the result as a single string. objects in order and parsing the result as a single string.
6.1. DMARC URIs 6.1. DMARC URIs
[URI] defines a generic syntax for identifying a resource. The DMARC [URI] defines a generic syntax for identifying a resource. The DMARC
mechanism uses this as the format by which a Domain Owner specifies 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 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 Each URI can have associated with it a maximum report size that may
be sent to it. This is accomplished by appending an exclamation be sent to it. This is accomplished by appending an exclamation
point (ASCII 0x21), followed by a maximum size indication, before a point (ASCII 0x21), followed by a maximum size indication, before a
separating comma or terminating semi-colon. separating comma or terminating semi-colon.
Thus, a DMARC URI is a URI within which any commas or exclamation Thus, a DMARC URI is a URI within which any commas or exclamation
points are percent-encoded per [URI], followed by an OPTIONAL points are percent-encoded per [URI], followed by an OPTIONAL
exclamation point and a maximum size specification, and, if there are exclamation point and a maximum size specification, and, if there are
additional reporting URIs in the list, a comma and the next URI. 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 processed; unknown tags MUST be ignored. To avoid version
compatibility issues, tags added to the DMARC specification SHOULD compatibility issues, tags added to the DMARC specification SHOULD
NOT change the semantics of existing records when processed by NOT change the semantics of existing records when processed by
implementations conforming to prior specifications. implementations conforming to prior specifications.
The following tags are introduced as the initial valid DMARC tags: The following tags are introduced as the initial valid DMARC tags:
adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or
not strict DKIM identifier alignment is required by the Domain not strict DKIM identifier alignment is required by the Domain
Owner. If and only if the value of the string is "s", strict mode 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 aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether or
not strict SPF identifier alignment is required by the Domain not strict SPF identifier alignment is required by the Domain
Owner. If and only if the value of the string is "s", strict mode 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 none: {R5} The Domain Owner requests no specific action be taken
regarding delivery of messages. regarding delivery of messages.
quarantine: {R4} The Domain Owner wishes to have email that fails quarantine: {R4} The Domain Owner wishes to have email that fails
the DMARC mechanism check to be treated by Mail Receivers as the DMARC mechanism check to be treated by Mail Receivers as
suspicious. Depending on the capabilities of the Mail suspicious. Depending on the capabilities of the Mail
Receiver, this can mean "place into spam folder", "scrutinize Receiver, this can mean "place into spam folder", "scrutinize
with additional intensity", and/or "flag as suspicious". with additional intensity", and/or "flag as suspicious".
reject: {R4} The Domain Owner wishes for Mail Receivers to reject reject: {R4} The Domain Owner wishes for Mail Receivers to reject
email that fails the DMARC mechanism check. Rejection SHOULD email that fails the DMARC mechanism check. Rejection SHOULD
occur during the SMTP transaction. See Section 15.8 for some occur during the SMTP transaction. See Section 15.8 for some
discussion of SMTP rejection methods and their implications. discussion of SMTP rejection methods and their implications.
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL;
default is 100). {R8} Percentage of messages from the DNS domain's default is 100). {R8} Percentage of messages from the DNS domain's
mail stream to which the DMARC mechanism is to be applied. mail stream to which the DMARC mechanism is to be applied.
However, this MUST NOT be applied to the DMARC-generated reports, However, this MUST NOT be applied to the DMARC-generated reports,
all of which must be sent and received unhindered. The purpose of 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 enforcement of the DMARC mechanism. The prospect of "all or
nothing" is recognized as preventing many organizations from 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 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 ri: Interval requested between aggregate reports (plain-text, 32-bit
unsigned integer; OPTIONAL; default 86400). {R14} Indicates a unsigned integer; OPTIONAL; default 86400). {R14} Indicates a
request to Receivers to generate aggregate reports separated by no request to Receivers to generate aggregate reports separated by no
more than the requested number of seconds. DMARC implementations more than the requested number of seconds. DMARC implementations
MUST be able to provide daily reports and SHOULD be able to MUST be able to provide daily reports and SHOULD be able to
provide hourly reports when requested. However, anything other provide hourly reports when requested. However, anything other
than a daily report is understood to be accommodated on a best- than a daily report is understood to be accommodated on a best-
effort basis. 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 list delimiter or an OPTIONAL size limit. Section 8.2 discusses
considerations that apply when the domain name of a URI differs considerations that apply when the domain name of a URI differs
from that of the domain advertising the policy. See Section 15.6 from that of the domain advertising the policy. See Section 15.6
for additional considerations. Any valid URI can be specified. A for additional considerations. Any valid URI can be specified. A
Mail Receiver MUST implement support for a "mailto:" URI, i.e. the Mail Receiver MUST implement support for a "mailto:" URI, i.e. the
ability to send a DMARC report via electronic mail. If not ability to send a DMARC report via electronic mail. If not
provided, Mail Receivers MUST NOT generate aggregate feedback provided, Mail Receivers MUST NOT generate aggregate feedback
reports. URIs not supported by Mail Receivers MUST be ignored. reports. URIs not supported by Mail Receivers MUST be ignored.
The aggregate feedback report format is described in Section 8.3. 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; be reported (comma-separated plain-text list of DMARC URIs;
OPTIONAL). {R11} If present, the Domain Owner is requesting Mail 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; sp: {R6} Requested Mail Receiver policy for subdomains (plain-text;
OPTIONAL). Indicates the policy to be enacted by the Receiver at OPTIONAL). Indicates the policy to be enacted by the Receiver at
the request of the Domain Owner. It applies only to subdomains of the request of the Domain Owner. It applies only to subdomains of
the domain queried and not to the domain itself. Its syntax is the domain queried and not to the domain itself. Its syntax is
identical to that of the "p" tag defined above. If absent, the identical to that of the "p" tag defined above. If absent, the
policy specified by the "p" tag MUST be applied for subdomains. policy specified by the "p" tag MUST be applied for subdomains.
v: Version (plain-text; REQUIRED). Identifies the record retrieved v: Version (plain-text; REQUIRED). Identifies the record retrieved
as a DMARC record. It MUST have the value of "DMARC1". The value 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, 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 the entire retrieved record MUST be ignored. It MUST be the first
tag in the list. 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 6.3. Formal Definition
The formal definition of the DMARC format using [ABNF] is as follows: The formal definition of the DMARC format using [ABNF] is as follows:
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; "URI" is imported from [URI]; commas (ASCII 0x2c) ; "URI" is imported from [URI]; commas (ASCII 0x2c)
; and exclamation points (ASCII 0x21) MUST be encoded ; and exclamation points (ASCII 0x21) MUST be encoded
dmarc-record = dmarc-version dmarc-sep dmarc-record = dmarc-version dmarc-sep
dmarc-request [dmarc-request]
[dmarc-sep dmarc-srequest] [dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri] [dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi] [dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim] [dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf] [dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval] [dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-rfmt] [dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent] [dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and ; components other than dmarc-version and
; dmarc-request may appear in any order ; 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" ) "quarantine" / "reject" )
dmarc-srequest = %x73.70 *WSP "=" *WSP ( "none" / dmarc-srequest = "sp" *WSP "=" *WSP ( "none" /
"quarantine" / "reject" ) "quarantine" / "reject" )
dmarc-auri = %x72.75.61 *WSP "=" *WSP dmarc-auri = "rua" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri) 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-uri *(*WSP "," *WSP dmarc-uri)
dmarc-rfmt = %x72.66 *WSP "=" *WSP dmarc-rfmt = "rf" *WSP "=" *WSP
( "afrf" / "iodef" ) ( "afrf" / "iodef" )
dmarc-percent = %x70.63.74 *WSP "=" *WSP dmarc-percent = "pct" *WSP "=" *WSP
1*3DIGIT 1*3DIGIT
dmarc-adkim = %x61.64.6b.69.6d *WSP "=" *WSP dmarc-adkim = "adkim" *WSP "=" *WSP
( "r" / "s" ) ( "r" / "s" )
dmarc-aspf = %x61.73.70.66 *WSP "=" *WSP dmarc-aspf = "aspf" *WSP "=" *WSP
( "r" / "s" ) ( "r" / "s" )
A size limitation in a dmarc-uri, if provided, is interpreted as a 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, count of units followed by an OPTIONAL unit size ("k" for kilobytes,
"m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a "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 7. Policy Enforcement Considerations
Mail Receivers MAY choose to reject or quarantine email even if email Mail Receivers MAY choose to reject or quarantine email even if email
passes the DMARC mechanism check. The DMARC mechanism does not passes the DMARC mechanism check. The DMARC mechanism does not
inform Mail Receivers whether an email stream is "good". Mail inform Mail Receivers whether an email stream is "good". Mail
Receivers are encouraged to maintain anti-abuse technologies to Receivers are encouraged to maintain anti-abuse technologies to
combat the possibility of DMARC-enabled criminal campaigns. combat the possibility of DMARC-enabled criminal campaigns.
Mail Receivers MAY choose to accept email that fails the DMARC Mail Receivers MAY choose to accept email that fails the DMARC
mechanism check even if the Domain Owner has published a "reject" 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 Mail Receivers are not obligated to report reject or quarantine
policy actions in aggregate feedback reports that are not due to policy actions in aggregate feedback reports that are not due to
DMARC policy, but are instead the result of local policy. If local DMARC policy, but are instead the result of local policy. If local
policy information is exposed, abusers can gain insight into the policy information is exposed, abusers can gain insight into the
effectiveness and delivery rates of spam campaigns. 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) 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 8. DMARC Feedback
The DMARC mechanism requires highly accurate authentication The DMARC mechanism requires highly accurate authentication
deployments to allow Mail Receivers to safely and scalably enforce deployments to allow Mail Receivers to safely and scalably enforce
Domain Owner policies. Providing Domain Owners with visibility into Domain Owner policies. Providing Domain Owners with visibility into
how Mail Receivers implement and enforce the DMARC mechanism in the how Mail Receivers implement and enforce the DMARC mechanism in the
form of feedback is critical to establishing and maintaining accurate form of feedback is critical to establishing and maintaining accurate
authentication deployments. 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 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 domain at which that record was discovered is not identical to the
host part of the authority component of a [URI] specified in the host part of the authority component of a [URI] specified in the
"rua" or "ruf" tag, the following verification steps SHOULD be taken: "rua" or "ruf" tag, the following verification steps SHOULD be taken:
1. Extract the host portion of the authority component of the URI. 1. Extract the host portion of the authority component of the URI.
Call this the "destination host". Call this the "destination host".
2. Prepend the string "_report._dmarc". 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 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 result of this request is a temporary DNS error of some kind
(e.g., a timeout), the Mail Receiver MAY elect to temporarily (e.g., a timeout), the Mail Receiver MAY elect to temporarily
fail the delivery so the verification test can be repeated later. 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 corresponding value extracted from the domain's DMARC policy
record with the one found in this record. This permits the record with the one found in this record. This permits the
report receiver to override the report destination. However, to report receiver to override the report destination. However, to
prevent loops or indirect abuse, the overriding URI MUST use the prevent loops or indirect abuse, the overriding URI MUST use the
same destination host from the first step. same destination host from the first step.
For example, if a DMARC policy query for "blue.example.com" contained For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the host extracted from the "rua=mailto:reports@red.example.net", the host extracted from the
latter ("red.example.net") does not match "blue.example.com", so this latter ("red.example.net") does not match "blue.example.com", so this
procedure is enacted. A TXT query for 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 o The policy requested by the Domain Owner and the policy actually
applied (if different) {R18} applied (if different) {R18}
o The number of successful authentications {R19} o The number of successful authentications {R19}
o The counts of messages based on all messages received even if o The counts of messages based on all messages received even if
their delivery is ultimately blocked by other filtering agents their delivery is ultimately blocked by other filtering agents
{R20} {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 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] 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). its default).
These reports SHOULD include the "call-to-action" URI(s) from inside These reports SHOULD include the "call-to-action" URI(s) from inside
messages that failed to authenticate. {R21} messages that failed to authenticate. {R21}
9. Policy Discovery 9. Policy Discovery
As stated above, the DMARC mechanism utilizes DNS TXT records to As stated above, the DMARC mechanism utilizes DNS TXT records to
advertise policy. Policy discovery is accomplished similar to the advertise policy. Policy discovery is accomplished similar to the
way SPF records are discovered. Important differences are discussed 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 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 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 to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC
mechanism to the message. mechanism to the message.
If the RFC5322.From domain does not exist in the DNS, Mail Receivers If the RFC5322.From domain does not exist in the DNS, Mail Receivers
SHOULD direct the receiving SMTP server to reject the message {R9}. SHOULD direct the receiving SMTP server to reject the message {R9}.
The choice of mechanism for such rejection and the implications of The choice of mechanism for such rejection and the implications of
those choices are discussed in Section 11 and Section 15.8. 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 10. Domain Owner Actions
To implement the DMARC mechanism, Domain Owners perform the actions To implement the DMARC mechanism, Domain Owners perform the actions
enumerated in this section. For a trial operation, a Domain Owner enumerated in this section. For a trial operation, a Domain Owner
might at first deploy DMARC to cover only a subdomain. might at first deploy DMARC to cover only a subdomain.
1. Deploy authentication technologies [DKIM] (see also 1. Deploy authentication technologies [DKIM] (see also
[DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF]. [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and [SPF].
2. Align identifiers; i.e., audit internal systems so that mail 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 Therefore, Domain Owners SHOULD include "mailto" URIs at the end of
the lists of URIs they publish. the lists of URIs they publish.
11. Mail Receiver Actions 11. Mail Receiver Actions
This section describes receiver actions in the DMARC environment. This section describes receiver actions in the DMARC environment.
11.1. Extract Author Domain 11.1. Extract Author Domain
The domain in the RFC5322.From field is extracted as the domain to be 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 A message bearing multiple RFC5322.From identifiers is ambiguous
under DMARC. This includes messages with multiple RFC5322.From under DMARC. This includes messages with multiple RFC5322.From
fields (which is also forbidden under [MAIL]) and a message with a 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 11.2. Determine Handling Policy
To arrive at a policy disposition for an individual message, Mail To arrive at a policy disposition for an individual message, Mail
Receivers MUST perform the following actions or their semantic Receivers MUST perform the following actions or their semantic
equivalents. The first four steps MAY be done in parallel, whereas equivalents. The first four steps MAY be done in parallel, whereas
steps 5 and 6 require input from previous steps. steps 5 and 6 require input from previous steps.
The steps are as follows: 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 2. Query the DNS for a DMARC policy record. Continue if one is
found, or abort DMARC evaluation otherwise. See Section 9 for found, or abort DMARC evaluation otherwise. See Section 9 for
details. details.
3. Perform DKIM signature verification checks. A single email may 3. Perform DKIM signature verification checks. A single email may
contain multiple DKIM signatures. The results of this step are contain multiple DKIM signatures. The results of this step are
passed to the remainder of the algorithm and MUST include the passed to the remainder of the algorithm and MUST include the
value of the "d=" tag from all DKIM signatures that successfully value of the "d=" tag from all DKIM signatures that successfully
validated. validated.
4. Perform SPF validation checks. The results of this step are 4. Perform SPF validation checks. The results of this step are
passed to the remainder of the algorithm and MUST include the 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. a "pass" result.
5. Conduct identifier alignment checks. With authentication checks 5. Conduct identifier alignment checks. With authentication checks
and policy discovery performed, the Mail Receiver checks if and policy discovery performed, the Mail Receiver checks if
Authenticated Identifiers fall into alignment as decribed in Authenticated Identifiers fall into alignment as decribed in
Section 4. If one or more of the Authenticated Identifiers align Section 4. If one or more of the Authenticated Identifiers align
with the RFC5322.From domain, the message is considered to pass with the RFC5322.From domain, the message is considered to pass
the DMARC mechanism check. All other conditions (authentication the DMARC mechanism check. All other conditions (authentication
failures, identifier mismatches) are considered to be DMARC failures, identifier mismatches) are considered to be DMARC
mechanism check failures. 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 6. Apply policy. Emails that fail the DMARC mechanism check are
disposed of in accordance with the discovered DMARC policy of the disposed of in accordance with the discovered DMARC policy of the
Domain Owner. See Section 6.2 for details. Domain Owner. See Section 6.2 for details.
Heuristics applied in the absence of use by a Domain Owner of either 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 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 the case that the Domain Owner wishes a Message Receiver not to
consider the results of that underlying authentication protocol at consider the results of that underlying authentication protocol at
all. 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 11.3. Message Sampling
Attention must be paid to the possible presence of the "pct" tag in 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 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 MUST NOT enact the requested policy ("p" tag or "sp" tag") on more
than the stated percent of the totality of affected messages. than the stated percent of the totality of affected messages.
However, regardless of whether or not the "pct" tag is present, the However, regardless of whether or not the "pct" tag is present, the
Mail Receiver MUST include all relevant message data in any reports Mail Receiver MUST include all relevant message data in any reports
produced. produced.
skipping to change at page 31, line 46 skipping to change at page 37, line 25
12.2. Transport 12.2. Transport
Where the URI specified in an "rua" tag does not specify otherwise, a Where the URI specified in an "rua" tag does not specify otherwise, a
Mail Receiver generating a feedback report SHOULD apply a secure Mail Receiver generating a feedback report SHOULD apply a secure
transport mechanism. transport mechanism.
The Mail Receiver, after preparing a report, MUST evaluate the The Mail Receiver, after preparing a report, MUST evaluate the
provided reporting URIs in the order given. Any reporting URI that provided reporting URIs in the order given. Any reporting URI that
included a size limitation exceeded by the generated report (after included a size limitation exceeded by the generated report (after
compression and after any encoding required by the particular 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 If transport is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers 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 to a service that is unreachable, or all provided URIs specify size
limits exceeded by the generated record), the Mail Receiver SHOULD limits exceeded by the generated record), the Mail Receiver SHOULD
send a short report (see Section 12.2.4) indicating that a report is 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 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. data and try again later, or MAY discard data that could not be sent.
12.2.1. Email 12.2.1. Email
In the case of a "mailto" URI, the Mail Receiver SHOULD communicate In the case of a "mailto" URI, the Mail Receiver SHOULD communicate
reports using the method described in [STARTTLS]. reports using the method described in [STARTTLS].
The message generated by the Mail Receiver must be a [MIME] formatted The message generated by the Mail Receiver must be a [MIME] formatted
[MAIL] message. The aggregate report itself MUST be included in one [MAIL] message. The aggregate report itself MUST be included in one
of the parts of the message. A human-readable portion MAY be of the parts of the message. A human-readable portion MAY be
included as a MIME part (such as a text/plain part). 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/ 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: ABNF:
filename = receiver "!" policy-domain "!" begin-timestamp "!" filename = receiver "!" policy-domain "!" begin-timestamp "!"
end-timestamp "." extension end-timestamp [ "!" unique-id ] "." extension
unique-id = token
; "token" is imported from [MIME]
receiver = domain receiver = domain
; imported from [MAIL] ; imported from [MAIL]
policy-domain = domain policy-domain = domain
begin-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained ; indicating start of the time range contained
; in the report ; in the report
end-timestamp = 1*DIGIT end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; indicating end of the time range contained
; in the report ; 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". 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 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 The RFC5322.Subject field for individual report submissions SHOULD
conform to the following ABNF: conform to the following ABNF:
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC6376 domain-name 1*FWS ; from RFC6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS 1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" %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 This transport mechanism potentially encounters a problem when
feedback data size exceeds maximum allowable attachment sizes for feedback data size exceeds maximum allowable attachment sizes for
either the generator or the consumer. See Section 12.2.4 for further either the generator or the consumer. See Section 12.2.4 for further
discussion. discussion.
12.2.2. HTTP 12.2.2. HTTP
Where an "http" or "https" method is requested in a Domain Owner's Where an "http" or "https" method is requested in a Domain Owner's
URI list, the Mail Receiver MAY encode the data using the 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 The header portion of the POST or PUT request SHOULD contain a
Subject field as described in Section 12.2.1. 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 12.2.3. Other Methods
Other registered URI schemes may be explicitly supported in later Other registered URI schemes may be explicitly supported in later
versions. versions.
12.2.4. Error Reports 12.2.4. Error Reports
When a Mail Receiver is unable to complete delivery of a report via 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 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 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
| Tag Name | Defined | Status | Description | | Tag Name | Defined | Status | Description |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| adkim | [THIS MEMO] | current | DKIM alignment mode | | adkim | [THIS MEMO] | current | DKIM alignment mode |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| aspf | [THIS MEMO] | current | SPF alignment mode | | aspf | [THIS MEMO] | current | SPF alignment mode |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| pct | [THIS MEMO] | current | Sampling rate | | pct | [THIS MEMO] | current | Sampling rate |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| p | [THIS MEMO] | current | Requested handling policy | | p | [THIS MEMO] | current | Requested handling policy |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| rf | [THIS MEMO] | current | Forensic reporting format(s) | | rf | [THIS MEMO] | current | Failure reporting format(s) |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| ri | [THIS MEMO] | current | Aggregate Reporting interval | | ri | [THIS MEMO] | current | Aggregate Reporting interval |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| rua | [THIS MEMO] | current | Reporting URI(s) for | | rua | [THIS MEMO] | current | Reporting URI(s) for |
| | | | aggregate data | | | | | aggregate data |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| ruf | [THIS MEMO] | current | Reporting URI(s) for | | ruf | [THIS MEMO] | current | Reporting URI(s) for |
| | | | forensic data | | | | | failure data |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| sp | [THIS MEMO] | current | Requested handling policy | | sp | [THIS MEMO] | current | Requested handling policy |
| | | | for subdomains | | | | | for subdomains |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
| v | [THIS MEMO] | current | Specification version | | v | [THIS MEMO] | current | Specification version |
+----------+-------------+---------+------------------------------+ +----------+-------------+---------+------------------------------+
14.4. DMARC Report Format Registry 14.4. DMARC Report Format Registry
Names of DMARC forensic reporting formats must be registered with Names of DMARC failure reporting formats must be registered with
IANA. New entries are assigned only for values that have been IANA. New entries are assigned only for values that have been
documented in a published RFC that has had IETF Review, per documented in a published RFC that has had IETF Review, per
[IANA-CONSIDERATIONS]. Each registration must include the tag name, [IANA-CONSIDERATIONS]. Each registration must include the tag name,
the specification that defines it, a brief description, and its the specification that defines it, a brief description, and its
status which must be one of "current", "experimental" or "historic". status which must be one of "current", "experimental" or "historic".
The initial set of entries in this registry is as follows: The initial set of entries in this registry is as follows:
+--------+-------------+---------+-----------------------------+ +--------+-------------+---------+-----------------------------+
| Format | Defined | Status | Description | | Format | Defined | Status | Description |
skipping to change at page 39, line 5 skipping to change at page 44, line 49
reflective of the true originator of the message. reflective of the true originator of the message.
o The focus of email authentication efforts has been to create o The focus of email authentication efforts has been to create
mechanisms by which this field, or at least some field in the mechanisms by which this field, or at least some field in the
message, can be deemed genuine. Thus, this field is not easily message, can be deemed genuine. Thus, this field is not easily
forged within the context of its use with DMARC. forged within the context of its use with DMARC.
o The DMARC mechanism confers no additional privilege to the message o The DMARC mechanism confers no additional privilege to the message
without successful authentication of this identifier. without successful authentication of this identifier.
The absence of a single, properly-formed RFC5322.From field renders
the message invalid. This document prescribes no specific action in
that case, other than to suggest that the message ought to be
disposed of by the Mail Receiver's infrastructure in a safe manner
that recognizes and possibly even highlights the malformation.
15.2. Display Name Attacks 15.2. Display Name Attacks
A common attack in messaging abuse is the presentation of false A common attack in messaging abuse is the presentation of false
information in the "display name" portion of the RFC5322.From field. 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 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 an arbitrary address or domain name, while containing a well-known
name (a person, brand, role, etc.) in the display name, intending to name (a person, brand, role, etc.) in the display name, intending to
fool the end user into believing that the name is used legitimately. fool the end user into believing that the name is used legitimately.
The attack is predicated on the notion that most common Mail User The attack is predicated on the notion that most common Mail User
Agents (MUAs) will show the display name and not the email address Agents (MUAs) will show the display name and not the email address
skipping to change at page 41, line 28 skipping to change at page 47, line 31
domains that are claimed as external recipients. Negative caching domains that are claimed as external recipients. Negative caching
will mitigate this problem, but only to a limited extent, mostly will mitigate this problem, but only to a limited extent, mostly
dependent on the default time-to-live in the domain's SOA record. dependent on the default time-to-live in the domain's SOA record.
Where possible, external reporting is best achieved by having the Where possible, external reporting is best achieved by having the
report be directed to domains that can receive mail and simply having report be directed to domains that can receive mail and simply having
it automatically forwarded to the desired external destination. it automatically forwarded to the desired external destination.
Note that the addresses shown in the "ruf" tag receive more Note that the addresses shown in the "ruf" tag receive more
information that might be considered private data, since it is information that might be considered private data, since it is
possible for actual email content to appear in the forensic reports. possible for actual email content to appear in the failure reports.
The URIs identified there are thus more attractive targets for The URIs identified there are thus more attractive targets for
intrusion attempts than those found in the "rua" tag. Moreover, intrusion attempts than those found in the "rua" tag. Moreover,
attacking the DNS of the subject domain to cause forensic data to be attacking the DNS of the subject domain to cause failure data to be
routed fraudulently to an attacker's systems may be an attractive routed fraudulently to an attacker's systems may be an attractive
prospect. Deployment of DNSSEC is advisable if this is a concern. prospect. Deployment of [DNSSEC] is advisable if this is a concern.
The verification mechanism presented in Section 8.2 is currently not The verification mechanism presented in Section 8.2 is currently not
mandatory ("MUST") but strongly recommended ("SHOULD"). It is mandatory ("MUST") but strongly recommended ("SHOULD"). It is
possible that it would be elevated to a "MUST" by later security possible that it would be elevated to a "MUST" by later security
review. review.
15.7. Feedback Loops 15.7. Feedback Loops
Per [ARF-BCP] and [ARF-AS], it is highly advisable to vet the Per [ARF-BCP] and [ARF-AS], it is highly advisable to vet the
destinations of feedback streams to which Mail Receivers will send destinations of feedback streams to which Mail Receivers will send
skipping to change at page 42, line 11 skipping to change at page 48, line 14
mechanism by which one can request that no more reports be sent in mechanism by which one can request that no more reports be sent in
case some entity becomes the unwitting recipient of undesired data in case some entity becomes the unwitting recipient of undesired data in
high volumes. high volumes.
15.8. Rejecting Messages 15.8. Rejecting Messages
This proposal calls for rejection of a message during the SMTP This proposal calls for rejection of a message during the SMTP
session under certain circumstances. This is typically done in one session under certain circumstances. This is typically done in one
of two ways: of two ways:
o Full rejection, wherein the SMTP server issues a 5xy reply code o Full rejection, wherein the SMTP server issues a 5xy reply code as
(550 SHOULD be used) as an indication to the SMTP client that the an indication to the SMTP client that the transaction failed; the
transaction failed; the SMTP client is then responsible for SMTP client is then responsible for generating notification that
generating notification that delivery failed (see Section 4.2.5 of delivery failed (see Section 4.2.5 of [SMTP]).
[SMTP]).
o A "silent discard", wherein the SMTP server returns a 2xy reply o A "silent discard", wherein the SMTP server returns a 2xy reply
code implying to the client that delivery (or, at least, relay) code implying to the client that delivery (or, at least, relay)
was successfully completed, but then simply discarding the message was successfully completed, but then simply discarding the message
with no further action. with no further action.
Each of these has a cost. For instance, a silent discard may prevent Each of these has a cost. For instance, a silent discard may prevent
"backscatter" (the annoying generation of delivery failure reports, "backscatter" (the annoying generation of delivery failure reports,
which go back to the RFC5321.MailFrom address, about messages that which go back to the RFC5321.MailFrom address, about messages that
were fraudulently generated), but effectively means the SMTP server were fraudulently generated), but effectively means the SMTP server
has to be programmed to give a false result, which can confound has to be programmed to give a false result, which can confound
external debugging efforts. external debugging efforts.
Similarly, the text portion of the SMTP reply may be important to Similarly, the text portion of the SMTP reply may be important to
consider. For example, when rejecting a message, revealing the consider. For example, when rejecting a message, revealing the
reason for the rejection might give an attacker enough information to reason for the rejection might give an attacker enough information to
bypass those efforts on a later attempt, though it might also assist bypass those efforts on a later attempt, though it might also assist
a legitimate client to determine the source of some local issue that a legitimate client to determine the source of some local issue that
caused the rejection. 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 automated sorting of
rejection causes so they can be properly addressed. For example:
550 5.7.1 Email rejected per DMARC policy for example.com
If a Mail Receiver elects to defer delivery due to inability to If a Mail Receiver elects to defer delivery due to inability to
retrieve or apply DMARC policy, this SHOULD be done with a 450 SMTP retrieve or apply DMARC policy, this is best done with a 4xy SMTP
reply code. reply code.
15.9. Capacity Planning 15.9. Capacity Planning
DMARC participants will need to perform capacity planning to support DMARC participants will need to perform capacity planning to support
their implementations. Some factors to consider include: their implementations. Some factors to consider include:
Storage: As Mail Receivers process increasing numbers of messages -- Storage: As Mail Receivers process increasing numbers of messages --
from increasingly disparate sources -- claiming to be from DMARC- from increasingly disparate sources -- claiming to be from DMARC-
enabled domains, additional storage of information must be enabled domains, additional storage of information must be
skipping to change at page 45, line 9 skipping to change at page 51, line 23
For example, an attacker who controls the SPF record for For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an RFC5322.From containing "evil.example.com" can send mail with an RFC5322.From containing
"foo@example.com" that can pass both authentication and the DMARC "foo@example.com" that can pass both authentication and the DMARC
check against "example.com". check against "example.com".
The Organizational Domain administrator should be careful not to cede The Organizational Domain administrator should be careful not to cede
control of sub-domains if this is an issue, and to consider using the control of sub-domains if this is an issue, and to consider using the
"strict" Identifier Alignment option if appropriate. "strict" Identifier Alignment option if appropriate.
15.12. DNS Security
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
to the deployment of DMARC.
DNSSEC-enabled environments should consider the implication of
receiving insecure or bogus DNS replies in the DMARC context.
Operators should understand whether their DMARC implementations will
behave as expected when DNSSEC-secured queries temporarily fail due
to attempted exploit. For example, if lookup of a specific domain's
DMARC record is typically secured using DNSSEC, attention should to
paid to cases and behaviors when secured lookups fail. The operator
may consider configuring their DNSSEC-aware resolver to propagate a
"temporary error" condition to the DMARC mechanism to defer
acceptance of email until DNSSEC resolution can be restored.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[AFRF] Fontana, H., "Authentication Failure Reporting using the [AFRF] Fontana, H., "Authentication Failure Reporting using the
Abuse Report Format", Abuse Report Format", RFC 6591, April 2012.
I-D draft-ietf-marf-authfailure-report, September 2011.
[AFRF-DKIM]
Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651, June 2012.
[AFRF-SPF]
Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, June 2012.
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376, Identified Mail (DKIM) Signatures", RFC 6376,
September 2011. September 2011.
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[DNS-CASE] [DNS-CASE]
Eastlake, D., "Domain Name System (DNS) Case Insensitivity Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006. Clarification", RFC 4343, January 2006.
[GZIP] Levine, J., "The 'application/zlib' and 'application/gzip'
Media Types", RFC 6713, August 2012.
[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2000.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
skipping to change at page 46, line 46 skipping to change at page 53, line 46
[DKIM-DEPLOYMENT] [DKIM-DEPLOYMENT]
Hansen, T., Siegel, E., Crocker, D., and P. Hallam-Baker, Hansen, T., Siegel, E., Crocker, D., and P. Hallam-Baker,
"DomainKeys Identified Mail (DKIM) Development, "DomainKeys Identified Mail (DKIM) Development,
Deployment, and Operations", RFC 5863, May 2010. Deployment, and Operations", RFC 5863, May 2010.
[DKIM-OVERVIEW] [DKIM-OVERVIEW]
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585,
July 2009. July 2009.
[DKIM-THREATS]
Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
January 2003. January 2003.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
[IANA-CONSIDERATIONS] [IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and [ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, May 1997. Functions", RFC 2142, May 1997.
URIs
[1] <http://dmarc.org>
Appendix A. Technology Considerations Appendix A. Technology Considerations
This section documents some design decisions that were made in the This section documents some design decisions that were made in the
development of DMARC. Specifically, addressed here are some development of DMARC. Specifically, addressed here are some
suggestions that were considered but not included in the design. suggestions that were considered but not included in the design.
This text is included to explain why they were considered and not This text is included to explain why they were considered and not
included in this version. included in this version.
A.1. S/MIME A.1. S/MIME
skipping to change at page 47, line 42 skipping to change at page 55, line 6
DMARC is focused on authentication at the domain level (i.e., the DMARC is focused on authentication at the domain level (i.e., the
ADMD taking responsibility for the message), while S/MIME is really ADMD taking responsibility for the message), while S/MIME is really
intended for user-to-user authentication and encryption. This alone intended for user-to-user authentication and encryption. This alone
appears to make it a bad fit for DMARC's goals. appears to make it a bad fit for DMARC's goals.
S/MIME also suffers from the heavyweight problem of Public Key S/MIME also suffers from the heavyweight problem of Public Key
Infrastructure, which means distribution of keys used to verify Infrastructure, which means distribution of keys used to verify
signatures needs to be incorporated. In many instances, this alone signatures needs to be incorporated. In many instances, this alone
is a showstopper. There have been consistent promises that PKI is a showstopper. There have been consistent promises that PKI
usability and deployment will improve, but these have yet to usability and deployment will improve, but these have yet to
materialize. DMARC can revisit this chouice after those barriers are materialize. DMARC can revisit this choice after those barriers are
addressed. addressed.
S/MIME has extensive deployment in specific market segments S/MIME has extensive deployment in specific market segments
(government, for example), but does not enjoy similar widespread (government, for example), but does not enjoy similar widespread
deployment over the general Internet, and this shows no signs of deployment over the general Internet, and this shows no signs of
changing. DKIM and SPF both are deployed widely over the general changing. DKIM and SPF both are deployed widely over the general
Internet and their adoption rates continue to be positive. Internet and their adoption rates continue to be positive.
Finally, experiements have shown that including S/MIME support in the Finally, experiements have shown that including S/MIME support in the
initial version of DMARC would neither cause nor enable a substantial initial version of DMARC would neither cause nor enable a substantial
skipping to change at page 48, line 23 skipping to change at page 55, line 35
Specifically, consider a Domain Owner that has deployed one of the Specifically, consider a Domain Owner that has deployed one of the
technologies, and that technology fails for some messages, but such technologies, and that technology fails for some messages, but such
failures don't cause enforcement action. Deploying DMARC would cause failures don't cause enforcement action. Deploying DMARC would cause
enforcement action for policies other than "none", which would appear enforcement action for policies other than "none", which would appear
to exclude participation by that Domain Owner. to exclude participation by that Domain Owner.
The DMARC development team evaluated the idea of policy exception The DMARC development team evaluated the idea of policy exception
mechanisms on several occasions and invariably concluded that there mechanisms on several occasions and invariably concluded that there
was not a strong enough use case to include them. The specific was not a strong enough use case to include them. The specific
target audience for DMARC does not appear to have concerns about the target audience for DMARC does not appear to have concerns about the
failure modes of one or the other being a barried to DMARC's failure modes of one or the other being a barrier to DMARC's
adoption. adoption.
In the scenario described above, the Domain Owner has a few options: In the scenario described above, the Domain Owner has a few options:
1. Tighten up its infrastructure to minimize the failure modes of 1. Tighten up its infrastructure to minimize the failure modes of
the single deployed technology. the single deployed technology.
2. Deploy the other supported authentication mechanism, to offset 2. Deploy the other supported authentication mechanism, to offset
the failure modes of the first. the failure modes of the first.
skipping to change at page 49, line 37 skipping to change at page 57, line 7
mandatory check of this nature. It was ultimately removed, as the mandatory check of this nature. It was ultimately removed, as the
method's error rate was too high without substantial manual tuning method's error rate was too high without substantial manual tuning
and heuristic work. There are indeed use cases this work needs to and heuristic work. There are indeed use cases this work needs to
address where such a method would return a negative result about a address where such a method would return a negative result about a
domain for which reporting is desired, such as a registered domain domain for which reporting is desired, such as a registered domain
name that never sends legitimate mail and thus has none of these name that never sends legitimate mail and thus has none of these
records present in the DNS. records present in the DNS.
A.5. Issues With ADSP In Operation A.5. Issues With ADSP In Operation
DMARC has been chacarterized as a "super-ADSP" of sorts. DMARC has been characterized as a "super-ADSP" of sorts.
Contributors to DMARC have compiled a list of issues associated with Contributors to DMARC have compiled a list of issues associated with
ADSP, gained from operational experience, that have influenced the ADSP, gained from operational experience, that have influenced the
direction of DMARC: direction of DMARC:
1. ADSP has no support for subdomains, i.e., the ADSP record for 1. ADSP has no support for subdomains, i.e., the ADSP record for
example.com does not explicitly or implicitly apply to example.com does not explicitly or implicitly apply to
subdomain.example.com. If wildcarding is not applied, then subdomain.example.com. If wildcarding is not applied, then
spammers can trivially bypass ADSP by sending from a subdomain spammers can trivially bypass ADSP by sending from a subdomain
with no ADSP record. with no ADSP record.
skipping to change at page 54, line 27 skipping to change at page 61, line 46
"dmarc-feedback@example.com" "dmarc-feedback@example.com"
("rua=mailto:dmarc-feedback@example.com") ("rua=mailto:dmarc-feedback@example.com")
o All messages from this organizational domain are subject to this o All messages from this organizational domain are subject to this
policy (no "pct" tag present, so the default of 100% applies) policy (no "pct" tag present, so the default of 100% applies)
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool: common command-line tool:
% dig +short TXT _dmarc.example.com. % dig +short TXT _dmarc.example.com.
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com" "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
creates an entry like the following in the appropriate zone file creates an entry like the following in the appropriate zone file
(following the conventional zone file format): (following the conventional zone file format):
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; " _dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" ) "rua=mailto:dmarc-feedback@example.com" )
B.2.2. Entire Domain, Monitoring Only, Per-Message Reports B.2.2. Entire Domain, Monitoring Only, Per-Message Reports
The Domain Owner from the previous example has used the aggregate The Domain Owner from the previous example has used the aggregate
reporting to discover some messaging systems that had not yet reporting to discover some messaging systems that had not yet
implemented DKIM correctly, but they are still seeing periodic implemented DKIM correctly, but they are still seeing periodic
authentication failures. In order to diagnose these intermittent authentication failures. In order to diagnose these intermittent
problems they wish to request per-message forensic reports when problems they wish to request per-message failure reports when
authentication failures occur. authentication failures occur.
Not all Receivers will honor such a request, but the Domain Owner Not all Receivers will honor such a request, but the Domain Owner
feels that any reports it does receive will be helpful enough to feels that any reports it does receive will be helpful enough to
justify publishing this record. The default per-message report justify publishing this record. The default per-message report
format ([AFRF]) meets the Domain Owner's needs in this scenario. format ([AFRF]) meets the Domain Owner's needs in this scenario.
The Domain Owner accomplishes this by adding the following to its The Domain Owner accomplishes this by adding the following to its
policy record from Appendix B.2): policy record from Appendix B.2):
o Per-message forensic reports should be sent via email to the o Per-message failure reports should be sent via email to the
address "auth-reports@example.com" address "auth-reports@example.com"
("ruf=mailto:auth-reports@example.com") ("ruf=mailto:auth-reports@example.com")
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool (the output shown would appear on a single common command-line tool (the output shown would appear on a single
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT _dmarc.example.com. % dig +short TXT _dmarc.example.com.
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com\; "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@example.com" ruf=mailto:auth-reports@example.com"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file might create an entry like the following in the appropriate zone file
(following the conventional zone file format): (following the conventional zone file format):
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; " _dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; " "rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com" ) "ruf=mailto:auth-reports@example.com" )
B.2.3. Per-Message Forensic Reports Directed to Third Party B.2.3. Per-Message Failure Reports Directed to Third Party
The Domain Owner from the previous example is maintaining the same The Domain Owner from the previous example is maintaining the same
policy, but now wishes to have a third party receive and process the policy, but now wishes to have a third party receive and process the
per-message forensic reports. Again, not all Receivers will honor per-message failure reports. Again, not all Receivers will honor
this request, but those that do may implement additional checks to this request, but those that do may implement additional checks to
validate that the third party wishes to receive the forensic reports validate that the third party wishes to receive the failure reports
for this domain. for this domain.
The Domain Owner needs to alter its policy record from Appendix B.2.2 The Domain Owner needs to alter its policy record from Appendix B.2.2
as follows: as follows:
o Per message forensic reports should be send via email to the o Per message failure reports should be send via email to the
address "auth-reports@thirdparty.example.net" address "auth-reports@thirdparty.example.net"
("ruf=mailto:auth-reports@thirdparty.example.net") ("ruf=mailto:auth-reports@thirdparty.example.net")
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool (the output shown would appear on a single common command-line tool (the output shown would appear on a single
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT _dmarc.example.com. % dig +short TXT _dmarc.example.com.
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback@example.com\; "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
ruf=mailto:auth-reports@thirdparty.example.net" ruf=mailto:auth-reports@thirdparty.example.net"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file might create an entry like the following in the appropriate zone file
(following the conventional zone file format): (following the conventional zone file format):
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; " _dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; " "rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@thirdparty.example.net" ) "ruf=mailto:auth-reports@thirdparty.example.net" )
Because the address used in the "ruf" tag is outside the Because the address used in the "ruf" tag is outside the
Organizational Domain in whichthat this record is published, Organizational Domain in which this record is published, conforming
conforming Receivers will implement additional checks as described in Receivers will implement additional checks as described in
Section 8.2 of this document. In order to pass these additional Section 8.2 of this document. In order to pass these additional
checks, the third party will need to publish an additional DNS record checks, the third party will need to publish an additional DNS record
as follows: as follows:
o Given the DMARC record published by the Domain Owner at o Given the DMARC record published by the Domain Owner at
"_dmarc.example.com", the DNS administrator for the third party "_dmarc.example.com", the DNS administrator for the third party
will need to publish a TXT resource record at will need to publish a TXT resource record at
"example.com._report._dmarc.thirdparty.example.net" with the value "example.com._report._dmarc.thirdparty.example.net" with the value
"v=DMARC1". "v=DMARC1".
skipping to change at page 56, line 40 skipping to change at page 64, line 15
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT example.com._report._dmarc.thirdparty.example.net % dig +short TXT example.com._report._dmarc.thirdparty.example.net
"v=DMARC1" "v=DMARC1"
To publish such a record, the DNS administrator for example.net might To publish such a record, the DNS administrator for example.net might
create an entry like the following in the appropriate zone file create an entry like the following in the appropriate zone file
(following the conventional zone file format): (following the conventional zone file format):
; zone file for thirdparty.example.net ; zone file for thirdparty.example.net
; Accept DMARC forensic reports on behalf of example.com ; Accept DMARC failure reports on behalf of example.com
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 8.2 Intermediaries and other third parties should refer to Section 8.2
for the full details of this mechanism. for the full details of this mechanism.
B.2.4. Sub-Domain, Sampling, and Multiple Aggregate Report URIs B.2.4. Sub-Domain, Sampling, and Multiple Aggregate Report URIs
The Domain Owner has implemented SPF and DKIM in a sub-domain used The Domain Owner has implemented SPF and DKIM in a sub-domain used
for pre-production testing of messaging services. It now wishes to for pre-production testing of messaging services. It now wishes to
request that participating receivers act to reject messages from this request that participating receivers act to reject messages from this
sub-domain that fail to authenticate. sub-domain that fail to authenticate.
As a first step it will ask that a portion (1/4 in this example) of As a first step it will ask that a portion (1/4 in this example) of
failing messages be quarantined, enabling examination of messages failing messages be quarantined, enabling examination of messages
sent to mailboxes hosted by participating receivers. Aggregate sent to mailboxes hosted by participating receivers. Aggregate
feedback reports will be sent to a mailbox within the Organizational feedback reports will be sent to a mailbox within the Organizational
Domain, and to a mailbox at a third party selected and authorized to Domain, and to a mailbox at a third party selected and authorized to
receive same by the Domain Owner. 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 The Domain Owner will accomplish this by constructing a policy record
indicating that: indicating that:
o The version of DMARC being used is "DMARC1" ("v=DMARC1") o The version of DMARC being used is "DMARC1" ("v=DMARC1")
o It is applied only to this sub-domain (record is published at o It is applied only to this sub-domain (record is published at
"_dmarc.test.example.com" and not "_dmarc.example.com") "_dmarc.test.example.com" and not "_dmarc.example.com")
o Receivers should quarantine messages from this organizational o Receivers should quarantine messages from this organizational
domain that fail to authenticate ("p=quarantine") domain that fail to authenticate ("p=quarantine")
o Aggregate feedback reports should be sent via email to the o Aggregate feedback reports should be sent via email to the
addresses "dmarc-feedback@example.com" and addresses "dmarc-feedback@example.com" and
"example-tld-test@thirdparty.example.net" ("rua=mailto:dmarc- "example-tld-test@thirdparty.example.net", with the latter
feedback@example.com,mailto:tld-test@thirdparty.example.net") subjected to a maximum size limit ("rua=mailto:dmarc-feedback@
example.com,mailto:tld-test@thirdparty.example.net!10m")
o 25% of messages from this Organizational Domain are subject to o 25% of messages from this Organizational Domain are subject to
action based on this policy ("pct=25") action based on this policy ("pct=25")
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool (the output shown would appear on a single common command-line tool (the output shown would appear on a single
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT _dmarc.test.example.com % dig +short TXT _dmarc.test.example.com
"v=DMARC1\; p=quarantine\; rua=mailto:dmarc-feedback@example.com, "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
mailto:tld-test@thirdparty.example.net\; pct=25" mailto:tld-test@thirdparty.example.net!10m; pct=25"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone might create an entry like the following in the appropriate zone
file: file:
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; " _dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com," "rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net; " "mailto:tld-test@thirdparty.example.net!10m; "
"pct=25" ) "pct=25" )
B.2.5. Third Party Sender and Identifier Alignment B.2.5. Third Party Sender and Identifier Alignment
The Domain Owner only uses the top-level domain for email, and uses a The Domain Owner only uses the top-level domain for email, and uses a
third-party sender for some marketing message traffic. It has third-party sender for some marketing message traffic. It has
implemented SPF and DKIM across its in-house infrastructure and implemented SPF and DKIM across its in-house infrastructure and
required the third-party to do the same. A monitoring period has required the third-party to do the same. A monitoring period has
shown that the Domain Owner and the third-party sender are both shown that the Domain Owner and the third-party sender are both
executing well with respect to email authentication measures. executing well with respect to email authentication measures.
skipping to change at page 58, line 50 skipping to change at page 66, line 25
o Aggregate feedback reports should be sent via email to the address o Aggregate feedback reports should be sent via email to the address
"dmarc-feedback@example.com" "dmarc-feedback@example.com"
("rua=mailto:dmarc-feedback@example.com") ("rua=mailto:dmarc-feedback@example.com")
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool (the output shown would appear on a single common command-line tool (the output shown would appear on a single
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT _dmarc.example.com % dig +short TXT _dmarc.example.com
"v=DMARC1\; p=reject\; adkim=s\; aspf=r\; "v=DMARC1; p=reject; adkim=s; aspf=r;
rua=mailto:dmarc-feedback@example.com" rua=mailto:dmarc-feedback@example.com"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone might create an entry like the following in the appropriate zone
file: file:
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=reject; adkim=s; aspf=r; " _dmarc IN TXT ( "v=DMARC1; p=reject; adkim=s; aspf=r; "
"rua=mailto:dmarc-feedback@example.com" ) "rua=mailto:dmarc-feedback@example.com" )
skipping to change at page 60, line 8 skipping to change at page 67, line 31
o Aggregate reports should be sent via email to the addresses o Aggregate reports should be sent via email to the addresses
"dmarc-feedback@example.com" and "dmarc-feedback@example.com" and
"customer-analysis@thirdparty.example.net" ("rua=mailto:dmarc- "customer-analysis@thirdparty.example.net" ("rua=mailto:dmarc-
feedback@example.com,mailto:customer-data@thirdparty.example.net") feedback@example.com,mailto:customer-data@thirdparty.example.net")
The DMARC policy record might look like this when retrieved using a The DMARC policy record might look like this when retrieved using a
common command-line tool (the output shown would appear on a single common command-line tool (the output shown would appear on a single
line, but is wrapped here for publication): line, but is wrapped here for publication):
% dig +short TXT _dmarc.example.com % dig +short TXT _dmarc.example.com
"v=DMARC1\; p=quarantine\; sp=reject\; ri=14400\; "v=DMARC1; p=quarantine; sp=reject; ri=14400;
rua=mailto:dmarc-feedback@example.com, rua=mailto:dmarc-feedback@example.com,
mailto:customer-data@thirdparty.example.net" mailto:customer-data@thirdparty.example.net"
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone might create an entry like the following in the appropriate zone
file: file:
; DMARC record for the domain example.com ; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; sp=reject; " _dmarc IN TXT ( "v=DMARC1; p=quarantine; sp=reject; "
"rua=mailto:dmarc-feedback@example.com," "rua=mailto:dmarc-feedback@example.com,"
skipping to change at page 61, line 32 skipping to change at page 69, line 7
the Mail Receiver applies the DMARC-record-specified policy. the Mail Receiver applies the DMARC-record-specified policy.
However, before this action is taken, the Mail Receiver can consult However, before this action is taken, the Mail Receiver can consult
external information to override the Domain Owner's policy. For external information to override the Domain Owner's policy. For
example, if the Mail Receiver knows that this particular email came example, if the Mail Receiver knows that this particular email came
from a known and trusted forwarder (that happens to break both SPF from a known and trusted forwarder (that happens to break both SPF
and DKIM), then the Mail Receiver may choose to ignore the Domain and DKIM), then the Mail Receiver may choose to ignore the Domain
Owner's policy. Owner's policy.
The Mail Receiver is now ready to reply to the DATA command. If the 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 DMARC check yields that the message is to be rejected, then the Mail
Receiver replies with a 550 code to inform the sender of failure. If Receiver replies with a 5xy code to inform the sender of failure. If
the DMARC check cannot be resolved due to transient network errors, the DMARC check cannot be resolved due to transient network errors,
then the Mail Receiver replies with a 450 code to inform the sender 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 as to the need to reattempt delivery later. If the DMARC check
yields a passing message, then the Mail Receiver continues on with yields a passing message, then the Mail Receiver continues on with
email processing, perhaps using the result of the DMARC check as an email processing, perhaps using the result of the DMARC check as an
input to additional processing modules such as a domain reputation input to additional processing modules such as a domain reputation
query. query.
Before exiting DMARC-specific processing, the Mail Receiver checks to Before exiting DMARC-specific processing, the Mail Receiver checks to
see if the Author Domain DMARC record requests AFRF-based reporting. see if the Author Domain DMARC record requests AFRF-based reporting.
If so, then the Mail Receiver can emit an AFRF to the reporting If so, then the Mail Receiver can emit an AFRF to the reporting
address supplied in the DMARC record. address supplied in the DMARC record.
At the exit of DMARC-specific processing, the Mail Receiver captures At the exit of DMARC-specific processing, the Mail Receiver captures
(through logging or direct insertion into a data store) the result of (through logging or direct insertion into a data store) the result of
DMARC processing. Captured information is used to build feedback for DMARC processing. Captured information is used to build feedback for
Domain Owner consumption. 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.3.2. Real-time Feedback Processing B.3.2. Real-time Feedback Processing
If the DMARC record for the Author Domain of the message under If the DMARC record for the Author Domain of the message under
processing requests [AFRF]-based reporting, then the Mail Receiver processing requests [AFRF]-based reporting, then the Mail Receiver
can supply an AFRF report for a message that does not pass all can supply an AFRF report for a message that does not pass all
underlying DMARC authentication checks. In other words, if any underlying DMARC authentication checks. In other words, if any
DMARC-supporting authentication checks fail, an AFRF report should be DMARC-supporting authentication checks fail, an AFRF report should be
generated and sent to the reporting address found in the Author generated and sent to the reporting address found in the Author
Domain's DMARC record. Domain's DMARC record.
skipping to change at page 63, line 26 skipping to change at page 71, line 26
This is a multipart message in MIME format. This is a multipart message in MIME format.
------=_NextPart_000_024E_01CC9B0A.AFE54C00 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii" Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
This is an aggregate report from mail.receiver.example. This is an aggregate report from mail.receiver.example.
------=_NextPart_000_024E_01CC9B0A.AFE54C00 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/zip Content-Type: application/gzip
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; Content-Disposition: attachment;
filename="mail.receiver.example!example.com! filename="mail.receiver.example!example.com!
1013662812!1013749130.zip" 1013662812!1013749130.gz"
<zipped content of report> <gzipped content of report>
------=_NextPart_000_024E_01CC9B0A.AFE54C00-- ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
Not shown in the above example is that the Mail Receiver's feedback Not shown in the above example is that the Mail Receiver's feedback
should be authenticated using SPF. Also, the value of the "filename" should be authenticated using SPF. Also, the value of the "filename"
MIME parameter is wrapped for printing in this specification but MIME parameter is wrapped for printing in this specification but
would normally appear as one continuous string. would normally appear as one continuous string.
B.6. https Transport example B.6. https Transport example
A DMARC record can contain an "https" reporting address, such as: A DMARC record can contain an "https" reporting address, such as:
https:feedback.example.com/dmarc-feedback-submissions https://feedback.example.com/dmarc-feedback-submissions
A sample aggregate report from the Mail Receiver at A sample aggregate report from the Mail Receiver at
mail.receiver.example, being posted per the above URL via an mail.receiver.example, being posted per the above URL via an
established secure HTTP (https) connection, might look like this: established secure HTTP (https) connection, might look like this:
POST /dmarc-feedback-submissions HTTP/1.1 POST /dmarc-feedback-submissions HTTP/1.1
Host: feedback.example.com Host: feedback.example.com
Subject: Report Domain: example.com Subject: Report Domain: example.com
Submitter: mail.receiver.example Submitter: mail.receiver.example
Report-ID: <2002.02.15.1> Report-ID: <2002.02.15.1>
Content-Type: application/zip Content-Type: application/gzip
Content-Length: 19191 Content-Length: 19191
<zipped content of report here> <gzipped content of report here>
Appendix C. DMARC XML Schema Appendix C. DMARC XML Schema
The following is the proposed initial schema for producing XML The following is the proposed initial schema for producing XML
formatted aggregate reports as described in this memo: formatted aggregate reports as described in this memo.
NOTE: Per the definition of XML, unless otherwise specified in the
schema below, the minOccurs and maxOccurs values for each element is
set to 1.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dmarc.org/dmarc-xml/0.1"> targetNamespace="http://dmarc.org/dmarc-xml/0.1">
<!-- The time range in UTC covered by messages in this report, <!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. --> specified in seconds since epoch. -->
<xs:complexType name="DateRangeType"> <xs:complexType name="DateRangeType">
<xs:all> <xs:all>
<xs:element name="begin" type="xs:integer"/> <xs:element name="begin" type="xs:integer"/>
skipping to change at page 67, line 18 skipping to change at page 75, line 22
type="PolicyEvaluatedType" type="PolicyEvaluatedType"
minOccurs="0"/> minOccurs="0"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<xs:complexType name="IdentifierType"> <xs:complexType name="IdentifierType">
<xs:all> <xs:all>
<!-- The envelope recipient domain. --> <!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string" <xs:element name="envelope_to" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<!-- The envelope from domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The payload From domain. --> <!-- The payload From domain. -->
<xs:element name="header_from" type="xs:string" <xs:element name="header_from" type="xs:string"
minOccurs="1"/> minOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- DKIM verification result, according to RFC 5451 <!-- DKIM verification result, according to RFC 5451
Section 2.4.1. --> Section 2.4.1. -->
<xs:simpleType name="DKIMResultType"> <xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
skipping to change at page 67, line 43 skipping to change at page 75, line 50
<xs:enumeration value="temperror"/> <xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/> <xs:enumeration value="permerror"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="DKIMAuthResultType"> <xs:complexType name="DKIMAuthResultType">
<xs:all> <xs:all>
<!-- The d= parameter in the signature --> <!-- The d= parameter in the signature -->
<xs:element name="domain" type="xs:string" <xs:element name="domain" type="xs:string"
minOccurs="1"/> minOccurs="1"/>
<!-- The s= parameter in the signature -->
<xs:element name="selector" type="xs:string"
minOccurs="0"/>
<!-- The DKIM verification result --> <!-- The DKIM verification result -->
<xs:element name="result" type="DKIMResultType" <xs:element name="result" type="DKIMResultType"
minOccurs="1"/> minOccurs="1"/>
<!-- Any extra information (e.g., from <!-- Any extra information (e.g., from
Authentication-Results --> Authentication-Results -->
<xs:element name="human_result" type="xs:string" <xs:element name="human_result" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- SPF domain scope -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result --> <!-- SPF result -->
<xs:simpleType name="SPFResultType"> <xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
<xs:enumeration value="neutral"/> <xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/> <xs:enumeration value="pass"/>
<xs:enumeration value="fail"/> <xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/> <xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown" --> <!-- "TempError" commonly implemented as "unknown" -->
<xs:enumeration value="temperror"/> <xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error" --> <!-- "PermError" commonly implemented as "error" -->
<xs:enumeration value="permerror"/> <xs:enumeration value="permerror"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="SPFAuthResultType"> <xs:complexType name="SPFAuthResultType">
<xs:all> <xs:all>
<!-- The envelope From domain. --> <!-- The checked domain. -->
<xs:element name="domain" type="xs:string" minOccurs="1"/> <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 --> <!-- The SPF verification result -->
<xs:element name="result" type="SPFResultType" <xs:element name="result" type="SPFResultType"
minOccurs="1"/> minOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted <!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. --> with respect to DMARC. -->
<xs:complexType name="AuthResultType"> <xs:complexType name="AuthResultType">
<xs:sequence> <xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM <!-- There may be no DKIM signatures, or multiple DKIM
signatures. --> signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType" <xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. --> <!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1" <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
skipping to change at page 69, line 4 skipping to change at page 77, line 26
<!-- This element contains all the authentication results used <!-- This element contains all the authentication results used
to evaluate the DMARC disposition for the given set of to evaluate the DMARC disposition for the given set of
messages. --> messages. -->
<xs:complexType name="RecordType"> <xs:complexType name="RecordType">
<xs:sequence> <xs:sequence>
<xs:element name="row" type="RowType"/> <xs:element name="row" type="RowType"/>
<xs:element name="identifiers" type="IdentifierType"/> <xs:element name="identifiers" type="IdentifierType"/>
<xs:element name="auth_results" type="AuthResultType"/> <xs:element name="auth_results" type="AuthResultType"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<!-- Parent --> <!-- Parent -->
<xs:element name="feedback"> <xs:element name="feedback">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="version"
type="xs:decimal"/>
<xs:element name="report_metadata" <xs:element name="report_metadata"
type="ReportMetadataType"/> type="ReportMetadataType"/>
<xs:element name="policy_published" <xs:element name="policy_published"
type="PolicyPublishedType"/> type="PolicyPublishedType"/>
<xs:element name="record" type="RecordType" <xs:element name="record" type="RecordType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
skipping to change at page 69, line 47 skipping to change at page 78, line 24
this list occurred. Additional detail can be found in the this list occurred. Additional detail can be found in the
PolicyOverrideReason's "comment" field. PolicyOverrideReason's "comment" field.
sampled_out: Message was exempted from application of policy by the sampled_out: Message was exempted from application of policy by the
"pct" setting in the DMARC policy record. "pct" setting in the DMARC policy record.
trusted_forwarder: Message authentication failure was anticipated by trusted_forwarder: Message authentication failure was anticipated by
other evidence linking the message to a locally-maintained list of other evidence linking the message to a locally-maintained list of
known and trusted forwarders. known and trusted forwarders.
The "version" for reports generated per this specification MUST be
the value 1.0.
Appendix D. Public Discussion Appendix D. Public Discussion
Public discussion of the DMARC proposal documents is taking place on Public discussion of the DMARC proposal documents is taking place on
the dmarc-discuss@dmarc.org mailing list. Subscription is available the dmarc-discuss@dmarc.org mailing list. Subscription is available
at http://www.dmarc.org/mailman/listinfo/dmarc-discuss. at http://www.dmarc.org/mailman/listinfo/dmarc-discuss.
Appendix E. Acknowledgements
DMARC and the version of this document submitted to the IETF were the
result of lengthy efforts by an informal industry consortium:
DMARC.org [1]. Participating companies included: Agari, American
Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook,
Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn,
Microsoft, Netease, Paypal, ReturnPath, Trusted Domain Project, and
Yahoo!. Although the number of 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,
Murray Kucherawy, Steve Jones, Franck Martin, Brett McDowell, and
Paul Midgen. The contributors would also like to recognize the
invaluable input and guidance that was provided by J.D. Falk.
Author's Address Author's Address
Murray S. Kucherawy (editor) Murray S. Kucherawy (editor)
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
USA
Phone: +1 415 946 3800 Email: superuser@gmail.com
Email: msk@cloudmark.com
 End of changes. 144 change blocks. 
309 lines changed or deleted 671 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/