Free DKIM Checker

DKIM Record Checker

Look up and validate DKIM public key records. Verify your signing configuration, key strength, and setup correctness.

Common selectors:

How DKIM Signing Actually Works

DKIM (defined in RFC 6376) is public-key cryptography applied to email. When your mail server sends a message, it computes a hash of the message body, then signs that hash together with a chosen set of headers — typically From, Subject, Date, and To — using a private key that never leaves your infrastructure. The result is attached as a DKIM-Signature header carrying the signing domain (d=), the selector (s=), the body hash (bh=), and the signature itself (b=). The receiving server fetches your public key from DNS at <selector>._domainkey.<domain> and verifies that nothing signed was altered in transit.

The selector is what makes this system scale: each sending service publishes its key under its own label, so one domain can sign through many providers at once. If you do not know which selector to check, open a message sent from your domain and view its raw headers — the s= tag in the DKIM-Signature header names it. Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1, and SendGrid typically uses s1 and s2.

DKIM's real payoff comes through DMARC. A DMARC pass requires that either SPF or DKIM verify with a domain that aligns with the visible From header — and DKIM is the more durable half of that pair, because a valid signature survives forwarding while SPF does not. A message signed with d=yourdomain.com keeps proving its origin no matter how many hops it takes, which is why getting DKIM right is the single most important step before tightening a DMARC policy to quarantine or reject.

DKIM Concepts Worth Knowing

selector (s=)

The label that picks which key to verify against. The record lives at <selector>._domainkey.yourdomain.com — one domain can publish many selectors side by side.

p= public key

The base64-encoded public key in the DNS record. An empty p= value is not an error — it is the standard way to revoke a retired key.

1024 vs 2048-bit keys

1024-bit RSA keys are considered weak and within reach of well-resourced attackers. Publish 2048-bit keys; split them across quoted strings if your DNS provider enforces 255-character limits.

Key rotation

Publish the new key under a fresh selector, switch signing to it, then delete the old record after a few days. Done this way, rotation causes zero verification failures.

DMARC alignment

The d= domain in the signature must match the From header domain for DKIM to count toward DMARC. A vendor signing as their own domain authenticates the mail but does not align it.

DNS truncation errors

A 2048-bit key exceeds the 255-character TXT string limit, so it must be published as multiple quoted strings. Keys silently truncated during copy-paste are a leading cause of DKIM failures.

Frequently Asked Questions