What to do when DKIM record is configured but emails are not DKIM signed?
Published 10 Jul 2025
Updated 28 May 2026
9 min read
Summarize with
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.
I treat this as a two-part problem: first prove whether the message is unsigned, then prove whether the current sender has DKIM signing enabled for the exact domain and selector in use. If the header is missing completely, changing a TXT record rarely fixes it. The provider needs to enable signing, verify the domain, or issue the correct DKIM selector.
A fast first check is to inspect the raw message headers, then validate the selector DNS with the 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.
The direct fix
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, the provider needs the private key through a secure admin flow, not in an email support ticket.
- Header: Open the raw email source and look for DKIM-Signature. If it is absent, the sender did not sign the message.
- Provider: Confirm the exact platform that sent the email, because the DNS record has to match that platform's signing setup.
- Selector: Ask which selector the provider uses, since an old selector can remain in DNS after a vendor change.
- Activation: 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 that the message has not changed in transit.
What DNS does
- Public key: DNS publishes the key receivers use to verify signatures.
- Selector lookup: The s= value tells receivers which DKIM record to query.
- No signing: DNS never attaches a DKIM header to the email.
What the sender does
- Private key: The sending system signs the message with the matching private key.
- Header creation: The sender adds the DKIM-Signature header.
- Domain choice: The sender chooses the signing domain shown in the d= tag.
DKIM public key in DNSdns
selector1._domainkey.example.com. 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
I avoid editing DNS until I know whether the problem is unsigned mail, a broken public key, or a sender that signs with a different domain. Those are different fixes. A missing signature is a sending configuration problem. A signature that exists but fails verification is usually a selector, DNS, body modification, or forwarding problem.
- Raw headers: Download or view the original message. Do not rely only on a mail client badge or summary.
- Signature presence: Search for DKIM-Signature. If there is no match, the message was not signed.
- Signing domain: If a signature exists, compare the d= domain with the visible From domain.
- Selector DNS: Check that the s= selector resolves under the signing domain.
- Send path: Test the same workflow that customers receive. Test-mode mail can use a separate sender.
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.
Common causes
The table below covers the causes I see most often when DNS looks right but outbound email is not DKIM signed. The key point is that "record exists" and "mail is signed" are separate states.
|
|
|
|---|---|---|
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 |
Domain not verified | Portal shows pending authentication | Wait for DNS, then verify again |
Private key missing | Provider cannot sign for your selector | Use the provider key setup flow |
Different domain | Signature uses provider-owned domain | Configure signing for your From domain |
Common reasons DKIM records exist while messages stay unsigned.
A useful support request
When you contact the provider, keep the request specific. You want them to check outbound signing, not only DNS verification.
Message to send the providertext
Please enable DKIM signing for mail sent with From: example.com. I have published the DKIM DNS record you provided, but messages sent through your platform do not include a DKIM-Signature header. Please confirm: 1. The selector you expect us to use. 2. The signing domain you will use. 3. Whether signing is activated for this sender. 4. Whether any private key or portal action is still required.
Provider-specific places to check
Different senders expose DKIM activation in different places. The pattern is the same: generate records, publish records, verify DNS, then enable signing. Missing the last step is common.
Microsoft Defender portal DKIM settings showing where signing is enabled.
Microsoft 365: Confirm the DKIM CNAMEs exist, then enable signing for the custom domain in the DKIM settings.
Google Workspace: Generate the DKIM record, publish it, then start authentication in the admin console.
AWS SES: Verify the identity and make sure Easy DKIM or your custom DKIM setup is active for that identity.
- ESP platforms: Check whether the sender domain still shows pending, unauthenticated, or unverified after DNS propagation.
If your case is Microsoft-specific, the details in Microsoft 365 DKIM fixes are worth checking before rotating keys or changing policy.
When the header exists but DKIM still fails
A message with a DKIM signature can still fail authentication. That is a different problem. In that case, the sender is signing, but receivers cannot verify the signature. I usually look for selector DNS errors, malformed public keys, body changes after signing, mailing list rewriting, or a mismatch between the signing domain and the domain used for DMARC evaluation.
Flowchart for deciding whether DKIM is missing or failing verification.
Separate missing from failing
- Missing: No DKIM-Signature header exists, so the sender did not sign the message.
- Failing: A signature exists, but the receiver cannot verify it against DNS.
- Next step: Use DKIM troubleshooting once the header exists and verification fails.
How Suped helps with this workflow
Suped's product helps turn this from a one-off header chase into a monitored workflow. In Suped, I can see which sources send for a domain, whether DKIM passes, whether the domain match needed for DMARC is working, and which source needs a fix. That matters when a company has marketing mail, product notifications, invoices, support mail, and internal mail leaving through different systems.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the strongest overall practical choice because it brings together DMARC monitoring, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, real-time alerts, and issue steps in one place. It is useful after the immediate DKIM fix because it shows whether the fix actually improves authentication across real mail streams.
DKIM signing coverage targets
Use these internal thresholds after enabling DKIM to decide whether the rollout is complete.
Healthy
95-100%
Most legitimate domain mail is signed by the expected systems.
Needs review
80-94%
Some send streams are still unsigned or signing with a different domain.
Incomplete
Below 80%
A major sender or workflow still needs DKIM activation.
Views from the trenches
Best practices
Confirm the live message has a DKIM-Signature header before changing DNS or policy.
Check the current sending provider because old DKIM DNS often survives vendor changes.
Use a real production send path because test modes can skip the normal signing pipeline.
Common pitfalls
Publishing a public key and assuming that alone activates signing on the sending server.
Asking support about DNS only, when the missing piece is the private signing key setup.
Leaving old selectors in DNS after moving traffic to a different email provider account.
Expert tips
Compare the header signing domain with the visible From domain before changing policy.
Ask providers for the exact selector and domain they expect to sign before editing DNS.
Wait for DNS verification, then click the provider's activate or authenticate control.
Expert from Email Geeks says the sending provider must sign messages with the private key; DNS only publishes the public key receivers use to verify it.
2022-07-12 - Email Geeks
Marketer from Email Geeks says a DKIM record can belong to an old email provider, so the current vendor should confirm which selector and domain it will sign.
2022-07-12 - Email Geeks
The practical takeaway
When DKIM DNS exists but messages are not DKIM signed, the immediate action is to check the raw header and then ask the current sending provider to enable signing for the sender domain. The DNS record is necessary, but it is not the signing mechanism.
Once the provider enables signing, send a real message through the same workflow, confirm the DKIM-Signature header appears, check that the selector resolves, and watch live DMARC results to confirm the fix holds across all send sources.
