App StoreApp Store
Google PlayGoogle Play
Temp Mail Logo

Temp Mail safeguards your privacy while keeping your inbox free from spam.

DKIM Checker · Tag Parser · Key Strength · Selector Discovery

DKIM Analyzer

Free DKIM record checker and analyzer. Look up any domain's DKIM DNS record, parse every tag, verify key strength, detect revoked keys and test mode. Includes 20-selector bulk scan.

✓ Full tag-by-tag parsing✓ RSA key bit estimation✓ Revocation detection✓ 20-selector bulk scan✓ No signup
Queries via Cloudflare DNS-over-HTTPS (Google DoH fallback). Enter a custom selector or leave blank for 'default'.
What this tool does

Free DKIM analyzer: check, validate, and inspect DKIM DNS records

DKIM (DomainKeys Identified Mail, defined in RFC 6376) is an email authentication protocol that lets a domain owner cryptographically sign outgoing messages. When your mail server sends an email, it attaches a digital signature in the DKIM-Signature header using a private key. Receiving mail servers retrieve the corresponding public key from DNS, the DKIM TXT record stored at selector._domainkey.yourdomain.com, and verify the signature. A valid signature confirms the message was not altered in transit and genuinely originated from an authorised source for the signing domain. Unlike SPF, DKIM signatures survive email forwarding because they are embedded in the message headers rather than tied to the sending server's IP address, making DKIM the more reliable alignment mechanism when combined with DMARC.

A DKIM record is stored under a specific selector subdomain. The selector is a label chosen by the domain owner that namespaces the key. A domain can have multiple DKIM keys active simultaneously, one per selector. This allows different email service providers (Google Workspace, SendGrid, Mailchimp, Salesforce) to each use a distinct key, and enables key rotation without disrupting delivery. Common selector names include google, selector1, selector2, mail, k1, and k2. If you do not know your selector, use the Bulk Scan mode to check 20 common names automatically.

This DKIM analyzer queries your domain's record in real time using Cloudflare DNS-over-HTTPS (with Google DoH fallback) and decodes every tag. It estimates RSA key bit-strength from the base64-encoded p= key length: anything under 1024 bits fails at many providers, 1024-2047 is valid but aging, and 2048+ is the current recommendation. Ed25519 keys are detected and treated as secure regardless of size. The analyzer also flags revoked keys (empty p= tag) and test mode configurations (t=y flag) that must be removed before production use.

What this tool analyzes
v= tag
Version. Should always be DKIM1
k= tag
Key type. RSA (standard) or Ed25519 (modern, compact)
p= tag
Public key. Analyzed for bit strength; empty p= means revoked
t= tag
Flags. Detects test mode (t=y) that must be removed for production
h= tag
Hash algorithms. Checks for SHA-256 support; flags SHA-1 only
s= tag
Service type. Detects keys restricted to specific service types
n= tag
Notes. Any human-readable notes published by the domain owner
Key bit-strength
Estimates RSA key size from base64 p= length: <1024 = bad, 1024-2047 = warn, 2048+ = good
Bulk selector scan
Checks 20 common selectors to discover all active DKIM keys on a domain
Revoked key
Immediately flags an empty p= tag and explains the delivery impact
Why it matters

Why verifying your DKIM record protects deliverability, alignment, and domain trust

DKIM serves two distinct purposes that are often conflated. The first is message integrity. The cryptographic signature proves the email body and specified headers were not modified between the sending server and the recipient. The second, and more practically critical for most domain owners, is DMARC alignment. Under a DMARC policy, a message passes only if either SPF or DKIM aligns with the visible From: header domain. For organisations using email service providers, Mailchimp, SendGrid, HubSpot, Klaviyo, Zendesk, the Return-Path address is almost always the ESP's own domain, which means SPF alignment fails. DKIM alignment is the primary mechanism that keeps DMARC passing in these configurations.

This means a broken, revoked, or missing DKIM record is not just a theoretical concern. Under a DMARC enforcement policy of p=quarantine or p=reject, it directly causes legitimate email to be filtered or rejected. The failure is often silent: from the sender's perspective the message appears to send normally, but DMARC aggregate reports show a spike in failures from that sending source. Regularly checking DKIM with this analyzer catches these issues before they become delivery incidents.

Key strength is a second area where neglect has real consequences. RSA-1024 keys, common in setups configured five or more years ago, are now flagged as insecure by Google and Microsoft. If your analyzer result shows a 1024-bit key, plan a rotation to 2048-bit RSA or Ed25519 at your next maintenance window. The rotation process is non-disruptive: publish the new selector, let DNS propagate, switch signing to the new key, then revoke the old one. All without any gap in delivery.

For domains targeting the Google and Yahoo 2024 bulk sender requirements, DKIM is mandatory. Senders of more than 5,000 daily messages to Gmail must have valid DKIM signing in place. Even below that threshold, missing DKIM is one of the strongest negative signals spam filters use to classify email from unknown senders.

Troubleshooting

Common DKIM problems and how to fix them

Most DKIM failures trace to one of a small number of root causes. Here is what each means and how to resolve it.

DKIM record not found. No TXT record at selector._domainkey.yourdomain.com
Why it happens: DKIM signing has never been configured for this domain and selector, or the DNS record was published at the wrong hostname. A common mistake is publishing at domainkey.yourdomain.com instead of selector._domainkey.yourdomain.com (note the selector prefix and underscore).
Fix: Locate the correct selector name from your email provider's admin settings. Google Workspace uses 'google', Microsoft 365 uses 'selector1' and 'selector2', Mailchimp uses 'k1'. Publish the TXT record at the exact hostname: selector._domainkey.yourdomain.com. Use the bulk scan mode to confirm the record is live after publishing.
DKIM passes but DMARC is still failing
Why it happens: DKIM alignment is failing. The DKIM d= signing domain does not match the From: header domain. This happens when an ESP signs messages using their own domain in d= rather than yours. The signature is cryptographically valid but provides no DMARC alignment for your domain.
Fix: Check your ESP's settings for a 'custom DKIM' or 'authenticated domain' option. Most major platforms (Mailchimp, SendGrid, HubSpot, Klaviyo) allow you to add a CNAME record to your DNS that delegates signing to their infrastructure while placing your domain in the d= tag. After adding the CNAME and enabling custom DKIM in the platform, re-check alignment using the DMARC Checker.
Key shows as 1024-bit RSA. Flagged as weak
Why it happens: The DKIM key was generated several years ago when 1024-bit was considered acceptable. Many providers including Gmail and Outlook now flag or reject email signed with sub-2048-bit keys.
Fix: Generate a new 2048-bit RSA or Ed25519 key pair. Publish the new key under a new selector name (e.g. if the current selector is 'google', the new one might be 'google2' or use your provider's rotation mechanism). Configure your mail server or email provider to sign with the new selector, wait for DNS propagation, confirm the new record appears in this analyzer, then revoke the old key by setting its p= value to empty.
Key shows as REVOKED. Empty p= tag
Why it happens: The DKIM key for this selector has been intentionally or accidentally revoked. Any email signed with this selector will fail DKIM verification immediately.
Fix: If this was intentional (old key being retired): confirm a replacement selector is active by running a bulk scan. If accidental: check your DNS zone for whether the p= value was cleared during an edit. To restore the key, you will need to regenerate it in your mail server or provider. The private key is not recoverable from the DNS record alone. Publish a new selector and begin signing with it immediately.
Test mode enabled. T=y flag present
Why it happens: The DKIM record was published with the t=y flag during initial setup and was never updated for production. Test mode means receiving servers may not enforce DKIM failures.
Fix: Edit your DKIM DNS TXT record and remove the t=y flag, or remove the t= tag entirely. The record should not contain t=y in production. After removing it, allow DNS to propagate and re-run this analyzer to confirm the flag is gone.
Multiple DKIM records found for the same selector
Why it happens: Two or more TXT records exist at the same selector._domainkey.yourdomain.com hostname. This can cause verification failures as receiving servers may retrieve either record unpredictably.
Fix: Log into your DNS provider and delete all but one TXT record at that selector hostname. Keep only the most recent, correct record. This typically occurs when a DNS panel creates a new record on each save rather than overwriting the existing one.
Examples

Real DKIM records decoded: what the analyzer finds in each case

Six configurations covering the most common patterns seen in production deployments.

Example 1Google Workspace, 2048-bit RSA
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a8...
Standard Google Workspace DKIM configuration. v=DKIM1 and k=rsa are correct. A long p= value indicates a 2048-bit RSA key. Secure and widely supported. This configuration passes all checks.
Example 2Ed25519 modern key
v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=
A compact Ed25519 key. Only 44 base64 characters but provides approximately 256-bit security equivalent. Modern and efficient. Supported by most major mail servers. The analyzer correctly identifies this as a non-RSA key and skips bit-strength estimation.
Example 3Revoked key. Will fail verification
v=DKIM1; k=rsa; p=
An empty p= tag signals that this DKIM key has been revoked. Any email signed with this selector will immediately fail DKIM verification at receiving mail servers. Publish a new selector with a new key before revoking the old one.
Example 4Test mode. Not enforced in production
v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...
The t=y flag puts this selector in test mode. Receiving servers may log DKIM failures rather than treating them as hard errors. This is appropriate during initial setup, but must be removed before the selector is used in production email.
Example 5Weak key. Below minimum (1024-bit RSA)
v=DKIM1; k=rsa; p=MIGJAoGBALRiMLAHudeSA8xP...
A shorter p= value indicates a 1024-bit RSA key, which is below the current recommended minimum of 2048 bits. Gmail and other major providers may reject or warn on email signed with sub-1024-bit keys. Rotate to a 2048-bit or Ed25519 key as soon as possible.
Example 6SHA-1 only hash. Deprecated algorithm
v=DKIM1; k=rsa; h=sha1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
The h=sha1 tag restricts this key to SHA-1 hashing only. SHA-1 is deprecated for email authentication. Many modern mail servers will not accept SHA-1 DKIM signatures. The h= tag should be either omitted (which defaults to accepting both SHA-1 and SHA-256) or set to h=sha256 explicitly. Update the record and regenerate the key if your signing infrastructure does not support SHA-256.
FAQ

DKIM analyzer questions and answers

Answers to the most common questions about DKIM records, selectors, key strength, alignment, and setup for Google Workspace and Microsoft 365.

What is a DKIM record?
A DKIM (DomainKeys Identified Mail) record is a DNS TXT entry published at selector._domainkey.yourdomain.com that contains the public key used to verify cryptographic signatures on outgoing email. When a mail server receives a message, it reads the DKIM-Signature header to find the selector (s=) and signing domain (d=), then retrieves the corresponding public key from DNS and uses it to verify the signature. A valid signature confirms the message was not altered in transit and genuinely originated from the signing domain. This mechanism is defined in RFC 6376.
What is a DKIM selector?
A selector is a label that namespaces the DKIM key, stored in DNS as selector._domainkey.yourdomain.com. A domain can publish multiple DKIM keys simultaneously. One per selector name. This allows different email services to use different keys, and enables safe key rotation without disrupting delivery. Common selector names include default, google, selector1, selector2, mail, k1, and k2. Checking common selector names is the fastest way to discover whether DKIM is configured when you do not know the selector in advance.
How do I find my DKIM selector?
The fastest method is to look in the DKIM-Signature header of any email you have sent from that domain. The s= tag contains the selector name. You can view email headers in most email clients under 'View Source' or 'Show Original'. If you use Google Workspace, your selector is typically 'google'. For Microsoft 365 it is 'selector1' or 'selector2'. For Mailchimp it is often 'k1'. For SendGrid it is commonly 's1'. If you cannot find a sent email, use the bulk scan mode above to check 20 common selectors automatically.
What DKIM key size is recommended?
2048-bit RSA is the current recommendation for all new DKIM deployments. Keys below 1024 bits are rejected by many mail providers including Gmail and Outlook. Keys between 1024 and 2047 bits are technically valid but considered aging and should be rotated. Ed25519 is an excellent modern alternative. It provides approximately 256-bit equivalent security in a much smaller key and is supported by most major mail servers including Gmail and Outlook since 2022. If your current record shows a 1024-bit RSA key, plan a rotation to 2048-bit or Ed25519 at your next maintenance window.
What does 'key revoked' mean in a DKIM record?
A revoked DKIM key has an empty p= tag (p=). This signals to receiving mail servers that the key is no longer valid and any email signed with that selector should fail DKIM verification. If you need to rotate keys, always publish a new selector with the new key first, allow DNS to propagate (typically 5-30 minutes for modern providers), then revoke the old one. Never delete an active DKIM DNS record without first deploying a replacement selector, as in-flight messages signed with the old key will immediately fail verification.
What is DKIM test mode?
DKIM test mode is indicated by the t=y flag in the DKIM record. It signals to receiving servers that the domain owner is still testing their DKIM setup and that failures should not be treated as hard errors. Receiving servers may log the failure rather than enforcing it. This is useful during initial configuration but the t=y flag must be removed before the selector is used in production. Otherwise DKIM provides no real authentication benefit and emails may still fail downstream checks.
What does the DKIM p= tag contain?
The p= tag contains the RSA or Ed25519 public key in base64-encoded format. For RSA keys, the length of this base64 string is proportional to the key size. A 2048-bit key produces a significantly longer p= value than a 1024-bit key. This analyzer estimates bit-strength by measuring the decoded length of the p= value. An empty p= tag (p=) means the key has been explicitly revoked. A missing p= tag means the record is malformed.
How does this DKIM analyzer work?
The tool queries the DKIM DNS TXT record at selector._domainkey.yourdomain.com using Cloudflare DNS-over-HTTPS as the primary resolver, with Google DoH as automatic fallback. It then parses the raw TXT record and analyzes each tag: v= (version), k= (key type), p= (public key and bit-strength estimate), t= (flags including test mode), h= (hash algorithms), s= (service type restriction), and n= (human-readable notes). The analyzer runs entirely from your browser. No email is sent, no domain is stored on Best-TempMail servers.
What is a DKIM bulk selector scan?
The bulk scan mode checks 20 common DKIM selector names against your domain simultaneously. Including default, google, selector1, selector2, mail, k1, k2, mailchimp, sendgrid, amazonses, mimecast, proofpoint, and others. This is useful when auditing all active DKIM keys on a domain, when you do not know which selectors your providers have configured, or when inheriting a domain you did not originally set up. The bulk scan runs in parallel and displays which selectors are active, which have weak keys, and which are revoked.
Does DKIM alone protect against email spoofing?
DKIM alone is not sufficient for full protection. It verifies that the signing domain authorised the message and that it was not altered in transit, but it does not prevent a completely different domain from signing with their own DKIM key and sending a spoofed message. DKIM is most effective as part of the full authentication stack: SPF restricts which servers can send on behalf of your domain, DKIM signs messages cryptographically, and DMARC ties the two together by requiring alignment, the DKIM d= domain must match the visible From: header, and specifying a policy for failures.
Why is DMARC failing even though DKIM is passing?
DKIM passing is not the same as DKIM alignment passing. DMARC requires the DKIM d= signing domain to match the From: header domain. Either exactly (strict mode, adkim=s) or as a parent domain (relaxed mode, adkim=r, the default). If your DKIM signature uses a signing domain that does not match your From: header, for example, a DKIM signature from your ESP's own domain rather than yours, DKIM passes cryptographically but fails alignment. The fix is to ensure your ESP signs with your own domain in the d= tag, which typically requires adding a CNAME record to your DNS pointing to the ESP's signing infrastructure.
How do I set up DKIM for Google Workspace?
In Google Workspace, navigate to Apps > Google Workspace > Gmail > Authenticate email in the Admin Console. Click Generate new record, choose 2048-bit as the key size, and Google will provide a TXT record value to publish at google._domainkey.yourdomain.com. After publishing the DNS record, return to the same Admin Console page and click Start authentication. Google will verify the record and begin signing outgoing messages. The selector is 'google'. Allow 24-48 hours after DNS propagation before testing to ensure all Google mail servers have picked up the new key.
How do I set up DKIM for Microsoft 365?
In Microsoft 365, go to the Defender portal (security.microsoft.com), navigate to Email & Collaboration > Policies & Rules > Threat Policies > DKIM. Select your domain and click Enable. Microsoft will display two CNAME records to publish. One for selector1 and one for selector2. Publish both CNAME records in your DNS, then return to the Defender portal and click Enable again once DNS has propagated. Microsoft 365 automatically rotates between selector1 and selector2 for key rotation. Allow up to 15 minutes after DNS propagation for DKIM signing to activate.
What is the difference between RSA and Ed25519 DKIM keys?
RSA DKIM keys are the traditional standard. Widely supported across all mail servers. The recommended size is 2048 bits; 4096 bits is more secure but note that some DNS providers cannot publish 4096-bit keys in a single TXT record due to the 255-byte string limit, requiring two records. Ed25519 keys are a modern elliptic-curve alternative that provide roughly 256-bit equivalent security in a much smaller key (44 base64 characters vs hundreds for RSA-2048). Ed25519 resolves the DNS size problem entirely, is faster to verify, and is supported by Gmail, Outlook, and most modern mail servers. If your provider supports it, Ed25519 is the better choice for new deployments.
How often should I rotate DKIM keys?
The generally recommended rotation interval is every 6-12 months for RSA-2048 keys, though many organisations with strong security practices rotate quarterly. The process is: (1) generate a new key pair, (2) publish the new selector in DNS, (3) wait for propagation, (4) configure your mail server to sign with the new selector, (5) revoke the old selector by setting its p= tag to empty, (6) remove the old record after 30 days. Never delete the old DNS record immediately. Messages in transit may still carry the old signature. Google Workspace and Microsoft 365 handle rotation automatically. For custom mail server setups, add key rotation to your annual infrastructure calendar.
Technical background

DKIM in the email authentication stack: how it works with SPF and DMARC

DKIM does not operate in isolation. It is the signature layer in a three-part authentication stack, and understanding where each standard begins and ends is essential for diagnosing failures and configuring authentication from scratch.

SPF (Sender Policy Framework) answers the question: is this IP address authorised to send email for this domain? It validates the SMTP envelope sender, the hidden MAIL FROM address used during the server handshake, not the visible From: header. SPF breaks for forwarded email and for any sender using an ESP that sends via their own mail infrastructure. Use the SPF Record Checker to verify your SPF record is valid and within the 10-lookup limit. If your record has too many include: chains, the SPF Flattening Tool resolves them to direct IP ranges.

DKIM (DomainKeys Identified Mail) answers a different question: was this message signed by the domain that claims to have sent it, and has it been altered since signing? The signature is tied to the d= domain in the DKIM-Signature header, a domain you control, so it is unaffected by the sending server's IP or the ESP's Return-Path address. This is why DKIM alignment is more reliable than SPF alignment for third-party sending platforms, and why it is the primary mechanism that keeps DMARC passing when SPF alignment is structurally unavailable.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It requires at least one of SPF or DKIM to pass with alignment to the visible From: header, and defines what to do when neither does: none (monitor), quarantine (spam folder), or reject (block delivery). It also enables daily aggregate reports showing pass/fail rates from all sending sources. The most practical way to catch DKIM issues early. Check your current DMARC enforcement level with the DMARC Checker, or get a full tag-by-tag breakdown with the DMARC Analyzer.

The recommended deployment sequence is: (1) set up SPF covering all sending sources, (2) enable DKIM signing via all email providers, (3) publish DMARC at p=none with rua= configured, (4) review aggregate reports for 2-4 weeks, (5) advance to p=quarantine then p=reject once all sources are passing. DKIM is step two. Getting it right before advancing DMARC policy is what makes enforcement safe.

Related Email Authentication Tools

Need a disposable address right now? Generate a free, instant throwaway email. Zero signup, zero trace.

Get Free Temp Mail