In a previous blogpost, I already discussed DKIM signing with Exchange 2016:  SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II

Exchange out-of-the-box does support SPF checking, but DKIM signing/verifying and DMARC verifying are not supported. There are free 3^rd party tools for DKIM Signing that can be found on GitHub, but at the moment of writing this tool only supports DKIM Signing, but does not support DKIM verifying. I have to admit that DKIM signing with this tool works very well.

I already explained earlier that I’ve installed and configured a Cisco Email Security Appliance (ESA, previously known as IronPort) appliance in my lab environment, and this is installed like this:

Figure 1. My testlab Exchange environment.

All outbound SMTP mail is via the ESA. The FQDN of the ESA is smtphost.exchangelabs.nl, of course it has a public IP address with a corresponding PTR record.

SPF is configured to allow SMTP mail from this FQDN and IP address, but I have configured it with a ‘soft fail’ option, in case receiving SMTP hosts cannot check properly. The following screenshot is taken from the http://mxtoolbox.com site:

Figure 2. checking the SPF record

I’ve also configured a DMARC record. As outlined in the SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III blogpost this is used by receiving SMTP hosts, not by my Exchange server. My DMARC policy is just for checking (p=none), 100% of my messages are checked and the aggregate results are send to DMARCIAN. Again, this screenshot is taken from the http://mxtoolbox.com site:

Figure 3. Checking the DMARC record

So far this is not too exciting, and everybody should configure this and use a tool like DMARCIAN to monitor your internet confidence level.

Cisco Email Security Appliance DKIM signing

Just a quick primer what DKIM signing is and how it works. Using DKIM signing you can create a DKIM-Signature that’s stored in the header of the SMTP message. This signature is created using a private key. Since you are the only one having access to the private key, the receiver of the message can be sure that you are the legitimate sender.

To decrypt the DKIM-Signature the receiving server needs to have your public key, and this is stored in public DNS. When a message is received, the receiving server gets the public key from DNS and puts an authorization header in the message. The workflow is like this:

Figure 4. DKIM signing and encryption, courtesy of Cisco.

Enabling DKIM signing in the ESA consists of a few steps.

1. Create signing keys. In contrast to the Github solution, the Cisco appliance can generate its own keys. Key length can vary between 512 bytes (not very secure) to 2048 bytes (extremely secure). A 1024 key length is considered secure, a key length of 2048 has a performance impact. In the appliance, select Mail Policies –> Domain Keys –> Signing Keys and click Add Key. Enter a name, select key number of bits (I use 1024) and click Submit. A key pair is now created. You can use the view option under Public Key to copy the public key. This will be stored in DNS later on.

2. The second step to to create a Domain Profile. This is where the sending domain is associated with the signing key. To create a domain profile, select Mail Policies –> Signing Profiles and click the Add Profile button. Enter a name and in the drop-down box select DKIM. The window will expand and you can enter DKIM specific information like the domain name, the selector, the private key that was created in the previous step, canonicalization, which headers to use etc.

Figure 5. Configuring DKIM specifics.

3. Enable DKIM signing on an outgoing profile. Select Mail Policies à Mail Flow Policies (under Host Access Table) and select the OutgoingMail policy. Click the Relayed policy, scroll down to the Security Features section and in the Domain Key/DKIM Signing field select On.

This is all it takes to enable DKIM signing on outbound messages for a particular domain. When I send out and email (to my home address) and check the message header, the DKIM-Signature is clearly visible.

Figure 6. The DKIM-Signature header in an outbound SMTP message

The Authentication-Results header still shows “dkim=invalid”, but that’s because the public key isn’t stored in DNS yet. ESA is capable of generating the DNS Text record, which in my environment will look like this:

When this information is entered in DNS and an email is sent we can check the message header again, and yes, Authentication-Results show “dkim=pass”.

At this moment only my default domain is DKIM signed. Additional domains is easy, create a new signing profile for this domain (with the existing keypair or a new keypair), create a DNS record for this additional domain and you’re good to go.

Cisco Email Security Appliance DKIM verification

Now that we have DKIM signing working it’s time to enable DKIM verification. For DKIM verification a predefined profile is already available on the ESA.

To enable DKIM verification (it is available out of the box) go to Mail Policies –> Mail flow policy and select the IncomingMail policy. Scroll down to the Security Features section and select the On radiobutton at DKIM Verification.

Now when I send an email from a domain that does DKIM signing to a mailbox in my lab through the ESA we can see it is actually verified and it shows ‘dkim=pass (signature verified)’ in the email header:

Summary

In this blogpost I showed you how to enable DKIM Signing and DKIM Verification on the Cisco Email Security Appliance. Using DKIM signing the receiving server knows that your server is allowed to send email on your behalf by verifying the DKIM signature in the email header.

Vice versa, if you receive an email with a DKIM signature in the email header you can verify if the sending server really is allowed to send mail on behalf of this user by verifying the DKIM signature.

In the next blog I’ll show you how to enable DMARC on the ESA and what you can do with it to fight spam.