Classify the observed state

First ask whether a DKIM-Signature field exists. If none exists, investigate the sending stream and signer configuration; a DNS key cannot make an unsigned message signed after delivery.

If a signature exists, record its required tags and timestamps. t= is the signature timestamp when present. x= is an optional expiration time; a verifier should not consider the signature valid after that time. Compare in UTC and account for an obviously incorrect system clock without silently rewriting evidence.

“Missing DKIM” can also mean that a dashboard failed to associate a receiver result with a signature. Preserve the raw message and the trusted Authentication-Results before drawing a conclusion.

Query the exact key name

Use s= and d= to construct the selector name. Distinguish:

  • no DNS name or no key data;
  • a deliberately revoked key with an empty public-key value;
  • invalid key syntax;
  • unsupported algorithm or key constraints;
  • temporary resolver failure.

A later lookup is not guaranteed to reproduce what the receiver saw when it evaluated the message. Record query time and resolver, and consider recent rotations or DNS migrations.

Trace the signing system

Match the message to its provider event and sender account. Confirm that signing was enabled for that domain, the correct selector was loaded, and no downstream service stripped or replaced fields. If only one template or route is unsigned, compare its path with a working message instead of changing the whole domain.

For an expired signature, determine why the message was delayed or why the signer chose that lifetime. Do not extend validity blindly; understand queue delays, replay risk, and provider behavior.

Repair and retest

Restore or publish the intended public key only after confirming its relationship to the protected private key. If the private key is unavailable or suspected compromised, rotate to a new selector rather than improvising. Configure the final outbound system to sign after required transformations.

Send a new representative message and verify it at a trusted receiver. Document whether the incident involved absent signing, signature expiry, DNS/key retrieval, or another verification failure. That classification prevents the next operator from repeating an irrelevant DNS change.