DKIM: Connection refused

When I enable the new DKIM Milter, I get this:

warning: connect to Milter service inet:localhost:8891: Connection refused

Not sure if this is a firewall issue since the documentation didn’t mention needing to open a port.

Advise is appreciated.


Any firewall you could be running shouldn’t block local connections like that… it actually looks like the DKIM service isn’t running.

Try running this from the command line as root:

/etc/init.d/dkim-filter start

Does that solve the issue? If not, do you see an error of any sort when trying to start that up?


-bash: /etc/init.d/dkim-filter: No such file or directory

Okay, should be milter oppose to filter and this is what I get:

/etc/init.d/dkim-milter start
Starting DomainKeys Identified Mail Milter (dkim-filter): dkim-filter: /etc/mail/dkim-milter/dkim-filter.conf: configuration error at line 152: unrecognized parameter

Hmm… so what do you see on lines 151, 152, and 153 of /etc/mail/dkim-milter/dkim-filter.conf?

And which distro is it that you’re using?



This is using CentOS 5.5.

Line 151 is “Domain” followed by every domain hosted on the server.
Line 152 and 153, etc are commented out instructions:

default (none)

Specify for which domain(s) signing should be done. No default; must

be specified for signing.

I’ve a near identical problem. Same error but on Ubuntu which has a slightly different dkim-filter.conf


Okay, so, those are some odd problems :slight_smile:

We’d like to help dig into them… would it be possible to see a copy of your dkim-filter.conf config files?

I’m curious if you could send me an email containing:

  • Your dkim-filter.conf file added as an attachment

  • Your distribution and version

  • The exact error you get when trying to launch the DKIM daemon

If you could send that to, that’d be great… and we’ll try and figure out what’s going on :slight_smile:




Did my conf file reveal anything?


Oh, right… yeah, after seeing your config files, Jamie discovered a problem in the config files that were being generated. It seems related to the overall size of the Domain line, which can grow quite large with dealing with a lot of domains.

Essentially, the issue is that the DKIM Milter program can’t handle a Domain line larger than 1024 characters.

He’s working out a fix for that.

A workaround he’s found may to use “Domain *”, rather than listing each individual domain there. That idea needs some testing before it’s automatically used in Virtualmin though.


Okay, great - I appreciate that. I am testing Jamie’s workaround and this time it started up with out any errors.

However, it’s not passing DKIM tests

The results are as follows:

DomainKey-Status: no signature

Does it make a difference that my DNS is handled by a 3rd party DNS service?

I have the identical problem, I think.

I just implemented the DKIM feature. Except for the problems, I think it’s a fantastic new feature an I really appreciate you adding this into Virtualmin.

I’m using Centos 5.5 (32-bit).

After enabling the DKIM feature, I ran into the key-length problem and fixed that.

Both named and dkim-filter are running as verified with:

ps ax|egrep ‘dk|name’

However, outgoing mail still was not getting signed (no headers added) and I get this error in maillog:

Oct 26 11:00:38 www postfix/smtpd[3188]: warning: connect to Milter service inet:localhost:8891: Connection refused

It turns out that the milter was configured for socket-based communications instead of TCP-based connections as noted by the lack of port 8891 in this test:

netstat -tapn|grep 8891

The solution (Centos 5.5) was to edit the dkim-milter startup script and change it to use TCP connections:

vim /etc/init.d/dkim-milter




service dkim-milter restart


Send an e-mail to and wait for a response.

I hope this saves others some time,


Thanks for the wonderful info!

I pointed that out to Jamie (as well as the other issues that have come up), and he’s working to integrate fixes for all that into the next Virtualmin release.

Thanks again,



I’m also trying to get the DKIM signing of outgoing mail configured via the Virtualmin control panel as described here:

I found two bugs in the settings that the Virtualmin 3.82 GPL script produces (running Ubuntu 10.04):

  1. the DNS TXT records generated are missing a semicolon after k=rsa
    i.e., they read:
    k=rsa t=y; p=MIGfMA0G …
    instead of:
    k=rsa; t=y; p=MIGfMA0G …

Here is a useful link where you can have the validity of your DNS TXT record checked:

  1. the keylist that is generated looks like this:


this gives an error when trying to start the dkim-filter service saying “dkim-filter: /etc: read(): Is a directory”

I fixed this by adding the selector to each line (/etc/dkim-filter.conf has “selector im”) so it looks like this:


/etc/im is a symbolic link to the key file in etc/dkim.key

Now mail goes out with a correct-looking DKIM header, but it still fails the test one can do by sending a test mail to
Unfortunately there is not a very detailed report in their feedback email, it just says “Signature verification failed; signature is missing or key could not be found”, so I suppose it’s some error in the outgoing email headers, because my dns entries pass the test at the first link.

This is an example of an outgoing email header being generated:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=im;
t=1290951635; bh=4bYd6ZlIWAG92Y7oV7+JdZrw99unl9uLKC7csIf6pwc=;

I wonder if anyone has had more luck using OpenDKIM instead of the dkim-filter package?

Another issue with the virtual host scenario is that all virtual domains use the same key.
But even if they didn’t since even with a separate key for each domain, the key is selected based on the From: header (if I understand correctly), so with one Postfix service being shared by all domains, there would be nothing to stop a script on one of the virtual domains sending out emails with a From header of another and getting it signed.

After much trial and error I finally discovered that the reason the outgoing emails were not passing the DKIM test at the receiving end was the use of “\r\n” as EOL in the headers added in the php code calling mail().
It should have just been “\n”, because apparently Postfix is adding the \r irrespective of whether it’s already present, so one winds up with an extra \r if one puts it in the php generated headers.
The safest is to use the constant PHP_EOL when adding headers, for example,

$headers = ‘From:’ . PHP_EOL . ‘Content-Type: text/plain; charset=ANSI_X3.4-1968’ . PHP_EOL;

mail($to, $subject, $message, $headers)


DKIM was working all fine on Centos 5.5 and now it appears that its not any longer…

was this linked to the a recent upgrade to Virtualmin/Webmin?



Managed to fix the problem that I had by:

Just wanted to quote a few lines from outside about DKIM-Milter and OpenDKIM:

“dkim-milter is dead upstream and the original author has forked it and picked up development in a fork called opendkim. dkim-milter suffers from some serious bugs that won’t be fixed and users should switch to opendkim instead” —

“The project started from a code fork of version 2.8.3 of the open source dkim-milter package developed and maintained by Sendmail, Inc… The OpenDKIM package consists of a library that implements the DKIM service and a milter-based filter application that can plug in to any milter-aware MTA to provide that service to sufficiently recent sendmail MTAs and other MTAs that support the milter protocol.” ----

Now, I want to mention that we are using/testing this Virtualmin integrated DKIM-Milter for a while (replacing our working DKIMProxy setup for the sake of integration with VM), and it’s just not stable. The DKIM-milter process dies/hangs-up randomly. We are keeping it up with Webmin status monitor (restart on down), but still, there are at least one minute of outage every few minutes. Also, it’s worth mentioning that we tried dkim-milter back in 2009 for some of our servers and the experience was no better. Later, we went ahead with DKIMProxy.

I know, we can make dkim-milter logs speak louder and find out clues about the actual bug(s). But still, I think, as we are aware of the facts above, we should better look forward to switch to OpenDKIM fork. Let’s not overlook the new features (such as, multiple signs - one for virtual domain, another for host which comes handy with Yahoo! FBL participation)

We already have the spec and init files in the source package. Building it for RHEL is no biggie. We only need a few adjustments in the virtualmin DKIM library to handle slightly changed config syntax, and have the RPM hosted on VM repository. Thoughts?

Any plans to use OpenDKIM? I think it is about time =) Please please please!

This is a relatively old thread, but I had the same problem. The following lines in /etc/opendkim.conf referenced non-existent files and that was preventing opendkim from starting:

ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

So to fix it, I just commented them out and then opendkim started successfully with service opendkim start

Hope this helps.