Exchange and SPF, DKIM, and DMARC. Oh my!

Email security should be top-of-mind for any organization. Being that the SMTP protocol does not provide much (any) security or authentication natively, we rely on frameworks and extensions to provide these capabilities. Here's a quick primer on what they are, how they work, and how you can protect your organization.

• Sender Protection Framework (SPF) - SPF provides a way for you to list permitted IP addresses that send email for your SMTP domain. An SPF (TXT) record is created in the public DNS zone for the SMTP domain. The statement includes all the IPs that are allowed to send emails for that domain and a recommendation on how the recipient server should treat emails from other sources.

• DomainKeys Identified Mail (DKIM) - DKIM digitally signs all outbound emails and provides an easy way for receiving SMTP servers to verify that the incoming message comes from a legitimate server. Signing is typically done using a transport agent as the email exits the sending organization.

Both SPF and DKIM go a long way to confirm that an email is coming from a legitimate source, but both have their shortcomings. When SPF was originally announced, there wasn't much good documentation and a lot of customers implemented it incorrectly. This caused email deliveries to fail and organizations sometimes couldn't trust it. DKIM works great for confirming that a message is indeed legitimate, but doesn't specify what to do when messages are not DKIM signed. If a message comes without a signature, there's no easy way for a receiver to know that it should have been signed, and in that case it's most likely not authentic. That's where DMARC comes in.

• Domain Message Authentication Reporting & Conformance (DMARC) - DMARC is simply an enforcement statement in DNS that defines that SPF and/or DKIM are used by the SMTP domain and what the receiving server MUST do with emails that do not align with SPF or DKIM. It also provides a way for recipients to report invalid emails.

This combination of mechanisms are used to attest that emails sent by your organization are really from you. They don't prevent inbound spoofing or spam emails from other domains, but if everyone implemented SPF, DKIM, and DMARC it would help enormously. More and more organizations are requiring SPF, DKIM, and DMARC for sent emails, otherwise they're more likely to treat them as spam. It behooves you to get these setup for your organization as soon as possible.

On March 15, 2018 Office 365 implemented some stringent email security changes to the service which caused a tremendous amount of email to go into customer's Junk Email folders. This was because the changes "Junked" emails from senders without SPF, DKIM, and DMARC. The changes had to be rolled back quickly, but were reimplemented a week later with different logic. Read, Anti-spoofing protection in Office 365, to understand some of those changes and how EOP protects you from inbound spoofing and phishing attacks.

SPF, DKIM, and DMARC for Exchange Online

If your organization is using Office 365 you can use SPF, DKIM, and DMARC to protect your email and SMTP namespace. Office 365 provides a DKIM mechanism that is configurable from the Exchange Admin Center. When this is enabled for each SMTP domain, DKIM signs all outbound messages from your tenant. Even if your hybrid organization uses Exchange Server on-prem, but uses Exchange Online Protection (EOP) for outgoing email, all outbound emails can be signed by Office 365's DKIM.

SPF, DKIM, and DMARC for Exchange Server On-prem

If your organization uses Exchange on-premises there are a few options, but none of them are native to the product itself. Usually the best option is to employ an SMTP gateway that provides DKIM signing. This gateway can be a physical or virtual on-prem appliance, such as a Barracuda or IronPort, or it can be a cloud service, like EOP.

Another option is to use the DKIM Signing Agent for Microsoft Exchange on GitHub. This is an Exchange transport agent that signs all outbound emails with a DKIM signature. You start by defining your sending domains, create a public/private key pair, and installing the DKIM signing transport agent. See fellow MVP Jaap Wesselius' article on this for details. After configuring the agent and updating DNS, your Exchange Server will use DKIM signing. Note that you'll need to install and configure this agent on all your Exchange Hub Transport/Mailbox or Edge Transport servers to ensure all your outgoing emails are DKIM signed. You may also need to upgrade the DKIM signing agent after each Exchange cumulative update since the transport stack is subject to change.

Testing SPF, DKIM, and DMARC

There are several SPF/DKIM/DMARC testing sites I use to ensure these mechanisms are set up properly. I particularly like the AppMailDev DKIM test. You just go to the website to get a testing email address, send an email to that address from the system you want to test, and it tells you if your message passes SPF, DKIM, and DMARC in real-time.

SPF, DKIM, and DMARC protected email from Exchange 2016

Talk with the experts at EXPTA Consulting to discuss your messaging and security needs. Improve email delivery and stop email bounces, spam, and phishing attempts. We can help you with your SPF, DKIM, and DMARC implementations. Contact us today!