Setting up DKIM and DMARC records Part 1

The scenario

Another interesting one where the solution ended up being more complex than initially thought, it was determined, after a successful migration from an inhouse Exchange based email system to Office 365, that there was now a need to send a large amount of marketing type emails and that an ecommerce website – hosted elsewhere – would also soon be ready for deployment. This ecommerce site would, by its nature, send a lot of emails for such things as order confirmations. Accordingly, an SMTP relay service was selected and all that would have been needed, in a simple world, was as a simple change to the SPF record in DNS. However, it would be necessary to avoid the possibility that the emails from the non-corporate email servers would get the corporate domain – somecompany.com in this scenario - blocked or blacklisted so it was also decided to implement the additional DKIM and DMARC records – an approach beloved of governments and the myriad agencies - in DNS to help achieve this.

Just for information, if passing an SPF (Sender Policy Framework) check was all that was needed then a TXT record in the DNS zone for somecompany.com like the following would have done the trick as it would include the Office 365 email servers and the smtp relay service servers.

v=spf1 include:spf.protection.outlook.com include:smtprelaycompany.com -all

However, implementing DKIM and DMARC in a situation where two different email servers would be sending your company mail proves more than a bit challenging as the DKIM record requires the publication of the public half of a cryptographic key pair.

Initially, the choice came down to one of three options:

1. Relay via Office 365
2. Generate a key pair in Office 365 and use that key pair in the DKIM set up for the bulk email provider
3. Generate a key pair in the bulk email provider setup and use that in Office 365.

Whilst it was possible to relay via Office 365, it was not a viable choice as there is a limit on how many emails can be sent in a day and emails can only be relayed in the context of a user account which would mean that several additional Office 365 accounts would be needed to cover use on the website and with marketing emails. Transferring private keys about is a bad idea all round as, if the smtp relay provider were to be compromised, your private key could be misused to sign spam emails which would likely to adversely affect your corporate reputation and get your domain blacklisted or blocked.