## TL;DR
Restart OpenDKIM, fix the socket mismatch, and prove signing is back before worrying about DNS. The error means Postfix tried to reach the OpenDKIM milter at the unix socket path in its config and nothing was listening there, so compare the Socket setting in opendkim.conf with the smtpd_milters path in Postfix, align them, restart both services in the right order, and send a test that comes back with a DKIM-Signature header.

```text
postfix "connect to Milter service mount the host path unix at container path /run/opendkim/opendkim.sock: No such file or directory" dkim signing stopped
```

## Use this when
- Postfix logs show connect to Milter service mount the host path unix at container path /run/opendkim/opendkim.sock with No such file or directory.
- Outbound mail is delivered but has no DKIM-Signature header.
- The host was rebooted, upgraded, or the OpenDKIM service was restarted recently.

## Not for this skill when
- Inbound mail fails DKIM verification. That is a sender or forwarding problem, not your milter.
- Mail is signed but receivers report dkim=fail. That is a key, selector, or body hash problem.

## Steps
1. Check whether OpenDKIM is running and list the socket directory to see which socket file actually exists. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the service state and the real socket path are both known
2. Compare the Socket value in the OpenDKIM config with the milter paths in Postfix main.cf and master.cf, including any chroot prefix Postfix adds. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: both configs point at the same effective socket path
3. Fix the mismatch, make sure the runtime directory is recreated on boot by the service unit or tmpfiles config, and check the postfix user can traverse the directory. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the socket file exists after a restart and permissions allow the postfix user to reach it
4. Restart OpenDKIM first, then reload Postfix, and watch the mail log during a test send. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the log shows the milter accepted the message with no connect error
5. Send a test to an external mailbox and inspect the delivered headers. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: a DKIM-Signature header with your selector is present and an online checker reports dkim=pass

## Why it happens
Postfix hands each message to OpenDKIM over a local socket for signing. If the daemon is stopped, crashed, or listening on a different path than the one Postfix was configured with, signing silently stops while delivery continues. Runtime directories under /run are cleared on reboot, so a socket that was created by hand once often vanishes at the next restart unless the service itself recreates it.

## Variants and edge cases
### postfix opendkim milter socket no such file or directory signing stopped
The log-line phrasing copied straight from mail.log.
### opendkim not signing after reboot socket missing postfix
The reboot variant that points at the runtime directory cause.
### dkim signature header missing postfix milter connection failed
The symptom variant searched from the receiver side evidence.

Compatibility: Postfix 3.x with OpenDKIM 2.11 on Linux, systemd service units, non-chroot and chroot Postfix setups.

Edge cases to check:
- Postfix in a chroot prefixes the socket path; a path that looks correct can still resolve inside the chroot jail.
- When the milter is unreachable Postfix tempfails or passes mail unsigned depending on milter_default_action; know which behaviour you have configured.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_K71OTQrTfhr-huV0JCFDJQ