How it works
The sending server signs selected headers and the body of each message with a private key and adds the result as a DKIM-Signature header. Among other things, it names the signing domain (d=) and the selector (s=). The method is specified in RFC 6376.
The domain publishes the matching public key as a TXT record at selector._domainkey.domain, for example selector1._domainkey.example.com with v=DKIM1; k=rsa; p=MIIBIjANBg… The receiver fetches it and recomputes the signature; if it matches, the message has not been modified since it was signed.
Selectors let a domain run several keys side by side, say one for Microsoft 365 and one for the newsletter platform, and swap keys without interrupting mail flow. RSA keys should be 2048 bits; receivers reject keys under 1024 bits. Ed25519 (RFC 8463) can be added as a second algorithm.
For DMARC, DKIM only counts when the signing domain matches the visible From domain. A service that signs only with its own domain passes DKIM, but that pass does nothing for your domain.
Why it matters
Without a valid DKIM signature, receivers lack the strongest evidence that a message really comes from you. Since SPF routinely breaks when mail is forwarded, DMARC often depends on DKIM alone: if the key is missing or revoked, mail fails under p=quarantine or p=reject.
Outages typically happen when switching providers or rotating keys, when the new selector never makes it into DNS or an old record is deleted while a service still uses it. Very short RSA keys (512 or 768 bits) can be cracked with modest effort, which lets an attacker produce validly signed mail in your name.
How to prevent it
- Turn on DKIM for every service that sends on your behalf (mailbox provider, shop, CRM, newsletter) and have it sign with your own domain.
- Generate 2048-bit RSA keys and replace old 1024-bit keys.
- When rotating, publish the new selector first, then switch over, and delete the old record only after a few days.
- Remove testing mode (t=y) once the rollout is done.
- Document the selectors in use and add them to monitoring so a deleted record shows up right away.
How DomainWarn detects it
The DKIM check queries the domain’s key records. If selectors are configured, it checks exactly those; otherwise it tries 39 common selectors used by major providers, such as google, selector1, k1, mailgun, ionos and strato. Finding nothing is only a hint, because selectors cannot be listed from the outside.
If a configured selector is missing, DomainWarn opens a “DKIM missing” incident after two runs. Revoked keys (empty p=), missing or invalid keys, a wrong version tag, an unknown key type and multiple records under one selector lead to “DKIM invalid”, and an RSA key below 1024 bits is critical. Keys under 2048 bits and testing mode are hints. The timeline shows added and removed selectors as well as rotated keys.
The check only sees the published keys, not whether your mail is actually signed. That is what the mail test, which verifies every signature cryptographically, and the DMARC reports are for.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.