A dkim=none result is not another spelling of a broken signature. RFC 8601 §2.7.1 defines the DKIM none result as the message not being signed. That distinction changes the investigation: an unsigned message needs a signing-path review, while a signed message that fails needs verification evidence.
Start by confirming what the result belongs to and who supplied it. A tool summary, an Authentication-Results field and the raw message can describe different observations. Trust the result only within a verified receiver boundary, and preserve the original message before trying to reconcile apparent contradictions.
Read the complete result field
In Authentication-Results, dkim=none is a result for the DKIM method. The separate form consisting of an authentication service identifier followed by a bare none indicates that no message authentication was performed. These forms are not interchangeable; see RFC 8601 §2.2. Missing Authentication-Results is also not proof that a message was unsigned; the header may not have been added or retained.
Read the authserv-id and understand which system it identifies. A message can contain results from several hops, including untrusted text inserted before delivery. RFC 8601 §7.1 describes trust-boundary handling because an attacker can write a convincing-looking result field. A pass or none string has meaning only when its provenance and evaluation context are established.
Inspect the signature evidence
Look for DKIM-Signature fields in the preserved raw message. If none are present and the trusted receiver reports dkim=none, investigate whether the sender enabled signing on that route. Check application SMTP, relay connectors and API-generated mail independently of ordinary mailbox mail.
If a signature is present but the result says none, do not immediately accuse the receiver of an error. A later hop may have added the signature, or the available sample may differ from the message evaluated by that receiver. Establish where each result and signature entered the path. The interpretation depends on the observation boundary, not just on the final header list.
Separate three practical cases
Case one: no signature exists at the trusted evaluation boundary. The next action is to confirm the supported signing configuration and route. Publishing another public key does not make the service sign.
Case two: a signature exists but the corresponding key is absent. RFC 6376 §6.1.2 treats this as a no-key verification failure, not an unsigned message. Derive the lookup from the signature's d and s values and investigate DNS publication or retirement.
Case three: the key is retrieved but the covered content does not verify. Investigate body representation, signed headers, key material, damaged signature values and signer/verifier defects; a failure alone does not establish which input changed. An intact DKIM-Signature field does not mean the signature passes. These cases are a diagnostic framework, not a set of live test results.
Keep DMARC separate from the label
Under an applicable DMARC policy, an unsigned message can still pass through passing aligned SPF under RFC 9989 §5.3.5. Conversely, a passing DKIM signature under an unrelated domain might not supply DMARC alignment. Record the From domain, SPF identity and result, each DKIM identity and result, and alignment as distinct observations.
Do not infer delivery or safety from none alone. Receivers apply their own filtering, and DKIM is one input rather than proof that a message is harmless. The operational question is whether the expected authorized sending path has the intended authentication coverage.
Prove the signing repair
If the route should sign, use the provider's supported configuration and test new messages after the change. Verify that the intended d domain and selector appear, that the signature passes at a trusted receiver and that it aligns where required. Include the actual business format and route rather than a different service's test button.
Preserve the before-and-after evidence with timestamps and a route description. Close the issue as signing absent on a named path, missing verification material, or failed integrity verification as appropriate. Precise classification gives the next incident a useful starting point.
Evidence needed for the next decision
For illustration, Authentication-Results: mx.example; dkim=none reports unsigned mail for that method, while Authentication-Results: mx.example; none says no authentication schemes were performed. Neither string is trustworthy merely because mx.example appears in it. If the raw sample later contains a signature, obtain the reporting-hop sample or logs before deciding whether signing was absent there. These are synthetic header examples.