Look up a DKIM public key, read its real size out of the record, and tell a revoked key apart from a broken one.
DKIM puts a cryptographic signature on each message. The receiver fetches your public key from DNS and checks that the message really came from you and was not altered on the way. Unlike SPF it survives forwarding, which is why it carries most of the weight in practice.
The key is published under a selector, and the selector cannot be discovered from DNS. It lives in the message header, not in the zone, so any tool claiming to find your DKIM automatically is guessing at a list of common vendor names. We try that list and say plainly when we are guessing. The reliable way is to open a message your domain sent and read s= from its DKIM-Signature header.
Two states get misread constantly. A p= tag with nothing after it is not a broken record, it is the documented way to revoke a key, and any message still signed with that selector will fail. And a key that looks malformed is usually a key that was reassembled wrongly: records over 255 characters arrive in pieces that must be joined with nothing between them, so a stray space turns a perfectly good 2048-bit key into something unreadable.
2048 bits. Anything below 1024 is forgeable by anyone who cares to try, and a forged signature is worse than no signature because it authenticates the forgery.
Testing mode. It tells receivers not to act on a verification failure. It is meant for the days after a key is first published and is routinely left in place for years, quietly cancelling the protection the key provides.