How DKIM Record Checking Works
When you enter a domain and DKIM selector, the tool constructs a DNS query for the TXT record at selector._domainkey.yourdomain.com. This is the standard location where DKIM public keys are published according to RFC 6376. The tool retrieves the raw TXT record, reassembles it if it is split across multiple DNS strings, and then parses each tag-value pair in the record. Key tags include v (version), k (key type, typically RSA), p (the Base64-encoded public key), t (flags), and h (acceptable hash algorithms).
After parsing, the checker decodes the public key to determine its bit length and validates the key against cryptographic standards. Keys shorter than 1024 bits are considered insecure, while 2048-bit keys are the current recommended minimum. The tool also detects common configuration errors such as missing or empty p= tags (which indicate a revoked key), invalid Base64 encoding, unsupported key types, and the presence of testing flags (t=y) that signal the key is not yet in production. If your domain uses multiple selectors for different email services, you should check each selector individually to ensure all signing keys are valid and properly configured.
When to Use This Tool
- Configuring DKIM for a new email service — After adding a DKIM DNS record for services like Google Workspace, Microsoft 365, or Mailchimp, verify that the record is correctly published and that the public key is valid before enabling DKIM signing.
- Investigating DKIM authentication failures — When email headers show
dkim=failordkim=neutral, use this tool to check whether the public key in DNS matches the selector being used and whether the key has been revoked or is malformed. - Rotating DKIM keys — Security best practices recommend rotating DKIM keys periodically, especially upgrading from 1024-bit to 2048-bit keys. After publishing the new key and revoking the old one, verify both selectors to confirm the transition is complete.
- Auditing domain email security — As part of a comprehensive email authentication audit alongside SPF and DMARC checks, verify that all active DKIM selectors use strong keys and that no deprecated selectors remain active in DNS.
Understanding Your Results
The results display the full DKIM record along with a parsed breakdown of every tag. The most critical element is the public key length. A key of 2048 bits or greater receives a passing status, while 1024-bit keys trigger a warning recommending an upgrade. Keys below 1024 bits are flagged as insecure because they are vulnerable to brute-force factoring attacks. If the p= tag is empty, the tool reports that the key has been revoked, meaning the selector is no longer valid for signing.
Additional details in the results include the key type (RSA or Ed25519), any flags set on the record, and whether the record is in testing mode. A t=y flag means the domain owner has indicated the key is being tested, and verifiers should treat failures more leniently. If no record is found at the queried selector, the tool reports that the selector does not exist, which could mean it was never published, was recently removed, or the selector name was entered incorrectly. For domains using multiple email providers, remember that each provider uses its own selector, so you must check each one separately.