DKIM Testing: The Complete Guide to Checking Your Email Authentication

If you send email from your own domain, DKIM testing is how you confirm that your authentication is actually working. A DKIM record can exist in DNS but still be misconfigured, expired, or mismatched with your signing key. The only way to know for sure is to test it.

This guide covers every aspect of DKIM testing — from a quick one-off check to systematic verification across multiple providers, reading email headers to confirm signing, and ongoing monitoring that catches problems before your emails start bouncing.

DKIM is defined in RFC 6376, maintained by the IETF. Understanding what a DKIM test actually checks — and what it can't tell you — is the difference between confident email delivery and debugging in the dark.

Test Your DKIM Record

Enter your domain and selector to check your DKIM configuration instantly.

Don't know your selector? Common selectors include google (Google Workspace), selector1 (Microsoft 365), k1 (Mailchimp), and s1 (SendGrid). See our guide to finding your DKIM selector for a complete list by provider.

What a DKIM Test Actually Checks

A DKIM test examines the public side of your DKIM configuration — the DNS record that receiving servers use to verify your email signatures. This is fundamentally different from testing whether your emails are being signed correctly, which requires sending a real message and inspecting the headers.

Here's what the DNS-side test covers and why each check matters:

Record existence is the most basic check, but it catches the most common problem: wrong selector names. If you're looking up google._domainkey.example.com but your service actually uses selector1, you'll get "not found" even though a perfectly valid DKIM record exists under a different name.

Key strength matters more than many administrators realize. A 512-bit RSA key can be factored in hours on modern hardware — anyone could forge your DKIM signatures. 1024-bit keys are deprecated by NIST and increasingly flagged by Google and other providers. If your test shows a weak key, upgrading to 2048-bit should be your immediate priority.

What a DNS test can't tell you: Whether your mail server is actively signing outgoing messages. A perfectly valid DNS record is useless if signing isn't enabled. That's why DNS testing is only half the process — you also need to send a test email and check the headers.

For manual DNS-level testing with command-line tools, see How to Check DKIM Records Using dig and nslookup.

When to Test DKIM

DKIM isn't set-and-forget. There are specific moments when testing is critical:

After initial setup. The most obvious one. After publishing your DNS record and enabling signing, verify both sides work before relying on DKIM for production email.

After any DNS change. Migrating DNS providers (e.g., from GoDaddy to Cloudflare), changing nameservers, or even updating unrelated DNS records can sometimes disrupt existing records. A quick DKIM test after DNS changes confirms nothing was lost.

After email provider changes. Switching from one email service to another — or adding a new service — means new DKIM keys and selectors. Test each service independently after setup.

After key rotation. If your provider rotates DKIM keys (Google Workspace does this automatically), verify the new key is in DNS and the old one is still active during the transition period.

Periodically. DNS records can be accidentally deleted, hosting migrations can drop records, and provider changes can invalidate keys. A monthly check catches problems before they affect deliverability. Better yet, set up continuous monitoring so you don't have to remember.

When deliverability drops. If your emails suddenly start landing in spam, DKIM is one of the first things to check. A broken DKIM record is one of the most common causes of sudden deliverability drops.

How to Test DKIM Step by Step

A complete DKIM test has two phases: checking the DNS record, then verifying that actual emails are being signed and verified.

Phase 1: Test the DNS Record

Phase 2: Test Actual Email Signing

Reading Email Headers for DKIM

Knowing how to read email headers is essential for Phase 2 testing. Here's how to find DKIM information in the major email clients:

Gmail: Open the email, click the three-dot menu, select "Show original." You'll see the full headers including Authentication-Results at the top (showing dkim=pass or dkim=fail) and the DKIM-Signature header further down.

Microsoft Outlook (web): Open the message, click the three dots, select "View message details" or "View message source." The Authentication-Results header shows the DKIM verification result.

Apple Mail: Open the email, go to View → Message → All Headers. Look for the DKIM-Signature and Authentication-Results headers.

Thunderbird: Open the email, go to View → Headers → All. Same headers to look for.

In the Authentication-Results header, you're looking for a line like:

dkim=pass header.d=yourdomain.com header.s=google

This tells you three things: DKIM passed verification (dkim=pass), which domain signed it (header.d), and which selector was used (header.s). If you see dkim=fail, the reason= field explains why — common reasons include "signature verification failed," "body hash did not verify," and "key not found."

The DKIM-Signature header itself contains the full signature with all its parameters. The most important fields to check are d= (signing domain), s= (selector), a= (algorithm), and h= (which headers were signed). For a deep dive into every field, see Understanding DKIM Signatures.

Understanding DKIM Test Results

When you test a DKIM record, the result tells you what to do next:

"Record not found" is the most common result — and it's almost always a wrong selector. Before assuming your record is missing, try the common selectors for your provider. Google Workspace uses google, Microsoft 365 uses selector1, Mailchimp uses k1. Our selectors guide has the full list.

"Invalid key" usually means a copy-paste error. DKIM public keys are long base64 strings. When copying them into DNS, it's easy to accidentally truncate the value or introduce a line break. Some DNS providers also have character limits on TXT records that silently truncate your key. If you see this, regenerate the key at dkimcreator.com and carefully paste the full value.

For a deep dive into each failure type, see DKIM Check Failing? A Systematic Troubleshooting Guide.

Testing DKIM Across Multiple Providers

Most businesses don't send email from just one service. A typical setup might include:

• Google Workspace or Microsoft 365 for employee email
• Mailchimp, HubSpot, or ActiveCampaign for marketing campaigns
• SendGrid, Mailgun, or Amazon SES for transactional email (password resets, order confirmations)
• Zendesk or Freshdesk for customer support
• Shopify, Cvent, or another platform for specialized notifications

Each of these services signs email with its own private key and selector. That means your domain might have 3-5 separate DKIM records in DNS, each under a different selector. Testing DKIM for your domain means testing every selector, not just one.

The process:

1. Inventory your sending services. List every service that sends email from your domain. Don't forget transactional services and support platforms — they're easy to overlook.
2. Find each service's selector. Check the service's admin panel or documentation. Our provider-specific guides list the selectors for each service.
3. Test each selector independently. Use the DKIM test tool above for each selector._domainkey.yourdomain.com combination.
4. Send test emails from each service. Verify that each service is actively signing messages and that the signatures verify.

Testing DKIM for Multiple Domains

If your organization manages multiple domains — perhaps a primary domain, a marketing domain, and regional domains — each domain needs its own DKIM testing. DKIM records are domain-specific, so selector._domainkey.example.com and selector._domainkey.example.co.uk are completely separate records.

For each domain:

• Verify DKIM records exist for every service that sends email from that domain
• Confirm signing is enabled in each service for that specific domain
• Check that DKIM alignment passes (the signing domain matches the From address domain)

This is where continuous monitoring becomes essential. Manually testing 5 selectors across 3 domains every month is 15 separate checks — easy to let slip. Automated monitoring handles this silently and alerts you only when something breaks.

Testing DKIM for Your Email Provider

Each email service configures DKIM differently. We have step-by-step setup and verification guides for the most popular providers:

Email services: Google Workspace, Microsoft 365, Gmail, Mailchimp, SendGrid, Amazon SES, Mailgun, HubSpot, Klaviyo, Salesforce, Zoho Mail

DNS providers: Cloudflare, GoDaddy, Namecheap, IONOS, cPanel, Squarespace, Wix

For the general setup process, see How to Set Up DKIM: The Complete Guide.

Troubleshooting Failed DKIM Tests

When a DKIM test fails, the fix depends on the specific error. Start with the most common causes:

• DKIM Check Failing? — systematic walkthrough of why DKIM authentication fails and how to fix it
• Common DKIM Errors — reference guide covering every standard DKIM error code with solutions
• "DKIM Selector Not Found" — the most common lookup failure, usually a wrong selector or missing DNS record
• "Body Hash Did Not Verify" — the email body was modified after signing, often by mailing lists or security gateways

If you know your record is correct but DKIM still fails on received emails, the issue is likely with the signature rather than the record. Common causes include email modification in transit (mailing lists, security gateways), canonicalization mismatches, and forwarding breaking the signature. Check the DKIM Signatures guide to understand what's in the DKIM-Signature header and what can go wrong.

Comparing DKIM Testing Tools

There are several ways to test DKIM, each suited to different situations:

Use DKIM Test when you need a quick, focused answer: is my DKIM record published correctly? The tool parses every tag, validates the key, checks strength, and explains any errors in plain language.

Use dig or nslookup when you're debugging DNS propagation — checking specific nameservers to see if a new record has propagated, or scripting checks in a CI/CD pipeline. See DKIM Test vs Manual DNS Lookups for detailed examples.

Use Mail-Tester when you want end-to-end email analysis — not just DKIM, but also SPF, DMARC, content quality, and spam score. It requires sending an actual email to their test address. See DKIM Test vs Mail-Tester.

Use MXToolbox when you need a broad DNS diagnostic that covers MX records, blacklists, and other email infrastructure alongside DKIM. See DKIM Test vs MXToolbox.

For most DKIM testing scenarios, the fastest workflow is: DNS test here first, then send a test email to Gmail to verify signing.

Beyond Testing: Continuous Monitoring

A one-time DKIM test confirms your setup works today. But DKIM records can break silently — a DNS change during a provider migration, an expired key after rotation, or an accidental record deletion. By the time you notice, your emails have been landing in spam for days or weeks.

The gap between "working when I last checked" and "broken right now" is where deliverability problems hide. Common scenarios that break DKIM without warning:

• DNS provider migration — records don't transfer automatically between providers
• Domain renewal — some registrars reset DNS records on renewal
• Team changes — a new IT admin cleans up "unused" DNS records
• Provider key rotation — automated rotation fails silently
• CNAME target changes — the provider updates their DKIM infrastructure, breaking CNAME pointers

Continuous monitoring checks your DKIM records on a schedule and alerts you when something changes. The Email Deliverability Suite monitors DKIM alongside SPF, DMARC, and MX records across all your domains — so you catch problems before your recipients do.

Complete Your Email Authentication

DKIM is one of three protocols that work together to authenticate your email:

• SPF verifies which servers are authorized to send email for your domain. Check yours at spfrecordcheck.com.
• DMARC ties SPF and DKIM together with a policy and provides reporting. Check yours at dmarcrecordchecker.com.
• DKIM verifies the message content hasn't been tampered with. You're already here.

All three are required by Google and Yahoo for bulk senders. For a full explanation of how they interact, see SPF, DKIM, and DMARC Explained.

Need to generate a new DKIM key pair? dkimcreator.com creates keys and DNS records in seconds.

Who Needs DKIM Testing?

Different roles use DKIM testing differently:

• IT Administrators — setup, troubleshooting, and multi-domain management across the organization
• Marketing Teams — ensuring campaign emails from Mailchimp, HubSpot, and other platforms are authenticated
• E-commerce — protecting order confirmations, shipping notifications, and transactional email
• Agencies — managing email authentication across multiple client domains

References

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — IETF standard defining DKIM
• Google Email Sender Guidelines — Requirements for sending email to Gmail users
• Yahoo Sender Best Practices — Requirements for sending email to Yahoo users
• NIST SP 800-131A Rev. 2 — Guidance on cryptographic key strength