How DKIM signing and verification work
DKIM (DomainKeys Identified Mail) lets your mail server sign each outgoing message with a private key. The matching public key is published in DNS as a TXT record at selector._domainkey.yourdomain.com. Receivers read the selector from the DKIM-Signature header, fetch the public key and verify that the message body and key headers were not altered in transit.
A valid signature proves the message really came from a server holding your private key. For DMARC to pass on DKIM, the d= domain in the signature must align with the From domain. That alignment is what protects cold email domains from spoofing and is why Gmail and Microsoft require DKIM from bulk senders.
google._domainkey.yourdomain.com TXT
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...Finding your DKIM selector
The selector is the label before _domainkey and every provider picks its own. Google Workspace defaults to google, Microsoft 365 uses selector1 and selector2, and most sending platforms use short names like k1, s1 or pm. Some providers publish the record as a CNAME that points to their own DNS, which is fine because resolvers follow it.
When in doubt, send yourself a message from the domain, open the original headers and read the DKIM-Signature line. The value after s= is the selector and the value after d= is the signing domain. Paste that selector into the checker for a direct lookup rather than a scan.
- Google Workspace: selector google, generated in Admin console under Authenticate email.
- Microsoft 365: selector1 and selector2, published as CNAMEs to onmicrosoft.com.
- Sending platforms usually show the selector on their domain authentication page.
- Selectors can rotate; check again after enabling a new key.
Key length and why 1024-bit is no longer enough
The checker estimates key length from the base64 public key. RSA keys of 2048 bits are the current recommendation and are what Google Workspace and Microsoft 365 issue by default. Older 1024-bit keys still verify but are considered weak, and some providers refuse to sign with anything shorter. Ed25519 keys are a modern alternative that is compact and strong, though not every receiver verifies them yet, so keep an RSA selector alongside.
If you see a 1024-bit key, rotate it in your provider's DKIM settings, publish the new record, wait for DNS to propagate, then switch signing over. InboxOne provisions 2048-bit DKIM on every Google Workspace mailbox it creates so this never has to be done by hand.
DKIM flags and tags that quietly break authentication
A record can be published and still give you no protection. The t=y flag puts the key in test mode, telling receivers to ignore failures. An empty p= revokes the key entirely. Restricting hashes with h=sha1 or service types with s= that excludes email will cause verification to fail at major providers. Each of these is flagged by the checker with the exact tag to change.
- Remove t=y once you have confirmed that signatures verify.
- Never leave p= empty unless you intend to retire the selector.
- Split long keys into multiple quoted strings if your DNS host limits string length to 255 characters.
- Do not add line breaks or spaces inside the base64 key when pasting.
