A DKIM failure means a receiving mailbox could not verify the digital signature expected on a message. It can hurt authentication and deliverability, but the right repair depends on the exact sender and header result. Start with a real failed message, not a DNS record alone: identify the sending platform, selector, signing domain, and result in the message headers.
What DKIM is checking
A sending service signs selected parts of a message with a private key. The receiver uses the selector in the signature to find a public key in DNS and verify the message. For a business using several sending tools, each tool may use a different selector and setup. A valid-looking key at one selector does not prove that another platform is signing mail correctly.
Common causes
- DKIM was never enabled in the sender’s dashboard.
- The published selector or key is missing, truncated, or in the wrong DNS zone.
- The provider changed or rotated a selector and DNS was not updated.
- The message is modified after signing by a gateway, forwarding rule, or intermediary.
- The platform is signing with an unrelated domain, which can create DMARC alignment issues.
Run a free Beacon domain check for the public record, then send a fresh test directly from the affected platform to a mailbox where you can view headers.
A safe diagnosis sequence
- Record the visible From domain, the DKIM
d=domain, and selectors=from the failed message. - Confirm the message came from the platform you are investigating.
- Compare the selector and DNS record against that provider’s current instructions.
- Confirm signing is enabled in the provider account, not merely that a DNS key exists.
- Test a new direct message after any change; compare results across every sender.
For the record-checking basics, see how to check a DKIM record. Keep each change documented so a later provider rotation is not mistaken for an attack.
Example
A firm enables a new help desk. It publishes the DKIM record supplied during setup but leaves the product’s “authenticate domain” step unfinished. Newsletter messages pass DKIM because they use another provider, while support replies fail. The correct fix is to finish the help-desk setup and test a reply—not to replace the newsletter selector or add unrelated DNS records.
DKIM, SPF, and DMARC
DKIM is one part of email authentication. DMARC can pass when either aligned DKIM or aligned SPF passes, but a DKIM failure is still worth resolving because it removes a valuable identity signal. Review the relationship in SPF vs DKIM vs DMARC. If authentication passes but mail still goes to spam, investigate permission, reputation, and sending patterns as well.
What not to do
Do not copy a selector from another provider, delete a key before the sender has moved away from it, or assume one successful mailbox test represents every sending system. Do not weaken DMARC as a permanent response. Work from the actual failed headers, use the provider’s documentation, and retain the old value for rollback.
Preventing repeat failures
Keep a sender inventory with provider, owner, selector, and purpose. Review it after a migration, DNS change, or agency handoff. Once your baseline works, monitoring gives you a useful signal when monitored authentication conditions change. For broader failure triage, read Email Authentication Failed.
When the key looks right but verification still fails
Verify that the DNS host published the complete value and correct record type at the selector hostname. Some interfaces split long keys visually; copying only part of the value will break verification. Check the active DNS provider after a nameserver migration, because adding a record to an inactive registrar zone has no effect. Also compare the selector in the header with the selector you published: providers can use different selectors for different streams or rotate keys automatically.
If an intermediary modifies a signed portion of the message, direct tests may pass while forwarded mail fails. Do not “fix” that by weakening your normal configuration. Collect both header examples, identify the intermediary, and ask the provider whether the behavior is expected.
Work with third parties safely
Give a vendor the exact failed header evidence and your sending domain, but do not give them DNS-account credentials. Ask for their official record requirements and retain a change log. Schedule key rotation outside a critical campaign window, publish the new record before changing the signer when the provider directs it, and keep the former selector until every active message stream has moved.
Finally, make sure the result is visible to the person responsible for the business process that sends the mail. A technically repaired signature is valuable only when invoices, customer replies, and campaigns are all tested in the conditions where they actually run.
FAQ
Does a DKIM fail mean my account was hacked?
Not necessarily. Configuration and key problems are common; investigate unknown senders and account access separately.
Can I remove an old DKIM record?
Only after confirming no active sender uses its selector and testing the remaining systems.