MailDingo

dkim=neutral

dkim=neutral

The message had a signature, but the receiver couldn't use it, so it treats the message as if it had not been signed.

dkim=neutral means a DKIM signature was present but the receiver couldn't turn it into a verdict. Usually the signature was malformed, or it failed in a way the receiver didn't want to call a plain fail. Either way, the message is treated as unsigned.

What the RFC says

RFC 8601 §2.7.1 gives neutral two jobs. It covers signatures that contain syntax errors or that the verifier was otherwise unable to process, and it is the catch-all for failures not covered by the other result names. The same section explains the difference from fail: reporting fail leaves the next system to decide what to do with a broken signature, while reporting neutral (or none) settles it, and the message counts as unsigned. In practice, receivers draw the line between neutral, fail and permerror in different places.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=sel2026;
       h=from:subject:date; bh=...
Authentication-Results: mx.example.org;
       dkim=neutral (bad format) header.d=example.com header.s=sel2026;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

The signature in that snippet has no b= tag. RFC 6376 §3.5 makes b= required, so the verifier has nothing to check.

What produces it

  • A damaged signature header. A relay or filter truncated or re-wrapped the DKIM-Signature field, or a required tag (v, a, b, bh, d, h, s) is missing or malformed. RFC 6376 §6.1.1 says such signatures must be ignored.
  • An algorithm the receiver doesn't support. A signature using Ed25519 (a=ed25519-sha256, RFC 8463 §3) can come out neutral at a verifier that only knows RSA. That is why senders who use Ed25519 also add an RSA signature.
  • Receiver house style. Some large receivers, Gmail among them, have been seen reporting a body-hash mismatch as dkim=neutral (body hash did not verify) rather than fail. If your comment says that, read the dkim=fail page, because the causes are the same.
  • A key in testing mode. A key record with t=y tells verifiers to treat the domain's mail like unsigned mail (RFC 6376 §3.6.1). How that gets reported varies by receiver.

If you received this message

Ignore the DKIM line and look at the other results. Above, SPF passed for the From domain, so DMARC still passed. If nothing else authenticates the message, the analyser will flag it as unauthenticated.

If you own the domain

Read the comment text first. If it points to format, check the raw DKIM-Signature on a delivered copy for truncation, and look for a downstream system that rewrites headers. If you send Ed25519 signatures, keep an RSA signature alongside them. If it says "body hash did not verify", treat it as a fail: find what changes the body after signing.

See it in your own message

Paste the headers into the analyser to see which domain DKIM checked and whether it lines up with the From address.

Open the analyser