Free DKIM Record Checker
A DKIM lookup needs two things, and that is what makes it harder than an SPF check: the domain and the selector. Enter both above and the checker fetches the record at selector._domainkey.domain and validates it. If you do not know your selector, the section below shows you how to find it in thirty seconds from any message you have already sent.
First, Find Your Selector
There is no way to list a domain’s selectors from DNS. DKIM records are not enumerable: you cannot ask a domain what selectors it has, you can only ask whether one specific selector exists. That is why every DKIM checker asks you for it, and why a checker returning nothing usually means the selector is wrong rather than that DKIM is missing.
The reliable way to find it is to read a message you have sent. Open it in the recipient’s mailbox, view the raw source, and find the DKIM-Signature header. The s= tag is your selector and the d= tag is the signing domain:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id; ...In that example the selector is google and the record lives at google._domainkey.example.com. In Gmail the raw source is under the three-dot menu, Show original. In Outlook on the web it is View message source. The full anatomy of that header is in the DKIM record reference covering syntax and setup, and the headers around it in the Authentication-Results header guide.
If you cannot get at a sent message, the common defaults are worth trying, because most domains use their provider’s standard selector and never change it.
| Platform | Usual selector | Record type |
|---|---|---|
| Google Workspace | google | TXT |
| Microsoft 365 | selector1 and selector2 | CNAME, not TXT |
| Most ESPs | A vendor-specific string set at domain authentication | Usually CNAME |
The Microsoft row is the one that trips people up. Microsoft 365 publishes DKIM as a CNAME that points into your onmicrosoft.com tenant, and the TXT record only exists at the far end of that pointer. A raw TXT query against the selector returns the CNAME target rather than a key, which reads like a failure and is not:
$ dig +short selector1._domainkey.microsoft.com selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com. $ dig +short selector2._domainkey.microsoft.com selector2-microsoft-com._domainkey.microsoft.onmicrosoft.com.
Two selectors rather than one is deliberate: it is how Microsoft rotates keys without an outage. Client-side settings for both platforms are in the Microsoft 365 mail server reference and the Google Workspace mail server reference.
How to Read the Record
A published DKIM record is a TXT record holding a public key. Here is a live one, truncated in the middle for width:
$ dig +short TXT google._domainkey.uber.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD47RWlgqkIHUpMVRDcEDEtf0N2
... key material ...
84jVRne/OYpLVJPDPQIDAQAB| Tag | Meaning |
|---|---|
v=DKIM1 | Version. Optional in theory, expected in practice, and must come first when present. |
k=rsa | Key type. RSA is the near-universal choice; ed25519 exists and is rarely deployed alone. |
p= | The public key, base64 encoded. This is the record. An empty p= is a revoked key, not an error, and it tells receivers to fail every signature for this selector. |
t=y | Test mode. Receivers are told to treat failures leniently. Fine while rolling out, harmful if left behind. |
h=sha256 | Restricts the permitted hash algorithm. Usually omitted. |
Key length is the thing worth checking that nobody checks. A 1024-bit RSA key is still accepted everywhere and is no longer a strong choice; 2048-bit is the sensible default and is what current provider setup flows generate. If your DKIM was configured years ago and never touched, it is probably 1024-bit, which is a rotation task rather than an emergency.
What the Checker Reports, and What Each Result Means
| Result | What it usually means |
|---|---|
| No record found | Nine times out of ten the selector is wrong, not missing. Confirm it from a sent message before concluding DKIM is unconfigured. |
| CNAME returned instead of a key | Normal on Microsoft 365 and most ESPs. Follow the pointer; the key sits at the target. |
Empty p= tag | The key is revoked. Every signature using this selector will fail by design. If that is not intentional, the record was published wrong or a rotation was left half done. |
| Record present but signatures still fail | The published key does not match the private key doing the signing, or the message is being modified in transit by a forwarder or a mailing list. |
t=y still set | Test mode was never removed after rollout. Receivers discount your failures, which also means they discount your passes. |
| Key shorter than 2048 bits | Valid and accepted. Schedule a rotation rather than treating it as an incident. |
How to Check DKIM Without a Tool
The record is an ordinary TXT record at a predictable name, so any DNS client reaches it. Substitute your own selector and domain:
$ dig +short TXT google._domainkey.uber.com $ nslookup -type=txt google._domainkey.uber.com $ host -t TXT google._domainkey.uber.com
The literal string _domainkey sits between the selector and the domain and is not optional. A guessed selector returns nothing at all, which is the expected answer rather than an error:
$ dig +short TXT zzzfake._domainkey.google.com (no output)
That empty answer is exactly what a wrong selector produces on a domain with perfectly healthy DKIM, which is why the checker cannot tell you DKIM is missing. It can only tell you that the selector you supplied is not published.
Several Senders, Several Selectors
Unlike SPF, DKIM has no single record to overfill and no lookup limit to breach. Each sender gets its own selector, and adding the fifth one costs nothing that the first four paid. That is the structural advantage of DKIM and the reason it is the authentication method that survives forwarding.
What it does create is a checking problem: a domain with six senders has six selectors, and verifying one tells you nothing about the other five. Check each provider’s selector separately after you authenticate the domain with them. The rollout pattern is set out in running DKIM across multiple ESPs with several selectors.
What a DKIM Check Cannot Tell You
The checker confirms the public half exists in DNS. Whether the private half is actually signing your mail, and signing it correctly, only shows up in a real message’s Authentication-Results header.
DKIM can pass on a signing domain that has nothing to do with the From address your reader sees. DMARC is what requires the two to match.
Anyone can publish DKIM for a domain they own, including a look-alike registered this morning. Signing proves custody of a domain, never good intent.
Read alongside SPF, which authorises the sending host, and DMARC, which ties either result back to the visible From domain. The last card is expanded in why most phishing now authenticates cleanly.
DKIM Checker FAQ
How do I check my DKIM record?
Enter your domain and your selector in the checker above. Manually, run dig +short TXT selector._domainkey.yourdomain.com, substituting your own selector. You need the selector either way, because DKIM records cannot be enumerated from DNS.
How do I find my DKIM selector?
Open a message you have sent, view its raw source, and read the s= tag in the DKIM-Signature header. That is the selector; the d= tag next to it is the signing domain. Failing that, try your platform’s default: google for Google Workspace, selector1 and selector2 for Microsoft 365.
The checker says no record found. Is my DKIM broken?
Probably not. The most common cause by far is the wrong selector, and a wrong selector on a perfectly healthy domain returns exactly the same empty answer as a domain with no DKIM at all. Confirm the selector from a sent message before changing anything in DNS. The second most common cause is Microsoft 365, where the record is a CNAME and a TXT-only query looks empty.
Can one domain have more than one DKIM record?
Yes, and it should. Unlike SPF, where a second record is a fatal error, DKIM expects one record per selector and one selector per sender. There is no limit and no lookup budget to exhaust. This is why adding a sixth sending platform is a DKIM non-event and an SPF problem.
What does an empty p= tag mean?
It is a revocation. Publishing p= with nothing after it tells receivers that any signature from this selector must fail. It is the correct way to retire a key. If you see it and did not intend it, either a rotation was left unfinished or the record was pasted incorrectly.
My DKIM record is published but messages still fail DKIM. Why?
The published public key and the private key doing the signing no longer match, or something is altering the message after it was signed. Mailing lists that append a footer and forwarders that rewrite headers both break signatures legitimately. Check a real message’s Authentication-Results header rather than the DNS record, because that is where the verdict actually lives.
Related Free Tools
DKIM Record Generator to create a key pair · SPF Record Checker · DMARC Record Checker · SPF Record Generator · DMARC Record Generator
