Verify the DKIM (DomainKeys Identified Mail) record for any domain and selector.
Also check: SPF Record Checker · DMARC Record Checker.
Checking a DKIM record only takes a few seconds:
example.com.default, google, selector1, or a provider-specific value._domainkey hostname.If no DKIM record is found, first confirm that both the signing domain and selector are correct. A domain can use multiple selectors, and different email services may use different DKIM keys.
The DKIM Checker retrieves the DNS record associated with the domain and selector you provide.
The DNS hostname being checked follows this format:
selector._domainkey.example.com
For example, if the signing domain is:
example.com
and the selector is:
google
the DKIM record is queried at:
google._domainkey.example.com
A DKIM record was found in DNS for the domain and selector you entered.
A typical DKIM public-key record looks similar to:
v=DKIM1; k=rsa; p=PUBLIC_KEY
The p= value contains the public key that receiving mail servers can use when verifying DKIM signatures created with the corresponding private key.
Finding the record confirms that the DKIM key is published in DNS. It does not confirm that your outgoing email is currently being signed with that key or that a particular message passes DKIM verification.
To verify actual DKIM signing, send a message through the relevant email service and inspect its authentication results or DKIM-Signature header.
The checker could not find a DKIM record for the domain and selector you entered.
This does not necessarily mean DKIM is completely missing from the domain. The most common cause is an incorrect selector.
Check your email provider’s DKIM configuration or inspect the DKIM-Signature header of a message sent through the service to find the selector and signing domain actually being used.
The p= tag contains the public key used by receiving mail systems to verify DKIM signatures associated with that selector.
For example:
p=MIIBIjANBgkqh...
The corresponding private key remains with the sending system and should never be published in DNS.
If the public key is missing or has been revoked, messages signed with the corresponding private key cannot be successfully verified using that DKIM record.
DKIM records can identify the type of public key using the k= tag.
For example:
k=rsa
indicates an RSA public key.
If the k= tag is omitted, RSA is the default under the original DKIM specification.
Your email provider normally generates and manages the key pair, so you should follow its DKIM setup instructions rather than manually modifying the public key.
DKIM (DomainKeys Identified Mail) is an email authentication standard that uses cryptographic signatures to associate a signing domain with an email message.
When an email service signs a message with DKIM, it adds a DKIM-Signature header containing information about the signature, including the signing domain and selector.
Two particularly important values are:
d= — the DKIM signing domain
s= — the DKIM selector
A receiving mail server uses these values to determine where to retrieve the corresponding public key from DNS.
For example, a signature containing:
d=example.com; s=selector1
causes the public key to be queried at:
selector1._domainkey.example.com
The receiving system can then use the public key to verify the cryptographic signature and confirm that the signed content has not changed since it was signed.
DKIM does not encrypt the email, hide its contents, or hide the sender’s IP address.
A DKIM selector is a label that identifies a specific public key within a signing domain.
A domain can publish multiple DKIM keys by assigning each one a different selector.
For example:
google._domainkey.example.com
selector1._domainkey.example.com
marketing._domainkey.example.com
These could all represent different DKIM keys associated with the same domain.
Selectors allow organizations and email providers to manage multiple keys simultaneously. They are also useful for key rotation because a new key can be published under a new selector before an older key is retired.
The selector itself does not need to be secret. It is included in the DKIM-Signature header of signed emails.
If you don’t know your selector, the easiest method is usually to inspect an email sent through the service you want to check.
Use a message that was actually sent through the email provider or application whose DKIM configuration you want to verify.
Depending on your email client, this may be called:
DKIM-Signature headerSearch the headers for:
DKIM-Signature:
A simplified example might contain:
d=example.com; s=selector1;
d= and s=The value after d= is the DKIM signing domain.
The value after s= is the DKIM selector.
For example:
d=example.com
s=selector1
means the public key should be available at:
selector1._domainkey.example.com
You can enter example.com and selector1 into the DKIM Checker to retrieve the published record.
Using the wrong selector is one of the most common reasons a DKIM lookup returns no record.
A domain does not have one universal DKIM selector. Different email providers can use different selectors, and selectors can change when keys are rotated.
Inspect a recently sent message or check your provider’s DKIM configuration to confirm the selector currently in use.
The domain in the visible From: address is not necessarily the same domain used for the DKIM signature.
When checking a DKIM record from an actual message, use the domain shown in the d= value of its DKIM-Signatureheader.
The combination of d= and s= determines the DNS location of the DKIM public key.
Finding a DKIM record in DNS does not prove that your email provider is actively signing outgoing messages with it.
DKIM signing normally needs to be enabled in the sending platform.
To verify that signing is active, send a real message and inspect its headers for a DKIM-Signature and the resulting authentication status.
Domains can accumulate DKIM records for services or keys that are no longer used.
An old DKIM record does not necessarily cause authentication problems, but obsolete keys should be reviewed as part of normal email-security maintenance.
Before removing a DKIM selector, make sure no active email service is still signing messages with the corresponding private key.
A message can pass DKIM authentication and still fail DMARC.
DMARC requires the domain authenticated by DKIM to align with the domain shown in the visible From: address.
For example, a message might contain:
From: billing@example.com
while the DKIM signature uses:
d=email-provider.example
The DKIM signature may be cryptographically valid, but the domains may not satisfy DMARC alignment.
This is why DKIM should be considered alongside SPF and DMARC rather than as a standalone anti-spoofing control.
FAQ
DKIM supports multiple public keys for the same signing domain.
The selector identifies which specific key should be retrieved from DNS.
The combination of the selector and signing domain determines the DNS hostname:selector._domainkey.example.com
Without the selector, the checker does not know which DKIM key to retrieve.
Yes.
A domain can publish multiple DKIM records using different selectors. This allows different email services to maintain separate keys and makes DKIM key rotation possible without immediately removing an existing key.
For example:google._domainkey.example.com
and:marketing._domainkey.example.com
can contain different DKIM public keys for the same domain.
DKIM key rotation is the process of replacing an existing cryptographic signing key with a new one.
Selectors make rotation easier because the new public key can be published under a new selector while the previous key remains available temporarily.
A typical rotation process is:
1. Generate or provision a new DKIM key pair.
2. Publish the new public key under a new selector.
3. Begin signing outgoing messages with the new private key and selector.
4. Confirm that messages using the new key verify successfully.
5. Retire the old selector after it is no longer required.
Your email provider may automate some or all of this process.
There is no universal DKIM rotation interval that applies to every organization or email provider.
Rotation practices depend on factors such as the provider, key-management capabilities, security requirements, and organizational policy.
If your email provider manages DKIM keys automatically, follow its documented rotation process. If you manage your own keys, establish a rotation policy appropriate for your security requirements and replace a key immediately if its private key may have been compromised.
No.
DKIM provides cryptographic authentication and integrity checking for signed portions of a message. It does not encrypt the email's contents.
Other technologies, such as TLS during mail transport or end-to-end encryption systems, address different aspects of email confidentiality.
No.
DKIM does not hide the route an email takes or the IP addresses that may appear in its headers.
Its purpose is to attach a verifiable cryptographic signature to an email message.
No.
This checker retrieves the DKIM public-key record published in DNS for the domain and selector you provide.
It does not inspect an email, calculate its body hash, or verify its DKIM-Signature.
To determine whether an actual message passes DKIM, send a test email through the relevant service and inspect the authentication results in the received message.
DKIM authentication and DMARC alignment are related but different checks.
A DKIM signature can be cryptographically valid even when its d= signing domain does not align with the domain shown in the visible From: address.
DMARC requires at least one aligned authentication mechanism—SPF or DKIM—to pass.
As a result, dkim=pass does not automatically mean dmarc=pass.
DKIM provides cryptographic authentication for email, but it is most effective when deployed alongside SPF and DMARC.
SPF identifies authorized sending infrastructure, while DMARC checks whether SPF or DKIM authentication aligns with the domain shown in the visible From: address and allows the domain owner to publish a handling policy for messages that fail DMARC.
If you're configuring email authentication for a domain, read our How to Set Up SPF, DKIM, and DMARC for Email Authentication guide for the complete deployment process.
Try UptimeObserver now. Setup in 2 minutes.