DKIM Key Validation (selectors)

DKIM (DomainKeys Identified Mail, RFC 6376) lets your sending mail server cryptographically sign outgoing mail. Receivers verify the signature by fetching a public key at <selector>._domainkey.yourdomain.tld. The selector is a label your sender chooses, and there is no way to enumerate every possible selector from DNS alone. RedScore probes a list of common selectors plus selectors inferred from your MX and SPF records, but it cannot prove DKIM is absent. When no key is found at sampled names, the verdict is inconclusive with full credit (an honest Tier-1 posture).

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: at least one sampled selector has a v=DKIM1 record with a non-empty p= value (a valid signing key).
• Warn: sampled selectors return v=DKIM1 records but every p= is empty. Empty p= is a revoked key; it is RFC-correct briefly during rotation, but should be cleaned up afterward.
• Inconclusive (full credit): no DKIM TXT records at any sampled selector. Either DKIM is not configured, or you use a custom selector the scanner does not probe. Passive DNS cannot tell the difference, so the check awards full credit and surfaces the result for you to verify.

Inconclusive: verify whether DKIM is actually working

Two common explanations:

1. DKIM is set up, but with a selector the scanner did not probe

Send a test message from each of your legitimate senders to a Gmail address. Open the message, click the three-dot menu, and choose "Show original." The header includes a DKIM-Signature: line that names both the signing domain (d=) and selector (s=). If you see s=mycustom and the scan probed selector1, selector2, google but not mycustom, that is the answer. Confirm by querying the selector directly:

dig +short TXT mycustom._domainkey.yourdomain.tld @1.1.1.1

2. DKIM is not actually set up

If "Show original" shows dkim=none or no DKIM-Signature: line, your sender is not signing. Set DKIM up with each provider that sends mail "from" your domain. Most providers walk you through this in their admin UI and give you the exact DNS record(s) to publish at <selector>._domainkey.yourdomain.tld.

• Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate a key, publish the TXT record at the selector Google specifies (typically google._domainkey), then turn signing on.
• Microsoft 365: Microsoft Defender → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Publish the two CNAME records (selector1._domainkey, selector2._domainkey) Microsoft generates, then enable DKIM signing.
• SendGrid, Mailchimp, Postmark, ProtonMail Business, Fastmail, Zoho, etc.: each provider's docs show the selector and key value to publish. Follow their docs exactly.

After publishing, send a test message and confirm "Show original" reports dkim=pass with d=yourdomain.tld matching the From: header.

Warn: revoked keys

Empty p= signals "this key is revoked." Publishing an empty-p= record briefly during key rotation is RFC-correct: it tells receivers to stop accepting signatures from the old key while the new one rolls out. After the rotation window passes (typically a week or two), delete the record entirely. Two common causes for warns here:

• A rotation never finished. The old selector sits in DNS as empty p= long after the new key took over. Delete the empty record.
• A provider was removed but the DKIM record was left behind. Delete it.

Pass: still worth auditing

Pass means at least one sampled selector has a valid key. It does not mean every sender that signs as your domain is doing so correctly. Use DMARC aggregate reports (see DMARC Reporting) to identify any sender failing DKIM alignment.

Verify the fix

• For each known selector: dig +short TXT <selector>._domainkey.yourdomain.tld @1.1.1.1 should return a v=DKIM1 record with a non-empty p= base64 string.
• Send a test message from each sender to a Gmail address. "Show original" must show dkim=pass with d=yourdomain.tld.
• Check key length: 1024-bit keys still work, but 2048-bit is preferred for new deployments. Most providers default to 2048-bit; very old setups may still be on 1024-bit.
• Re-run the RedScore lookup.

Common pitfalls

• DKIM signed with the wrong d= value. If your sender signs as d=mailer.providerdomain.com instead of d=yourdomain.tld, DMARC alignment fails (relaxed alignment requires the same registered domain; strict alignment requires an exact match). Configure each provider to sign with d= set to your own domain.
• TXT record split across lines incorrectly. DKIM keys are long enough to require quoted-string concatenation in most zone formats. Most managed DNS UIs handle this transparently, but BIND and similar require explicit quoted segments. Verify with dig that the assembled record parses.
• Forgetting subdomain coverage. If a transactional sender uses a subdomain envelope (mail.yourdomain.tld), DKIM needs to be set up at the subdomain selector (<selector>._domainkey.mail.yourdomain.tld), not the apex.
• Old 1024-bit keys never rotated. Rotate at least annually and prefer 2048-bit keys.
• Multiple v=DKIM1 records at the same selector. Only one is valid; receivers may pick either with unpredictable results. Each selector should hold exactly one record.
• Inferring "DKIM is broken" from the inconclusive verdict. Inconclusive means "the scanner could not find evidence," not "DKIM is missing." Verify with the Gmail header check before assuming anything.