Free DKIM Checker

Testing and validating your domain's email authentication with our DKIM Checker is straightforward and ensures your outgoing messages pass cryptographic inspection by major mailbox providers:

1. Identify Your DKIM Selector: Locate the specific DKIM selector associated with your sending service. You can find this in your email service provider's administrative console (such as Google Workspace, Microsoft 365, SendGrid, Amazon SES, or Mailchimp) or by inspecting the raw headers of an authentic email sent from your domain (look for the s= tag within the DKIM-Signature header).
2. Enter the Selector and Domain: In the selector field, enter the selector key name (e.g., google, selector1, k1, or default). In the domain field, enter your sending domain name (e.g., example.com or mail.example.com). Avoid adding protocol prefixes such as https:// or trailing slashes.
3. Execute the DKIM Verification: Click the Check DKIM button to query global Domain Name System (DNS) servers for the corresponding authoritative TXT or CNAME record published at [selector]._domainkey.[domain].
4. Analyze the Public Key and Record Tags: Examine the parsed DKIM record output. Verify that the version tag is set to v=DKIM1, review the key algorithm type (k=rsa or k=ed25519), and check optional flags like the test mode flag (t=y) or service type restrictions (s=email).
5. Evaluate Cryptographic Key Strength: Inspect the detected key length. Ensure your public key uses modern 2048-bit RSA or Ed25519 encryption. If the tool flags an obsolete 1024-bit or 512-bit key, plan an immediate upgrade to maintain email security and comply with receiving provider standards.
6. Verify DNS Syntax and Concatenation: Confirm that the Base64 public key (p=) string is properly formatted without truncated characters, misplaced spaces, or syntax errors resulting from DNS provider 255-character string chunking limits.

A DKIM Checker is an essential email security and deliverability diagnostic tool that queries, parses, and validates DomainKeys Identified Mail (DKIM) DNS records. Standardized under RFC 6376, DKIM is an industry-standard email authentication protocol that employs asymmetric public-key cryptography to verify sender identity and ensure message integrity across global email networks.

When an email is dispatched, the sender's mail server computes a cryptographic hash of the message body and selected headers, encrypts that hash using a securely held private key, and embeds the resulting digital signature into the email header as a DKIM-Signature. To verify the email, receiving mail transfer agents (MTAs)—such as Gmail, Microsoft Outlook, and Yahoo Mail—locate the sender's public key by performing a DNS lookup at a designated subdomain formatted as selector._domainkey.domain.com. The receiver uses this public key to decrypt the signature and verify that the message genuinely originated from the claimed domain and remained untampered during transit.

Because DKIM records cannot be looked up at the apex domain level without specifying a selector, a DKIM Checker automates the resolution of [selector]._domainkey.[domain]. It verifies DNS propagation, decodes complex Base64 public key data, checks cryptographic tag configurations (such as v=DKIM1, k=rsa, and p=), and flags syntax anomalies or deprecated key lengths that could cause legitimate corporate correspondence to be flagged as spam or rejected outright.

Configuring and regularly verifying your DKIM records with an authoritative DKIM Checker is vital for maintaining cyber defense, email deliverability, and brand reputation across modern enterprise communication channels:

• Prevents Email Spoofing and Phishing Attacks: Cybercriminals frequently impersonate corporate domains to orchestrate Business Email Compromise (BEC), CEO fraud, and spear-phishing campaigns. DKIM cryptographic signatures guarantee that receiving mail servers can distinguish between authentic corporate communications and forged emails sent by unauthorized third parties.
• Guarantees In-Transit Message Integrity: DKIM includes a tamper-evident body hash (bh=) and signed header list. If a malicious intermediary alters email contents, modifies payment instructions, or injects malicious links while the message travels across the Internet, the DKIM signature breaks, alerting the receiver that the payload has been compromised.
• Ensures Compliance with Google and Yahoo Sender Requirements: Major email mailbox providers, including Google, Yahoo, and Apple, mandate strict email authentication (SPF, DKIM, and DMARC) for all bulk senders. Failure to maintain valid, cryptographically robust DKIM records results in high bounce rates, spam folder routing, or outright domain-level blocking.
• Powers DMARC Alignment and Policy Enforcement: Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies on DKIM and SPF to establish alignment. A valid DKIM signature where the signing domain (d=) aligns with the visible From: header allows domain owners to safely enforce strict DMARC quarantine or reject policies (p=quarantine or p=reject).
• Builds and Protects Domain Reputation: Internet Service Providers (ISPs) track sender reputation by domain identity rather than fluctuating IP addresses. Consistently passing DKIM verification builds long-term domain reputation, ensuring high inbox placement for marketing newsletters, transactional notices, and user onboarding emails.
• Prerequisite for BIMI and Verified Sender Checkmarks: Deploying Brand Indicators for Message Identification (BIMI)—which displays official company logos and verified checkmarks inside recipient inboxes—requires comprehensive DMARC enforcement backed by flawless DKIM cryptographic signing.

Adhere to these enterprise-grade best practices when generating, implementing, and maintaining DKIM records across your domain infrastructure:

• Deploy 2048-Bit RSA Keys or Modern Ed25519: Avoid deprecated 512-bit and 1024-bit RSA keys, which are increasingly susceptible to off-line mathematical factorization. Always generate 2048-bit RSA keys or modern Ed25519 elliptic-curve keys to ensure robust cryptographic security without exceeding DNS UDP packet size limits.
• Implement Regular DKIM Key Rotation: Establish a routine key rotation policy that updates DKIM key pairs every 6 to 12 months. Using distinct selectors during rotation (such as q1-2026, q3-2026) enables zero-downtime transition: publish the new public key in DNS first, switch your MTA to sign with the new private key, and retire the legacy selector after in-flight messages have cleared.
• Assign Unique Selectors to Every Third-Party Sending Service: Never share a single DKIM key pair across multiple platforms. Assign dedicated, descriptive selectors to each email gateway, CRM, and transactional email provider (e.g., goog._domainkey for Google Workspace, mktg._domainkey for HubSpot, s1._domainkey for SendGrid). This isolates operational risks and allows revoking an individual compromised key without disrupting other channels.
• Ensure Strict Alignment with the RFC 5322 From Domain: To achieve DMARC alignment, configure your sending platforms so that the DKIM signature domain tag (d=) matches the domain visible to users in the email's From: header. If an email service provider signs with their shared domain by default, establish custom DKIM (branded sending domains) to ensure alignment.
• Accurately Manage DNS 255-Character String Splitting: A 2048-bit RSA public key string exceeds the 255-character limit for individual DNS TXT character strings. When configuring DNS records in BIND, AWS Route 53, Cloudflare, or local zone files, format long keys into multiple double-quoted strings within a single TXT record rather than concatenating them improperly or splitting them across multiple records.
• Safeguard Private Keys with Strict Access Controls: Protect your DKIM private keys within hardware security modules (HSMs) or encrypted credential stores on your mail servers. Never commit private keys to public code repositories, transmit them over unencrypted channels, or grant broad administrative access to key pairs.

Avoid these prevalent technical errors and configuration pitfalls when managing DKIM records and email signing architecture:

• Querying the Apex Domain Without a Selector: Unlike SPF records which reside directly at the root domain (example.com), DKIM records require a selector prefix to be resolved (selector._domainkey.example.com). Attempting to query DKIM records without entering the specific selector will return an empty DNS result (NXDOMAIN).
• Using Deprecated and Weak 1024-Bit RSA Keys: Continuing to rely on legacy 1024-bit RSA keys leaves signatures vulnerable to modern computational cryptanalysis. Leading mailbox providers recommend or mandate 2048-bit keys to guarantee long-term cryptographic integrity.
• Syntax Errors in DNS TXT Record Strings: Minor typographical errors—such as missing semicolons between tag-value pairs, rogue whitespace characters within the Base64 p= string, or confusing the letter l with the number 1 in v=DKIM1—will invalidate the entire public key record and cause verification to fail.
• Mishandling DNS 255-Character Chunking: Many DNS web management interfaces automatically break strings longer than 255 characters. If spaces or escaped quotes are inadvertently inserted during this chunking, the reconstructed Base64 public key becomes corrupted, resulting in invalid signature decoding by recipient mailboxes.
• Leaving Test Mode Active in Production (t=y): Publishing a DKIM record with the test mode flag (t=y) signals to receiving mail servers that the signature should not be treated as authoritative for policy enforcement. Failing to remove the t=y tag after migration prevents DMARC policies from rejecting spoofed emails.
• Email Modifications in Transit by Intermediaries: Adding automatic email disclaimers, antivirus scanning footers, link-wrapping trackers, or altering message encodings via downstream MTAs will alter the email body. Because DKIM calculates a body hash (bh=) prior to transmission, any post-signing alteration invalidates the signature unless proper canonicalization and MTA routing hierarchies are enforced.
• Orphaning Obsolete Selectors in DNS: Leaving retired DKIM selectors with published public keys active in DNS long after migrating providers creates security vulnerabilities. Always delete DNS records for decommissioned services or revoke keys by publishing an empty public key tag (p=).