DKIM Record Checker

Check whether a domain publishes a DKIM key. Enter your selector if you know it, or leave it blank and we will try the common ones.

Free · needs a free account · reads public data only

See your results in one click. Sign in with Google, then run any of the 150 free tools.

Continue with Google
DKIM Record Checker — dkim checker

A DKIM checker confirms that a domain publishes the public key receivers need to verify its email signatures. Our tool looks up the TXT record at selector._domainkey on your domain. Give it your selector and it checks that one exact location; leave the box empty and it tries a list of common selectors used by Google Workspace, Microsoft 365 and popular sending platforms. Every key it finds is shown in full, and revoked keys are flagged. The short answer: if a TXT record with a public key (the p= tag) exists at selector._domainkey.yourdomain for the selector in your DKIM-Signature header, receivers can verify your signatures; if it is missing, empty or truncated, DKIM fails and DMARC has to rely on SPF alone.

How to use the DKIM checker

  1. 1 Enter your domainType the domain that signs your email, such as example.com, or paste an email address and we will use its domain.
  2. 2 Add your selector if you know itEnter the s= value from the DKIM-Signature header of an email you sent. Leave it blank to try the common selectors automatically.
  3. 3 Run the DKIM lookupSign in with your free account and run the check. Results for each domain and selector are cached for about ten minutes.
  4. 4 Review each key foundEach published key appears as a pass with its full record. A warning means no key was found, or that a selector has been revoked.

What DKIM does

DKIM adds a cryptographic signature to every email you send. Receivers fetch your public key from DNS at selector._domainkey.yourdomain and use it to confirm the message really came from you and was not altered.

What this checker looks at

For each key it finds, it follows a CNAME to the platform that hosts the key, names the provider where it can, measures the RSA key length (under 1024 bits is rejected, 2048 is recommended), and flags test mode (t=y), SHA-1-only keys, revoked keys and records that will not parse. Each tag is listed with what it means.

Why the selector matters

DNS cannot list every DKIM key on a domain — you have to know the selector. Google Workspace uses "google", Microsoft 365 uses "selector1" and "selector2"; other platforms tell you theirs when you set DKIM up. Running your own mail server? Create a key with the DKIM Record Generator.

What a DKIM record check confirms

DomainKeys Identified Mail, defined in RFC 6376, lets a sending server sign each outgoing message with a private key. The signature travels in a DKIM-Signature header, and the matching public key is published in DNS so any receiver can verify it. If the signature checks out, the receiver knows the message was authorized by the signing domain and that the signed headers and body were not changed in transit.

A DKIM record check answers the first practical question: is the public key actually published where receivers will look for it? If the key is missing, mistyped or revoked, every message signed with that selector fails DKIM, and DMARC then has to rely on SPF alone.

How DKIM signing and verification work

Each DKIM-Signature header carries two values that matter here: d=, the signing domain, and s=, the selector. The receiver joins them to build the DNS name selector._domainkey.domain, fetches the TXT record there and reads the public key from its p= tag. It then uses that key to check the signature against a hash of the signed headers and the message body.

Selectors exist so one domain can have several keys at once, one per sending service, and so keys can be rotated without downtime: you publish a new selector, switch signing to it, then retire the old one. Because DNS cannot list every name under _domainkey, nobody can discover your selectors without seeing a signed email. That is why our DKIM checker either needs your selector or tries the names that providers commonly use, including default, google, selector1, selector2, k1, k2, s1, s2, dkim, mail, smtp and a few platform-specific ones.

Reading the DKIM checker results

We treat a TXT record as a DKIM key if it contains v=DKIM1 or a p= tag. When the automatic search finds keys on several selectors, each one is listed separately, which is common when a domain uses more than one sending service.

  • DKIM key found (selector "name"), pass: a key is published at that selector and we show the full record, including the key type and public key.
  • Selector "name" is revoked, warning: the record exists but its p= tag is empty. That is how a key is deliberately retired, and any mail still signed with it will fail DKIM.
  • DKIM not found, warning: no key exists on the selector you entered, or on any of the common selectors if you left the box blank. This does not prove DKIM is off, as you may use a custom selector.

Finding your DKIM selector to check

The quickest way to get an exact answer from a DKIM check is to use the selector your mail is really signed with. Send an email from the account or platform you want to test to a personal mailbox, then open the original message: in Gmail use Show original, and in Outlook open the message properties or view source. Find the DKIM-Signature header and note the s= value and the d= value.

Enter the d= domain and the s= selector in our checker. If d= shows your email platform's domain rather than yours, the platform is signing on its own behalf, and you need to set up custom DKIM in that platform before the signature can align for DMARC. Repeat this for each service that sends as your domain, because each one usually has its own selector.

How to set up or fix DKIM with your provider

DKIM keys are generated by whoever sends your mail, so the fix always starts in that provider's admin area rather than in DNS.

In Google Workspace, open the Admin console, go to Apps, Google Workspace, Gmail, Authenticate email, choose your domain and generate a new record, picking 2048-bit where your DNS host supports it. Publish the TXT record at google._domainkey, wait for it to propagate, then return to the Admin console and click Start authentication. Until you click it, Google keeps signing with its own default domain rather than yours, which does not align for DMARC.

In Microsoft 365, open the Microsoft Defender portal, go to Email authentication settings, DKIM, select your custom domain and follow the prompts. Microsoft gives you two CNAME records for selector1._domainkey and selector2._domainkey that point to keys it hosts and rotates. Once both CNAMEs are live, enable signing. A DNS lookup follows the CNAME to the key, so our checker sees it exactly as a receiving server would.

On cPanel hosting, open Email Deliverability, where cPanel shows the DKIM record for the domain and can install it for you if the DNS is hosted on the same server. If your DNS lives elsewhere, for example in Cloudflare, copy the record from cPanel and add it as a TXT record in Cloudflare with the name default._domainkey. For newsletter and transactional platforms, look for an option called domain authentication or custom DKIM, which usually gives you CNAME records to add. If you run your own mail server, the DKIM Record Generator creates a 2048-bit key pair and the TXT record in your browser.

DKIM key length, record size and rotation

RFC 8301 requires verifiers to reject RSA keys shorter than 1024 bits and recommends signers use at least 2048 bits. A 2048-bit public key is longer than the 255-character limit for a single DNS string, so it has to be published as several quoted strings in one TXT record. Most modern DNS panels split it for you. If yours does not, the key may be truncated and signatures will fail, so check the full record our tool returns against the one your provider gave you.

Rotate keys periodically, for example once or twice a year, and immediately if you suspect a private key has leaked. Publish the new selector first, switch signing over, wait a few days for in-flight mail to be delivered, then empty the old key's p= tag or remove the record. Ed25519 keys, defined in RFC 8463, are also valid but not every receiver verifies them yet, so they are normally used alongside an RSA key rather than instead of one.

Why DKIM matters for Gmail, Yahoo and Outlook delivery

Since February 2024, Gmail and Yahoo require bulk senders to sign mail with DKIM, and they strongly recommend it for everyone. Microsoft brought in comparable rules for high-volume senders to Outlook.com addresses in 2025. DKIM is also the authentication method DMARC relies on most, because it survives forwarding and mailing lists where SPF breaks.

For DMARC to count a DKIM pass, the d= domain must align with your From domain. A key signed by your email platform's own domain does not help, which is why running a DKIM check on your own domain, with your own selector, is worth doing for every service that sends on your behalf. Then check the other two pieces: the SPF checker for your sending servers and lookup count, and the DMARC checker for the policy that ties them together.

Examples you can copy

RSA DKIM key published as a TXT record at google._domainkey.example.com (key shortened)

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3...IDAQAB

A 2048-bit key split into two quoted strings in one TXT record (key shortened)

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5f..." "...q8XcQIDAQAB"

Microsoft 365 style CNAME for a hosted, rotated key

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com

Revoked key: the record stays but the p= tag is empty

v=DKIM1; k=rsa; p=

Common mistakes to avoid

Publishing the key but not turning signing on

In Google Workspace and Microsoft 365, adding the DNS record is only half the job. Go back to the admin console and enable signing, or your mail goes out unsigned by your domain.

Adding the domain twice in the host name

Entering google._domainkey.example.com in a panel that appends the domain creates google._domainkey.example.com.example.com. Enter only google._domainkey as the host.

Truncating a long key

Some panels silently cut values at 255 characters. Split the key into quoted strings in one TXT record and compare the published value with the original.

Line breaks or spaces inside the key

Copying from a PDF or email can insert breaks into the base64 key, which makes it invalid. Paste it into a plain text editor first and remove any whitespace inside the p= value.

Deleting an old selector too early

Mail signed just before a rotation may still be in transit. Keep the old key for a few days after switching, then revoke it.

Frequently asked questions

Open the headers of an email you sent and look for the DKIM-Signature line: the s= value is the selector and d= is the signing domain.

Use a 2048-bit RSA key where your provider supports it. 1024-bit keys are still accepted but are the minimum, and keys shorter than that are rejected.

Not necessarily. If you use a custom selector we did not try, enter it above. If your provider has no DKIM set up, enable it in their admin panel and publish the record they give you.

Yes. Each selector holds its own key, so you can have one for Google Workspace, another for your newsletter platform and another for your CRM, all on the same domain.

The receiver found your key but the signature did not verify, usually because the message was altered in transit or the published key does not match the private key used to sign.

The key itself is always read from a TXT record. Many providers ask you to add a CNAME that points to a TXT record they host, so they can rotate the key for you.

No. DKIM signs messages to prove who sent them and that they were not changed. Encryption in transit is handled separately by TLS, and MTA-STS can enforce it.

Every six to twelve months is a sensible routine for a small business. Providers that host keys through CNAMEs, such as Microsoft 365, can rotate them for you.

Free website audit

See how your site scores, free

Speed, SEO, DNS, email (SPF/DKIM/DMARC) and security in one scan, with a prioritised fix list.