DKIM Record Lookup

Verify your DomainKeys Identified Mail (DKIM) public key record to ensure emails are cryptographically signed.

About DKIM and Selectors

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outbound emails. When a receiving mail server gets your email, it asks DNS for the public key associated with that signature to verify that the email was actually sent by you and wasn't altered in transit.

Multiple email services (e.g., Google Workspace, Mailchimp, Sendgrid) can send email on your behalf simultaneously. To prevent their cryptographic keys from conflicting, DKIM uses selectors.

A selector is a string of text that identifies the specific key being used. The DNS query format is: selector._domainkey.example.com. Common selectors include google, selector1, k1, or a unique ID provided by your ESP.

Our DKIM Checker retrieves the public key published at selector._domainkey.yourdomain.com, validates its syntax, and reports the key type and length. Use it to confirm your outgoing mail can actually be verified by receiving servers.

What is DKIM?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message your mail server sends. The receiving server fetches your public key from DNS and uses it to verify that the message genuinely came from your domain and was not altered in transit.

Your mail server holds a private key and signs selected headers plus the message body. The matching public key is published as a DNS TXT record at a name built from a selector: selector._domainkey.yourdomain.com. The signature itself travels in the DKIM-Signature header of the message and names which selector to use.

Selectors are what make key rotation practical. You can publish a new key under a new selector, switch signing over to it, and retire the old one without any gap in verification.

Cryptographically signs outgoing messages to prove authenticity
Public key published in DNS, private key held by your mail server
Defined in RFC 6376
Selectors allow multiple keys and clean rotation
Survives forwarding better than SPF, which breaks when the path changes

Why DKIM Matters

DKIM is one of the two authentication mechanisms DMARC relies on, and it is the more robust of the pair. SPF validates the connecting server, so it breaks the moment a message is forwarded through a mailing list or an alias. A DKIM signature travels with the message and keeps verifying regardless of how many hops it takes.

Since February 2024, Google and Yahoo require bulk senders to authenticate with both SPF and DKIM. Without valid DKIM signing, your DMARC policy cannot reach enforcement safely, and high-volume mail is filtered or rejected.

Required alongside SPF by Google and Yahoo for bulk senders since 2024
Survives message forwarding, unlike SPF
One of the two authentication paths DMARC can align against
Proves the message body was not modified in transit
Directly improves inbox placement and sender reputation

How This DKIM Checker Works

The tool queries the DNS TXT record for the selector you supply and parses the published key.

Validates the domain and selector inputs against format and SSRF safety checks
Queries DNS for a TXT record at selector._domainkey.yourdomain.com
Parses the DKIM tags: v=, k=, p= and any flags
Determines the key algorithm and its length in bits
Flags revoked, empty or malformed keys

How to Use the DKIM Checker

Enter your domain name in the input field
Enter the selector your mail provider uses, such as google, s1, or default
Run the check to query the published public key
Confirm a key is present and at least 1024 bits, ideally 2048
If you do not know your selector, look at the s= tag in the DKIM-Signature header of a message you sent

Understanding Your DKIM Results

A DKIM record is a set of tag-value pairs. Here is what each one means:

Field / Value	Meaning
`v=DKIM1`	The version tag. Optional, but when present it must be the first tag in the record.
`k=`	The key algorithm. rsa is the default and by far the most common. ed25519 is supported by newer implementations and produces much shorter keys.
`p=`	The public key itself, base64 encoded. This is the essential field. An empty p= means the key has been revoked and all signatures using this selector will fail.
`Key length`	Derived from the key data. 1024-bit is the practical minimum and is increasingly considered weak; 2048-bit is the current recommendation.
`t=y`	Testing mode. Receivers are told to treat failures leniently. Useful during initial setup, but it must be removed once signing is confirmed working.
`h=`	Restricts which hash algorithms may be used with this key. Most records omit it. If present it should permit sha256, since sha1 is deprecated.

Common Problems & How to Fix Them

Either the selector is wrong or the DNS record was never published.

Find the correct selector by opening a message you sent, viewing its full headers, and reading the s= tag in the DKIM-Signature line. Common values are google for Google Workspace, selector1 and selector2 for Microsoft 365, and s1 or s2 for many ESPs.

If the selector is right but no record exists, publish the public key your mail provider supplied as a TXT record at selector._domainkey.yourdomain.com.

A 1024-bit RSA key still verifies but is considered weak by modern standards, and some receivers have begun to discount it.

Generate a 2048-bit key at your mail provider, publish it under a new selector, switch signing to that selector, and remove the old record once no mail is signed with it. Note that a 2048-bit key exceeds the 255-character TXT string limit, so it must be split into multiple quoted strings — most DNS providers do this automatically.

An empty p= value explicitly revokes the key. Every signature made with this selector will fail verification.

If the revocation was intentional, remove the record entirely once no mail is signed with that selector. If it was accidental, republish the correct public key value.

The published public key does not match the private key the mail server is actually signing with. This is common after a key rotation that was only half completed.

Regenerate the key pair at your mail provider and publish the new public key exactly as given, with no added line breaks or spaces. Also check that nothing in your mail path modifies the message after signing — some appliances and mailing list footers break the body hash.

The t=y flag tells receivers to ignore DKIM failures for this domain, which means your signatures provide no real protection.

Remove t=y from the record once you have confirmed signing works correctly.

Best Practices

Use 2048-bit RSA keys rather than 1024-bit
Rotate DKIM keys at least annually using a new selector each time
Sign every outbound stream, including transactional and marketing mail
Remove the t=y testing flag once signing is verified
Keep the private key on the mail server only and never in version control
Use descriptive selector names that indicate the sending system and rotation date
Remove old selector records once no mail is signed with them

Security Recommendations

Treat the DKIM private key as a credential — anyone holding it can sign mail as your domain
Rotate keys on a schedule and immediately after any suspected server compromise
Audit third-party senders that sign on your behalf, since each one holds a key for your domain
Ensure DKIM alignment with the From domain, because an unaligned valid signature does not satisfy DMARC
Prefer sha256 hashing and reject sha1, which is deprecated for DKIM
Monitor DMARC aggregate reports for DKIM failures, which often reveal an unauthorised sender or a broken mail path

Frequently Asked Questions

DKIM is an email authentication method that adds a cryptographic signature to outgoing messages. The receiving server fetches your public key from DNS and verifies the signature, proving the message came from your domain and was not altered in transit.

A selector is a label that identifies which key to use, forming the DNS name selector._domainkey.yourdomain.com. Selectors let a domain publish several keys at once, which is what makes clean key rotation possible without interrupting verification.

Open a message you sent, view its full headers, and find the DKIM-Signature line. The s= tag in that header is your selector. Common values include google, selector1 and selector2, s1, and default.

Use 2048-bit RSA. 1024-bit keys still verify but are considered weak by modern standards. Note that a 2048-bit key exceeds the 255-character DNS string limit and must be split across multiple quoted strings, which most providers handle automatically.

Yes. They protect against different things and SPF has a significant weakness: it breaks when a message is forwarded, because the connecting server changes. A DKIM signature travels with the message and keeps verifying. DMARC can align against either, so having both gives you a fallback when one fails.

At least annually, and immediately if you suspect the private key has been exposed. Publish the new key under a new selector, switch signing over, confirm mail verifies, then remove the old record.

Many mailing lists modify the subject line or append a footer to the body, which invalidates the signature. This is why ARC exists — it preserves the original authentication results across intermediaries that legitimately alter messages.

Yes, and most organisations do. Each sending system typically has its own selector and key. This is normal and necessary when transactional mail, marketing mail and your main mail platform are handled by different providers.