It is possible for providers who see a statically significant potion of mail traffic to see all or almost all DKIM selectors.
I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.
I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.
Yes, but you can’t know that every authenticated sender is using DKIM at all. If the mail you just recieved from a new sender (even if it is from a domain which you have recieved DKIM signed mail from before) passes SPF but is not signed using DKIM, they are quite probably from a valid, albeit rarely used, mail sender who simply does not use DKIM.
> I think what the line you quote is trying to say is reject mail from MailChannels that isn't DKIM signed.
No, they can’t be saying that, since elsewhere they say that only 105 out of 2 million MailChannel domains are using DKIM. Therefore, they can’t be reasonably suggesting to block all mail from all but 105 of these domains.
For this and other reasons, people who actually work in the email industry do not trust SPF when authenticating domains. An SPF pass is necessary but not sufficient to know that someone is responsible for the email you just received. A far more trustworthy element is a valid DKIM signature; this certifies that the domain owner signed the message contents with a key they presumably control themselves.
This is how other similar things have solved similar problems, like DANE, CAA DNS records, and HSTS headers in HTTP. CAA records, in particular, long had a similar problem which was only solved with RFC 8657; discussion here: <https://news.ycombinator.com/item?id=34035148>