DKIM (DomainKeys Identified Mail, RFC 6376) lets your mail server sign every message it sends. The signature names your domain (d=) and a selector (s=), and the receiving server fetches the public key from a TXT record at selector._domainkey. plus the domain to verify it. A DKIM check of DNS makes sure that record is there and usable; if it is missing or broken, every signature made with it fails.

This DKIM checker works in two ways:

• With a selector (google._domainkey.example.com): one DKIM lookup of exactly that name, as a receiver makes it.
• With a domain only: we try the 43 selectors that common mail providers use, such as google for Google Workspace and selector1 and selector2 for Microsoft 365, and a made-up name that shows whether the domain answers for any name. Selectors can be any name the sender chooses, and DNS cannot list them (RFC 6376 §3.1), so finding nothing is a warning, not proof that DKIM is missing.

For every key record found, the check reads:

• The record's syntax: v=DKIM1 first if present, valid tag=value pairs, no tag twice, one record per selector.
• The key in p=: present, not revoked, a readable RSA or Ed25519 key, and for RSA its length (RFC 8301).
• Restrictions that can stop receivers from using it: hash algorithms (h=), service types (s=) and testing mode (t=y).
• Where the key lives: a CNAME to your mail provider, who then manages the key for you.

What a DNS check cannot tell you is whether your messages are signed and the signature verifies; for that, see the DKIM test of a real message. We send no email: the check is DNS lookups through a recursive resolver, and every answer is in the Raw evidence panel under the result.

The panel at the top of the result is the verdict: a colored icon and a short label. Beside it, a short reading names the key, such as RSA 2048 · selector google, or for a domain how many common selectors hold a key. Below come the name that was looked up, the record with its key and flags, or the table of selectors that answered. Each finding links to its explanation on this page.

Pass: receivers can use the key

The record is there, readable, not revoked, and holds an RSA key of 2048 to 4096 bits or an Ed25519 key. Without a selector: at least one common selector holds such a key and nothing found is broken. Pass says the key is usable; whether your mail is signed with it is a test of a real message.

Warning: DKIM works, but something needs attention

An RSA key of 1024 bits, testing mode, a revoked key on a selector we found by trying, the same record published twice, a domain that answers for any selector name, or no key on the common selectors at all. Each is explained below.

Fail: signatures with this key cannot verify

No record at the selector you entered, a revoked key there, a record receivers must discard, a key they cannot read, an RSA key under 1024 bits, only sha1 allowed, a service type other than email, or two different records at one selector. Mail signed with that selector fails DKIM, and under DMARC it then needs SPF to pass.

Could not check

A DNS lookup the verdict depends on did not get a usable answer: it timed out, the server reported a failure (SERVFAIL) or refused. A receiver would call that a temporary failure and may try again later. We stop a check after 20 seconds and report it the same way. This says nothing about whether your key is correct. Without a selector, one unanswered selector is enough for Could not check: it might hold a broken key. Try again in a minute.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

Selectors: the name of the key

A domain can publish several keys at once, one per selector (RFC 6376 §3.1): one for Google Workspace, two for Microsoft 365, others for a newsletter tool. The signature says which one to use in s=. With a selector entered, no record at selector._domainkey. plus your domain is Fail: receivers stop with “no key for signature” (RFC 6376 §6.1.2). Check the spelling against s= of a real signature, and that the record is published under the domain in d=.

Microsoft 365 uses the pair selector1 and selector2. When the one you entered has no key but the other has a working one, that is a Warning: it may just be the selector Microsoft 365 is not signing with. When neither has a key, DKIM signing is not set up in Microsoft 365 (Fail). Without a selector, every common selector with a key is listed, which is a note marked Pass.

No key on the common selectors: how to find yours

Many senders use a selector of their own, so no key on the 43 common names is a Warning, not a failure. To find yours, open a message you sent from the domain, show its full headers (in Gmail: More, then Show original) and find the DKIM-Signature header. Its s= is the selector and d= the domain: enter s-value._domainkey.d-value above. The email header analyzer lists every signature of a pasted header with its selector. A message with no DKIM-Signature header is not signed at all: turn signing on at your provider (see how to fix). If some common selectors got no answer, the result is Could not check instead.

Record syntax

A key record is a list of tag=value pairs separated by semicolons. v=DKIM1 may be left out, but if it is there it must come first and read exactly DKIM1; otherwise receivers discard the record (RFC 6376 §3.6.1). A tag written twice makes the whole list invalid, tag names are case-sensitive (P= is not p=), and a record without p= has no key. All of these are Fail. A long key is often published as several strings; receivers join them without spaces (RFC 6376 §3.6.2.2), so that is fine.

Revoked keys: an empty p=

p= with nothing after it means the key has been revoked (RFC 6376 §3.6.1): every signature with that selector fails. On a selector you entered, that is Fail, because you asked about a key your mail may be using. On a selector we found by trying it is a Warning: a retired selector left revoked on purpose is normal. If every name answers with a revoked key, the domain declares that it signs nothing, as the UK government advises for domains that send no mail (*._domainkey v=DKIM1; p=); that is a Warning to check it is meant.

Key format

p= must hold a base64 public key of the type in k=: rsa (the default) or ed25519. An unknown k=, text that is not base64, bytes that are not a key, or a key of a different type than k= says are Fail. Two format mistakes come with a fix that keeps the same key: an Ed25519 key must be the raw 44-character key, not wrapped like an RSA key (RFC 8463 §4.2), and an RSA key written as a bare RSAPublicKey instead of the usual SubjectPublicKeyInfo form is rejected by some verifiers, so we mark it Fail too.

Key length: 1024, 2048 and more bits

RFC 8301 §3.2 says signers should use RSA keys of at least 2048 bits, and verifiers must not accept signatures made with keys under 1024 bits. So: under 1024 bits is Fail; 1024 up to 2047 bits is a Warning (it works, but move to 2048); 2048 to 4096 bits is Pass; over 4096 is a Warning, because verifiers only have to handle up to 4096. An Ed25519 key is Pass, with a note: in a test Red Sift published on April 16, 2026, Gmail, Microsoft 365 and Yahoo did not verify Ed25519 signatures, so sign with an RSA key as well. How to change a key without breaking mail: replacing a key.

Hash algorithms: h=

h= limits which hash algorithms the key may be used with. RFC 8301 §3.1 says rsa-sha1 must not be used for signing or verifying, so a key restricted to sha1 is Fail, and so is any h= without sha256. Remove h= or set h=sha256, and make sure your server signs with rsa-sha256.

Service type: s=

In a key record, s= lists the services the key is for. Receivers must ignore a record whose s= lists neither email nor * (RFC 6376 §3.6.1), so such a key is Fail. Remove the tag (the default is *) or set s=email.

Testing mode: t=y

t=y says the domain is testing DKIM. RFC 6376 §3.6.1 tells receivers not to treat mail signed with a key in testing mode differently from unsigned mail, even if the signature fails to verify, so a signature that fails while you set DKIM up costs you no more than sending unsigned mail. It is a Warning: remove t=y once signing works.

More than one record for a selector

Each selector may have only one TXT record; with several, the result is undefined (RFC 6376 §3.6.2.2) and a receiver may take any of them. Two different records, for example an old and a new key, are Fail; the same record twice is a Warning. Keep one record per selector and publish a new key under a new selector instead.

Keys hosted by your provider: CNAME records

Microsoft 365, SendGrid, Mailgun, Amazon SES and others ask you to publish the selector as a CNAME that points to a name they manage, so they can change the key without your help. We follow the CNAME and check the key at its end, and name the provider when the target shows it; that note is marked Pass. A CNAME whose target has no key, found by trying, is listed as a note too; it does not affect mail signed with another selector. We saw it on github.com on September 28, 2026: selector1 held a key, selector2 pointed to Microsoft with none.

Wildcard answers

Some domains answer every name under _domainkey with the same record (a wildcard). Then every selector we try seems to have a key, so we also look up a made-up selector: records identical to its answer prove nothing and are not counted as keys (Warning). If that lookup got no answer, we cannot tell a wildcard from real keys, and the result is Could not check.

DKIM is switched on where your mail is sent, not in DNS alone: the provider creates the key, signs your mail with it and gives you the record to publish. Most problems the check finds come with a fix in the result. The rules at every DNS host:

1. Publish exactly what the provider gives you, as a TXT or CNAME record, at the name selector._domainkey (most DNS hosts add your domain themselves).
2. One record per selector. A new key goes under a new selector, not next to the old record.
3. At Cloudflare, keep a DKIM CNAME set to DNS only: a proxied name is answered with Cloudflare's own addresses instead of the CNAME, so receivers never reach the key.
4. Then turn signing on at the provider, and check the selector here. A result is reused for 60 seconds, so wait a minute after publishing.

Google Workspace, Microsoft 365 and sending services

• Google Workspace: in the Admin console go to Menu > Apps > Google Workspace > Gmail > Authenticate email, generate a record (2048 bits if your DNS host accepts it; the default selector is google), publish the TXT record at google._domainkey, then select Start authentication. Google says it can take up to 48 hours to start working.
• Microsoft 365: in the Microsoft Defender portal go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, open your domain and publish the two CNAME records it shows for selector1._domainkey and selector2._domainkey (take the values from the portal). Then turn on Sign messages for this domain with DKIM signatures.
• Zoho Mail: you name the selector in the Zoho admin console, choose 1024 or 2048 bits (choose 2048), publish the TXT record it shows and select Verify.
• SendGrid: domain authentication gives CNAME records for s1._domainkey and s2._domainkey.
• Mailgun: Automatic Sender Security uses the CNAME records pdk1._domainkey and pdk2._domainkey.
• Amazon SES: Easy DKIM gives three CNAME records to publish for the verified domain.
• Your own mail server: create a key pair with the DKIM generator and publish its record; its page has the steps for Cloudflare, GoDaddy and Namecheap.

Replacing a weak or broken key without breaking mail

1. Create a new 2048-bit key at your provider, or with your own server, under a new selector.
2. Publish its record and check the new selector here until it passes.
3. Switch signing to the new selector and send yourself a test message.
4. Only then remove the old record, or revoke it with an empty p=. Never remove the record of the selector your mail is still signed with: every such message then fails DKIM.

With Microsoft 365, SendGrid, Mailgun or Amazon SES the key sits behind their CNAME records and the provider changes it; you only keep the CNAMEs in place.

A published key does not prove that your mail is signed with it. To test DKIM on a real message:

• Run the deliverability test: send one email to the address it gives you and see whether the DKIM signature verified, for which domain, and how SPF and DMARC came out.
• Read the headers of a message you sent to a mailbox you can open: the receiver's Authentication-Results header should show dkim=pass for your domain. Paste them into the email header analyzer to see each signature and its result.

If the message has no DKIM-Signature header, signing is off at your provider. If it has one but fails, check its selector here: a missing or changed key is the most common cause.

A DKIM key is an ordinary TXT record at selector._domainkey. plus the domain, so dig or nslookup shows it if you know the selector:

dig TXT google._domainkey.example.com +short
nslookup -type=TXT google._domainkey.example.com 1.1.1.1

On September 28, 2026 our own 2048-bit key came back as two strings, which receivers join into one record:

$ dig TXT google._domainkey.mxverdict.com +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmZnUPHxsU1SL6w8A…" "aG/tYDJU7+Ci++MeLkggF8Jjthnyix06UAQ7lICQWSrO1u80KLFMs3jZ…"

A key hosted by a provider shows the CNAME first; GitHub's Microsoft 365 selector the same day:

$ dig TXT selector1._domainkey.github.com +short
selector1-github-com._domainkey.microsoft.onmicrosoft.com.
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZC/z2cK+2s1f…"

(Keys shortened here.) A command line cannot guess a selector, check the key's length or tell a revoked key from a working one; the checker above does.