I have Postfix running on a Debian 9 machine, and installed opendkim (both from the Debian repositories). The milter socket/connection is inet:localhost:8892, and the iptables firewall allows that connection (a telnet localhost 8892 succeeds).

However, I only get signed messages if I send e-mail from the console (with mail -s "testing DKIM" my-address@not-the-same-domain), but not if I send it from Thunderbird. Notice, with Thunderbird, I use ssh tunneling, so that the mail server sees the connection as originating from localhost. (that is, on my desktop, I run ssh -Llocalhost:2525:my-server:25 tunnel@my-server, and I tell Thunderbird that the outgoing mail server is localhost, port 2525.

This is an example of the signature I get when sending from the console:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=[omitted -- but it shows the correct domain];
    s=mail; t=1557228588;
    b=jtOM5OOM83l [ ··· several lines of "gibberish" ··· ] 4qdpSt4l86DEA==

Any ideas on what could be causing this issue?

[[EDIT]] The problem gets more puzzling. While inspecting the logs, I noticed a warning external host XXXX.my-service-provider.com attempted to send as my-domain.com

I adjusted /etc/hosts, /etc/hostname ... Finally I realized that I had to adjust the reverse DNS lookup, and I did that. Now, the command hostname responds with the FQDN (the correct domain for which I'm configuring DKIM).

Now, in /var/log/syslog when I send an e-mail, I'm getting the message external host *the-correct-FQDN* attempted to send as *the-correct-FQDN*. And the transmitted message does not contain a DKIM signature.

If I do telnet localhost 25, greet the SMTP server with helo the-correct-FQDN, the message is DKIM-signed; the logs show that a connection from localhost ( was responsible for the transmission.

Any ideas?
[[ END EDIT ]]


Turns out the issue was caused by a lack of a InternalHosts parameter. For the current version of opendkim on Debian 9 (2.11), I solved it as follows:

Edited file /etc/opendkim.conf and added the following line:

InternalHosts file:/etc/opendkim-trustedhosts.conf

Then, the file /etc/opendkim-trustedhosts.conf contains:
x.x.x.x (the actual public IP of the server)

And voilà --- restart and that fixed the problem!

Some differences I noticed w.r.t. other info I found out there --- from what I could see, on CentOS (not sure whether older versions or still like this), the default configuration is: there is a directory etc/opendkim, and inside that directory there is, among others, a file TrustedHosts.conf; the file /etc/opendkim.conf already has the InternalHosts directive pointing to the TrustedHosts file. On Debian 9, one has to create it manually.


Similar problem and context: using openDKIM with Postfix as MTA that is then a relay only for authenticated Mail User Agents (MUA's), the later counting notably MS-Outlook clients configured with SMTP+POP or SMTP+IMAP connexions to the Postfix MTA over TLS/SSL + SASL (authentication with login and password) through port 587 in my case.

When local console 'mailx' or 'sendmail' is used, the openDKIM integration is controlled through the non_smtpd_milters option in postfix/main.cf, whereas smtpd_milters option do control the case of incoming SMTPD e-mails from authenticated MUA's. So first you may need to check that both options are aligned, e.g. like

smtpd_milters = inet:
non_smtpd_milters = $smtpd_milters

Then, when a valid DKIM signature is generated for local e-mails (via 'mailx' or 'sendmail') but not on e-mails from authenticated MUA's, it is most likely an issue with determining who is the message sender and thus preventing openDKIM to crawl to the 'From:' domain for which the signature is setup. You may likely found traces like:

opendkim[9530]: E3B6A13CBED: can't determine message sender;

which in my case was due to an interference with the header_checks option in Postfix. Look for it in either main.cf or master.cf (which can override options in main.cf), e.g.

-o header_checks=regexp:/etc/postfix/submission_header_cleanup

and ensure the associateed header cleanup rules will NOT contain a regex like:

/^Received:/            IGNORE

which you must then comment-OUT or remove.

Last, ensure postfix/main.cf will tell Postfix to pass sufficient data to opendkim through the milter protocol with an option like:

milter_mail_macros =  i {mail_addr} {client_addr} {client_name} {auth_type} {auth_authen}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.