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.