On Tue, Dec 1, 2020 at 9:50 PM John Levine <jo...@taugh.com> wrote: > In organizations that are not universities, the entity that > is responsible for the registered domain generally sets policies for > the whole organization, and a good deal of the DMARC design is there > to let them figure out who is sending mail with their name on it from > any of their subdomains and identify and adjust senders whose mail > doesn't match the policy. > > This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk.
-- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
