Free DKIM record checker

DKIM, or DomainKeys Identified Mail, lets a receiving mail server verify that a message was signed by an authorized sender and was not changed after signing. The sender adds a cryptographic signature to the message, while the domain publishes the matching public key in DNS.

A DKIM record is normally published at a selector-specific name such as s1._domainkey.example.com. The selector allows a domain to use different keys for different providers and rotate keys without replacing every signing setup at once.

Enter the domain used for sending email, then add the selector supplied by your email service. The checker queries the selector record and reports the exact DNS name, live value, signing algorithm, public-key length, warnings, and errors.

If you do not know the selector, leave that field blank to try common names. A more reliable method is to send a message through the provider and inspect its DKIM-Signature header. The selector appears after s=, and the signing domain appears after d=.

A useful DKIM record test should help you confirm:

• The selector resolves at the expected _domainkey DNS name.
• The published value contains a recognizable DKIM public key.
• The key algorithm and length are suitable for the sending setup.
• The record does not contain formatting or configuration errors.
• The selector is ready to be checked against a real signed message.

DNS validation is an important first step, but it does not prove that your sender is using the record. Use the email header analyzer on a delivered test message and confirm that Authentication-Results reports dkim=pass for the expected domain and selector.

A selector identifies one public key beneath a domain. For example, the selector mail2026 on example.com is queried at mail2026._domainkey.example.com. Providers often choose names such as s1, s2, google, or a dated value.

Multiple selectors can be valid at the same time. This makes safe key rotation possible: publish the new selector, wait for DNS propagation, switch the sender, verify real messages, and only then retire the old record.

DKIM checks often uncover one of these problems:

• The selector is missing, misspelled, or published beneath the wrong domain.
• The public key was truncated, split, or quoted incorrectly by the DNS provider.
• The sender was switched to a new selector before its DNS record propagated.
• An old selector was removed while queued messages were still using it.
• DKIM passes, but the signing domain does not align with the visible From domain.

When a record looks correct but a real message still fails, compare the record with the message headers. The sending platform may be using a different selector, signing domain, or canonicalization setup than expected.

DKIM proves that a message carries a valid signature tied to a domain. SPF checks whether the sending server is authorized. DMARC evaluates whether SPF or DKIM passes in alignment with the visible From domain and applies the domain owner's policy.

Check all three records when onboarding a sender or investigating delivery problems. Continue with the SPF checker and DMARC checker, then use an inbox placement test to see where the authenticated message actually lands.

A one-time DKIM lookup is useful during setup and troubleshooting. Sender configuration can still drift later when DNS records, providers, selectors, or policies change. Recurring domain monitoring helps teams find those changes before they become persistent delivery failures.

MailSlurp can monitor SPF, DKIM, DMARC, BIMI, MX, MTA-STS, and TLS reporting alongside inbox placement and message testing. Review the domain authentication monitoringworkflow to connect DNS health with real email deliverability.