[dataflow]

> Btw, there was proposal to add a feature that could be used for this signaling but it didn’t get adopted, so DMARC is the only practical solution right now.

Wow, thanks. That definitely explains this mess.

Do you know why it didn't get adopted? I'd have thought that in a sane world all you'd need is to literally have a DNS record that specifies the DKIM info... pretty simple. Why on earth did people find it more convenient to do it in such a convoluted fashion instead? Especially now that there's ARC too, which I'd have thought shouldn't be necessary either.

[aj3]

Corporate politics and death by committee. These standards were created by many parties with conflicting interests. My understanding is that they couldn't agree on an exact way From header should be checked and thus deferred all policy aspects to further standard.

If you read DKIM RFC it actually only specifies how to sign and verify the email signature, but does not mandate exact checks recipient should do to figure out authenticity. E.g. technically Microsoft could send mail from @gmail.com address and use "d=outlook.com" in the signature - the signature would be valid, but obviously it wouldn't make it authentic (meaning such mail wouldn't be authorized by Google). Although common sense dictates that there should be some sort of connection between domain seen in From header and the one that's DKIM-signing the mail (and most real-world implementations will do some kind of checks), RFC deliberately does not standardize these steps.

The intended standard that should have clarified these issues was ADSP, but it wasn't well received and now we have DMARC which handles both SPF and DKIM together (this is better for deliverability as mails that fail one of these checks might still pass another).