Instantly look up and validate any domain's DKIM record. Check for errors, inspect the public key, detect weak configurations, and get actionable recommendations — free, instant, no account needed.
Enter any domain — e.g. yourdomain.com.
Common selectors: default, google, selector1, mail, dkim. Check your email provider's settings.
Fix Your DKIM — Then Fix Your Inbox Placement with Warmbase
A valid DKIM record is only one piece of the puzzle. To consistently land in the primary inbox — not spam — you need to warm up your sending domain, build sender reputation, and maintain it over time. Warmbase automates all of it.
✓ Automatic inbox warming — no manual work required
✓ Real human-like email interactions that build reputation
✓ Works with any ESP, Google Workspace, or custom SMTP
A DKIM checker is a diagnostic tool that queries a domain's DKIM (DomainKeys Identified Mail) DNS record for a specific selector and analyses it for validity, public key presence, key strength, tag structure, and deliverability risks. Instead of manually querying DNS and decoding base64 keys, a DKIM checker does all the heavy lifting — surfacing errors, inspecting key length, parsing all DKIM tags, and providing actionable recommendations in plain language.
How Our Free DKIM Checker Works?
Our free Warmbase DKIM Checker performs a live DNS lookup at selector._domainkey.yourdomain.com, parses the DKIM TXT record in full, validates it against RFC 6376, detects configuration errors and warnings, scores the key strength, checks SPF and DMARC status, and gives you a complete authentication analysis — all in real time, with no signup required.
How DKIM Works
DomainKeys Identified Mail (DKIM) is an email authentication standard defined in RFC 6376. It allows the sender of a message to attach a cryptographic digital signature to the email headers. The receiving mail server then uses a public key — published in DNS — to verify that the signature is authentic and that the message has not been tampered with in transit.
The process works in two steps. First, the sending mail server signs outgoing messages using a private key. The signature is embedded in the DKIM-Signature header. Second, the receiving server looks up the corresponding public key in DNS at selector._domainkey.yourdomain.com and uses it to verify the signature. If the signature matches, DKIM passes. If the signature is invalid or the DNS record is missing, DKIM fails.
Unlike SPF — which verifies only the sending IP — DKIM proves the email's content integrity. DKIM also survives email forwarding, making it the more reliable authentication signal for inbox placement and DMARC alignment.
How to Check a DKIM Record
Using our checker is the fastest way. Enter your domain name and selector above and click Check DKIM Record. You'll get a full analysis in seconds — including key length, tag breakdown, errors, and recommendations.
You can also check a DKIM record manually using command-line tools:
Linux / macOS:dig TXT default._domainkey.yourdomain.com
Replace default with the actual selector used by your sending platform. Look for a TXT record that starts with v=DKIM1 or contains p=. If no record is returned, DKIM has not been configured for that selector.
To find your selector, check the DKIM-Signature header in a sent message — look for the s= field. Alternatively, check your email provider's documentation or admin panel.
DKIM Selector Explained
A DKIM selector is a string that identifies which DKIM key pair to use for signing and verification. It is combined with the domain to form the DNS lookup path for the public key: selector._domainkey.yourdomain.com.
Selectors allow domains to publish multiple DKIM keys simultaneously — one per sending platform or use case. This is important because each service (Google Workspace, Microsoft 365, SendGrid, Mailgun, etc.) signs with its own private key and needs its own corresponding public key in DNS.
Common selectors by platform:
Google Workspace:google
Microsoft 365:selector1, selector2
SendGrid:s1, s2
Mailgun:pic, smtp
Amazon SES: a long auto-generated string
Custom SMTP / Postfix: often default or mail
To find your exact selector, look at the DKIM-Signature header in a raw email sent from your platform. Find the s= tag — that is your selector.
DKIM Public Key Explained
The DKIM public key (the p= tag in your DNS record) is the publicly accessible half of an RSA key pair. Your sending mail server holds the private key and uses it to create a cryptographic signature for each outgoing message. The receiving server downloads the public key from DNS and uses it to verify that signature.
The public key is encoded in base64 and can be long — typically 216 characters for a 1024-bit key and around 392 characters for a 2048-bit key. This is normal. The full value must be published as a single DNS TXT record.
An empty p= value (p= with nothing after the equals sign) is a valid DKIM construct — it means the key has been intentionally revoked. Any message signed with that selector will fail DKIM verification. This is used when rotating keys to retire old selectors.
If you see an empty p= that you did not intend, republish the correct public key immediately. Every message signed with that selector will fail authentication until the key is restored.
DKIM Syntax Breakdown
A DKIM TXT record is a semicolon-separated list of tag=value pairs. A minimal valid DKIM record looks like this:
s= — Service type. Restricts key usage. s=email or s=* (all services).
h= — Hash algorithms. Colon-separated. Defaults to allowing all algorithms. Prefer sha256.
n= — Human-readable notes. Ignored by mail servers.
Tags are separated by semicolons. Whitespace around tags and values is ignored. The p= value may contain whitespace that should be stripped before use.
Why DKIM Fails
DKIM failures are one of the most common email deliverability problems. The most frequent causes:
Wrong selector: The selector in the DKIM-Signature header does not match any published DNS record. Check the s= field in the email header and make sure it matches a record in DNS.
Key mismatch: The private key used to sign the message does not match the public key published in DNS. This happens after a key rotation where the DNS record was not updated, or where the wrong key was uploaded to the sending platform.
Missing DNS record: The public key was never published, was deleted, or the DNS record contains a typo in the host entry.
Empty p= (revoked key): The record exists but the public key was intentionally or accidentally revoked.
Message body modified in transit: DKIM signs a hash of the message body. If a relay or forwarding server modifies the body (adds a footer, changes encoding), the hash will not match and DKIM will fail. This is a legitimate forwarding failure, not a configuration problem.
DNS propagation: A newly published or updated DKIM record may not yet be visible to all DNS resolvers. Wait up to 48 hours and check again.
Testing mode (t=y): The key is marked as a test key. Some receivers treat test keys as if DKIM did not exist.
How to Fix DKIM Errors
The fix depends on the specific error found by the checker above. Common fixes:
No DKIM record found: Publish a DKIM TXT record at selector._domainkey.yourdomain.com. Generate a 2048-bit RSA key pair — upload the private key to your sending platform and publish the public key in DNS.
Wrong selector: Find the exact selector from your sending platform's documentation or from the DKIM-Signature header in a real sent message. Re-run this checker with the correct selector.
Key mismatch: Regenerate a new key pair in your sending platform and re-publish the new public key in DNS. After publishing, wait for propagation before testing.
Empty p= (revoked): If unintentional, immediately republish the public key. If intentional, generate a new key pair under a new selector.
1024-bit key: Generate a new 2048-bit key pair. Publish it under a new selector (e.g. if your current selector is mail, use mail2). Update your sending platform to use the new private key, then test before removing the old selector.
Testing mode: Remove t=y from your DNS record once you have confirmed DKIM is working correctly.
DKIM for Google Workspace
Google Workspace (formerly G Suite) supports DKIM signing for all outbound email. Setting it up requires generating a key in the Google Admin console and publishing it in your domain's DNS.
Steps to set up DKIM for Google Workspace:
Go to Google Admin console → Apps → Google Workspace → Gmail → Authenticate email.
Select your domain and click Generate new record. Choose 2048-bit key length.
Copy the DNS TXT record provided. The host entry will be google._domainkey.yourdomain.com.
Publish the TXT record in your DNS provider.
Wait for propagation (up to 48 hours), then return to the Admin console and click Start authentication.
To check your Google Workspace DKIM, enter your domain in the checker above with the selector google. If the record is found and valid, DKIM is configured correctly.
DKIM for Cold Email Outreach
DKIM is non-negotiable for cold email. Since Google and Yahoo introduced bulk sender requirements in 2024, authenticated email — meaning valid DKIM, SPF, and DMARC — is required for anyone sending at scale. Without DKIM, your cold emails are at high risk of spam folder placement or outright rejection.
For cold email infrastructure, follow these best practices:
Use a 2048-bit DKIM key for every sending domain and subdomain.
Set up a dedicated sending domain (e.g. mail.yourdomain.com or a separate domain entirely) to protect your main domain's reputation.
Publish DKIM for every domain in your sending infrastructure — even secondary or warmup domains.
Pair DKIM with a valid SPF record and a DMARC policy (at minimum p=none with a reporting email) for full authentication coverage.
Warm up new domains before sending cold outreach. A brand-new domain with no sending history will be treated with suspicion regardless of authentication setup.
Authentication is the foundation — inbox warming is what builds the reputation on top of it. Use Warmbase to automate the warmup process and maintain sender reputation across all your sending domains.
DKIM Key Strength: 1024-bit vs 2048-bit
The key length directly affects the cryptographic security of your DKIM signatures. Here is how 1024-bit and 2048-bit keys compare:
1024-bit keys: Historically standard, but now considered weak by modern cryptographic standards. The IETF recommended moving away from 1024-bit RSA keys in 2014 (RFC 6376 update). While most mail servers still accept 1024-bit keys, some strict receivers reject them. Google's 2024 sender requirements recommend 2048-bit keys.
2048-bit keys: The current recommended minimum. Significantly more secure and accepted by all major mail servers and providers. Generates longer DNS TXT records but this is well within DNS limits.
If the checker shows your domain is using a 1024-bit key, you should plan an upgrade. The process: generate a new 2048-bit key pair, publish it under a new selector, update your sending platform to use the new private key, confirm delivery, then remove the old 1024-bit selector.
Never delete an old selector until you have confirmed the new one is working. Both can coexist in DNS simultaneously during the transition.
DKIM vs SPF vs DMARC
Email authentication relies on three complementary standards. Each protects against different attack vectors:
SPF (Sender Policy Framework): Publishes a list of IP addresses authorised to send email on behalf of a domain. The receiving server checks the connecting IP against this list. SPF verifies the envelope sender, not the visible From: address. SPF breaks when email is forwarded.
DKIM (DomainKeys Identified Mail): Attaches a cryptographic signature to each message, tied to the sending domain. The receiving server verifies the signature using the public key in DNS. DKIM verifies message content integrity and survives forwarding. It does not verify the sending IP.
DMARC (Domain-based Message Authentication, Reporting & Conformance): Ties SPF and DKIM together and enforces a policy. DMARC requires that the From: domain aligns with either the SPF envelope domain or the DKIM signing domain. It also provides reporting so domain owners can see authentication results. DMARC policies range from p=none (monitoring only) to p=quarantine (spam folder) to p=reject (block entirely).
All three are needed. SPF alone can be bypassed via forwarding. DKIM alone does not prevent IP-based spoofing. DMARC without SPF or DKIM has nothing to enforce. Together, they form a complete email authentication stack that protects deliverability and prevents domain spoofing.
Troubleshooting DKIM Issues
If DKIM is failing despite a record appearing to be published, work through this checklist:
Verify the selector: Use this checker with the exact selector from the DKIM-Signature header in a real sent message. The selector is in the s= field of the header.
Check for typos in the DNS host entry: The record must be published at exactly selector._domainkey.yourdomain.com. A common mistake is publishing at selector._domainkey without the domain, or adding www..
Verify the public key matches the private key: If you regenerated keys and uploaded the new private key but forgot to update the DNS TXT record, DKIM will fail. Regenerate and republish both.
Wait for propagation: DNS changes can take up to 48 hours. Use multiple DNS checkers (including this one) to check if the record is visible from multiple locations.
Check for DNS record length issues: Some DNS providers split long TXT records across multiple strings. Most handle this transparently, but some don't. If the public key appears truncated in our checker, try re-publishing as a single concatenated string.
Send a test message and inspect headers: Send an email to check-auth@verifier.port25.com for a full authentication report. Or send to Gmail and look at the original headers — find the Authentication-Results header for the verdict.
Check DMARC reports: If DMARC is set up, reports will tell you which messages are failing DKIM and from which IP addresses.
Best Practices for DKIM
Use 2048-bit RSA keys. Always generate 2048-bit keys for new setups. Never generate new 1024-bit keys.
Use a unique selector per service. Each sending platform should have its own selector and key pair. This isolates services — if one key is compromised, only that service is affected.
Rotate keys periodically. Best practice is to rotate DKIM keys every 6–12 months. Publish the new key under a new selector, transition your sending platform, then retire the old selector.
Never delete an old selector until confirmed. Keep old selectors active for at least 72 hours after transitioning to give in-flight messages time to be delivered and verified.
Do not use t=y in production. Testing mode is only for initial setup validation. Remove it immediately once DKIM is confirmed working.
Pair with SPF and DMARC. DKIM alone is not sufficient. A complete authentication stack requires SPF, DKIM, and DMARC working together.
Set up DMARC reporting. Even p=none with a rua= reporting address gives you visibility into authentication failures before you enforce a stricter policy.
Warm up new domains. Authentication is not a substitute for sender reputation. New domains must be warmed up gradually to build the trust signals that major inbox providers use for filtering decisions.
Frequently Asked Questions
A DKIM checker is a tool that performs a live DNS lookup for a domain's DKIM TXT record at a specified selector, validates the record for errors, inspects the public key, parses all DKIM tags, and provides actionable deliverability recommendations. It saves you from manually querying DNS and interpreting raw records.
A DKIM selector is a string used to identify which DKIM key to use. It forms part of the DNS lookup path: selector._domainkey.yourdomain.com. To find your selector, look at the raw headers of a sent message and find the DKIM-Signature header — the s= field is your selector. Common selectors include google, selector1, mail, and default.
The most common reasons are: you are checking the wrong selector (verify the exact selector from your provider), the DNS record has not yet propagated (wait up to 48 hours), there is a typo in the DNS host entry, or DKIM was never configured for this domain with your email platform. Check your provider's documentation for the exact DNS entry required.
2048-bit keys are strongly recommended and effectively required for modern email infrastructure. While 1024-bit keys still work at most receivers, some strict servers reject them, and the IETF and Google both recommend 2048-bit as the minimum. Always generate new keys at 2048 bits.
DNS propagation for a new DKIM record typically takes between a few minutes and 48 hours, depending on your DNS provider and the TTL of the record. Most major DNS providers propagate changes within 1–2 hours. If your record is not found immediately after publishing, wait and check again before troubleshooting further.
Yes — unlike SPF, DKIM supports multiple selectors per domain. Each selector is an independent DNS record. You can have one for Google Workspace, one for SendGrid, one for your custom SMTP, and so on. All work simultaneously. This is best practice: each sending service should have its own DKIM key pair.
Common causes include: the wrong selector configured in Google Admin, the DNS record not yet published or containing a typo, the private key in Google Admin not matching the public key in DNS, or DKIM not yet activated in Google Admin after publishing the DNS record. Go to Admin console → Apps → Google Workspace → Gmail → Authenticate email and verify the status shows "Authenticating email".
An empty p= tag means the DKIM key has been revoked. Any message signed with this selector will fail DKIM verification. If this was intentional (you retired an old key), ensure a new selector with a valid key is active. If it was unintentional, republish the correct public key immediately.
DKIM generally survives email forwarding — unlike SPF, which breaks when the connecting IP changes. However, some forwarders modify the message body (adding a footer or disclaimer), which invalidates the DKIM body hash and causes verification failure. DKIM header signing is unaffected by body changes, but body signature failures can still impact DMARC alignment depending on the signing configuration.
Security best practice recommends rotating DKIM keys every 6–12 months. To rotate safely: generate a new key pair, publish the new public key under a new selector, update your sending platform to use the new private key, confirm email is being signed and verified with the new key, then retire the old selector after 72 hours to allow in-flight messages to be verified.
DKIM is necessary but not sufficient on its own. You also need a valid SPF record and a DMARC policy. Beyond authentication, inbox placement depends heavily on sender reputation — which is built over time through consistent sending, low bounce rates, good engagement, and inbox warming. Authentication is the foundation; reputation is built on top of it.
Increase email deliverability with Warmbase and never land in your prospect's spam box again.
