OpenDKIM doesn't reject unvalidated incoming emails

Last a few weeks I found that my OpenDKIM stopped rejecting incoming mails with no dkim-signature, bad-signature etc. Signing outgoing is OK, and according to the mail headers verifying provided, as well. That happened after updating the server's OS Archlinux (now kernel v.5.9.6-arch1-1). Some of configs:

Opendkim:

AlwaysAddARHeader  yes
AuthservID         OpenDKIM-Main
LogWhy          yes
Mode            sv
On-NoSignature reject
On-BadSignature reject
On-SignatureError reject
On-KeyNotFound  reject
Socket          inet6:8891@[::1]
UMask           002

Postfix:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:[::1]:8891, inet:[::1]:8893  #last one is OpenDMARC
non_smtpd_milters = $smtpd_milters

From validated mails the header concerning dkim like this:

Authentication-Results: OpenDKIM-Main; dkim=pass (1024-bit key) header.d=stackoverflow.email [email protected] header.b=Lq1gxzV+

From unvalidated, which must be rejected:

Authentication-Results: OpenDKIM-Main; dkim=none

How to fix this issue?

Two separate things are going on here, and splitting them apart helps.

First, the regression itself. This is a known OpenDKIM bug, not something you misconfigured. It's tracked upstream as issue #106, "OpenDKIM doesn't reject unvalidated mails on CentOS8 and Archlinux", with exactly your symptom: the On-NoSignature / On-BadSignature reject actions silently stop taking effect on the newer builds. The reported pattern matches yours closely, Arch's 2.10.3 and CentOS 8's 2.11.0 fail to reject, while the same 2.11.0 on CentOS 7 still rejects. It is unresolved, and at least one person reports that even compiling from source on Arch didn't bring the behaviour back. So your config is fine; the OpenDKIM build on your updated OS simply doesn't honour those reject actions anymore.

Your LogWhy is already on, so the mail log will confirm it: you'll see OpenDKIM evaluate the message, land on dkim=none, and then return no reject to Postfix. That lines up with the Authentication-Results header you quoted.

Second, and more useful for the long run: rejecting at the OpenDKIM layer with On-NoSignature reject isn't really what you want, and this is a good moment to move the enforcement. On-NoSignature reject bounces every message that arrives without a DKIM signature. A lot of legitimate mail is unsigned, or is signed by a domain you don't control, or loses its signature passing through a forwarder, so a blanket "no signature means reject" throws away real mail along with the junk. That's why DKIM on its own was never designed to be a pass/fail gate.

The layer that is meant to make that decision is DMARC, and you already have OpenDMARC running on :8893. DMARC rejects mail that fails authentication for a From domain whose owner has published p=reject or p=quarantine, and it checks alignment against the visible From address. That drops spoofed mail based on the real sender's own stated policy, without nuking legitimate unsigned mail from domains that just don't sign. Make sure opendmarc.conf has RejectFailures true (and keep OpenDKIM in verify mode so OpenDMARC can read its result), and let DMARC be the thing that rejects.

One honest caveat: DMARC will not reproduce "reject anything that isn't DKIM-signed", because that isn't a goal DMARC, or good deliverability practice, supports. If you genuinely want to penalise missing DKIM beyond what DMARC does, do it as a score in a content filter like rspamd or SpamAssassin, where a missing or broken signature adds weight instead of causing a hard 5xx.

And if you truly must keep the hard OpenDKIM reject, the only thing reported to work is pinning OpenDKIM to a build that still honours the action, since the behaviour changed on the newer packaged versions. I'd treat that as a last resort rather than the fix