What DKIM proves
Your mail server signs each outgoing message with a private key. The matching public key sits in DNS. A receiver fetches it, checks the signature, and now knows two things: the message was authorised by your domain, and nothing in the signed parts changed on the way.
That second half is what SPF cannot do. It is also why DKIM survives forwarding while SPF usually does not, and why a domain with solid DKIM is far more resilient than one leaning on SPF alone.
The selector problem
A DKIM key lives at selector._domainkey.yourdomain.com. The selector is chosen by whoever set up the signing, and there is no record anywhere that enumerates the ones in use. You cannot list them and you cannot brute force them at any sensible scale.
There are two reliable ways to find yours. Look at a message you have already sent, open the raw headers, and read the s= value in the DKIM-Signature line. Or check your sending provider documentation, since most use a fixed default: Google Workspace signs with google, Microsoft 365 with selector1 and selector2, Mailchimp with k1, Postmark with pm.
This checker tries eighteen of those defaults in parallel, which covers most senders. A blank result does not mean you have no DKIM, it means you are on a custom selector and the header is the only way to find it.
What can be wrong with a key that exists
An empty p= tag is a revoked key. The record is still there, and it is telling receivers to treat every signature from that selector as invalid. This happens when a provider is disconnected without the DNS being cleaned up, and it is worse than a missing record because it looks fine at a glance.
t=y is testing mode. It asks receivers to ignore failures, which is correct while you are setting up and a quiet hole in your authentication once you are live.
Key length is the last one. 1024-bit RSA still verifies everywhere and 2048 is the current recommendation. Below 1024 a receiver is entitled to ignore the signature entirely.
Two providers, two keys
Unlike SPF, DKIM has no combining problem. Each sending service gets its own selector and its own record, and they do not interfere. If you send through Google Workspace and a marketing platform, you should expect to find two keys, and this checker will list the extra selectors it saw.
Then confirm the other two records with the SPF checker and the DMARC checker. DMARC needs SPF or DKIM to be aligned before it can pass anything at all.