On 3/14/2024 3:49 PM, Todd Herr wrote:
On Thu, Mar 14, 2024 at 4:43 PM Mark Alley <mark.alley=40tekmarc....@dmarc.ietf.org> wrote:On 3/14/2024 3:38 PM, Todd Herr wrote:On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman <skl...@kitterman.com> wrote: I think this is correct. I think it's obviously enough correct that I'm surprised anyone was confused. Do we know what the theory was that led people to think otherwise? Seems to me we don't really need this, but maybe there's a reason. The reasons given were: 1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1 2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5 3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if it's not explicitly mentioned... Granted, the first two citations are in regards to DKIM records, not DMARC records, but those were the reasons given.Couldn't hurt to clarify explicitly, I'm for it. Domain owners have been using CNAMEs with DMARC TXT RRs pretty much since its inception.I agree that clarifying it can't hurt, obviously, but I was quite surprised to hear that CNAMEs were being published for DMARC records, as I'd never seen one. On the other hand, I've seen *lots* of DKIM public keys published as CNAMEs, which I'm sure just wrecks the person citing DKIM RFCs as a reason that DMARC records can't be CNAMEs.
Domain owner use cases with DMARC CNAMEs boils down to really either of 2 things:
* Single point of policy management for orgs with dozens, hundreds, or thousands of domains to manage DMARC on, and also applicable to RUA/RUF addresses. * Delegation to a third-party for management, similar to DKIM CNAMEs as you noted that are popularly in use by many ESPs for vendor-managed key rotation. - Mark Alley
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
