Look up and validate DKIM records for any domain. Check key type, key length, and signature configuration in seconds.
Common selectors: google, selector1, selector2, default, dkim, s1, s2, k1
DKIM (DomainKeys Identified Mail) is an email authentication protocol that attaches a digital signature to every outgoing email from your domain. The receiving mail server verifies that signature using a public key published in your DNS. If the signature matches, the server knows two things: the email genuinely came from your domain, and the message body was not tampered with during transit.
Think of DKIM as a wax seal on a letter. The seal proves who sent it and proves nobody opened the envelope along the way. Without the seal, anyone could forge the sender's name, and nobody would know whether the contents were altered in transit.
DKIM was developed by merging two earlier proposals — Yahoo's DomainKeys and Cisco's Identified Internet Mail — and was standardized as RFC 6376 in 2011. Today, it is one of three core email authentication protocols alongside SPF and DMARC.
Every major mailbox provider — Gmail, Outlook, Yahoo, Apple Mail — checks DKIM signatures when processing inbound email. Google and Yahoo both made DKIM a requirement for bulk senders starting in 2024. If you send marketing emails, cold outreach, or transactional messages, a valid DKIM record is no longer optional.
DKIM public keys are stored as TXT records in your domain's DNS. The record lives at a specific address formed by combining the selector and your domain: selector._domainkey.yourdomain.com. When a receiving server needs to verify a DKIM signature, it looks up this exact DNS path to retrieve the public key.
Unlike SPF, which is limited to one record per domain, DKIM allows multiple records because each one is identified by a unique selector. This means you can use different signing keys for different email services — one for Google Workspace, another for your marketing platform, another for your transactional email provider — all on the same domain without conflicts.
DKIM relies on public-key cryptography. Your sending server holds a private key that signs outgoing emails, and your DNS holds the corresponding public key that anyone can use to verify those signatures. Here is the full process:
When you send an email, the outgoing mail server takes specified parts of the message -- typically the body and key headers like From, To, Subject, and Date -- and runs them through a hashing algorithm (usually SHA-256) to produce a fixed-length digest.
The sending server encrypts that hash digest using your domain's DKIM private key. This produces the digital signature -- a unique string of characters that can only be generated by someone holding your private key.
The encrypted signature is added to the email as a DKIM-Signature header. This header also includes metadata: the selector (s=), the signing domain (d=), the algorithm used (a=), and which headers were signed (h=).
When the email arrives at the recipient's mail server, the server reads the DKIM-Signature header and extracts the selector and domain values to know where to find the public key.
Using the selector and domain from the signature, the receiving server queries DNS for the TXT record at selector._domainkey.domain.com. This is the exact lookup our DKIM checker performs above.
The receiving server decrypts the signature using the public key from DNS, independently hashes the same email content, and compares the two values. If they match, the email passes DKIM authentication. If they don't, the signature is invalid.
Every DKIM-signed email carries a DKIM-Signature header that looks something like this:
v=1DKIM version (always 1)a=rsa-sha256Signing algorithm (RSA key with SHA-256 hash)d=yourdomain.comThe signing domains=googleThe selector used to locate the public keyc=relaxed/relaxedCanonicalization method for headers/bodyh=from:to:subject:...Which headers are included in the signaturebh=abc123...Hash of the email bodyb=xyz789...The actual digital signatureAfter running a domain through our DKIM record checker, here's how to interpret each field.
The DKIM record exists, the syntax is correct, and the public key is properly formatted. This is the result you want -- your emails can be verified by any receiving server.
A DKIM TXT record exists at the selector path, but something is wrong -- the key may be malformed, the version tag could be missing, or the record might have syntax errors. Emails may fail DKIM verification.
No TXT record exists at selector._domainkey.yourdomain.com. Either the selector is wrong, the record hasn't been created, or DNS hasn't propagated yet.
The cryptographic algorithm used for the key pair. RSA is the dominant standard, used by virtually all email providers. Ed25519 is a newer, faster algorithm with smaller keys, but it has limited adoption and some mail servers don't support it yet. If your key type shows RSA, you're in good shape.
The size of the RSA key in bits. 2048-bit is the current standard. If you see 1024-bit, your key is considered weak by modern standards and could theoretically be cracked with enough computing power. Upgrade to 2048-bit as soon as possible. Keys of 4096-bit offer additional security but can cause issues with DNS record length limits at some providers.
The hashing method used to create the message digest. SHA-256 is the current standard and is secure. If you see SHA-1, it is deprecated and considered weak — update your DKIM configuration to use SHA-256.
Optional flags that modify how the key is used. The most common flag is t=y which indicates testing mode — receiving servers should treat DKIM failures as non-fatal. The t=s flag means strict alignment: the signing domain must exactly match the From domain. If no flags are set, the key is in production mode with relaxed alignment.
A DKIM selector is a name that identifies which DKIM key a receiving server should look up. Since a single domain can have multiple DKIM keys — one for each email service — the selector tells the verifying server exactly which public key to retrieve from DNS.
The selector appears in two places: in the DKIM-Signature email header (as the s= value) and in the DNS record path. If your selector is google and your domain is acme.com, the public key lives at google._domainkey.acme.com.
Default selector for Gmail/Workspace
selector1, selector2
Microsoft uses two selectors for key rotation
s1, s2
SendGrid's standard DKIM selectors
smtp, k1
Varies by configuration
Custom CNAME
SES uses unique CNAME-based selectors
20yymmdd (date-based)
Uses date-stamped selectors
hs1, hs2
HubSpot's DKIM selectors
default, dkim
Common cold email tool defaults
If you do not know your DKIM selector, the easiest way to find it is to send yourself an email from the domain and inspect the full email headers of the received message:
If you cannot send a test email, try common selectors in our DKIM checker above. Start with google (if using Google Workspace), selector1 (if using Microsoft 365), or default as a general fallback.
The key length of your DKIM key directly affects the security of your email signatures. Here is why it matters and what you should use.
In 2012, a team of researchers demonstrated that a 768-bit RSA key could be factored with modest computing resources. By extrapolation, 1024-bit keys are considered within reach of well-funded attackers. While no public demonstration of cracking a 1024-bit DKIM key has been published, the cryptographic community unanimously recommends 2048-bit or higher.
Google rotates its own DKIM keys to 2048-bit. Microsoft 365 uses 2048-bit by default. If your DKIM checker results show a 1024-bit key, your email provider likely generated it years ago. Most providers offer a straightforward way to regenerate a stronger key — check your admin console or contact support.
What about 4096-bit? While 4096-bit RSA keys offer even stronger security, they create very long DNS TXT records that can exceed the 255-character per-string limit in DNS. Some DNS providers handle this by splitting the record into multiple strings, but others do not. Unless you have a specific compliance requirement for 4096-bit, 2048-bit is the safe choice. You can generate new DKIM keys with our free DKIM Generator.
These are the issues we see most often when checking DKIM records. If our DKIM checker flagged something for your domain, here's what to do about it.
No TXT record exists at the selector path you specified. This could mean the record was never created, you're using the wrong selector, or DKIM signing was never enabled on your email provider.
Fix: Verify you are using the correct selector by checking the DKIM-Signature header in a sent email. If DKIM has not been set up, enable it in your email provider's admin console and add the public key TXT record to your DNS.
You entered a selector that does not match the one your email provider is actually using to sign emails. The DNS lookup returns nothing even though DKIM is configured.
Fix: Send a test email and inspect the full headers to find the actual s= value in the DKIM-Signature header.
Your DKIM key is only 1024 bits long. While it will still pass DKIM checks, it is considered cryptographically weak by modern standards.
Fix: Generate a new 2048-bit DKIM key through your email provider's admin panel. Update the DNS TXT record with the new public key. The old key can be removed once the new one is live and verified.
The TXT record exists but contains syntax errors — a missing v=DKIM1 version tag, a truncated public key, extra whitespace characters, or improperly concatenated DNS record strings.
Fix: Compare your DNS record against the exact value your email provider gave you. Copy the record fresh from your provider's admin console and replace the existing DNS entry completely. Pay attention to DNS string concatenation if the record exceeds 255 characters.
You just added or updated your DKIM record but our checker does not see it yet. DNS changes can take time to propagate across the global DNS infrastructure.
Fix: Wait 1-4 hours for initial propagation, or up to 48 hours for full global propagation. Check that you added the record to the correct DNS zone (especially if you use a third-party DNS provider like Cloudflare). Verify the record name follows the selector._domainkey format exactly.
One of DKIM's biggest advantages over SPF is that it survives email forwarding. This is a critical distinction that directly affects your deliverability, especially if your recipients use mailing lists, email aliases, or forwarding rules.
When an email is forwarded, the forwarding server's IP address is different from the original sending server's IP address. Since SPF checks the sending server's IP, forwarded emails almost always fail SPF authentication. The forwarding server is not listed in the original sender's SPF record, so the check fails.
DKIM works differently. The signature is embedded in the email headers and is tied to the message content, not the transmitting server's IP address. As long as the forwarding server does not modify the signed portions of the email (the headers listed in h= and the body), the DKIM signature remains valid regardless of how many times the email is forwarded.
This is exactly why DMARC alignment is so important. DMARC requires either SPF or DKIM to pass and align with the From domain. In a forwarding scenario, SPF will fail but DKIM will pass — and that passing DKIM check is what saves your email from being rejected by DMARC. Without DKIM, forwarded emails have no surviving authentication and are far more likely to be rejected or spam-filtered.
While DKIM generally survives forwarding, there are situations where it breaks:
These edge cases are why ARC (Authenticated Received Chain) was developed — to preserve authentication results across forwarding hops. But for the vast majority of email, DKIM's forwarding resilience is a major advantage. Make sure your DKIM is set up correctly by running our checker above, then verify your DMARC policy ties SPF and DKIM together.
DKIM (DomainKeys Identified Mail) is an email authentication protocol that adds a digital signature to outgoing emails. The signature is verified by the receiving server using a public key published in the sender's DNS. If the signature checks out, the email is confirmed to be from the claimed domain and unmodified in transit.
Enter your domain name and DKIM selector into the checker at the top of this page. The tool will query DNS for the DKIM record at selector._domainkey.yourdomain.com and display the results, including the public key, key length, and any syntax issues. You can also check manually using dig or nslookup in a terminal.
A DKIM selector is a label that identifies a specific DKIM key for a domain. Since a domain can have multiple DKIM keys for different email services, the selector tells the receiving server which key to look up. It appears as the s= value in the DKIM-Signature email header.
Send an email from the domain and view the full email headers of the received message. Look for the DKIM-Signature header and find the s= tag -- that value is your selector. Alternatively, try common selectors like google, selector1, default, or s1 depending on your email provider.
Use 2048-bit. It is the current industry standard and provides strong security without compatibility issues. Avoid 1024-bit (weak and deprecated by NIST since 2013) and be cautious with 4096-bit (can cause DNS record length issues with some providers).
DKIM alone does not prevent spoofing. It proves that an email was signed by a specific domain, but it does not prevent other domains from sending email with a forged From address. To prevent spoofing, you need DKIM combined with DMARC, which enforces domain alignment and defines a policy for failed authentication.
Without DMARC, a DKIM failure is one negative signal among many -- the email may still be delivered but is more likely to land in spam. With a DMARC policy of p=quarantine or p=reject, a DKIM failure combined with an SPF failure will result in the email being quarantined or rejected.
Yes. A domain can have as many DKIM records as needed, as long as each one uses a different selector. This is common when a domain uses multiple email services -- each service gets its own selector and key pair. Unlike SPF, there is no limit on the number of DKIM records per domain.
Your DKIM record is one piece of your email authentication setup. Make sure everything else is dialed in too:
ScaledMail configures DKIM, SPF, and DMARC correctly for every inbox from day one. 2048-bit keys, proper selectors, full alignment — handled automatically.
Get Started with ScaledMail