Identify the active selector
Send a mail to Gmail or Outlook and look at the headers: DKIM-Signature: … d=example.com; s=selector1; …. s= is the active selector.
Tool
Tests the common selectors (default, google, selector1/2, k1, mail and others) and reports where a DKIM public key was found. We automatically try the 11 most common selector names.
Permalink:?domain=… works too.
—
——
—
—
DKIM (DomainKeys Identified Mail) complements SPF with a cryptographic signature. While SPF only checks whether the sending IP is authorized, DKIM signs selected header fields and the mail body with a private key. Receiving servers fetch the corresponding public key from DNS and verify, if the signature matches, the mail is guaranteed to be unaltered and to originate from a system with access to the private key.
The public key is stored in a TXT record at the hostname <selector>._domainkey.<domain>. The selector is a freely chosen name, common ones are default, google, selector1/selector2, k1, mail. Multiple selectors in parallel enable key rotation without downtime and independent keys per sender.
An incoming mail carries a DKIM-Signature: header line with selector (s=), signing domain (d=) and the signature. The receiver looks up the public key, verifies cryptographically and reports the result as dkim=pass or dkim=fail. For DMARC alignment, d= must additionally match the From domain.
Sending runs on a new selector, the old one is orphaned in DNS. Check tools report it as valid even though it no longer signs anything. Clean up, otherwise the record looks confusing when debugging.
Standard before 2015, too weak today. Recommendation: RSA-2048. Check tools often already flag 1024-bit keys as warn. Rotating to 2048 bit is bread and butter.
The sender signs with selector X, but there's no TXT under X._domainkey.… in DNS. Result: dkim=fail. Common after a provider switch or DNS migration.
Two records under the same selector hostname → receivers take the first one or reject both. Exactly one TXT with v=DKIM1 per selector.
Keys older than 12 months, uncritical in normal operation, but devastating if the key is compromised. Running two selectors in parallel and rotating every six months is common practice.
2048-bit keys don't fit into a 255-byte string and must be split. Some DNS providers split them incorrectly automatically. Test: dig TXT ….
Sender uses custom names like v1, 2024a. Generic check tools only try 10-15 standard names, the custom selector then incorrectly appears as "missing". Manual dig required.
Send a mail to Gmail or Outlook and look at the headers: DKIM-Signature: … d=example.com; s=selector1; …. s= is the active selector.
Create a new selector at your sending provider with key length 2048 bit, publish the public key as TXT in DNS, switch the sending system to the new selector.
selector2._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"
Wait 1-2 weeks, during this time mail providers still deliver mail with the old signature from caches. Only then remove the old TXT.
The aggregate reports show DKIM pass + alignment per IP. If all sources return dkim=pass + aligned, the setup is clean.
The full SelfCheck additionally tests SPF/DKIM/DMARC, BIMI, MTA-STS, TLS-RPT, DNSSEC and MX in a single run.
Start full SelfCheck →<selector>._domainkey.<domain>. Multiple selectors allow parallel keys for different senders or for key rotation without downtime.warn. Check the selector manually with dig TXT <selector>._domainkey.<domain>.d= tag must additionally match the From domain.