Security Intelligence Node

DKIM Signature
Validator.

Q: What is a DKIM selector?

A DKIM selector is a label that lets a domain publish multiple DKIM keys at once. The selector appears as part of the DNS record name: {selector}._domainkey.{domain}. Most sending platforms define the selector for you (google, selector1 / selector2 for M365, s1 / s2 for SendGrid, etc.).

Q: How do I find my DKIM record?

Look at the DKIM-Signature header of an email sent through the platform you're checking. The s= tag is the selector; the d= tag is the signing domain. Then query {selector}._domainkey.{domain} in DNS — or paste the pair into the validator above.

Q: Why is my DKIM record not found?

Three common reasons: (1) the selector name doesn't match what the platform is actually signing with, (2) the platform expects a CNAME (Google, M365, SendGrid) but you published a TXT, (3) DNS propagation hasn't completed. The validator above tells you which of the three is happening.

Q: Does DKIM alignment matter for DMARC?

Yes. DMARC requires either SPF alignment or DKIM alignment (or both). DKIM alignment is the more reliable of the two because DKIM signatures survive forwarding, while SPF breaks the moment a message hits a corporate distribution list or a fwd-as-attachment.

Q: How do I enable DKIM in Microsoft 365?

In Microsoft Defender: Email & collaboration → Email authentication settings → DKIM. Add your custom domain, publish the two CNAMEs Microsoft provides (selector1 and selector2), wait for DNS, then enable signing.

Q: How do I enable DKIM in Google Workspace?

In Admin Console: Apps → Google Workspace → Gmail → Authenticate email. Generate a new key, publish the TXT record at google._domainkey, wait for DNS, then turn on authentication.

Q: How often should I rotate DKIM keys?

For 2048-bit RSA keys, an annual rotation is typical. The rotation pattern is: publish a new selector with the new key, switch signing to the new selector, leave the old selector running with the old key for at least 7 days (to let in-flight mail validate), then revoke the old selector by setting its p= to empty.

Intercept and analyze cryptographic handshakes. Ensure your domain's digital signature is impenetrable and properly rotated across the global mail infrastructure.

shield_locked

Domain Name

Selector

Example DKIM records

Three real-world DKIM TXT records covering the three patterns you see most often: a Google Workspace selector, an M365 selector, and a SendGrid / transactional-platform selector. Selector names vary by sending platform; the record format is the same.

Google Workspace selector (google._domainkey)

google._domainkey.example.com  TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl4...

Standard Google Workspace selector. Activate in Admin Console → Apps → Google Workspace → Gmail → Authenticate email.

Microsoft 365 selector (selector1._domainkey)

selector1._domainkey.example.com  TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...

M365 publishes a CNAME at selector1 / selector2 that points to Microsoft's key host. Enable in Microsoft Defender → Email & collaboration → DKIM.

Third-party platform selector (SendGrid example)

s1._domainkey.example.com  TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr8u7...

Marketing / transactional platforms each define their own selector convention. The validator above lets you check any selector + domain pair in seconds.

Every DKIM record tag, explained

v Version: Always DKIM1 if present. Optional in some implementations but recommended. v=DKIM1
k Key type: Public key algorithm. rsa is universal; ed25519 is gaining adoption for shorter records but receiver coverage is uneven. k=rsa
p Public key Required: Base64-encoded public key. Setting p= to empty revokes the selector — the standard way to retire a key without deleting the record outright. p=MIIBIjANBgkqhkiG9w0BAQEFAA...
t Flags: t=y marks the key as test-mode (receivers MUST NOT treat verification failures as a reason to lower deliverability). t=s prevents subdomain use. t=s
s Service types: Comma-separated list of service types this key may be used for. * means all; email is the only widely-used value. s=email
h Hash algorithms: Comma-separated list of hash algorithms the key supports. sha256 is the only safe choice today; sha1 is deprecated. h=sha256
n Notes: Human-readable notes intended for administrators. Never inspected by receivers; safe to use for rotation tracking. n=rotated 2026-06-01
g Granularity: Local-part restriction on the i= tag (rarely seen in modern records, mostly historical). g=*

Common DKIM mistakes and how to fix them

Seven failure modes the validator catches most often. Every one of them silently breaks DMARC alignment.

Issue	What it means	How to fix it
Selector not found	No TXT record (or CNAME chain) at {selector}._domainkey.{domain}. The selector listed in the DKIM-Signature header has no published key.	Confirm the selector with the sending platform, then publish the TXT record they provided. CNAME-based hosts (M365, SendGrid, Mailgun) need a CNAME, not a TXT.
Public key (p=) is empty	The record exists but p= has no value — the selector is explicitly revoked.	Empty p= is intentional in key-rotation workflows. If the rotation is complete, remove the record entirely. If not, restore the key.
Invalid base64 in p=	The public key string contains line breaks, whitespace, or characters not in the base64 alphabet. Receivers reject the record as malformed.	Re-export the public key from the sending platform. Watch for DNS hosts that auto-wrap long TXT values — use a host that supports a single-string TXT or paste the key without line breaks.
Key too short (<2048 bits)	A 1024-bit RSA key is technically valid but considered cryptographically weak. Gmail and Microsoft have flagged this in deliverability reports.	Rotate to a 2048-bit key. The DKIM rotation pattern (publish new selector → switch signing → drain old selector → revoke) is documented in the Academy.
Wrong selector in DKIM-Signature	The s= tag in the DKIM-Signature header refers to a selector that does not match the published TXT record.	Confirm that the sending platform is configured with the same selector you published. M365 and Google selectors are platform-defined; SaaS platforms vary.
DKIM signing not enabled at platform	The DNS records are published correctly, but the platform itself is not signing outgoing mail — so the DKIM-Signature header is absent.	Enable DKIM signing in the platform admin. M365: Defender → Email & collaboration → DKIM. Google: Admin Console → Apps → Gmail → Authenticate email.
t=y test-mode flag left in production	t=y tells receivers to ignore DKIM verification failures — fine in staging, but turns DKIM off in production.	Remove t=y from the record once the rollout is complete.

Selector not found

What it means: No TXT record (or CNAME chain) at {selector}._domainkey.{domain}. The selector listed in the DKIM-Signature header has no published key.
How to fix it: Confirm the selector with the sending platform, then publish the TXT record they provided. CNAME-based hosts (M365, SendGrid, Mailgun) need a CNAME, not a TXT.

Public key (p=) is empty

What it means: The record exists but p= has no value — the selector is explicitly revoked.
How to fix it: Empty p= is intentional in key-rotation workflows. If the rotation is complete, remove the record entirely. If not, restore the key.

Invalid base64 in p=

What it means: The public key string contains line breaks, whitespace, or characters not in the base64 alphabet. Receivers reject the record as malformed.
How to fix it: Re-export the public key from the sending platform. Watch for DNS hosts that auto-wrap long TXT values — use a host that supports a single-string TXT or paste the key without line breaks.

Key too short (<2048 bits)

What it means: A 1024-bit RSA key is technically valid but considered cryptographically weak. Gmail and Microsoft have flagged this in deliverability reports.
How to fix it: Rotate to a 2048-bit key. The DKIM rotation pattern (publish new selector → switch signing → drain old selector → revoke) is documented in the Academy.

Wrong selector in DKIM-Signature

What it means: The s= tag in the DKIM-Signature header refers to a selector that does not match the published TXT record.
How to fix it: Confirm that the sending platform is configured with the same selector you published. M365 and Google selectors are platform-defined; SaaS platforms vary.

DKIM signing not enabled at platform

What it means: The DNS records are published correctly, but the platform itself is not signing outgoing mail — so the DKIM-Signature header is absent.
How to fix it: Enable DKIM signing in the platform admin. M365: Defender → Email & collaboration → DKIM. Google: Admin Console → Apps → Gmail → Authenticate email.

t=y test-mode flag left in production

What it means: t=y tells receivers to ignore DKIM verification failures — fine in staging, but turns DKIM off in production.
How to fix it: Remove t=y from the record once the rollout is complete.

For MSPs

How MSPs use this validator during client onboarding

Two patterns we see at onboarding: the client doesn't know which selectors are signing their mail, and the client has DKIM records published for platforms they stopped using 18 months ago.

The validator above lets you check any selector + domain pair in seconds, which is the right tool for both situations. During the kick-off call, walk through the standard selectors (google, selector1, selector2 for M365, s1 / s2 for most transactional platforms, k1 / k2 / k3 for Mailchimp, smtpapi for SendGrid). The output tells you which ones are real and which ones are noise.

For the stale ones, leave them in DNS unless they're throwing errors — a revoked DKIM record with p= empty is the safest way to retire a selector. Deleting outright can break DMARC alignment for in-flight mail that was signed with the old key.

Once the inventory is clean, the next move is continuous monitoring: aggregate reports will tell you the moment a SaaS vendor rotates a selector or adds a new one. That's where a daily-check tool becomes more useful than a one-off validator.

See how DMARC AI works for MSPs

From manual to managed

From validator to continuous DKIM monitoring

DKIM keys rotate. Selectors change. SaaS vendors add new signing identities without telling anyone in IT. A one-time validator catches the snapshot you take today; aggregate-report-driven monitoring catches the changes that happen between client check-ins.

DMARC AI ingests aggregate reports across every client domain in one tenant and surfaces new DKIM selectors as they appear — including ones the marketing team rotated last week and forgot to mention. The same tool you run during onboarding becomes the daily watchtower.

Start a free trial

New-selector detection from aggregate reports
Per-client selector inventory across the full portfolio
Cross-tenant view of DKIM signing posture
Smart alerts when a signing platform stops signing
Webhook + API for ticketing-system integration

Related tools

Validate the rest of your email-authentication stack alongside DKIM.

verified_user

DMARC Checker

Verify your DMARC record, policy, alignment, and aggregate-report destinations.

Open tool verified

SPF Analyzer

Parse your SPF record, count DNS lookups against the 10-lookup limit, find void lookups.

Open tool palette

BIMI Generator

Build a valid BIMI DNS record (requires DMARC enforcement + DKIM alignment).

Open tool lock

MTA-STS Checker

Verify your MTA-STS policy — TLS mode, allowed MX hosts, max_age — in one HTTPS probe.

Open tool

Continue learning

Deeper Academy reading on DKIM and adjacent protocols.

DKIM — Complete guide

Selectors, key rotation, signature anatomy, alignment with DMARC, and how DKIM survives forwarding when SPF does not.

6 min read

DMARC explained — Complete guide

How DKIM and SPF combine into DMARC alignment, why alignment usually leans on DKIM in the wild.

8 min read

SPF (Sender Policy Framework) — Complete guide

The third leg of the authentication tripod. Every mechanism, qualifier, and the 10-lookup limit.

7 min read

BIMI — Display your verified brand logo

BIMI requires DMARC enforcement + DKIM alignment. The next step once your DKIM story is solid.

5 min read

Free check is good — running a portfolio is better

Two ways to go from a one-off check to a managed practice.

Self-serve No credit card

Start a free 30-day Premium trial

Sign up, add a domain, see real DMARC reports inside 48 hours. No credit card. Premium AI features included for the trial; drop back to free Basic monitoring afterwards or convert per-active-domain.

Start a free 30-day Premium trial arrow_forward

Guided 30 minutes with an engineer

Book demo

Walk through the multi-tenant dashboard with a real engineer. Bring a client domain — we will load it live and show what the reports look like for your portfolio.

Book demo north_east

DKIM FAQ for Professionals

What is a DKIM selector? expand_more