-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathdraft-ietf-dmarc-dmarcbis-02.txt
3864 lines (2566 loc) · 151 KB
/
draft-ietf-dmarc-dmarcbis-02.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
DMARC T. Herr (ed)
Internet-Draft Valimail
Obsoletes: 7489 (if approved) J. Levine (ed)
Intended status: Standards Track Standcore LLC
Expires: 18 December 2021 16 June 2021
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
draft-ietf-dmarc-dmarcbis-02
Abstract
This document describes the Domain-based Message Authentication,
Reporting, and Conformance (DMARC) protocol.
DMARC permits the owner of an email author's domain name to enable
validation of the domain's use, to indicate the Domain Owner's or
Public Suffix Operator's severity of concern regarding failed
validation, and to request reports about use of the domain name.
Mail receiving organizations can use this information when evaluating
handling choices for incoming mail.
This document obsoletes RFC 7489.
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 https://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 18 December 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 1]
Internet-Draft DMARCbis June 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 7
2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
3.1. Conventions Used in This Document . . . . . . . . . . . . 8
3.2. Authenticated Identifiers . . . . . . . . . . . . . . . . 9
3.3. Author Domain . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Domain Owner . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Identifier Alignment . . . . . . . . . . . . . . . . . . 9
3.6. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Mail Receiver . . . . . . . . . . . . . . . . . . . . . . 10
3.8. Non-existent Domains . . . . . . . . . . . . . . . . . . 10
3.9. Organizational Domain . . . . . . . . . . . . . . . . . . 10
3.10. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 10
3.11. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 10
3.12. PSO Controlled Domain Names . . . . . . . . . . . . . . . 10
3.13. Report Receiver . . . . . . . . . . . . . . . . . . . . . 10
3.14. More on Identifier Alignment . . . . . . . . . . . . . . 11
3.14.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 12
3.14.2. SPF-Authenticated Identifiers . . . . . . . . . . . 12
3.14.3. Alignment and Extension Technologies . . . . . . . . 13
3.15. Determining The Organizational Domain . . . . . . . . . . 13
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 14
4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 15
5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 17
6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 18
6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. General Record Format . . . . . . . . . . . . . . . . . . 19
6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 22
6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 24
6.5.1. Publish an SPF Policy for an Aligned Domain . . . . . 24
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 2]
Internet-Draft DMARCbis June 2021
6.5.2. Configure Sending System for DKIM Signing Using an
Aligned Domain . . . . . . . . . . . . . . . . . . . 24
6.5.3. Setup a Mailbox to Receive Aggregate Reports . . . . 24
6.5.4. Publish a DMARC Policy for the Author Domain . . . . 25
6.5.5. Collect and Analyze Reports and Adjust
Authentication . . . . . . . . . . . . . . . . . . . 25
6.5.6. Decide If and When to Update DMARC Policy . . . . . . 25
6.6. PSO Actions . . . . . . . . . . . . . . . . . . . . . . . 25
6.7. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 25
6.7.1. Extract Author Domain . . . . . . . . . . . . . . . . 25
6.7.2. Determine Handling Policy . . . . . . . . . . . . . . 26
6.7.3. Policy Discovery . . . . . . . . . . . . . . . . . . 27
6.7.4. Message Sampling . . . . . . . . . . . . . . . . . . 29
6.7.5. Store Results of DMARC Processing . . . . . . . . . . 32
6.7.6. Send Aggregate Reports . . . . . . . . . . . . . . . 33
6.8. Policy Enforcement Considerations . . . . . . . . . . . . 33
7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 34
8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 34
9. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 36
9.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 36
9.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 36
9.4. Identifier Alignment Considerations . . . . . . . . . . . 37
9.5. Interoperability Issues . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10.1. Authentication-Results Method Registry Update . . . . . 38
10.2. Authentication-Results Result Registry Update . . . . . 39
10.3. Feedback Report Header Fields Registry Update . . . . . 41
10.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 41
10.5. DMARC Report Format Registry . . . . . . . . . . . . . . 42
10.6. Underscored and Globally Scoped DNS Node Names
Registry . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11.1. Authentication Methods . . . . . . . . . . . . . . . . . 43
11.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . 44
11.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 44
11.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 44
11.5. External Reporting Addresses . . . . . . . . . . . . . . 45
11.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 46
12. Normative References . . . . . . . . . . . . . . . . . . . . 46
13. Informative References . . . . . . . . . . . . . . . . . . . 48
Appendix A. Technology Considerations . . . . . . . . . . . . . 49
A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 50
A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 51
A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 51
A.5. Issues with ADSP in Operation . . . . . . . . . . . . . . 52
A.6. Organizational Domain Discovery Issues . . . . . . . . . 53
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 3]
Internet-Draft DMARCbis June 2021
A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 53
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 54
B.1. Identifier Alignment Examples . . . . . . . . . . . . . . 54
B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 54
B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 55
B.2. Domain Owner Example . . . . . . . . . . . . . . . . . . 56
B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 56
B.2.2. Entire Domain, Monitoring Only, Per-Message
Reports . . . . . . . . . . . . . . . . . . . . . . . 57
B.2.3. Per-Message Failure Reports Directed to Third
Party . . . . . . . . . . . . . . . . . . . . . . . . 58
B.2.4. Subdomain, Sampling, and Multiple Aggregate Report
URIs . . . . . . . . . . . . . . . . . . . . . . . . 59
B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 61
B.4. Processing of SMTP Time . . . . . . . . . . . . . . . . . 61
B.5. Utilization of Aggregate Feedback: Example . . . . . . . 63
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 63
C.1. January 5, 2021 . . . . . . . . . . . . . . . . . . . . . 63
C.1.1. Ticket 80 - DMARCbis SHould Have Clear and Concise
Defintion of DMARC . . . . . . . . . . . . . . . . . 63
C.2. February 4, 2021 . . . . . . . . . . . . . . . . . . . . 64
C.2.1. Ticket 1 - SPF RFC 4408 vs 7208 . . . . . . . . . . . 64
C.3. February 10, 2021 . . . . . . . . . . . . . . . . . . . . 64
C.3.1. Ticket 84 - Remove Erroneous References to RFC3986 . 64
C.4. March 1, 2021 . . . . . . . . . . . . . . . . . . . . . . 64
C.4.1. Design Team Work Begins . . . . . . . . . . . . . . . 64
C.5. March 8, 2021 . . . . . . . . . . . . . . . . . . . . . . 64
C.5.1. Removed E. Gustafsson as editor . . . . . . . . . . 64
C.5.2. Ticket 3 - Two tiny nits . . . . . . . . . . . . . . 64
C.5.3. Ticket 4 - Definition of "fo" parameter . . . . . . . 65
C.6. March 16, 2021 . . . . . . . . . . . . . . . . . . . . . 65
C.6.1. Ticket 7 - ABNF for dmarc-record is slightly wrong . 65
C.6.2. Ticket 26 - ABNF for pct allows "999" . . . . . . . . 65
C.7. March 23, 2021 . . . . . . . . . . . . . . . . . . . . . 65
C.7.1. Ticket 75 - Using wording alternatives to
'disposition', 'dispose', and the like . . . . . . . 65
C.7.2. Ticket 72 - Remove absolute requirement for p= tag in
DMARC record . . . . . . . . . . . . . . . . . . . . 65
C.8. March 29, 2021 . . . . . . . . . . . . . . . . . . . . . 66
C.8.1. Ticket 54 - Remove or expand limits on number of
recipients per report . . . . . . . . . . . . . . . . 66
C.9. April 12, 2021 . . . . . . . . . . . . . . . . . . . . . 66
C.9.1. Ticket 50 - Remove ri= tag . . . . . . . . . . . . . 66
C.9.2. Ticket 66 - Define what it means to have implemented
DMARC . . . . . . . . . . . . . . . . . . . . . . . . 66
C.9.3. Ticket 96 - Tweaks to Abstract and Introduction . . . 66
C.10. April 13, 2021 . . . . . . . . . . . . . . . . . . . . . 66
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 4]
Internet-Draft DMARCbis June 2021
C.10.1. Ticket 53 - Remove reporting message size
chunking . . . . . . . . . . . . . . . . . . . . . . 66
C.10.2. Ticket 52 - Remove strict alignment (and adkim and
aspf tags) . . . . . . . . . . . . . . . . . . . . . 66
C.10.3. Ticket 47 - Remove pct= tag . . . . . . . . . . . . 67
C.10.4. Ticket 2 - Flow of operations text in dmarc-base . . 67
C.11. April 14, 2021 . . . . . . . . . . . . . . . . . . . . . 67
C.11.1. Ticket 107 - DMARCbis should take a stand on
multi-valued From fields . . . . . . . . . . . . . . 67
C.11.2. Ticket 82 - Deprecate rf= and maybe fo= tag . . . . 67
C.11.3. Ticket 85 - Proposed change to wording describing 'p'
tag and values . . . . . . . . . . . . . . . . . . . 67
C.12. April 15, 2021 . . . . . . . . . . . . . . . . . . . . . 67
C.12.1. Ticket 86 - A-R results for DMARC . . . . . . . . . 67
C.12.2. Ticket 62 - Make aggregate reporting a normative
MUST . . . . . . . . . . . . . . . . . . . . . . . . 68
C.13. April 19, 2021 . . . . . . . . . . . . . . . . . . . . . 68
C.13.1. Ticket 109 - Sanity Check DMARCbis Document . . . . 68
C.14. April 20, 2021 . . . . . . . . . . . . . . . . . . . . . 68
C.14.1. Ticket 108 - Changes to DMARCbis for PSD . . . . . . 68
C.15. April 22, 2021 . . . . . . . . . . . . . . . . . . . . . 68
C.15.1. Ticket 104 - Update the Security Considerations
section 11.3 on DNS . . . . . . . . . . . . . . . . . 68
C.16. June 16, 2021 . . . . . . . . . . . . . . . . . . . . . . 68
C.16.1. Publication of draft-ietf-dmarc-dmarcbis-02 . . . . 68
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
(https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis)
Abusive email often includes unauthorized and deceptive use of a
domain name in the RFC5322.From header field. The domain typically
belongs to an organization expected to be known to - and presumably
trusted by - the recipient. The Sender Policy Framework ([RFC7208])
and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-
level authentication but are not directly associated with the
RFC5322.From domain. DMARC leverages them, so that Domain Owners
publish a DNS record indicating their RFC5322.From field:
* Email authentication policies
* Level of concern for mail that fails authentication checks
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 5]
Internet-Draft DMARCbis June 2021
* Desire for reports about email use of the domain name
DMARC can cover non-existent sub-domains, below the "Organizational
Domain", as well as domains at the top of the name hierarchy,
controlled by Public Suffix Operators (PSOs).
As with SPF and DKIM, DMARC classes results as "pass" or "fail". A
pass from either SPF or DKIM is required. Depending on the stated
DMARC policy, the passed domain must be "aligned" with the
RFC5322.From domain in one of two modes - "relaxed" or "strict".
Domains are said to be "in relaxed alignment" if they have the same
Organizational Domain, which is at the top of the domain hierarchy,
while having the same administrative authority as the RFC5322.From
domain, while domains are "in strict alignment" if and only if they
are identical.
A DMARC pass indicates only that the RFC5322.From domain has been
authenticated for that message. Of course, authentication does not
carry an explicit or implicit value assertion about that message or
about the Domain Owner. Indeed, a mail-receiving organization that
performing DMARC validation can choose to follow the Domain Owner's
requested disposition for authentication failures, and to inform the
Domain Owner of the mail handling decision for that message. It also
might choose different actions.
For a mail-receiving organization supporting DMARC, a message that
passes validation is part of a message stream that is reliably
associated with the RFC5322.From field Domain Owner. Therefore,
reputation assessment of that stream by the mail-receiving
organization is not encumbered by accounting for unauthorized use of
that domain in the RFC5322.From field. A message that fails this
validation is not necessarily associated with the Domain Owner's
domain and its reputation.
DMARC, in the associated [DMARC-Aggregate-Reporting] and
[DMARC-Failure-Reporting] documents, also specifies a reporting
framework. Using it, a mail-receiving domain can generate regular
reports about messages that claim to be from a domain publishing
DMARC policies, sending those reports to the addresses specified by
the Domain Owner.
Use of DMARC creates some interoperability challenges that require
due consideration before deployment, particularly with configurations
that can cause mail to be rejected. These are discussed in
Section 9.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 6]
Internet-Draft DMARCbis June 2021
2. Requirements
Specification of DMARC is guided by the following high-level goals,
security dependencies, detailed requirements, and items that are
documented as out of scope.
2.1. High-Level Goals
DMARC has the following high-level goals:
* Allow Domain Owners and PSOs to assert their severity of concern
for authentication failures for messages purporting to have
authorship within the domain.
* Allow Domain Owners and PSOs to verify their authentication
deployment.
* Minimize implementation complexity for both senders and receivers,
as well as the impact on handling and delivery of legitimate
messages.
* Reduce the amount of successfully delivered spoofed email.
* Work at Internet scale.
2.2. Out of Scope
Several topics and issues are specifically out of scope for this
work. These include the following:
* different treatment of messages that are not authenticated versus
those that fail authentication;
* evaluation of anything other than RFC5322.From header field;
* multiple reporting formats;
* publishing policy other than via the DNS;
* reporting or otherwise evaluating other than the last-hop IP
address;
* attacks in the From: header field, also known as "display name"
attacks;
* authentication of entities other than domains, since DMARC is
built upon SPF and DKIM, which authenticate domains; and
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 7]
Internet-Draft DMARCbis June 2021
* content analysis.
2.3. Scalability
Scalability is a major issue for systems that need to operate in a
system as widely deployed as current SMTP email. For this reason,
DMARC seeks to avoid the need for third parties or pre-sending
agreements between senders and receivers. This preserves the
positive aspects of the current email infrastructure.
Although DMARC does not introduce third-party senders (namely
external agents authorized to send on behalf of an operator) to the
email-handling flow, it also does not preclude them. Such third
parties are free to provide services in conjunction with DMARC.
2.4. Anti-Phishing
DMARC is designed to prevent bad actors from sending mail that claims
to come from legitimate senders, particularly senders of
transactional email (official mail that is about business
transactions). One of the primary uses of this kind of spoofed mail
is phishing (enticing users to provide information by pretending to
be the legitimate service requesting the information). Thus, DMARC
is significantly informed by ongoing efforts to enact large-scale,
Internet-wide anti-phishing measures.
Although DMARC can only be used to combat specific forms of exact-
domain spoofing directly, the DMARC mechanism has been found to be
useful in the creation of reliable and defensible message streams.
DMARC does not attempt to solve all problems with spoofed or
otherwise fraudulent email. In particular, it does not address the
use of visually similar domain names ("cousin domains") or abuse of
the RFC5322.From human-readable <display-name>.
3. Terminology and Definitions
This section defines terms used in the rest of the document.
3.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 8]
Internet-Draft DMARCbis June 2021
Readers are encouraged to be familiar with the contents of [RFC5598].
In particular, that document defines various roles in the messaging
infrastructure that can appear the same or separate in various
contexts. For example, a Domain Owner could, via the messaging
security mechanisms on which DMARC is based, delegate the ability to
send mail as the Domain Owner to a third party with another role.
This document does not address the distinctions among such roles; the
reader is encouraged to become familiar with that material before
continuing.
3.2. Authenticated Identifiers
Domain-level identifiers that are validated using authentication
technologies are referred to as "Authenticated Identifiers". See
Section 4.1 for details about the supported mechanisms.
3.3. Author Domain
The domain name of the apparent author, as extracted from the From:
header field.
3.4. Domain Owner
An entity or organization that owns a DNS domain. The term "owns"
here indicates that the entity or organization being referenced holds
the registration of that DNS domain. Domain Owners range from
complex, globally distributed organizations, to service providers
working on behalf of non-technical clients, to individuals
responsible for maintaining personal domains. This specification
uses this term as analogous to an Administrative Management Domain as
defined in [RFC5598]. It can also refer to delegates, such as Report
Receivers, when those are outside of their immediate management
domain.
3.5. Identifier Alignment
When the domain in the address in the From: header field has the same
Organizational Domain as a domain validated by SPF or DKIM (or both),
it has Identifier Alignment. (see below)
3.6. Longest PSD
The term Longest PSD is defined in [DMARC-PSD].
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 9]
Internet-Draft DMARCbis June 2021
3.7. Mail Receiver
The entity or organization that receives and processes email.
Mail Receivers operate one or more Internet- facing Mail Transport
Agents (MTAs).
3.8. Non-existent Domains
For DMARC purposes, a non-existent domain is a domain for which there
is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This
is a broader definition than that in [RFC8020].
3.9. Organizational Domain
The domain that was registered with a domain name registrar. In the
absence of more accurate methods, heuristics are used to determine
this, since it is not always the case that the registered domain name
is simply a top-level DNS domain plus one component (e.g.,
"example.com", where "com" is a top-level domain). The
Organizational Domain is determined by applying the algorithm found
in Section 3.15.
3.10. Public Suffix Domain (PSD)
The term Public Suffix Domain is defined in [DMARC-PSD].
3.11. Public Suffix Operator (PSO)
The term Public Suffix Operator is defined in [DMARC-PSD].
3.12. PSO Controlled Domain Names
The term PSO Controlled Domain Names is defined in [DMARC-PSD].
3.13. Report Receiver
An operator that receives reports from another operator implementing
the reporting mechanisms described in this document. Such an
operator might be receiving reports about messages related to a
domain for which it is the Domain Owner or PSO, or reports about
messages related to another operator's domain. This term applies
collectively to the system components that receive and process these
reports and the organizations that operate them.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 10]
Internet-Draft DMARCbis June 2021
3.14. More on Identifier Alignment
Email authentication technologies authenticate various (and
disparate) aspects of an individual message. For example, DKIM
[RFC6376] authenticates the domain that affixed a signature to the
message, while SPF [RFC7208] can authenticate either the domain that
appears in the RFC5321.MailFrom (MAIL FROM) portion of [RFC5322] or
the RFC5321.EHLO/ HELO domain, or both. These may be different
domains, and they are typically not visible to the end user.
DMARC authenticates use of the RFC5322.From domain by requiring that
it have the same Organizational Domain (be aligned with) as an
Authenticated Identifier. The RFC5322.From domain was selected as
the central identity of the DMARC mechanism because it is a required
message header field and therefore guaranteed to be present in
compliant messages, and most Mail User Agents (MUAs) represent the
RFC5322.From header field as the originator of the message and render
some or all of this header field's content to end users.
Thus, this field is the one used by end users to identify the source
of the message and therefore is a prime target for abuse. Many high-
profile email sources, such as email service providers, require that
the sending agent have authenticated before email can be generated.
Thus, for these mailboxes, the mechanism described in this document
provides recipient end users with strong evidence that the message
was indeed originated by the agent they associate with that mailbox,
if the end user knows that these various protections have been
provided.
Domain names in this context are to be compared in a case-insensitive
manner, per [RFC4343].
It is important to note that Identifier Alignment cannot occur with a
message that is not valid per [RFC5322], particularly one with a
malformed, absent, or repeated RFC5322.From header field, since in
that case there is no reliable way to determine a DMARC policy that
applies to the message. Accordingly, DMARC operation is predicated
on the input being a valid RFC5322 message object, and handling of
such non-compliant cases is outside of the scope of this
specification. Further discussion of this can be found in
Section 6.7.1.
Each of the underlying authentication technologies that DMARC takes
as input yields authenticated domains as their outputs when they
succeed.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 11]
Internet-Draft DMARCbis June 2021
3.14.1. DKIM-Authenticated Identifiers
DMARC requires Identifier Alignment based on the result of a DKIM
authentication because a message can bear a valid signature from any
domain, including domains used by a mailing list or even a bad actor.
Therefore, merely bearing a valid signature is not enough to infer
authenticity of the Author Domain.
DMARC permits Identifier Alignment based on the result of a DKIM
authentication to be strict or relaxed. (Note that these terms are
not related to DKIM's "simple" and "relaxed" canonicalization modes.)
In relaxed mode, the Organizational Domains of both the DKIM-
authenticated signing domain (taken from the value of the d= tag in
the signature) and that of the RFC5322.From domain must be equal if
the identifiers are to be considered to be aligned. In strict mode,
only an exact match between both the Fully Qualified Domain Names
(FQDNs) is considered to produce Identifier Alignment.
To illustrate, in relaxed mode, if a validated DKIM signature
successfully verifies with a "d=" domain of "example.com", and the
RFC5322.From address is "alerts@news.example.com", the DKIM "d="
domain and the RFC5322.From domain are considered to be "in
alignment". In strict mode, this test would fail because the d=
domain does not exactly match the RFC5322.From domain.
However, a DKIM signature bearing a value of "d=com" would never
allow an "in alignment" result, as "com" should appear on all public
suffix lists (see Appendix A.6.1) and therefore cannot be an
Organizational Domain.
Note that a single email can contain multiple DKIM signatures, and it
is considered to produce a DMARC "pass" result if any DKIM signature
is aligned and verifies.
3.14.2. SPF-Authenticated Identifiers
DMARC permits Identifier Alignment based on the result of an SPF
authentication. As with DKIM, Identifier Alignement can be either
strict or relaxed.
In relaxed mode, the Organizational Domains of the SPF-authenticated
domain and RFC5322.From domain must be equal if the identifiers are
to be considered to be aligned. In strict mode, the two FQDNs must
match exactly in order from them to be considered to be aligned.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 12]
Internet-Draft DMARCbis June 2021
For example, in relaxed mode, if a message passes an SPF check with
an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the
address portion of the RFC5322.From header field contains
"payments@example.com", the Authenticated RFC5321.MailFrom domain
identifier and the RFC5322.From domain are considered to be "in
alignment" because they have the same Organizational Domain
("example.com"). In strict mode, this test would fail because the
two domains are not identical.
The reader should note that SPF alignment checks in DMARC rely solely
on the RFC5321.MailFrom domain. This differs from section 2.3 of
[RFC7208], which recommends that SPF checks be done on not only the
"MAIL FROM" but also on a separate check of the "HELO" identity.
3.14.3. Alignment and Extension Technologies
If in the future DMARC is extended to include the use of other
authentication mechanisms, the extensions will need to allow for
domain identifier extraction so that alignment with the RFC5322.From
domain can be verified.
3.15. Determining The Organizational Domain
The Organizational Domain is determined using the following
algorithm:
1. Acquire a "public suffix" list, i.e., a list of DNS domain names
reserved for registrations. Some country Top-Level Domains
(TLDs) make specific registration requirements, e.g., the United
Kingdom places company registrations under ".co.uk"; other TLDs
such as ".com" appear in the IANA registry of top-level DNS
domains. A public suffix list is the union of all of these.
Appendix A.6.1 contains some discussion about obtaining a public
suffix list.
2. Break the subject DNS domain name into a set of "n" ordered
labels. Number these labels from right to left; e.g., for
"example.com", "com" would be label 1 and "example" would be
label 2.
3. Search the public suffix list for the name that matches the
largest number of labels found in the subject DNS domain. Let
that number be "x".
4. Construct a new DNS domain name using the name that matched from
the public suffix list and prefixing to it the "x+1"th label from
the subject domain. This new name is the Organizational Domain.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 13]
Internet-Draft DMARCbis June 2021
Thus, since "com" is an IANA-registered TLD, a subject domain of
"a.b.c.d.example.com" would have an Organizational Domain of
"example.com".
The process of determining a suffix is currently a heuristic one. No
list is guaranteed to be accurate or current.
Ticket 109, Original text: (Seems like these two paragraphs should be
moved elsewhere?)
In addition to Mediators, mail that is sent by authorized,
independent third parties might not be sent with Identifier
Alignment, also preventing a "pass" result.
Issues specific to the use of policy mechanisms alongside DKIM are
further discussed in [@RFC6377], particularly Section 5.2.
4. Overview
This section provides a general overview of the design and operation
of the DMARC environment.
4.1. Authentication Mechanisms
The following mechanisms for determining Authenticated Identifiers
are supported in this version of DMARC:
* DKIM, [RFC6376], which provides a domain-level identifier in the
content of the "d=" tag of a validated DKIM-Signature header
field.
* SPF, [RFC7208], which can authenticate both the domain found in an
[RFC5322] HELO/EHLO command (the HELO identity) and the domain
found in an SMTP MAIL command (the MAIL FROM identity).
Section 2.4 of [RFC7208] describes MAIL FROM processing for cases
in which the MAIL command has a null path.
4.2. Key Concepts
DMARC policies are published by the Domain Owner or PSO, and
retrieved by the Mail Receiver during the SMTP session, via the DNS.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 14]
Internet-Draft DMARCbis June 2021
DMARC's filtering function is based on whether the RFC5322.From
domain is aligned with (has the same Organizational Domain as) an
authenticated domain name from SPF or DKIM. When a DMARC policy is
published for the domain name found in the RFC5322.From header field,
and that domain name is not validated through SPF or DKIM, the
handling of that message can be affected by that DMARC policy when
delivered to a participating receiver.
It is important to note that the authentication mechanisms employed
by DMARC authenticate only a DNS domain and do not authenticate the
local-part of any email address identifier found in a message, nor do
they validate the legitimacy of message content.
DMARC's feedback component involves the collection of information
about received messages claiming to be from the Author Domain for
periodic aggregate reports to the Domain Owner or PSO. The
parameters and format for such reports are discussed in
[DMARC-Aggregate-Reporting]
A DMARC-enabled Mail Receiver might also generate per-message reports
that contain information related to individual messages that fail SPF
and/or DKIM. Per-message failure reports are a useful source of
information when debugging deployments (if messages can be determined
to be legitimate even though failing authentication) or in analyzing
attacks. The capability for such services is enabled by DMARC but
defined in other referenced material such as [RFC6591] and
[DMARC-Failure-Reporting]
A message satisfies the DMARC checks if at least one of the supported
authentication mechanisms:
1. produces a "pass" result, and
2. produces that result based on an identifier that is in alignment,
as defined in Section 3.
4.3. Flow Diagram
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 15]
Internet-Draft DMARCbis June 2021
+---------------+ +--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+
| . ^
V V .
+-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+
| Service | | Signer | | Verifier |<***>| SPF |
+-----------+ +--------+ +----------+ * | Verifier |
| ^ * +----------+
| * *
V v *
+------+ (~~~~~~~~~~~~) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **>| DKIM |
+------+ (~~~~~~~~~~~~) +------+ | Verifier |
| +----------+
| ^
V .
+-----------+ .
+---------+ | MDA | v
| User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing |
| Domain(s) |
+-----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
The above diagram shows a simple flow of messages through a DMARC-
aware system. Solid lines denote the actual message flow, dotted
lines involve DNS queries used to retrieve message policy related to
the supported message authentication schemes, and asterisk lines
indicate data exchange between message-handling modules and message
authentication modules. "sMTA" is the sending MTA, and "rMTA" is the
receiving MTA.
Put simply, when a message reaches a DMARC-aware rMTA, a DNS query
will be initiated to determine if the author domain has published a
DMARC policy. If a policy is found, the rMTA will use the results of
SPF and DKIM validation checks to determine the ultimate DMARC
authentication status. The DMARC status can then factor into the
message handling decision made by the recipient's mail sytsem.
More details on specific actions for the parties involved can be
found in Section 6.5 and Section 6.7.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 16]
Internet-Draft DMARCbis June 2021
5. Use of RFC5322.From
One of the most obvious points of security scrutiny for DMARC is the
choice to focus on an identifier, namely the RFC5322.From address,
which is part of a body of data that has been trivially forged
throughout the history of email.
Several points suggest that it is the most correct and safest thing
to do in this context:
* Of all the identifiers that are part of the message itself, this
is the only one guaranteed to be present.
* It seems the best choice of an identifier on which to focus, as
most MUAs display some or all of the contents of that field in a
manner strongly suggesting those data as reflective of the true
originator of the message.
The absence of a single, properly formed RFC5322.From header field
renders the message invalid. Handling of such a message is outside
of the scope of this specification.
Since the sorts of mail typically protected by DMARC participants
tend to only have single Authors, DMARC participants generally
operate under a slightly restricted profile of RFC5322 with respect
to the expected syntax of this field. See Section 6.7 for details.
6. Policy
DMARC policies are published by Domain Owners and PSOs and can be
used by Mail Receivers to inform their message handling decisions.
A Domain Owner or PSO advertises DMARC participation of one or more
of its domains by adding a DNS TXT record (described in Section 6.1)
to those domains. In doing so, Domain Owners and PSOs indicate their
severity of concern regarding failed authentication for email
messages making use of their domain in the RFC5322.From header field
as well as the provision of feedback about those messages. Mail
Receivers in turn can take into account the Domain Owner's severity
of concern when making handling decisions about email messages that
fail DMARC authentication checks.
Herr (ed) & Levine (ed) Expires 18 December 2021 [Page 17]
Internet-Draft DMARCbis June 2021
A Domain Owner or PSO may choose not to participate in DMARC
evaluation by Mail Receivers. In this case, the Domain Owner simply
declines to advertise participation in those schemes. For example,
if the results of path authorization checks ought not be considered
as part of the overall DMARC result for a given Author Domain, then
the Domain Owner does not publish an SPF policy record that can
produce an SPF pass result.
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-
effort attempt to adhere to the Domain Owner's or PSO's published
DMARC Domain Owner Assessment Policy when a message fails the DMARC
test.
Since email streams can be complicated (due to forwarding, existing
RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY
deviate from a published Domain Owner Assessment Policy during
message processing and SHOULD make available the fact of and reason
for the deviation to the Domain Owner via feedback reporting,
specifically using the "PolicyOverride" feature of the aggregate
report defined in [DMARC-Aggregate-Reporting]
6.1. DMARC Policy Record
Domain Owner and PSO DMARC preferences are stored as DNS TXT records
in subdomains named "_dmarc". For example, the Domain Owner of
"example.com" would post DMARC preferences in a TXT record at
"_dmarc.example.com". Similarly, a Mail Receiver wishing to query
for DMARC preferences regarding mail with an RFC5322.From domain of
"example.com" would issue a TXT query to the DNS for the subdomain of
"_dmarc.example.com". The DNS-located DMARC preference data will
hereafter be called the "DMARC record".
DMARC's use of the Domain Name Service is driven by DMARC's use of
domain names and the nature of the query it performs. The query
requirement matches with the DNS, for obtaining simple parametric
information. It uses an established method of storing the
information, associated with the target domain name, namely an
isolated TXT record that is restricted to the DMARC context. Use of
the DNS as the query service has the benefit of reusing an extremely
well-established operations, administration, and management
infrastructure, rather than creating a new one.
Per [RFC1035], a TXT record can comprise several "character-string"
objects. Where this is the case, the module performing DMARC
evaluation MUST concatenate these strings by joining together the