DKIM CNAME Validator

Why DKIM uses CNAME

When you set up DKIM with a third-party email service — Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, Brevo, Salesforce, HubSpot, virtually every ESP — the provider asks you to add a CNAME at <selector>._domainkey.<yourdomain> pointing to a record they control. That way they can rotate the actual signing key without making you touch DNS again.

The downside: when something breaks in that chain — a typo'd target, a delegated zone that drifted out of sync, the provider deleting their target after a tenant migration — DKIM fails silently and DMARC alignment falls apart with it. This tool walks every CNAME hop until it lands on the terminal TXT (or hits a dead end), then validates the key.

What the validator checks

• Chain walk — up to 10 hops, loop-detected. Most ESP chains are 1-3 hops; longer chains usually mean someone added an extra alias layer for white-labelling.
• Terminal TXT — confirms the alias chain actually lands on a DKIM record (not a dangling reference).
• v=DKIM1 presence — required version tag. Absent = receiver ignores the key entirely.
• p= tag presence and content — an empty p= means the key has been revoked. Receivers treat it as DKIM failure.
• Key strength — RSA 2048 or stronger (RFC 8301 recommendation), RSA 1024 (accepted but flagged), Ed25519 (RFC 8463, also accepted).
• h= / t= / s= tags — flags h=sha1 (obsoleted by RFC 8301), t=y (test mode — receivers don't enforce), and service-type restrictions.

Common selectors by provider

Common failure modes

• Dangling CNAME — the chain target was deleted or never existed. Often happens when a tenant is migrated between ESP accounts. Fix: re-add the CNAME or point at the new target.
• CNAME at zone apex — RFC 2181 forbids CNAME at the same name as other records. Some DNS providers reject the setup outright; others accept it but resolution is undefined. Move the selector to a sub-label.
• CNAME loop — selector A points at selector B which points back at A. Usually a copy-paste mistake when onboarding a second ESP.
• Mixed CNAME + TXT at the same name — also forbidden by RFC 2181 §10.1. The TXT effectively becomes invisible.
• 1024-bit RSA key — historically the default, RFC 8301 recommends 2048. Most receivers still accept 1024 but the trend is to flag it. Ask the ESP to rotate.
• p= empty (revoked key) — the ESP rotated away from this selector but left an empty p=; behind to signal revocation. Receivers will treat DKIM as fail. Remove the selector entirely or migrate to the new one.

What this tool does not cover

The validator inspects DNS only. It cannot tell you whether messages from that selector are actually being signed — that lives in the message headers. Pair with the Email Header Analyzer on a sample message to see the dkim-signature header and confirm the selector, domain, hash algorithm, and canonicalization match what DNS publishes. If DKIM is signed correctly but DMARC still fails, the cause is usually alignment — use the DMARC Failure Diagnoser next.

Read the complete DKIM guide to learn more.