DKIM Checker

How to use this DKIM checker

DKIM uses a selector to find a public key in DNS. The sender signs the message with a private key, and the receiver looks up the public key at selector._domainkey.example.com. Because selectors are chosen by the sending platform, no scanner can discover every possible selector automatically. This tool checks a fixed list of common selectors and also supports a manual selector so you can test the exact value from Google Workspace, Microsoft 365, SendGrid, Mailgun, Amazon SES, Zoho, Fastmail, Proton, or another provider.

A domain can have several DKIM selectors at the same time. This is normal during key rotation and when several services send mail for the same domain. The scanner displays every selector it finds, not only the first one. This matters because one healthy selector does not make the whole DKIM posture clean if another old selector is weak, revoked, or still published with an empty p tag. A weak or revoked selector should be removed or rotated with the provider that owns it.

For RSA keys, 2048-bit or stronger is the preferred baseline. Some older systems still publish 1024-bit RSA keys. Those should be planned for upgrade. Very small RSA keys should be treated as high risk. Ed25519 DKIM keys are handled separately because they do not use RSA bit length. If the scanner finds a key but cannot parse the size, it will say so instead of guessing.

DKIM alone does not stop spoofing. DKIM proves that a message was signed by a domain or service, but DMARC decides whether the visible From domain aligns with SPF or DKIM and what the receiver should do when alignment fails. For real protection, use DKIM with SPF and an enforcing DMARC policy. During a manual assessment, VAPT Experts can confirm whether the signatures used by your mail flows actually align with your visible From domain.

Common DKIM mistakes this tool finds

• No common DKIM selector found, with a clear note that custom selectors may exist.
• Empty p tag, which usually means the key is revoked.
• RSA keys that are too small for current security expectations.
• Unknown key types that require manual review.
• Multiple selectors where at least one selector is weak or misconfigured.

DKIM remediation workflow

DKIM should be enabled on every platform that sends legitimate email for the domain. Microsoft 365, Google Workspace, CRMs, marketing platforms, helpdesk systems, and transactional email providers often use different selectors. That is why this scanner checks a fixed list of common selectors and also supports a manual selector. If no common selector is found, the correct next step is to check your mail platform documentation or DNS console for the exact selector name.

Old selectors should not be left behind forever. A selector with an empty p value is revoked, but stale selectors with weak keys can create confusion and reduce confidence in the domain posture. A mature DKIM setup uses current keys, rotates them periodically, removes unused records, and confirms that outgoing mail is signed by the correct provider. For RSA keys, 2048-bit or stronger is preferred. Ed25519 keys are modern and should not be judged by RSA bit length.

DKIM does not prove that mail is safe or wanted. It proves that a message was signed by a key published in DNS and that signed parts of the message were not changed. DMARC still decides whether that DKIM signature aligns with the visible From domain. If DKIM exists but DMARC is missing or p=none, spoofing protection is still incomplete.