Web Technician Online

DKIM failure: match the selector and signing domain

Inspect a received message’s DKIM-Signature header for d=, the signing domain, and s=, the selector.

What does this mean?

DKIM verifies a signature associated with a signing domain and selected public key. A missing public record, wrong key, disabled signing or a modified signed message can cause different failures. Finding a TXT key alone does not prove that a particular message’s signature is valid.

What should I check first?

Inspect a received message’s DKIM-Signature header for d=, the signing domain, and s=, the selector. Use those exact values in the public record checker. Do not guess a selector such as default when the provider signs with another name. Remove message content and personal addresses before sharing headers.

How can I diagnose the cause?

Compare the returned TXT or CNAME data with the provider’s current DKIM instructions. Some services delegate the key through CNAME, and key rotation can leave more than one valid selector. A record at the visible From domain is not necessarily the key used by the message.

How do I fix it safely?

Restore the provider-issued public record in the active DNS zone and confirm signing is enabled in its service. Never publish or paste a private signing key. If a signature passes on direct delivery but fails after a mailing list or gateway, investigate whether that intermediary changes signed headers or body content.

Verify the fix and know when to contact your provider

Save the zone before editing and test a newly sent message rather than an old queued copy. Ask the email provider to review signing configuration when the record is correct but verification fails. Include d=, s=, the timestamp and redacted receiver result; do not send private keys or a full confidential message.

Work through these checks in order

  1. From a real DKIM-Signature header, copy d= and s= exactly. Query the resulting selector._domainkey.signing-domain name; a key at another selector is not evidence for this signature.
  2. Compare the returned public TXT or delegated CNAME with the provider dashboard. Confirm signing is enabled and check whether a key rotation requires keeping an earlier selector temporarily.
  3. Test a fresh direct message and a forwarded example separately. If only the intermediary path fails, ask whether it modifies signed content rather than replacing a correctly published key.

Which tool can help?

DKIM public record checker · DNS lookup

DNS tools show one resolver’s public answers. Record explainers do not authenticate a message, and calculators do not monitor a server. Use the evidence alongside your provider’s logs.

Reference

Official technical documentation