Why it matters
Without DKIM, receivers cannot cryptographically verify that a message truly came from your domain or that its signed headers and body were unchanged in transit, so your mail is trivially spoofable and more likely to be filtered or junked, especially at Gmail, Yahoo, and Microsoft, whose 2024 bulk-sender requirements demand SPF, DKIM, and DMARC alignment. DKIM is also the more durable of DMARC's two authentication paths: SPF tends to fail on indirect mail flows - when a message is forwarded, the forwarding server's IP is not in your SPF record so SPF fails outright, and mailing lists typically rewrite the envelope (return-path) sender so SPF no longer aligns with your visible From: domain - whereas a DKIM signature travels with the message and keeps validating. A domain with no DKIM must lean entirely on SPF for DMARC alignment, so any forwarded or list traffic fails DMARC, landing in spam under `p=quarantine` or being rejected under `p=reject`. This is governed by RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures.
Common causes
- The sending platform was never configured to sign: DKIM is enabled per-domain/tenant in most providers (Google Workspace, Microsoft 365, SendGrid, Mailgun, etc.) and is off until you turn it on and publish the key.
- The key pair was generated but the public-key TXT record was never added to DNS, or was added under the wrong host (e.g. the full FQDN got duplicated so the record lands at `selector._domainkey.domain.com.domain.com`).
- Selector mismatch: the server signs with selector `s1` but the published record lives at a different selector, so `s1._domainkey.domain` resolves to nothing.
- The DKIM TXT record's value was split or truncated on paste, long RSA-2048 keys exceed the 255-character per-string TXT limit and must be entered as multiple quoted strings; a mangled `p=` reads as no valid key.
- A CNAME-delegated DKIM (common with ESPs and Microsoft 365, which uses two `selector1`/`selector2` CNAMEs) was never created, or points at the wrong target so the chain doesn't resolve.
- Multiple mail streams (marketing ESP, transactional relay, help desk) each send as your domain but only one is signed, so mail from the others shows no DKIM.
How to fix No DKIM Record Found
- Inventory every service that sends mail as your domain (primary mailbox host, marketing ESP, transactional/SMTP relay, ticketing, invoicing). Each stream needs its own DKIM key and selector; DKIM is per-sender, not one record for the whole domain.
- In each sending platform, enable DKIM and let it generate a key pair, prefer RSA-2048 (RFC 8301 requires at least 1024-bit and recommends 2048; 1024-bit is being phased out). The platform keeps the private key and gives you a selector plus the public key to publish. Choose a distinct, memorable selector per service (e.g. `google`, `s1`, `mg`).
- Publish the public key in DNS. For a raw key, create a TXT record at `<selector>._domainkey.<yourdomain>` with value `v=DKIM1; k=rsa; p=<base64 public key>`. If your provider gives you CNAME targets instead (Microsoft 365 `selector1`/`selector2`, most ESPs), create those CNAMEs exactly as specified and do not also add a TXT.
- Enter the key as one continuous value in your DNS panel, most panels auto-split it into 255-char TXT strings for you. If you must split manually, use adjacent double-quoted strings (resolvers concatenate them with no separator); never insert spaces or line breaks inside the base64 `p=` value.
- Verify resolution before enabling enforcement: `dig +short TXT selector._domainkey.yourdomain.com` (or `nslookup -type=TXT`). Confirm you get back the `v=DKIM1; ... p=...` value with no typos and no doubled domain suffix.
- In the sending platform, flip DKIM signing to ON (some, like Google Workspace, publish the record first and then require you to click 'Start authentication'). Send a live test to a Gmail account, open 'Show original', and confirm DKIM = PASS and that `d=` matches your From: domain (alignment).
- Once every stream signs and passes, add or tighten DMARC (`_dmarc.yourdomain` TXT, RFC 7489) starting at `p=none` with `rua=` reporting, review aggregate reports to catch any unsigned source, then move to `quarantine`/`reject`. Rotate DKIM keys periodically and retire old selectors after the new one is verified passing.
Frequently asked questions
Is there one standard DKIM record name I can just look up?
No. DKIM keys live at `<selector>._domainkey.<domain>`, and the selector is chosen by each sender, so there's no universal name. A verifier learns the selector from the `s=` tag inside a signed message's `DKIM-Signature` header, then queries that exact host. This is why unsigned mail shows 'no DKIM', there's no signature to reveal a selector.
Do I still need SPF and DMARC if I set up DKIM?
Yes. DKIM proves integrity and origin but doesn't by itself tell receivers what to do with failures, that's DMARC's job, and DMARC needs at least one of SPF or DKIM to pass AND be aligned with the visible From: domain. Keep SPF for envelope-path authorization and publish DMARC to tie them together. DKIM is the alignment path that survives forwarding, so it's the most important of the three to get right.
RSA-1024 or RSA-2048 for the key?
Use RSA-2048. RFC 8301 requires signers to use at least 1024-bit keys and recommends 2048, and 1024-bit keys are being phased out by major receivers. The only practical caveat is that a 2048-bit public key exceeds the 255-character TXT string limit and must be published as multiple concatenated strings, most DNS UIs handle this automatically.
I published the record but mail still shows no DKIM: why?
Most often the platform hasn't been switched to actively sign yet (publishing the key and enabling signing are separate steps in Google Workspace and others), the selector you published doesn't match the one the server signs with, or DNS hasn't propagated/was entered under a doubled hostname. Confirm signing is ON, `dig TXT selector._domainkey.domain` returns your exact key, and a test message actually carries a `DKIM-Signature` header.