DKIM checker for all your domains

Your sending service signs each message with a private key and adds a DKIM-Signature header to it. Two tags in that header name the key: d= is the signing domain and s= is the selector. The receiver fetches the matching public key from a TXT record at <selector>._domainkey.<domain> and checks the signature against it (RFC 6376 section 3.6.1).

A domain can publish many DKIM keys, one per selector, so Google, Resend and a newsletter tool can each sign with a key of their own without touching the others. This DKIM record checker reads every selector on its own. Keys don't carry over to subdomains: if mail is signed as updates.yourdomain.com, that name needs its own key, and our guide to DKIM on a subdomain shows one published on a live domain.

Each domain gets one verdict pill:

• DKIM found (green): at least one selector holds a key receivers can use, and nothing else needs fixing.
• Found, with a warning (amber): a usable key is there, but a live key is still in testing mode (t=y), or another selector is broken: a CNAME that points nowhere, an unreadable key, or two records at one name.
• Revoked key only (amber): every key we found has an empty p=.
• DKIM broken (red): we found selectors, but none of them holds a usable key.
• No key at these selectors (amber): nothing at any selector we tried. This is amber, not red, because DNS has no way to list a domain's selectors, so a key under a name we didn't try stays out of sight.
• Couldn't check (grey): DNS didn't answer in time. Run it again in a minute.
• Doesn't exist in DNS (grey): the name has no records at all. Check the spelling.

Next to the pill, each selector we found gets a chip with its key badge, like google · RSA 2048, selector2 · RSA 1024 or fm1 · revoked. When a selector is a CNAME into a sender we recognize, the row names that sender. We only go by where the CNAME points, never by the selector name, since a name like default is used by many hosts.

Open a domain to see each selector's record name, the CNAME it follows, the raw record with a copy button, the parsed tags (p= shown as its length plus its first and last 8 characters) and every finding with its fix. If a zone answers any name under _domainkey with the same wildcard record, the checker says so and doesn't count those answers as keys.

The selector is the label before ._domainkey in the record name. There are three ways to find yours:

1. Open a message you sent from the domain and view its original (in Gmail: the three dots, then Show original). In the DKIM-Signature header, s= is the selector and d= is the domain it signed for.
2. Open your sender's DNS settings page. The record name before ._domainkey is the selector.
3. Leave the selector field empty, and the checker tries every selector in the table below.

Selectors checked on 31 October 2026. Each sender's name links to its own DKIM help page. Many cPanel hosts also use default, so a key there doesn't mean Porkbun.

Postmark, and Mailyond, which sends through it, use a dated selector ending in pm that changes when the key rotates, so no checker can guess it. Amazon SES uses three generated tokens. Paste yours, or the full host name, like 20260905115320pm._domainkey.updates.yourdomain.com, and the checker splits it into selector and domain.

Each sender keeps its own selector, which is why two senders on one domain don't clash.

RFC 8301 section 3.2 sets the rules for RSA keys: signers must use at least 1024 bits and should use 2048, and receivers must not accept a signature made with a key under 1024 bits. The key badge follows it:

• RSA 2048 or longer: green.
• RSA 1024 to 2047: green, with a note. It meets the minimum, and it's the default key size in Microsoft 365's New-DkimSigningConfig.
• RSA under 1024: red. Receivers have to treat those signatures as invalid.
• Ed25519: green. A shorter key type (RFC 8463) that some senders publish next to an RSA key.
• revoked: the p= tag is empty.
• unreadable key: p= doesn't decode to a key.

Our take: use 2048 where your sender lets you choose. Google Workspace and Zoho let you pick it when you generate the key, and Microsoft 365 switches on the next rotation (Rotate-DkimSigningConfig -KeySize 2048). If your sender only offers 1024, that's still valid.

A 2048-bit key is longer than one 255-character DNS string, so the record is stored as two or more strings that get joined on lookup. That's fine. What breaks keys is pasting: a value that lost its end, picked up a space or kept extra quotes is the usual cause of an unreadable key.

The checker looks for each of these:

• No key at the selector. The record was added under the wrong name. Panels that append your domain to every name, like Cloudflare, Porkbun, Namecheap and GoDaddy, turn google._domainkey.yourdomain.com into google._domainkey.yourdomain.com.yourdomain.com. Type only google._domainkey in the name field.
• A CNAME that points nowhere. The sender deleted or rotated the key, or the target has a typo. Copy the value again from the sender. In Cloudflare, keep DKIM CNAMEs on DNS only (grey cloud), as Microsoft's own guide says. Microsoft 365 and Proton keep one selector waiting for the next rotation, so the checker shows that one as inactive, not broken.
• Revoked key (empty p=). Normal for a few days after a rotation, as long as another selector is live.
• Unreadable key. The value was cut off, broken up with spaces, or pasted with extra quotes. Paste the whole value again as one string.
• Testing mode left on (t=y). RFC 6376 tells receivers to treat mail signed in testing mode like unsigned mail. Remove t=y once mail passes.
• Two records at one selector. RFC 6376 section 3.6.2.2 leaves the result undefined when one name holds several. Delete the old one.
• SHA-1 only (h=sha1). Generate a new key. RFC 8301 section 3.1 no longer allows SHA-1 for DKIM.
• Wrong version, key type or service. v=, if it's there, has to be DKIM1 and come first, k= has to be rsa or ed25519, and s=, if it's there, has to include email or *.

Every domain and subdomain you send as needs its own key. It's common for one domain to carry Google's key while another has nothing, because a new tool went live there and nobody added its record. Paste them all, and the grid shows the gaps.

A passing DKIM check isn't the whole story. For DMARC, the d= domain in the signature has to align with the From domain. Our DMARC checker, which reads the policy and alignment settings on the same domains, shows whether that alignment is relaxed or strict. SPF is the other way to pass DMARC, and the SPF checker, which counts every include against the limit of 10, covers that side.