1

I run dkimproxy to sign outbound email and verify inbound email.

Since a while, I am experiencing the following permanent problem. The dkimproxy service is unable to query the DNS. Each and every message I receive gets the following header set (in my example I am example.org and sender example.biz)

Authentication-Results: mail.example.org; dkim=invalid (public key: DNS query timeout for api._domainkey.example.biz at /usr/lib/perl5/vendor_perl/5.18.1/Mail/DKIM/DNS.pm line 156, line 643.) header.i=@example.biz; dkim=invalid (public key: DNS query timeout for api._domainkey.example.biz at /usr/lib/perl5/vendor_perl/5.18.1/Mail/DKIM/DNS.pm line 156, line 643.) header.i=@example.biz

The error is permanent. If I log in via SSH and try to use nslookup to get the TXT record from the remote DNS I can successfully read it.

How can I fix the above problem?

[Edit] my problem doesn't fall into this known question, because in that question the DKIM check seems to be done by SpamAssassin. I check DKIM with dkimproxy

4
  • To clarify, this did work at one point in time?
    – pete
    Apr 5 '16 at 11:07
  • Maybe. About one year ago I migrated my mail server to a newer OS. I did test much of the stuff, in particular DKIM signing. I am not sure if I ever tested DKIM verify. I could have left that test forgotten. And I don't have any firewall rule disallowing dkim user to query DNS Apr 5 '16 at 12:20
  • Two thoughts: If dkimproxy or perl is being run within a chroot or jail, that could affect it determining the correct resolver to use. If you can use tcpdump, take a look at the dns traffic - make sure it is attempting to use the correct resolver, on the appropriate interface
    – pete
    Apr 5 '16 at 23:35
  • Confirmed dkimproxy does not run in chroot or jail. Obviously it runs unprivileged using a dedicated dkim user. Need to confirm DNS lookup yet Apr 6 '16 at 6:46
0

I have voted to close my own question because it already has an answer in a different QA: Azure DNS does not lookup SPF policies for certain domains

Switching /etc/resolv.conf to any other public DNS (e.g. 8.8.8.8) allows TCP querying and SPF returns to work.

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