Introduction
SPF (Sender Policy Framework) is a DNS text entry which shows a list
of servers that should be considered allowed to send mail for a specific
domain. Incidentally, the fact that SPF is a DNS entry can also
considered a way to enforce the fact that the list is authoritative for
the domain, since the owners/administrators are the only people allowed
to add/change that main domain zone.
- upon receipt, the HELO message and the sender address are fetched by the receiving mail server
- the receiving mail server runs a TXT DNS query against the claimed domain SPF entry
- the SPF entry data is then used to verify the sender server
- in case the check fails a rejection message is given to the sender server
DKIM (DomainKeys Identified Mail) should be instead considered a method to verify that the messages' content
are trustworthy, meaning that they weren't changed from the moment the
a message left the initial mail server. This additional layer of
trustability is achieved by an implementation of the standard
public/private key signing process. Once again the owners of the domain
add a DNS entry with the public DKIM key which will be used by
receivers to verify that the message DKIM signature is correct, while on
the sender side the server will sign the entitled mail messages with
the corresponding private key.
- when sending an outgoing message, the last server within the
domain infrastructure checks against its internal settings if the domain
used in the "From:" header is included in its "signing table". If not
the process stops here
- a new header, called "DKIM-Signature", is added to the mail message by using the private part of the key on the message content
- from here on the message *main* content cannot be modified otherwise the DKIM header won't match anymore
- upon reception, the receiving server will make a TXT DNS query to retrieve the key used in the DKIM-Signature field
- the DKIM header check result can be then used when deciding if a message is fraudulent or trustworthy
Setting Up SPF
SPF requires only that you add a TXT record to your DNS zone for the domain. How that happens depends on the tools provided by your domain registrar, or the tools you set up yourself should you manage your own nameservers. If using a registrar's web interface to make DNS changes,
you may or may not have the option to enter a subdomain for the record.
If you do, then leave that field blank.
This generic SPF TXT record authorizes mail originating from mail
servers for your domain that is identified by MX records and all other
servers associated with your domain that have A records:
Note that the double quotes are a necessary part of the SPF TXT record.
Much more complicated records than this are possible, as outlined in the
SPF documentation.
Setting Up DKIMSetting up DKIM is a little more involved than SPF, but still not too challenging if you are already running a Postfix mail server on Ubuntu.
First, install the necessary packages:
apt-get install opendkim opendkim-tools -y
Open /etc/opendkim.conf:
nano /etc/opendkim.conf
Add the following:
Domain your_domain
KeyFile /etc/postfix/dkim.key
Selector dkim
SOCKET inet:8891@localhost
Open /etc/default/opendkim:
nano /etc/default/opendkim
Add the following:
SOCKET="inet:8891@localhost"
Configure postfix to use this milter:
nano /etc/postfix/main.cf
Make sure that these two lines are present in the Postfix config file and are not commented out:
milter_protocol = 2
milter_default_action = accept
It is likely that a filter (SpamAssasin, Clamav etc.) is already used by Postfix; if the following parameters are present, just append the opendkim milter to them (milters are separated by a comma), the port number should be the same as in opendkim.conf:
smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:8891
non_smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:8891
If the parameters are missing, define them as follows:
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
Generating the Public and Private KeysNow you can generate a private key for signing outgoing mail. Note that
in the following command, "dkim" is the value given to Selector in /etc/opendkim.conf.
This can be any simple string, provided you are consistent about replacing "dkim" with your desired value everywhere in this recipe. Run the following command to generate the key and associated materials in the form of two files,
dkim.private, and
dkim.txt. The former is the RSA private key, while the latter contains the entry you will have to place into your DNS records.
opendkim-genkey -t -s dkim -d your_domain
Move the key into place, but don't forget to take a copy and keep that copy backed up somewhere safe:
mv dkim.private /etc/postfix/dkim.key
You'll need to restart Postfix and OpenDKIM services to pick up the
configuration changes so that outgoing mail is signed using DKIM:
service opendkim start
service postfix restart
Adding the Public Key to The Domain's DNS RecordsNext up is the DNS record setup. How you do this is again completely dependent on how you manage DNS or how it is managed for you -
everyone's tools are different. Note that some registrars do not let you create raw TXT records with specific subdomains, which will prevent you from creating DKIM TXT records. If this is the case, then you will have to transfer your domain to a real registrar that lets you play with all the toys.
Or you can simply use our DNS management system!
You can find information about your public key in dkim.txt file:
cat dkim.txt
Here is how it looks on our DNS management system:
Sharing a DKIM Key for Multiple DomainsIf you are serving multiple domains from the same mail server, then the contents of
/etc/opendkim.conf:
nano /etc/opendkim.conf
Instead of:
Domain your_domain
KeyFile /etc/postfix/dkim.key
Selector dkim
SOCKET inet:8891@localhost
Should be:
Domain *
KeyFile /etc/postfix/dkim.key
Selector dkim
SOCKET inet:8891@localhost
TestingFirst of all, give the DNS changes a chance to propagate before using it. Decent testing service is
Mail Tester.