How to Check If Your DKIM Is Working Correctly

DKIM (DomainKeys Identified Mail) requires two components working in unison: a public key published in DNS and a mail server that cryptographically signs every outgoing message with the corresponding private key. If either component is misconfigured, DKIM verification will fail at the receiving end, which can undermine your DMARC compliance and hurt your deliverability. This guide walks through every method for verifying DKIM, explains the signature fields in detail, and covers common failures and their fixes.

Check DKIM in Gmail Headers

Gmail provides a straightforward way to inspect authentication results for any message you receive. This is the fastest method to confirm whether a sending domain has DKIM configured correctly.

1. Send a test email from the domain you want to verify to a personal Gmail account (@gmail.com).
2. Open the email in the Gmail web interface.
3. Click the three-dot menu (More) in the top-right corner of the message.
4. Select "Show original" from the dropdown. This opens a new tab with the full message headers.
5. Look at the summary section at the top. Gmail displays SPF, DKIM, and DMARC results in a clean table format.
6. Confirm DKIM shows "PASS" with the correct signing domain.

In the raw headers below the summary, look for the Authentication-Results header. A passing result looks like this:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=google header.b=abc12DEf;
       spf=pass (google.com: domain of [email protected] designates
           209.85.220.41 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

The key fields to check are dkim=pass, the header.i= (signing identity which should match your domain), and header.s= (the selector used). If you see dkim=fail or dkim=none, your DKIM configuration needs attention.

Check DKIM in Outlook Headers

Microsoft Outlook also allows you to inspect message headers, though the process differs between Outlook on the web (OWA) and the desktop application.

Outlook on the Web (OWA)

1. Open the email message you want to inspect.
2. Click the three-dot menu (More actions) in the top-right corner of the message.
3. Select "View" > "View message source" or "View message details" depending on your version.
4. Search for Authentication-Results in the header text.
5. Look for dkim=pass or dkim=fail in the result.

Outlook Desktop (Windows)

1. Open the email message in its own window (double-click it).
2. Go to File > Properties.
3. In the Properties dialog, look at the "Internet headers" text box at the bottom.
4. Search for the Authentication-Results header within the text.
5. Verify the DKIM result shows pass.

The Authentication-Results header in Outlook follows the same format as Gmail. Look for dkim=pass along with the signing domain and selector information. Microsoft 365 uses selectors named selector1 and selector2 by default for domains hosted on their platform.

Check DKIM Using MXToolbox

MXToolbox provides a web-based DKIM lookup tool that queries your DNS directly. This method verifies that your public key is published correctly without needing to send a test email.

1. Navigate to mxtoolbox.com/dkim.aspx in your browser.
2. Enter your domain name (e.g., example.com).
3. Enter your DKIM selector (e.g., "google", "selector1", or your custom selector).
4. Click "DKIM Lookup".
5. Review the results. The tool queries selector._domainkey.yourdomain.com and displays the public key record, key length, and any errors.

A successful lookup shows the full public key value, the key type (typically RSA), and the key length. MXToolbox will flag common issues such as missing records, syntax errors, or keys shorter than the recommended 2048 bits.

Finding Your DKIM Selector

If you do not know your selector, use one of these approaches:

• Check a sent email header: Look at the DKIM-Signature header in any email you have already sent. The selector is the s= value.
• Check your email provider documentation: Each provider uses standard selectors.

Common DKIM selectors by provider:

Email Provider	Default Selector(s)
Google Workspace	google
Microsoft 365	selector1, selector2
Amazon SES	Varies by region and configuration date
Mailchimp	k1
SendGrid	s1, s2
Postmark	Varies (check account settings)

Check DKIM Using Command Line (dig / nslookup)

For administrators and developers who prefer the command line, you can query your DKIM DNS record directly using dig (Linux/macOS) or nslookup (Windows).

Using dig (Linux / macOS)

dig TXT selector._domainkey.example.com +short

Replace selector with your actual DKIM selector and example.com with your domain. A successful response returns the TXT record containing your public key:

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

If the command returns no output, the DNS record does not exist for that selector and domain combination.

Using nslookup (Windows)

nslookup -type=TXT selector._domainkey.example.com

The output will include the TXT record contents if the DKIM record exists. On Windows, you can also use PowerShell:

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

Validating the DNS Record

When you retrieve your DKIM DNS record, verify the following:

• The record starts with v=DKIM1 (version tag).
• The k= tag specifies the key type (usually rsa).
• The p= tag contains the full Base64-encoded public key. If p= is empty, the key has been revoked.
• The record does not exceed DNS TXT record size limits (typically split into 255-character strings).

Understanding DKIM Signatures

Every DKIM-signed email includes a DKIM-Signature header that contains all the information a receiving server needs to verify the message. Understanding these fields helps you diagnose problems when DKIM verification fails.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=google;
        h=from:to:subject:date:message-id:mime-version;
        bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
        b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk2pFSSNEA...

Here is what each field means:

Field	Name	Description
v=1	Version	DKIM version. Always set to 1 in the current specification.
a=rsa-sha256	Algorithm	The cryptographic algorithm used to generate the signature. RSA-SHA256 is the standard; Ed25519-SHA256 is an emerging alternative.
c=relaxed/relaxed	Canonicalization	How the header and body are normalized before signing. The first value applies to headers, the second to the body. "relaxed" is tolerant of whitespace changes; "simple" requires exact matches.
d=example.com	Signing Domain	The domain claiming responsibility for the message. This value is critical for DMARC alignment.
s=google	Selector	Used to locate the public key in DNS at selector._domainkey.domain.com.
h=from:to:...	Signed Headers	The list of headers included in the signature calculation. The "from" header must always be signed.
bh=...	Body Hash	A hash of the canonicalized message body. The receiving server recalculates this to detect body modifications.
b=...	Signature	The actual cryptographic signature over the headers and body hash. Verified using the public key from DNS.

The d= (signing domain) field is particularly important because it determines whether DKIM aligns with DMARC. If your From header shows [email protected] but the DKIM signature uses d=esp-provider.com, DKIM will pass but will not align for DMARC purposes.

Understanding DKIM Verification Results

When a receiving mail server checks DKIM, it produces one of several result codes. Knowing what each means helps you diagnose issues quickly.

dkim=pass

The signature is valid. The receiving server found the public key in DNS, the body hash matched, and the cryptographic signature verified successfully. No action is required.

dkim=fail

The signature is invalid. The public key was found but the signature did not verify. Common causes include message modification after signing, a mismatched key pair, or a corrupted DNS record.

dkim=neutral or dkim=none

No DKIM signature was found on the message. This means your mail server is not signing outgoing emails, or the DKIM-Signature header was stripped in transit.

dkim=temperror

Temporary DNS lookup failure. The receiving server could not retrieve your public key due to a DNS timeout or transient network issue. This usually resolves itself, but persistent temperrors indicate DNS infrastructure problems.

dkim=permerror

Permanent error in the DKIM evaluation. This typically means the DNS record has syntax errors, the key format is invalid, or the record is otherwise unparseable. Check your DNS TXT record for formatting issues.

Common DKIM Failures and How to Fix Them

When DKIM verification fails, the cause almost always falls into one of these categories. Work through each systematically when debugging.

Selector Misconfiguration

The most frequent issue is a mismatch between the selector your mail server uses to sign messages and the selector where your DNS record is published. For example, if your server signs with s=selector1 but your DNS record is published at google._domainkey.example.com, the receiving server will look up the wrong location and fail to find the key.

Fix: Check the s= value in your DKIM-Signature header and verify that a matching TXT record exists at s-value._domainkey.yourdomain.com. Make sure the selector matches exactly, including case.

Body Hash Mismatch

A body hash mismatch (bh= does not match the recalculated hash) means the message body was altered after signing. This is one of the most common DKIM failures in practice.

Common causes:

• Mailing lists that append footers or modify content
• Email security gateways that add disclaimers or scan attachments
• Antivirus software that modifies message bodies
• Forwarding services that rewrite links or add tracking pixels

Fix: Identify which system in your mail flow is modifying the message after DKIM signing occurs. Reconfigure your sending pipeline so that DKIM signing happens last, after all content modifications are complete.

DNS Record Errors

DNS record problems prevent receiving servers from retrieving your public key entirely. Common DNS issues include:

• Missing record: The TXT record was never created or was accidentally deleted.
• Truncated key: The public key was cut off during copy-paste into the DNS management interface. TXT records longer than 255 characters must be split into quoted strings.
• Wrong record type: The key was published as a CNAME instead of a TXT record, or vice versa, depending on provider requirements.
• Propagation delay: DNS changes can take up to 48 hours to propagate globally. Test from multiple locations if you recently made changes.

Fix: Use dig or MXToolbox to verify the exact contents of your DNS record. Compare it against what your email provider expects. Ensure the full public key is present and the record is syntactically valid.

Key Pair Mismatch

If the private key used for signing does not correspond to the public key in DNS, every signature will fail. This can happen after a key rotation if the DNS record was updated but the mail server was not, or vice versa.

Fix: Regenerate the key pair through your email provider and update both the DNS record (public key) and the mail server configuration (private key) simultaneously. Use a new selector for the new key to avoid issues during the transition.

DKIM Key Rotation: Why and How Often

DKIM key rotation is the practice of periodically replacing your DKIM key pair with a new one. While DKIM keys do not expire in the traditional sense, rotating them limits the exposure window if a private key is ever compromised.

Why Rotate DKIM Keys

• Security hygiene: If your private key is leaked or stolen, an attacker can sign fraudulent emails that pass DKIM verification for your domain. Regular rotation limits the window of vulnerability.
• Key length upgrades: Older keys may use 1024-bit RSA, which is increasingly considered insufficient. Rotation provides an opportunity to upgrade to 2048-bit keys, which Gmail recommends for all bulk senders.
• Compliance requirements: Some security frameworks and industry standards require periodic key rotation as part of their certification criteria.

Recommended Rotation Schedule

Rotate your DKIM keys every six to twelve months under normal circumstances. Rotate immediately if you suspect any compromise. For high-security environments, quarterly rotation may be appropriate.

How to Rotate Without Downtime

1. Generate a new key pair with a new selector name (e.g., switch from s=selector1 to s=selector2).
2. Publish the new public key in DNS under the new selector.
3. Wait for DNS propagation (24-48 hours).
4. Update your mail server to sign with the new private key and new selector.
5. Keep the old DNS record active for at least 7 days to allow in-flight messages to verify.
6. Remove the old DNS record once the transition period is complete.

DKIM Alignment for DMARC

DKIM on its own verifies message integrity, but for DMARC to pass, DKIM must also align with your From header domain. Alignment means the domain in the DKIM signature (d= value) matches the domain in the visible From header.

Relaxed Alignment (Default)

Relaxed alignment requires the DKIM signing domain to share the same organizational domain as the From header. This means subdomains are allowed to align:

• From: [email protected] with d=example.com — PASSES relaxed alignment
• From: [email protected] with d=mail.example.com — PASSES relaxed alignment
• From: [email protected] with d=otherdomain.com — FAILS alignment

Strict Alignment

Strict alignment requires an exact match between the DKIM signing domain and the From header domain. No subdomain variation is permitted:

• From: [email protected] with d=example.com — PASSES strict alignment
• From: [email protected] with d=example.com — FAILS strict alignment

Relaxed alignment is the default in DMARC and is sufficient for most organizations. Strict alignment provides stronger protection against subdomain spoofing but requires all sending services to sign with the exact From domain. The alignment mode is configured in your DMARC record using the adkim= tag (r for relaxed, s for strict).

DKIM Verification Tools Compared

Several tools can help you verify DKIM configuration. The right choice depends on whether you need a quick DNS check, full message analysis, or ongoing monitoring.

Tool	Free / Paid	Features	Best For
MXToolbox DKIM Lookup	Free (basic) / Paid (monitoring)	DNS record lookup, key validation, syntax checking	Quick DNS record verification
Google Admin Toolbox	Free	DKIM, SPF, DMARC header analysis for Google-related setups	Google Workspace administrators
mail-tester.com	Free (limited) / Paid	Full message analysis, deliverability scoring, authentication checks	Comprehensive message testing
DKIM Validator (dkimvalidator.com)	Free	Send test email for full DKIM signature verification	End-to-end signing verification
dig / nslookup (CLI)	Free (built-in)	Direct DNS TXT record queries, scriptable, no third-party dependency	Administrators, scripting, automation
dmarcian DKIM Inspector	Free (basic) / Paid (full platform)	DNS record analysis, alignment testing, monitoring dashboards	Ongoing DKIM and DMARC monitoring

For a thorough verification, use at least two methods: a DNS lookup tool (like MXToolbox or dig) to verify the public key is published, and a message-based test (like sending to Gmail and checking headers) to confirm your server is actively signing. DNS-only checks do not verify that signing is actually happening.

DKIM Verification Checklist

Use this checklist to confirm your DKIM setup is fully operational across all sending sources:

1. Verify DNS record exists: Use MXToolbox or dig to confirm your public key is published at the correct selector._domainkey.domain.com location.
2. Confirm key length is 2048-bit: Check that your RSA key is at least 2048 bits. 1024-bit keys are increasingly deprecated by major providers.
3. Send a test email and check headers: Send to Gmail or Outlook and verify dkim=pass in the Authentication-Results header.
4. Verify DMARC alignment: Confirm the d= domain in your DKIM signature matches (or aligns with) your From header domain.
5. Test all sending sources: Repeat the test from every system that sends email on behalf of your domain: primary ESP, transactional service, CRM, marketing platform, and helpdesk.
6. Check SPF alongside DKIM: DMARC requires at least one of SPF or DKIM to pass with alignment. Verify both are configured correctly for redundancy.
7. Monitor DMARC reports: Review your DMARC aggregate reports regularly to catch DKIM failures from any sending source you may have missed.