Concept
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, generated with a private key, verifiable against a public key published as a TXT record at selector._domainkey.yourdomain.com. Unlike SPF and DMARC, which live at fixed, predictable record names, DKIM's "selector" is an arbitrary label chosen by whoever configured signing (RFC 6376 doesn't standardize it) — meaning there's no single record name an outside auditor can check to confirm DKIM is even in use, only specific selectors that happen to be guessed or already known.
Common Misconception
"If I can't find a DKIM record at a guessed selector, DKIM isn't set up." Not a valid conclusion — because selector names are arbitrary, a failed lookup at default._domainkey or google._domainkey only proves that specific selector doesn't exist, not that DKIM signing is absent entirely. This is exactly why NODA's own methodology treats an unfound key at a guessed selector as an Informational finding, not a Critical failure — confirmed absence would require knowing the actual selector in use, which passive DNS lookup alone can't guarantee.
Hands-On Exercise
No lab environment needed:
- marinadns.io/mailauth — checks common DKIM selectors for a domain and reports what it finds, with the same Informational-vs-Fail distinction NODA uses.
- marinadns.io/emailheader — paste a real email's raw headers to see the actual
DKIM-Signature header, including the exact selector (s=) and domain (d=) tags used for that specific message — the only fully reliable way to know the real selector.
For generating your own DKIM key pair, publishing the selector record, and validating a real signed test message end-to-end, see Lesson 9 in the DNS Admin Course Lab Environment page.
Commands to Run
# Generate a DKIM key pair (example using OpenSSL)
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem
# Publish the public key as a TXT record at: selector._domainkey.yourdomain.com
dig selector._domainkey.yourdomain.com TXT +short
# Send a real test email through a provider configured to sign with this key, then inspect headers:
# look for DKIM-Signature: header, note the 's=' (selector) and 'd=' (domain) tags
# Verify the signature validates against the published key
dig $(echo "your-selector")._domainkey.yourdomain.com TXT +short
# cross-check manually or via a validator (opendkim-testkey, or mail-tester.com)
Confirm the selector name in the actual DKIM-Signature header matches exactly what's published — a mismatch here is the most common DKIM misconfiguration.
Mastery Checkpoint
You should be able to explain, without looking anything up:
- Why DKIM selectors aren't standardized, and what that means for auditing DKIM from outside.
- Why an unfound key at a guessed selector is Informational, not a confirmed Fail.
- Where the actual selector in use for a piece of mail can be reliably found (hint: not by guessing).
If you can answer all three without re-reading this lesson, move to Lesson 10.
← DNS Admin Course Lab Environment
