DKIM Check — Are Your Signing Keys Published and Valid
DKIM signs outgoing mail with a private key and publishes the matching public key in DNS under a selector. This check fetches the key for a given selector and confirms it is present, correctly formed and of a usable length. Without a retrievable public key, the signature on your mail cannot be verified and the message is treated as unsigned.
Why run it
DKIM has an unusually quiet failure mode. A missing or malformed key does not bounce anything; it just means signatures fail to verify, which receiving servers weigh against you gradually rather than absolutely. The result is a slow decline in placement that is nearly impossible to attribute after the fact. Checking the selector directly answers the question in one step, which matters most immediately after a mail platform migration — the classic case is signing with a new key whose public half was never published.
Why automate it
Keys get rotated, and rotation is where this breaks. A provider generates a new selector and expects you to publish it; if the DNS half is missed or delayed, signing continues against a key nobody can find. Because there is no error anywhere in your own systems, this can persist for weeks. A scheduled check on every selector you use — including the ones belonging to platforms other teams manage — is what turns a silent degradation into an alert on the day it starts.
What it gives you
Assurance that the signature you are attaching to every message can actually be verified. It closes the gap between "we enabled DKIM" and "DKIM is working", which are separated by exactly one DNS record that nobody checks.