DKIM Record Checker is for a problem that hides in plain sight. You enter a domain name and a DKIM selector, and the checker looks up the DNS record at selector._domainkey.domain. From there it reads the DKIM TXT record, shows the public key, examines the record tags, checks the key type, and points out common failures such as missing data, revoked keys, weak RSA lengths, malformed records, and selectors that exist more in corporate folklore than in DNS reality. In ordinary language, it answers a blunt question: if your domain claims to sign email, is there actually a valid public key waiting in DNS, or is the whole setup one more ceremonial lie told by dashboards?
For someone who does not live inside mail systems, the plain version is simple. A domain is the readable name, like example.com. DNS, the Domain Name System, is the distributed lookup system that stores technical records under that name. DKIM is DomainKeys Identified Mail. The letters are not mystical. They are a label for a mail-signing system that uses a domain name, a cryptographic key pair, and DNS-published public keys to let a receiving mail system verify that a message was signed by someone holding the corresponding private key. That does not mean the message is morally pure, wise, or pleasant. It means a domain-associated signer took responsibility for it in a way that can be checked.
The name is unusually revealing if you bother to read it instead of skimming it with the glazed eyes of a person already traumatized by DNS. Domain means the system is anchored to a domain name rather than to a personal certificate for every human being on earth. Keys means public-key cryptography is involved. There is a private key used to sign and a public key published so others can verify. Identified means the point is not merely hiding content in cipher smoke; the point is to bind a responsible signing identity to the message. Mail means exactly that: email, the old global medium that spent decades being absurdly trusting and then had to invent layer after layer of technical suspicion once the world discovered spam, spoofing, phishing, and scale.
The historical path matters because DKIM did not appear out of nowhere. Before DKIM became the standard, there was DomainKeys, described in RFC 4870 as “Domain-Based Email Authentication Using Public Keys Advertised in the DNS”. Even the title sounds like an engineer clearing his throat before introducing a mechanism with all the warmth of a precision tool. DomainKeys was an early domain-level email authentication framework using public keys in DNS. DKIM, standardized in RFC 4871 and later revised in RFC 6376, carried that ancestry directly in its own name. It was built to let a person, role, or organization that owns the signing domain claim responsibility for a message and have that claim checked through a cryptographic signature and a DNS lookup for the public key.
That word responsibility is important. DKIM is not a halo. It is not a moral certificate. It is not the internet declaring, with tears in its eyes, that the message came from saints. The DKIM service overview is very clear that DKIM has a constrained job. It gives mail systems a verifiable identifier associated with the message so they can make later decisions. By itself, DKIM does not tell a receiver exactly what action to take, does not by itself prove every visible header means what a normal person assumes it means, and does not magically stop replay after successful verification. In other words, DKIM is useful because it is specific. People get into trouble when they ask it to be an entire philosophy of trust.
The reason DKIM uses DNS for key distribution is beautifully practical. The service overview explains that using DNS avoided the need to invent a completely new global query infrastructure. That was a very internet sort of decision: there is already a large, distributed, globally operated naming system, so use it instead of creating one more grand cathedral of technical ambition. DNS already knew how to distribute records at scale. DKIM simply stored the public verification material there. Sensible, efficient, and naturally destined to be misunderstood by generations of admins who would later copy DNS snippets from help articles without reading what they were pasting.
That brings us to one of the most useful ideas in DKIM: the selector. A selector is not there to make life interesting. It exists because one domain can have multiple signing keys and multiple signing arrangements. The selector lets the signing system point to the right public key without shoving all keys into one sad pile. RFC 5585 explains that the selector is combined with the signing domain identifier so the verifier knows which key to fetch. RFC 6376 goes further and notes that selectors help with key rotation, delegation, and even hierarchical naming, because periods inside selectors define DNS label boundaries. In plain language, the selector is the sub-label that says, “Use this key, not that one.” It is mail infrastructure’s version of labeling drawers, which sounds humble until you have seen what happens when nobody labels the drawers.
The fixed ._domainkey part also has a reason. RFC 6376 says all DKIM keys are stored in a subdomain named _domainkey. So if the signing domain is example.com and the selector is newsletter, the DNS query goes to newsletter._domainkey.example.com. That naming rule creates order. The selector picks the key. The _domainkey subdomain says what kind of data lives there. The base domain ties the whole thing to the signer’s namespace. Without that structure, DNS would become even more of a scavenger hunt than it already is.
Inside the DKIM record itself, the tags are not random decoration. v=DKIM1 declares the record version. p= carries the public key data. k= identifies the key type, historically most often RSA. Some other tags restrict service use, advertise flags, or describe acceptable hash behavior. An empty p= value has a particularly dry and important meaning in RFC 6376: it means the key has been revoked. That is one of those details the standards world handles with deadpan efficiency. No fireworks. No dramatic farewell. Just empty key data and the verifier is expected to treat that as failure.
A good DKIM checker also has to care about cryptography, because the public key is not decorative wallpaper. DKIM started in a world where RSA was the standard signing method, and RFC 6376 still reflects that era. Later, RFC 8301 updated DKIM cryptographic guidance, declaring rsa-sha1 obsolete and requiring signers to use RSA keys of at least 1024 bits, while noting that keys smaller than 2048 bits may be vulnerable to off-line attacks. That is standards language for “the old comfort blanket is getting thin.” Then RFC 8463 added Ed25519-based DKIM signing, which brought shorter keys for similar security levels. So when a checker looks at a DKIM key today, it should not merely announce “record found” like a golden retriever proudly carrying a stick. It should ask what kind of key it is, whether the key can be parsed, and whether the size belongs to current reality rather than to a museum of cryptographic optimism.
There is an almost comic contrast at the center of DKIM. The concept is clean: sign selected headers and body content, publish the public key in DNS, let receivers verify. The operational reality is less poetic. Key rotation gets forgotten. Old selectors accumulate. Vendors ask admins to publish one more selector, one more outsourced sender, one more supposedly harmless DNS record. Years later the organization has a small cemetery of stale selectors under _domainkey, some active, some abandoned, some half-documented, and one that everybody is afraid to remove because it might still power a billing system no one has touched since a management reorg three logos ago. That is why checking DKIM records is not academic hygiene. It is infrastructure archaeology with consequences.
The bigger lesson is worth saying plainly. Email authentication systems exist because the internet became too large and too hostile for trust by posture alone. DKIM is one answer to that reality. It lets a domain-associated signer attach a cryptographic signature to mail and lets receivers validate the associated public key through DNS. It does not solve every trust problem. It does not replace judgment. It does not rescue a badly run mail operation from its own habits. But it does provide a verifiable technical statement that can be checked instead of merely believed. On the modern internet, that counts as progress.
So what should a serious DKIM Record Checker really tell you? Whether the selector host exists. Whether a proper v=DKIM1 record is there. Whether the public key is present, decodable, and plausible. Whether the key appears revoked. Whether the record advertises flags or service restrictions that matter. Whether the cryptography looks current enough to be respectable. And, perhaps most importantly, whether your domain’s mail-signing story is built on an actual published key or on the kind of administrative wishfulness that tends to collapse the moment a receiving server asks for evidence.