One data point for dneuhaeuser's idea — saving the selector that was entered when the key is generated: the open admin-api PR #100 ("Store generated DKIM keys in a dedicated Redis keystore") already records the selector per domain when a key is generated in the Admin UI:
HSET DKIM_SELECTORS <domain> <selector>
With dkim_signing set to use_redis, that is the map rspamd itself signs from. So if checkDKIM() looked up DKIM_SELECTORS for the domain first and fell back to dkim when there is no entry, the check would test the key that is actually in use, for every key generated in the UI, without a new setting. That only helps where the keystore is enabled; the PR leaves it off by default.
For externally created keys, Steakie's point stands: grommunio cannot know the selector. The per-domain selector field MichaelH suggested would still be needed there. The lookup order could then be: field → keystore → dkim.
Today the check hardcodes dkim._domainkey. (dnsHealth.py L195–L196), so anyone rotating keys with dated selectors, which is the usual practice, sees the chip orange permanently.
Side note: in the same view the DMARC chip is coloured from the DKIM result, not the DMARC one, so a DKIM check that misses the selector turns the DMARC chip orange as well. Reported as https://github.com/grommunio/admin-web/issues/23.
