Suped

What to do when DKIM record is configured but emails are not DKIM signed?

Matthew Whittaker profile picture
Matthew Whittaker
Co-founder & CTO, Suped
Published 10 Jul 2025
Updated 18 Aug 2025
6 min read
It can be incredibly frustrating to discover your emails aren't DKIM signed, especially when you've diligently configured the DKIM record in your DNS. You've done your part, but the messages still lack that crucial layer of authentication. This situation is more common than you might think and often points to a disconnect between your DNS setup and your email sending infrastructure.
When emails aren't DKIM signed, it raises red flags for recipient mail servers, increasing the likelihood of your messages landing in spam folders or being rejected outright. This impacts your deliverability and sender reputation. I'm going to walk you through the typical causes of this issue and provide actionable steps to get your emails properly signed.
Suped DMARC monitoring
Free forever, no credit card required
Learn more
Trusted by teams securing millions of inboxes
Company logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logo

Understanding DKIM basics

Before diving into troubleshooting, it's essential to grasp how DKIM works. DKIM, or DomainKeys Identified Mail, uses a pair of cryptographic keys: a public key and a private key. The public key is published as a TXT record in your domain's DNS, making it publicly accessible.
When your email server sends a message, it uses the corresponding private key to generate a unique digital signature for the email. This signature is then added to the email's header. Recipient mail servers can then retrieve your public key from your DNS and use it to verify the signature, ensuring the email hasn't been tampered with and truly originated from your domain. This process is crucial for preventing email spoofing and improving trust in your emails.

How DKIM works in brief

  1. Key generation: A pair of cryptographic keys (public and private) is generated for your domain.
  2. Public key in DNS: The public key is published as a TXT record in your DNS, often under a specific selector (e.g., selector1._domainkey.yourdomain.com).
  3. Email signing: Your email sending server (like your Email Service Provider or mail server) uses the private key to create a digital signature for each outgoing email. This signature is embedded in the email header.
  4. Verification: Recipient mail servers use the public key from your DNS to verify the signature. If it matches, the email is authenticated.
For more detailed insights into selectors, refer to our practical guide to DKIM selector name examples. Also, check out this article about DKIM signatures.
A successful DKIM setup requires both the public record in DNS and the private key configured on the sending server. If either piece is missing or misconfigured, your emails won't be signed, even if online tools say your DNS record is valid. The tools often only check if the public record exists, not if signing is actively happening.

Common reasons for unsigned emails

Many factors can prevent your emails from being DKIM signed, even with a seemingly correct DNS record. One of the most frequent culprits is an unconfigured or incorrectly configured private key on your Email Service Provider (ESP) or mail server. Your public DNS record is only one half of the equation.
Another common issue is that the DKIM signing feature might simply be disabled or not activated within your ESP's dashboard. While you might have provided them with the necessary keys, a final step, often a toggle or button, might be required to enable the signing. It’s a small detail, but one that’s easy to miss.
Furthermore, issues like DNS propagation delays, incorrect selector names, or even conflicts with other email authentication protocols (like SPF or DMARC) can lead to DKIM signing failures. Understanding these potential pitfalls is the first step towards resolving the problem and ensuring your emails are properly authenticated.

Common issues

  1. No DKIM signature in email header: Even after publishing the DNS record, outgoing emails lack the DKIM-Signature header.
  2. Online checker says DKIM is valid: Tools confirm your public record is correctly published, but emails are still unsigned.
  3. Emails landing in spam or rejected: Despite DNS setup, deliverability issues persist due to lack of authentication.

Potential causes

  1. ESP configuration: Your Email Service Provider has not enabled DKIM signing on their end or lacks your private key.
  2. Mail server misconfiguration: If you manage your own mail server, it might not be configured to sign outgoing messages.
  3. Incorrect selector: The selector used by your sending server does not match the one in your DNS record.

Steps to troubleshoot and fix

The first and most important step is to contact your Email Service Provider. Explain that you have your DKIM DNS record configured, but your emails are not being signed. They should be able to confirm if they have your private key correctly set up and if the DKIM signing feature is enabled for your domain. Many ESPs require an explicit activation step, even after DNS records are published.
Next, inspect the email headers of a message sent from your domain. You can typically find an email's full headers by looking for an option like "show original" or "view source" in your email client. Look for a line starting with DKIM-Signature:. If this line is missing, it confirms the email was not signed. If it's present, but indicates a failure, the problem lies in the verification stage, which could be due to a mismatch between the public and private keys, or a modified email body.
Example DNS lookup for DKIM recordbash
dig TXT selector1._domainkey.yourdomain.com +short
Finally, ensure your DKIM selector matches. The selector is part of your DKIM DNS record (e.g., the 'selector1' in selector1._domainkey). Your ESP will use a specific selector when signing your emails. If the selector they use doesn't match the one in your DNS record, the recipient server won't be able to find the correct public key for verification. This is a common point of error, especially if you've migrated ESPs or have multiple DKIM keys for different purposes. This can sometimes lead to issues like MXToolBox reporting a non-verified DKIM signature.

Problem

Possible cause

Solution

Emails not signed at all
ESP or mail server not configured to sign, or signing feature not activated.
Contact your ESP to confirm private key setup and activate signing. For Microsoft 365, enable DKIM signing via admin settings.
DKIM verification fails in email headers
Public and private key mismatch, incorrect selector, or email content modified in transit.
Verify your DKIM selector. Check email content for integrity issues. This can lead to a DKIM body hash mismatch.
DNS propagation delays
New DNS records (TXT records for DKIM) take time to update globally.
Wait up to 48 hours for DNS changes to propagate fully. Use Google Workspace troubleshooting tools.
Internal email not signed
Some mail servers or ESPs do not sign internal mail by default.
Test by sending to an external email address (e.g., a Gmail or Outlook account) to verify DKIM signing.

Ensuring proper configuration

DKIM is a cornerstone of email authentication, but it works best when combined with SPF and DMARC. SPF (Sender Policy Framework) specifies which mail servers are authorized to send email on behalf of your domain, while DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on both SPF and DKIM to provide instructions to recipient servers on how to handle emails that fail authentication.
Even if your emails are DKIM signed, issues can arise if DMARC alignment fails. Regular monitoring of your DMARC reports is vital, as they provide valuable insights into your email authentication status, helping you identify and rectify issues like unsigned emails quickly. Consider using a DMARC monitoring service to stay on top of your email security posture.

Views from the trenches

I've gathered some insights from fellow professionals who have encountered similar DKIM signing issues.
Best practices
Always confirm with your ESP that the private key is properly configured and DKIM signing is enabled.
Regularly check your email headers for the DKIM-Signature to ensure emails are being signed correctly.
Monitor DMARC reports to catch any authentication failures, including unsigned DKIM messages, early.
Ensure your DKIM selector used by your sending server exactly matches your DNS record.
Test sending emails to external domains, not just internal ones, as signing behavior can differ.
Common pitfalls
Forgetting to activate DKIM signing in your ESP's portal after publishing the DNS record.
Assuming DNS propagation is immediate; it can take up to 48 hours for changes to take effect.
Mismatched DKIM selectors between your DNS record and your sending server's configuration.
Not contacting your ESP as the first step when DKIM signing issues arise, leading to prolonged troubleshooting.
Overlooking older DKIM records from previous email vendors that might be causing conflicts.
Expert tips
If using Microsoft 365, ensure you've published the necessary CNAME records and enabled DKIM signing for your custom domain.
When migrating ESPs, be sure to update your DKIM records and verify the new provider's signing process.
A DKIM record check tool only verifies the public key's existence, not the email signing process itself.
If troubleshooting, consider sending a test email to a Gmail account, as Google often provides detailed authentication results.
Remember that DKIM is one part of email authentication; combine it with SPF and DMARC for robust protection.
Marketer view
A marketer from Email Geeks mentioned they had their DKIM record configured in DNS, but their emails were not being signed, and wondered if this was an issue to raise with their email service provider.
July 12, 2022 - Email Geeks
Expert view
An expert from Email Geeks explained that DKIM has two essential components: a public key published in DNS and a corresponding private key used by the sending mail server to sign outgoing emails.
July 12, 2022 - Email Geeks

Getting your emails signed

When your DKIM record is correctly configured but emails aren't signed, the solution almost always lies with your Email Service Provider or mail server settings. It's crucial to confirm that the private key is properly implemented and that the signing functionality is activated on the sending end. Don't assume that a valid DNS record automatically means your emails are being signed.
By systematically checking your ESP's configuration, verifying email headers, and ensuring selector consistency, you can resolve most DKIM signing issues. Proactive monitoring and a comprehensive approach to email authentication with SPF and DMARC will further strengthen your email security and deliverability. If you need more help, review our troubleshooting guide for DKIM failures.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard

What you'll get with Suped

Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing