Probe the 14 most common DKIM selectors and confirm signing is live.
Probe the 14 most common DKIM selectors (default, google, mailgun, mandrill, k1…k3, smtp, dkim, selector1/2, m1…m3, mx) in parallel. If one publishes a key, DKIM signing is active — and both Gmail and Outlook treat unsigned mail with deep suspicion.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message you send. Your sending server signs key headers and the body with a private key; the matching public key is published in DNS at selector._domainkey.yourdomain.com. A receiver fetches that public key, verifies the signature, and now knows two things: the message genuinely came from your domain and it wasn't altered in transit. Unlike SPF, DKIM survives forwarding, which is why it carries more weight at the big mailbox providers.
The tricky part of DKIM is the selector. A selector is just a label your ESP picks (Google uses "google", Mailgun uses "k1"/"k2"/"k3", Postmark uses long hashes, and so on), and the public key lives under that specific selector. There's no way to enumerate selectors from DNS, so this tool probes the 14 selectors that cover the overwhelming majority of real-world setups and reports any that publish a key. A clean result means signing is live; nothing found usually means DKIM isn't configured, or your provider uses a custom selector this list doesn't cover.
DKIM belongs to the same domain-setup-and-pre-send-QA phase as SPF. You enable it once per sending service — usually by pasting a CNAME or TXT record your ESP generates — and then verify it before you start sending in volume. It's the second of the three authentication pillars, and the one DMARC most reliably aligns on, so getting it live is a prerequisite for moving DMARC past p=none.
DKIM public keys are published under a selector you choose (or your ESP chooses), at selector._domainkey.yourdomain.com. There's no DNS mechanism to list every selector for a domain, so this tool probes the 14 most common ones — covering Google, Mailgun, Mandrill, Microsoft, and generic defaults — and reports any that resolve.
Not necessarily. It means none of the 14 common selectors published a key. Your provider may use a custom selector (Postmark and SendGrid often do). Check your ESP's dashboard for the exact selector name, or run the DKIM generator to set one up.
SPF authorises sending IPs and breaks on forwarding; DKIM cryptographically signs the message itself and survives forwarding. They're complementary — DMARC requires at least one of them to pass and align with your visible From: domain.
Yes, and you usually should. Each sending service publishes its own selector, so a domain that sends from Google Workspace plus a transactional provider will legitimately have two or more live selectors. This checker reports every common one it finds.
Use 2048-bit keys where your provider supports them — 1024-bit is still widely accepted but increasingly considered weak. The key length is set when your ESP generates the record, not something you change in this checker.
During domain setup, every time you add a new sending service, and as part of pre-send QA. A missing or mis-published DKIM key is one of the most common reasons mail lands in spam at Gmail and Outlook.
SieveGuard's Domain Health add-on monitors DKIM signing on every domain you onboard, watching for rotated or removed keys, and surfaces a pass/fail badge alongside SPF and DMARC so nothing silently stops signing.