How to Check Your Domain's DKIM Record

Why setting up DKIM isn't enough

A DKIM signature protects your emails from tampering and confirms they genuinely come from your domain. But a DKIM record in DNS can become invalid — keys expire, providers change selectors, someone accidentally deletes a TXT record. When DKIM verification fails, you won't notice on the sending side. You'll find out from DMARC reports, or when customers start complaining about missing emails.

This article covers three ways to verify your DKIM record: an online analyzer, the command line, and checking email headers directly. For each method, you'll learn what to look for and how to interpret the results.

What you need to know: domain and selector

Unlike SPF, where you only need the domain name, DKIM requires two pieces of information:

• Domain (d=) — the domain that signs the email
• Selector (s=) — an identifier for a specific key in DNS

The DKIM record lives in DNS at {selector}._domainkey.{domain}. Without the selector, you can't query the public key — unlike SPF, there's no single universal record for the entire domain.

How to find the selector

If you don't know which selector your domain uses:

1. From a received email header — send a test message and look for the DKIM-Signature header. The s= tag value is the selector:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2024;
    h=from:to:subject:date; bh=2jUSOH9N...; b=AuUoFEfD...

In this example, the selector is mail2024 and the domain is example.com.

2. From your email service admin panel — most services display the selector in their DKIM settings:

   • Google Workspace: google
   • Microsoft 365: selector1 and selector2
   • Marketing platforms: each uses its own (e.g., k1 for Mailchimp, s1 for SendGrid)

3. From your DNS manager — look for records containing ._domainkey in the name.

Verification with an online analyzer

The quickest approach. An online analyzer fetches the DKIM record from DNS, validates its syntax, checks key type and length, and flags any issues.

What the analyzer checks

Check your DKIM record with SPF Monitor's analyzer — enter your domain and selector, and the analyzer will display the full record contents and highlight any issues found.

Verification via command line

A DKIM record is a standard TXT record in DNS. You can query it directly from the terminal — you just need both the domain and the selector.

Linux and macOS: dig command

dig mail2024._domainkey.example.com TXT +short

Output:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

If the command returns no output, no record exists for that selector.

Windows: nslookup

nslookup -q=txt mail2024._domainkey.example.com

Windows: PowerShell

Resolve-DnsName -Name "mail2024._domainkey.example.com" -Type TXT

What to look for in the output

1. Does the record exist? If DNS returns NXDOMAIN, the selector doesn't exist in DNS — either the name is wrong or the record is missing.
2. Does it contain the p= tag? The public key is a mandatory part of the record. An empty p= value (no key) means the key was intentionally revoked.
3. What's the key type and length? Tag k=rsa (default if absent) or k=ed25519. RFC 8301 recommends a minimum of 2048 bits for RSA; 1024-bit keys still work but are considered insufficient.
4. Is the record complete? Long RSA keys (2048+ bits) exceed the 255-byte limit of a single DNS string. The record must be properly split into multiple quoted strings — if DNS returns it truncated, there may be an error in how it was entered.

The command line shows the record contents but doesn't validate the key or verify that signing actually works. For that, use analyzers and header checks.

Verification by checking email headers

The most reliable way to confirm that DKIM actually works end to end — from signing to verification. The DNS record may be fine, but the server might not be signing emails, or it might be using a different selector.

How to check headers

1. Send an email from the domain you want to verify to another address (ideally Gmail or another major provider).
2. In the received email, view the source / headers.
3. Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
    dkim=pass header.d=example.com header.s=mail2024;
    spf=pass (google.com: domain of info@example.com designates 198.51.100.10 as permitted sender);
    dmarc=pass (p=REJECT) header.from=example.com

Interpreting the results

Checking the DKIM-Signature header

The outgoing email headers should contain a DKIM-Signature header. If it's missing, the server isn't signing emails — the issue is in the sending server configuration, not in DNS.

Verifying multiple selectors

A single domain can use multiple DKIM selectors — one for corporate email (Google Workspace), another for marketing campaigns (SendGrid), another for the helpdesk (Freshdesk). Each selector has its own key pair and DNS record.

Verify all active selectors:

1. Identify which services send email on behalf of your domain
2. For each service, find the selector (from the service admin panel or from received email headers)
3. Verify the DNS record for each selector separately

DMARC reports show which selectors are actually in use and whether they pass verification. If you haven't set up DMARC yet, start there — it gives you a complete picture of your domain's email authentication status.

Common issues found during verification

Record doesn't exist (NXDOMAIN)

Most common cause: wrong selector or the record was never added to DNS. Verify that the selector in DNS matches the one configured on the server. Watch for typos — selector1._domainkey and selector_1._domainkey are two different records.

Key is too short

Most verifiers still accept 1024-bit RSA keys, but RFC 8301 recommends (SHOULD) a minimum of 2048 bits. Upgrading means generating a new key pair and publishing a new DNS record — ideally under a new selector for a smooth transition.

Incomplete key in DNS

A 2048-bit key exceeds the 255-byte limit of a single DNS string (RFC 1035). The value must be split into multiple quoted strings:

mail2024._domainkey.example.com TXT ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQE..."
    "...FAAOCAQ8AMIIBCgKCAQEA...")

Some DNS panels handle this splitting automatically, others don't. If you paste the key as a single string without splitting, DNS may truncate it — resulting in an invalid key and dkim=fail.

Revoked key

An empty p= value (no key) signals that the selector was intentionally revoked:

mail2024._domainkey.example.com TXT "v=DKIM1; p="

This is standard practice during key rotation — the old selector gets revoked after a transition period. But if you see a revoked key on an active selector, that's an error.

DKIM fail after forwarding

Email forwarding can cause DKIM verification failure if the forwarding server modifies signed parts of the message — for example, by adding a mailing list footer or rewriting a header. The ARC protocol (Authenticated Received Chain) helps address this by preserving original authentication results.

When to verify your DKIM record

• After initial DKIM setup — verify both the DNS record and actual signing (send a test email)
• After key rotation — confirm the new selector is in DNS and the old one is revoked
• After changing email services — new service = new selector and key
• After DNS migration — verify that all _domainkey records were transferred
• Regularly — keys should be rotated at least annually, and DNS records can change without your knowledge

Check your domain's security with a complete analysis — verify SPF, DKIM, and DMARC in one place.

DKIM verification is just one piece of the puzzle

A valid DKIM record in DNS doesn't mean your domain is fully protected. DKIM verifies message integrity and origin, but without DMARC, the recipient has no instructions on what to do with a message that fails verification. And without SPF, there's no verification of the sending server's authorization.

If your DKIM check came back clean, verify your SPF record next and set up DMARC. The complete SPF + DKIM + DMARC trio is now essential — Google and Yahoo have required it for bulk senders since 2024.