dkim=policy

dkim=policy is the rarest DKIM result you will meet. It means the message was signed, but something about the signature fell short of the receiving system's own rules, so the receiver refused to count it as a pass. The signature may well be cryptographically valid. The receiver is saying "valid, but not good enough for us".

What the RFC says

RFC 8601 §2.7.1 defines policy as a signature with "some aspect" that the receiving domain doesn't accept. It separates that from verification: a signature is "acceptable" only if it passes the receiver's local checks. The RFC's example is a receiver that only accepts signatures from the From domain, so a valid third-party signature would get policy. §2.4 shows how a receiver can name the rule involved, using a policy. property:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; l=1200;
       h=from:to:date; bh=...; b=...
Authentication-Results: mx.example.org;
       dkim=policy policy.dkim-rules=unsigned-subject
       header.d=example.com header.s=s1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

The property name after policy. is the receiver's own label, not a standard, so expect different wording from different systems. §2.4 admits the mechanism has seen little real use.

What triggers it

Receivers don't publish their rules, so these are typical reasons rather than a definitive list:

• A body length limit (l=). It means only the first N bytes of the body are signed (RFC 6376 §3.5). Anything added after that is unprotected, and RFC 6376 §8.2 suggests receivers may ignore such signatures. The snippet signs only 1,200 bytes.
• Important headers left unsigned. RFC 6376 requires only From in h= (§6.1.1). A receiver may insist on Subject too, as the snippet's policy label says.
• Weak cryptography. RSA keys between 1024 and 2048 bits are still allowed, but RFC 8301 §3.2 explicitly lets verifiers use key length to decide whether a signature is acceptable.
• The wrong signer. A signature from a domain the receiver doesn't trust for this sender.

Many receivers report the same situations as permerror, neutral or a plain pass, so the label depends on who checked the message.

If you received this message

Treat the signature as unproven and look at the other results. Here SPF aligned, so DMARC passed anyway. A signature with l= on a message whose body has grown beyond the signed length is worth a second look: the extra content wasn't signed.

If you own the domain

Remove l= from your signing configuration, sign at least From, To, Subject, Date and Message-ID, and use 2048-bit RSA keys. Then send a test through the receiver that complained, paste the headers into the analyser, and look for dkim=pass.