DKIM Record Checker
Look up and validate DKIM (DomainKeys Identified Mail) records for any domain and selector. Auto-discovers common selectors used by Google Workspace, Microsoft 365, SendGrid, Mailgun and others. Validates public key length (1024 vs 2048-bit), signing algorithm (RSA-SHA256), and record syntax for email authentication compliance.
DKIM Record Check
What is DKIM?
DKIM (DomainKeys Identified Mail) is the cryptographic signature half of email authentication.
Your mail server signs each outgoing message with a private key; receivers verify the signature against a public key published in DNS at {selector}._domainkey.{domain}.
Selectors let one domain sign mail from multiple sources independently (Google Workspace, SendGrid, Mailgun etc.) without conflict.
New to email authentication? Read our Email Deliverability Guide 2026.
Popular Domains
Common DKIM Selectors by Provider
| Provider | Common selectors |
|---|---|
| Google Workspace | |
| Microsoft 365 | selector1, selector2 |
| SendGrid | s1, s2, em{customer-id} |
| Mailgun | mg, mailgun, pic |
| Mailchimp | k1, k2, k3 |
| Postmark | pm, 20220707pm |
| Amazon SES | amazonses |
| Klaviyo | klaviyo1, klaviyo2 |
| Brevo (Sendinblue) | brevo1, brevo2 |
| Mandrill / Mailchimp Transactional | mandrill, k1, k2, k3 |
| Zoho Mail | zoho |
| ProtonMail | protonmail, protonmail2, protonmail3 |
| Fastmail | fastmail1, fastmail2, fastmail3 |
| Self-hosted (Postfix/OpenDKIM) | dkim, default, mail |
About DKIM Record Checker
The DKIM Record Checker fetches the DKIM public-key record for any domain and selector combination, validates the record syntax, checks the public-key length (1024-bit is now considered weak; 2048-bit is the modern standard), confirms the signing algorithm (RSA-SHA256 vs the deprecated RSA-SHA1), and detects common configuration errors like malformed quoted strings, missing required tags, or expired/revoked keys (p= empty). It runs entirely from public DNS — no email is sent, no credentials are required, and the tool only reads what your DNS already publishes. Pairs naturally with the SPF Checker, DMARC Generator, MX Lookup, and Trace Email tools for an end-to-end deliverability audit.
Why use a DKIM Record Checker?
Email authentication errors are silent killers. A misconfigured DKIM record doesn't bounce mail — it quietly downgrades your authentication score, sending more of your messages to spam folders without any visible error. Modern receivers (Gmail, Yahoo, Microsoft) treat missing or invalid DKIM as a strong negative deliverability signal, especially after Google's and Yahoo's February 2024 bulk-sender requirements mandated DKIM for senders above 5,000 messages per day. Manually checking DKIM is fiddly: you need to know the selector (each sending service uses different conventions: google for Workspace, selector1/selector2 for Microsoft 365, s1/s2 for SendGrid), query the correct DNS record at {selector}._domainkey.{domain}, parse the result, decode the base64 public key, and verify the bit length. Most tools either don't auto-discover selectors or charge for the lookup. This tool auto-discovers the most common selectors in one request, displays the full key metadata (algorithm, key type, service type, flags), and warns you about weak keys or deprecated algorithms.
Who is it for?
Email administrators verifying authentication on their domains. DevOps engineers debugging deliverability issues after migrating between email providers. Security analysts investigating phishing campaigns and confirming whether suspicious messages came from authorized infrastructure. Compliance officers checking DKIM key length to meet 2048-bit minimums for SOC 2 and ISO 27001 audits. Domain administrators rotating DKIM keys and verifying that new selectors are correctly published. ESP customer success teams confirming customer setup before enabling sending. Marketing engineers configuring DKIM for ESPs like SendGrid, Mailgun, Postmark, Mailchimp, or Klaviyo. Anyone preparing a domain for Google's and Yahoo's bulk sender requirements who needs to verify DKIM is in place before scaling outbound volume.
How to use the tool
Enter the domain you want to check (e.g., example.com — no protocol or path needed)
Optional: enter a specific selector if you know it (e.g., google, selector1, s1). Leave blank to auto-discover common selectors in parallel
Click 'Check DKIM' to query DNS for the {selector}._domainkey.{domain} records
Review the headline summary — how many selectors were found and how many are valid
Inspect each selector card: version (DKIM1), key type (rsa), algorithm list, service type, flags, and key length
Read the validation issues — errors for revoked or weak keys, warnings for non-recommended config, info for testing flags
Copy the validated record or export the full report as JSON for documentation
Key Features
Auto-selector discovery
Tries 20+ common selectors in parallel without manual entry — covers Google Workspace, Microsoft 365, SendGrid, Mailgun, Mailchimp, Postmark, Amazon SES, Klaviyo, and self-hosted setups.
Public-key validation
Decodes the base64-encoded RSA public key, confirms it parses cleanly as a SubjectPublicKeyInfo structure, and reports the exact key length in bits.
Key-length warning
Flags 1024-bit keys with an upgrade recommendation to 2048-bit — the modern standard since Google's bulk-sender requirements (February 2024).
Algorithm detection
Identifies the h= hash algorithm list. Warns when only deprecated RSA-SHA1 is configured; confirms RSA-SHA256 is present.
Service type parsing
Shows whether the key is restricted to email (s=email) or open to all services (s=*). Useful when auditing key reuse.
Flags & revocation check
Detects t=y (testing flag — failures are not enforced) and the revoked-key signal (p= empty) so you can confirm that rotated selectors are correctly retired.
Common Use Cases
Verifying ESP setup
Scenario: After provisioning SendGrid, Mailgun, or Klaviyo for a domain, you want to confirm the DKIM selector is correctly published before flipping production sending.
✓ Run the check with your provider's selector (or leave blank for auto-discovery). Confirms the key is live, valid, 2048-bit, and signed with RSA-SHA256 — exactly what receiving servers will verify against.
Post-migration verification
Scenario: You moved from one email provider to another and need to confirm DKIM works on the new provider before retiring the old one.
✓ Check both providers' selectors against the same domain. Each can have its own DKIM record without conflict, so you can ramp traffic gradually.
Phishing investigation
Scenario: A suspicious email claims to be from your-bank.com. You want to know whether the sender's DKIM matches the displayed From: domain.
✓ Look up DKIM for the claimed domain and compare against the message's DKIM-Signature header. Mismatch = spoofing; match = the message really came from authorized infrastructure.
Compliance audits
Scenario: SOC 2 / ISO 27001 audit requires evidence that email authentication uses 2048-bit (or higher) keys with modern algorithms.
✓ Run the check, export the JSON report. Shows key length, algorithm list, and pass/fail status — drop it into the audit artifact.
Key rotation testing
Scenario: You're rotating DKIM keys. New selector published; you need to confirm it's live before retiring the old one.
✓ Check the new selector specifically. Confirm it returns a valid record before you start signing with it (and before you revoke the old one).
DKIM records are parsed per RFC 6376. RSA key length is computed by parsing the SubjectPublicKeyInfo ASN.1 structure — matches what receiving mail servers compute.
The DNS lookup runs server-side through our edge proxy. The domain is queried but not stored. No cookies, no analytics on input content.
Globally distributed edge infrastructure for low-latency queries.
Frequently Asked Questions
How do I find my DKIM selector?
DKIM selectors are configured by your email sending provider, not by you. Google Workspace uses 'google' as the selector; Microsoft 365 uses 'selector1' and 'selector2'; SendGrid issues per-customer selectors like 's1' or 'em1234'; Mailgun uses 'mg', 'mailgun', or 'pic'. To find yours, check your sending provider's DKIM setup page (usually under domain authentication), look at a previously-sent message's DKIM-Signature header for the s= value, or use this tool's auto-discovery feature which tries the most common selectors in parallel.
What is the difference between 1024-bit and 2048-bit DKIM keys?
The number refers to the RSA key length, which determines cryptographic strength. 1024-bit keys were the original DKIM standard but are now considered weak — they can theoretically be factored by determined adversaries with modern computing resources. 2048-bit keys are the modern minimum and the recommendation from Google's bulk-sender requirements (February 2024). 4096-bit keys exist but cause DNS record size issues in some providers. If your tool reports a 1024-bit key, plan to rotate to 2048-bit using your provider's key rotation flow.
Can I have multiple DKIM records on one domain?
Yes — DKIM is designed for multiple coexisting selectors. Each selector is a separate DNS record at {selector}._domainkey.{domain}, so they don't conflict. This is how you can sign mail from multiple sending sources (Google Workspace for internal mail, SendGrid for transactional, Mailchimp for marketing) on the same domain simultaneously. Each source signs with its own selector, and receivers verify the signature against the matching DKIM record. You can also have multiple selectors per provider for transparent key rotation.
What does p= mean in a DKIM record?
The p= tag holds the base64-encoded public key that receivers use to verify DKIM signatures. An empty p= value (just p=;) signals that the key has been revoked — the selector is intentionally invalidated, and receivers will treat any signature from that selector as failed. This is how you safely retire old keys during rotation. A missing p= tag entirely indicates a malformed record. A populated p= with a valid base64 key is the normal operational state.
Why isn't my DKIM record showing up?
Common causes: DNS propagation delay (new records can take 1-48 hours to propagate globally), wrong selector (verify the exact selector your provider uses), DNS provider TXT record character limits (long DKIM keys must be split into multiple quoted strings within the same record), or accidental publishing at the wrong subdomain (e.g., {selector}._domainkey.example.com vs ._domainkey.www.example.com). Use a DNS propagation checker to verify the record exists at multiple resolver locations.
How often should I rotate DKIM keys?
DKIM key rotation best practice is annually for normal operations and immediately if a private key is suspected of being compromised. The mechanism is straightforward: publish a new selector with a new key pair, configure your sending infrastructure to sign with the new selector, monitor for a few weeks to ensure no legitimate mail is unsigned, then revoke the old selector by setting its p= value to empty. Many ESPs handle this automatically — Microsoft 365's selector1/selector2 alternation is a built-in rotation mechanism.
How is DKIM different from SPF and DMARC?
SPF authorizes which IP addresses can send mail for your domain. DKIM cryptographically signs the message contents to prove they weren't altered and came from an authorized signer. DMARC ties the two together: it tells receivers what to do if SPF or DKIM fails, sets alignment requirements (the signing domain must match the From: domain), and provides reporting. All three are complementary — you need all three for modern email authentication. DKIM is the only one that provides per-message integrity verification.
What does 'k=rsa' mean in a DKIM record?
The k= tag specifies the key type. k=rsa (or just omitted, since rsa is the default) means the public key uses RSA cryptography. DKIM also supports k=ed25519 for EdDSA signatures, which produces smaller signatures and faster verification — but Ed25519 DKIM is not yet universally supported by receivers. For 2026, RSA remains the safe interoperable choice.
Does this tool store the DKIM records I check?
No. Lookups happen in real time against public DNS — the same data anyone with dig or nslookup can retrieve. Domain names you check aren't stored, logged, or associated with any user account. The tool runs as a stateless DNS proxy and only retains what's necessary to render your current result. There's no signup, no rate limit, and no tracking pixels on the result page.
How do I set up DKIM for Google Workspace?
In the Google Workspace admin console: Apps → Google Workspace → Gmail → Authenticate email. Click 'Generate new record' for your domain — Google will create a 2048-bit key and provide the DNS TXT record to publish at google._domainkey.{domain}. After publishing in your DNS provider's interface, wait 24-48 hours for propagation, then return to the admin console and click 'Start authentication'. Verify the setup with this DKIM Checker using selector 'google'. Microsoft 365, Mailgun, and SendGrid have analogous setup flows in their respective admin panels.
Technical Specifications
Supported Formats
- ✓RFC 6376 DKIM
- ✓All standard tags: v, k, t, s, h, n, p, g
- ✓Key types: rsa (parsed for length), ed25519 (detected)
- ✓Hash algorithms: sha256, sha1, rsa-sha256, rsa-sha1
- ✓Auto-discovery for 20+ common selectors
- ✓Key-length detection: 1024 / 2048 / 4096 bit
- ✓Revocation detection (p= empty)
- ✓Testing-flag detection (t=y)
Limits & Performance
- •File Size: Single domain per check
- •Validations: Live DNS resolution
- •Response Time: Typically 200-1500ms (parallel for auto-discovery)
- •Browsers: All modern browsers
Pro Tips
- Use 2048-bit keys minimum. 1024-bit is considered weak and explicitly deprecated by Google's bulk-sender requirements (February 2024).
- Use RSA-SHA256 (the standard h= value). RSA-SHA1 is cryptographically deprecated.
- Rotate DKIM keys annually — publish a new selector first, switch signing to it, monitor for a few weeks, then revoke the old selector by setting p= empty.
- When auditing a domain, check several common selectors at once (google, selector1, selector2, s1, k1) — auto-discovery does this automatically.
- If the tool reports p= empty, the selector has been intentionally retired. This is normal during key rotation; check the active selector instead.
- DKIM signs specific headers. If your ESP unexpectedly changes which headers it includes (during a migration, for instance), DKIM may start failing even though the record is correct.
- After any DKIM change, wait for the DNS TTL (often 1 hour) before re-checking. Faster checks can show stale cached results from local resolvers.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.