What to do when DKIM record is configured but emails are not DKIM signed?
Published 10 Jul 2025
Updated 15 Oct 2026
12 min read
Summarize with
Updated on 15 Oct 2026: We added server-side signing checks and corrected DKIM verification and key rotation guidance.
If a DKIM record is configured in DNS but the email has no DKIM-Signature header, the fix is usually with the sending provider, not the DNS host. The DNS record only publishes the public key. The mail server still has to sign each message with the matching private key before the message leaves the platform.
Treat this as a two-part problem: first check whether the delivered message has a signature, then confirm DKIM signing is enabled for the exact domain, selector, and send path in use. Inspect the raw source of a fresh message received outside your organization. A Sent folder copy can predate server-side signing. One dkim=none (message not signed) result can describe an earlier receiving hop. If no signature reaches the recipient, check sender activation and any intermediate relay before replacing a valid DNS record.
A fast first check is to inspect the raw message headers, then validate the selector DNS with the Suped DKIM checker. If DNS validates but the message remains unsigned, take it to the ESP, mailbox provider, CRM, billing system, or app that actually sends the email.
Enable DKIM signing on the sending system
Ask the sending provider to enable DKIM signing for the sender domain and confirm the selector they expect you to publish. If the provider generated a CNAME-based setup, publish the CNAMEs they give you. If the provider expects a TXT public key, publish that exact TXT record. If you generated your own key pair and the provider supports importing it, use its secure admin flow. Otherwise, use provider-generated keys. Never send a private key in an email support ticket.
- Open the raw email source and look for DKIM-Signature. If it is absent in a fresh external delivery, check signing activation and any relay that can remove headers.
- Confirm the exact platform that sent the email, because the DNS record has to match that platform's signing setup.
- Ask which selector the provider uses, since an old selector can remain in DNS after a vendor change.
- After DNS verification, click the provider's activate, authenticate, or start signing control if the portal requires it.
DNS alone cannot sign mail
A DKIM TXT record in DNS is passive. It lets receivers verify a signature that already exists. It does not add a signature to outbound messages. The outbound mail system must apply the signature before delivery.
How DKIM signing works
DKIM uses a public and private key pair. DNS stores the public key under a selector, and the sending server uses the private key to create a cryptographic signature over selected header fields and the body hash. Receivers read the selector and domain from the signature, fetch the DNS key, then verify the signed header fields and body content. Unsigned header fields are outside that protection.
What DNS does
- DNS publishes the key receivers use to verify signatures.
- The s= value tells receivers which DKIM record to query.
- DNS never attaches a DKIM header to the email.
What the sender does
- The sending system signs the message with the matching private key.
- The sender adds the DKIM-Signature header.
- The sender chooses the signing domain shown in the d= tag.
Illustrative DKIM TXT record with a shortened keydns
selector1._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...shortened..." )
DKIM signature in a message headertext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=base64-body-hash; b=base64-signature
Checks to run before changing DNS
Avoid editing DNS until you know whether the problem is unsigned mail, a broken public key, a sender that signs with a different domain, or a result recorded at another hop. Those are different fixes. A missing signature is usually a sending configuration problem. A signature that exists but fails verification points to the selector, DNS response, message modification, or forwarding path.
- Download or view the original message as received by an external mailbox. Do not rely only on a mail client badge, summary, or Sent folder copy.
- Search for DKIM-Signature. If there is no match, no signature reached this mailbox; investigate signing activation and the route it followed.
- Find the authentication result added by the recipient system you trust, since relays and forwarders can add separate results.
- If a signature exists, compare the d= domain with the visible From domain.
- Check the public key at <selector>._domainkey.<signing-domain>, using the s= and d= values in the signature. If the header is absent, get the expected pair from the sender.
- Test the same workflow that customers receive. Test mode, aliases, SMTP relays, and gateways can use separate signing rules.
DNS lookup for the example selectorbash
dig +short TXT selector1._domainkey.example.com dig +short CNAME selector1._domainkey.example.com
Replace the example selector and domain with the expected values. Follow any CNAME to its final public-key TXT record. Check for a domain suffix accidentally appended twice by the DNS host. Multiple quoted strings are valid when they form one TXT record. If authoritative DNS and a recursive resolver disagree, account for cached answers and the relevant TTL before retrying provider verification. RFC 6376 defines the selector lookup and TXT string concatenation.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a broader authentication read, use a domain health checker after checking the DKIM selector. That helps catch SPF, DMARC, and DNS issues that might sit next to the missing DKIM signature.
Read the right authentication result
The DKIM-Signature header identifies the claimed signing domain and selector. A trusted Authentication-Results header records how a receiving system evaluated the message. dkim=none means the message was not signed at that checking hop, as defined in RFC 8601. A signature elsewhere in the delivered source does not override that earlier result. Identify which system produced each result before deciding what it proves.
- Search the complete raw source for each DKIM-Signature header. A message can carry more than one.
- Record the d= signing domain and s= selector for the signature you expect.
- Use the result generated by the trusted recipient system. Read its authserv-id, the authentication service identifier after the colon. An untrusted sender can insert Authentication-Results headers, so a familiar-looking identifier alone does not establish trust.
- Check DMARC domain alignment separately. A passing DKIM signature counts for DMARC when its d= domain meets the visible From domain's alignment rules. Relaxed mode permits the same organizational domain; strict mode requires an exact domain match. DMARC passes when either SPF or DKIM passes with the required domain alignment. See RFC 9989 for these rules.
- Send through each real application, relay, and sender identity. A pass on one route does not prove that every route signs.
How to resolve conflicting header evidence
If the raw message has no DKIM-Signature header, check signing activation and any relay that removes headers. If the signature exists and the trusted recipient reports dkim=fail, troubleshoot key lookup or message modification. If the signature exists but another preserved result says dkim=none, identify which hop created each result before changing configuration.
Common causes of missing or unexpected DKIM signatures
These causes explain missing signatures or signatures using an unexpected domain. A provider-owned DKIM signature still means the message is signed, but it does not necessarily satisfy DMARC domain alignment.
|
|
|
|---|---|---|
Signing not enabled | DNS passes, headers have no signature | Activate signing in the provider portal |
Old vendor record | Selector belongs to a previous platform | Get fresh records from the current sender |
Wrong send path | Campaigns sign, app alerts do not | Enable DKIM on every sending system |
Signing rule mismatch | Primary addresses sign, but aliases or relays do not | Update the sender's signing rule for the actual route |
Domain not verified | Portal shows pending authentication | Check the exact DNS name and target, allow cached answers to expire, then retry verification |
Private key missing | Provider cannot sign for your selector | Use the provider key setup flow |
Different domain | Signature uses provider-owned domain | Enable custom-domain DKIM signing for your From domain |
Reasons for missing signatures or an unexpected DKIM signing domain.
A useful support request
Ask the provider to check outbound signing, not only DNS verification. Include the full headers from a fresh external delivery, its Message-ID, the UTC send time, the sender address, the affected workflow, and the expected selector DNS response. Keep private keys out of the ticket.
Message to send the providertext
Please check DKIM signing for messages with From: sender@example.com. The DKIM DNS record you provided is published, but a fresh external delivery through the affected workflow has no DKIM-Signature header. Sender: sender@example.com Workflow / SMTP route: [affected sending workflow] UTC send time: [timestamp] Message-ID: [message identifier] Expected DKIM DNS name: [selector]._domainkey.example.com Full received headers and the DNS response are attached. Please confirm: 1. The selector and signing domain this route uses. 2. Whether signing is activated for this sender and send path. 3. Whether a supported key-import or portal action is still required. 4. Whether the outbound trace shows signing was skipped or failed.
Check DKIM activation at your sending provider
Providers expose DKIM activation in different places. Generate the provider records, publish them, then check both domain verification and signing status. Some platforms require a separate activation step; others activate signing automatically after verification.
Microsoft 365 DKIM settings with custom-domain CNAME records and signing activation.
Microsoft 365: Publish both exact CNAME targets issued for the custom domain, then enable signing. Test delivery to a separate organization: Microsoft 365 omits DKIM for messages within the same organization. Follow Microsoft's DKIM documentation.
Google Workspace: Generate the DKIM record, publish it, then start authentication in the admin console.
AWS SES: Verify the identity and signing status in the AWS Region that actually sends the message. Check whether an email-address identity overrides inherited domain signing. Amazon SES documentation explains regional setup and identity overrides.
- ESP platforms: Check whether the sender domain still shows pending, unauthenticated, or unverified after DNS propagation.
Read-only Microsoft 365 DKIM status in Exchange Online PowerShellpowershell
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
For the custom domain, check for Enabled: True and Status: Valid and compare both CNAME values with DNS. If those checks pass but fresh external deliveries through Microsoft 365 still lack signatures, escalate with the message evidence. A Microsoft support case documents a backend signing fault resolved by Microsoft; repeated DNS edits or speculative key rotation are not a substitute for tracing it.
If your case is Microsoft-specific, the details in Microsoft 365 DKIM fixes are worth checking before rotating keys or changing policy.
Check the signer on a self-hosted mail server
When you control the mail transfer agent (MTA), check the active outbound configuration and mail logs. A published public key or control-panel checkbox does not confirm that the route used by the unsigned message invokes the DKIM signer.
- Confirm the DKIM signer is running. If it is a separate mail filter (milter), check that its socket is reachable by the mail process.
- Check signing rules for the actual From domain and submission method. Locally generated application mail and authenticated SMTP submissions can follow different processing paths.
- Confirm the signing process can read the private key with restricted permissions, and that its configured domain and selector match the published public key.
- Trace a fresh test by its queue ID. Look for key-file errors, skipped signing rules, or an outbound SMTP transport without DKIM settings. Reload the affected service after correcting its configuration.
The mail filter integration documentation distinguishes SMTP and local submission paths. The SMTP transport documentation explains transport-level signing. Use the applicable configuration model, then send a new external test.
When the header exists but DKIM still fails
A message with a DKIM signature can still fail verification. Check for selector DNS errors, malformed or truncated public keys, a public/private key mismatch, body changes after signing, and mailing list rewriting. A valid signature using a different signing domain can pass DKIM while failing DMARC's DKIM alignment check. If the message has multiple signatures, evaluate the expected d= and s= pair instead of treating every result as the same signature.
Read the recipient's reason alongside the result. dkim=temperror indicates a temporary verification problem, such as a DNS lookup failure. dkim=permerror indicates an unrecoverable verification error. A body hash mismatch points to changed body content. Forwarding itself does not necessarily break DKIM; modification of signed content does. Apply signing after outbound footer or disclaimer insertion.
DKIM troubleshooting flowchart separating missing signatures from failed verification.
Separate missing from failing
- No DKIM-Signature header exists in the received copy. Check sender activation, then investigate header removal if outbound evidence shows that a signature was added.
- A signature exists, but the receiver cannot verify it against DNS.
- Use DKIM troubleshooting once the header exists and verification fails.
Monitor DKIM results with Suped
Suped's DMARC reporting product groups authentication results by sending source so teams can track DKIM failures and DMARC domain alignment across production workflows. This is useful when product notifications, invoices, support mail, and other messages leave through separate systems.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
After the immediate DKIM fix, use Suped's DMARC monitoring to identify sources needing investigation and compare results after the change. Aggregate reports arrive after the reported traffic and cover participating receivers; they are not a live trace of every message. Use raw received headers and sender logs to distinguish unsigned mail from failed signatures. RFC 9990 defines aggregate reporting.
DKIM signing coverage targets
These example internal thresholds treat complete coverage across authorized send sources as the goal.
Healthy
100%
Every identified legitimate send source uses the expected DKIM signing setup.
Needs review
95-99%
At least one low-volume workflow or sender identity remains unsigned.
Incomplete
Below 95%
Unsigned legitimate traffic needs source identification and signing activation.
Verify the fix on every send path
Retest with newly sent messages after the configuration change. Messages already delivered will not gain a DKIM signature retroactively.
Send through each production workflow to a mailbox outside your organization. Confirm the expected DKIM-Signature domain and selector, then look for dkim=pass in the trusted recipient's results. If DMARC depends on DKIM, confirm domain alignment as well. Compare subsequent DMARC reports for the affected sources to check that the fix holds beyond the individual tests.
Frequently asked questions
No. DNS publishes the public key only. The sending server has to create the DKIM signature with the matching private key before the message leaves the sender.
Contact the email provider or application that sends the message. Your DNS host can help publish a record, but it cannot enable signing on another platform.
An old selector does not stop the current provider from signing, but checking it can give a misleading picture of the current setup. Confirm the current provider's expected selector. Retire obsolete records after legitimate use and queued delivery have ended; a published key continues to authorize signatures made with its matching private key.
No. Missing means no DKIM-Signature header is present in the received copy. Check signing activation and any relay that removes headers. Failing means a signature exists, but the receiver could not verify it.
dkim=none means the message was unsigned at the system that recorded that result. It is not a failure result for another signature. Compare the authentication service identifier and hop with the trusted recipient's results. A later signer or a preserved earlier result can explain the apparent conflict.
Follow the provider's rotation policy, and rotate promptly after suspected private-key compromise or when replacing a weak key. First diagnose signing activation when the signature is absent. For a planned rotation, publish the new key before using it and retain the old public key until queued messages and relevant caches have cleared. Revoke a compromised key promptly.
