For those who want or need to compile and install OpenDKIM from the source code, you can follow the instructions I wrote in this article.
If you’re looking for the fastest and easiest way to get OpenDKIM running on a RedHat system, I currently maintain the OpenDKIM package in the Fedora and EPEL repositories. This article will help you install the RPMs and then configure OpenDKIM with Postfix or Sendmail.
You are running a “modern” RedHat-compatible Linux distro (RHEL 5/6, CentOS 5/6, Fedora, etc).
You are running a milter-aware MTA, such as Postfix 2.3.3 or newer (do postconf -d mail_version to check) or Sendmail.
Your Postfix or Sendmail configuration is currently working (this is very important – you don’t want to troubleshoot two programs at once).
If you’re using Postfix, Sendmail is turned off (do service sendmail status to verify).
If you’re using Sendmail, Postfix is turned off (do service postfix status to verify).
The necessary commands in this tutorial are done as root. If you don’t know what that means, then you probably shouldn’t be doing this. You may be able to get away with just using sudo, but I wanted to make sure I didn’t run into any path issues, so I do it as root.
Install OpenDKIM with Yum
If you’re running Fedora 14 (or newer) or RHEL/CentOS 5 (or newer) then you can use Yum to quickly install OpenDKIM (RHEL/CentOS users must have the EPEL repositories enabled). Just do:
yum install opendkim
This will download and install OpenDKIM with all the default configuration options included below.
For those who like getting their hands dirtier, you can manually download one of my RPMs or even build your own RPM from my Source RPM, which are all available through the Fedora BuildSystem.
Generate keys for signing
Now you’re getting to the fun part. You need to generate a private and a public key for each of the domains for which you wish to sign mail. The private key is stored away from prying eyes on your server, while the public key gets published in your domain’s DNS records so that receiving mail servers can verify your DKIM-signed mail.
To make things easy, the first time you start opendkim after installing the RPM package, it will generate a default set of keys in /etc/opendkim/keys/ using your server’s domain name and the selector name “default.” However, if you want to sign for any virtual hosts or choose a different selector name than then default, you can easily generate your own keys. It really only takes a few seconds. Or, if you’re happy with the default keys, you can move on to the next step.
If you’re really hard-core, you can always build the keys manually. Or, you can use the easy script included with OpenDKIM to do it for you. I’ve manually generated enough keys in my life, so I use the script.
Before running this script, decide now what the name of your selector is going to be. A selector is a unique keyword that is associated with both keys (public and private), included in all the signatures, and published in your DNS records. For simplicity, I use the word default as my default selector. Not very creative, but it’s effective. Feel free to choose something different, but if you do, you’ll need to use it consistently throughout your setup. Also, while this should go without saying, you should use your mail domain instead of example.comthroughout the following steps.
You can do a man opendkim-genkey if you’re interested in what additional options are available when creating your keys. In this example, I used the -D (directory) option, the -d(domain) option, and the -s (selector) options. That’s all you need to get this going.
Edit the configuration files
You’re getting really close now. You need to create and/or edit four files:
/etc/opendkim.conf – OpenDKIM’s main configuration file
/etc/opendkim/KeyTable – a list of keys available for signing
/etc/opendkim/SigningTable – a list of domains and accounts allowed to sign
/etc/opendkim/TrustedHosts – a list of servers to “trust” when signing or verifying
On install, the RPM package should have created a simple /etc/opendkim.conf file on your system. By default, this file is set up for verification only. In order to sign outgoing mail, you’ll have to comment, uncomment, and configure some additional options in the configuration file. Use your favorite text editor to open /etc/opendkim.conf and make it look like this:
## CONFIGURATION OPTIONS
# Specifies the path to the process ID file.
# Selects operating modes. Valid modes are s (signer) and v (verifier). Default is v.
# Log activity to the system log.
# Log additional entries indicating successful signing or verification of messages.
# If logging is enabled, include detailed logging about why or why not a message was
# signed or verified. This causes a large increase in the amount of log data generated
# for each message, so it should be limited to debugging use only.
# Attempt to become the specified user before starting operations.
# Create a socket through which your MTA can communicate.
# Identifies a set internal hosts whose mail should be signed rather than verified.
You can do man opendkim.conf for more information on each of the options in this file.
Uncomment the Domain option (and include your actual domain name), the KeyTable,SigningTable, ExternalIgnoreList, and InternalHosts options. Also, since you’ll be using aKeyTable, you can comment the KeyFile option.
Next, you’ll need to create the three text files that you just uncommented in your config file. First, using your favorite text editor, create an /etc/opendkim/KeyTable file that looks like this:
The KeyTable file tells OpenDKIM where to find your keys. Each entry in the KeyTable file is asingle line for each key location (for example, all of the text in the above example should be on a single line in your file). If you’re going to use multiple keys (to sign mail for virtual domains with different keys, for example), you’ll need to create a separate line in theKeyTable file for each domain, like this:
Next, you need to create or edit the /etc/opendkim/SigningTable file. A default version of this file should have been installed in /etc/opendkim when you installed the RPM, so just uncomment the following line (or edit the file to include this line) so it reads:
The SigningTable file tells OpenDKIM how to use your keys, as in which senders should use which selectors for their signatures. In the above example, I’m saying that everyone (*) sending mail from the server “example.com” should use the selector named “default.” Again, for multiple domains and/or users, you’ll need multiple lines, like this:
In that example, everyone (*) sending mail from the server “example.com” can sign mail and should use the selector named “default.” But only Bob and Doug can sign mail for “example2.com” (also using a selector named default). It’s important to note that the * wildcard symbol will only work if the SigningTable option uses the refile: prefix before the filename (see the opendkim.conf documentation for more details).
Next, create an /etc/opendkim/TrustedHosts file that looks like this:
The TrustedHosts file tells OpenDKIM who to let use your keys. Because it’s referenced by theExternalIgnoreList directive in your conf file, OpenDKIM will ignore this list of hosts when verifying incoming mail. And, because it’s also referenced by the InternalHosts directive, this same list of hosts will be considered “internal,” and OpenDKIM will sign their outgoing mail.
IMPORTANT: Make sure you list the IP address for localhost (127.0.0.1) in the TrustedHostsfile or OpenDKIM won’t sign mail sent from this server. If you have multiple servers on the same network that relay mail through this server and you want to sign their mail as well, theymust be listed in the TrustedHosts file. Put each entry on its own line. An entry can be a hostname, domain name (e.g. “example.com”), IP address, an IPv6 address (including an IPv4 mapped address), or a CIDR-style IP specification (e.g. “192.168.1.0/24″).
It should also go without saying (but I’ll say it anyway) that if you’re planning to sign outgoing mail for remote hosts, your mail server should have been previously configured to allow relaying for those hosts.