# DKIM (DomainKeys Identified Mail): Definition and How It Works Source: https://wraps.dev/glossary/dkim AuthenticationDomainKeys Identified MailDKIM signature DKIM signs outgoing mail with a private key and publishes the matching public key in DNS, so a receiver can verify the message was not altered in transit and genuinely came from the signing domain. ## Where the public key lives The public key is published as a DNS TXT record at \`.\_domainkey.\`, where the selector is an arbitrary label the sender chooses and puts in the \`DKIM-Signature\` header of every message it signs. A domain can publish several selectors at once — useful for rotating keys or running multiple sending systems — and a receiver only ever looks up the one selector named in the specific message it is verifying. ## What the record's tags mean The record starts with \`v=DKIM1\`, names a key type with \`k=\` (\`rsa\` by default, or \`ed25519\`), and carries the actual public key in \`p=\`. An empty \`p=\` tag is not an error, it is a deliberate revocation: the key is intentionally disabled while the record stays in place. \`h=\` restricts which hash algorithms are acceptable — publishing \`sha1\` without \`sha256\` is flagged as a warning by Wraps' checker — and \`t=y\` marks the key as being in testing mode, where a failure should be logged but not acted on. ## Key size is a real, checkable number For RSA keys, Wraps' email-check package estimates bit length from the base64-decoded \`p=\` value and treats anything under 1024 bits as an outright error and anything under 2048 as a warning. 2048-bit RSA is the current baseline; some providers still publish 1024-bit keys from years-old setups, and those are the ones most likely to fail a modern deliverability audit even though they technically still validate. ## Providers don't all use predictable selectors Discovering DKIM by guessing selectors only works when the provider uses well-known ones. AWS SES generates a random per-identity selector rather than a fixed one, so a generic selector scan will not find it — the actual selector has to come from the SES console or the DKIM record it publishes at verification time. SendGrid and Mailgun similarly use their own custom selector conventions rather than a single industry-standard name, which is why a DKIM lookup tool has to either be told the selector or fall back to checking a large list of known vendor conventions. ## Why it matters DKIM is the authentication mechanism that survives forwarding, because the signature travels with the message body and headers rather than depending on which server relayed it — unlike SPF, which breaks the moment a message is forwarded through a server not in the original sender's SPF record. It is also the mechanism DMARC alignment most commonly relies on for exactly that reason. ## How to check it ``` dig +short TXT selector._domainkey.example.com ``` ## Common questions ### Why is my DKIM record's p= tag empty? An empty p= is a deliberate revocation, not a broken record. Whoever manages the domain intentionally disabled that key while leaving the record in place, usually mid-rotation or after retiring a sending system. ### What DKIM key size should I use? 2048-bit RSA. Anything under 1024 bits fails outright on a modern check, and 1024-2047 bits passes but is flagged, because it is weaker than current guidance recommends for a key that has to stay secure for years. ### Why can't a DKIM checker find my AWS SES selector? SES generates a random per-identity selector rather than a predictable one, so a tool has to read the actual selector from the SES console or the DNS records SES itself published, not guess it from a common-selector list.