Setting up DKIM and DMARC records Part 2

4. Setting up DKIM and DMARC records Part 2 In the second part, the DKIM records for the solution are deployed

Part 2

The Solution

It was decided therefore to separate the corporate – in this case, Office 365 – mail from the bulk mail that would emanate for the SMTP relay service provider would use different DKIM/DMARC records. This, by inference, means that the DNS entries for DKIM/DMARC would need to be in a different DNS zone. The decision was therefore taken to create a child DNS zone such as web.somecompany.com and use that for the bulk email while somecompany.com would be used for normal corporate emails. That way, if the bulk email traffic were to be blacklisted for some reason then the corporate emails would be unaffected.

The Steps

DKIM

DKIM (DomainKeys Identified Mail) publishes the public key of a key pair in DNS so that receiving mail servers can verify that the email has actually been sent – as in signed using the private key of the key pair – by the sender and therefore isn’t spam. The DKIM record itself is of type TXT named “selector._domainkey” – where “selector” is a custom value - and contains the key. The selector can be chosen by you but, in the case of Office 365 custom domain key pairs and for some bulk email providers, the selector will be supplied to you by them. Note that, as with all things cryptographic, the key length used in key generation is variable with longer being better e.g. 2048 bytes is better than 1024 bytes (if you are given a choice).

As a custom domain name was being used in Office 365, a key pair was generated within Office 365 and the resulting public key was added to a DKIM record in the DNS zone for somecompany.com.

In the DNS zone for somecompany.com, a child zone was created called web.somecompany.com. This domain was added to the configuration at the smtp relay provider. A key pair was generated and the resulting public key was added to the DKIM record in the DNS zone web.somecompany.com. As all the mail from the email addresses in the child DNS zone would come the smtp relay providers servers, an TXT record for SPF was also added to DNS. This looked like the following:

v=spf1 include:smtprelaycompany.com -all

Note that you should verify that your smtp relay provider actually offers a DKIM key generation option as some free or cheap ones don’t. It is also worth noting that many ISPs do not offer advanced configuration options such as the creation of child DNS zones in their web interfaces, so you may need to contact their technical support or, as was this case here, move the DNS provision to a different, specialist, hosted DNS service provider that could be configured appropriately.

Anyway, you should end up with a DKIM record in your DNS zone that looks something like this:

v=DKIM1; p=KAMfMA0GCSqTSIb9DQEBAQUAA4GNADCBiQKBgQDfl0chtL4siFYCrSPxw43fqc4z Oo3N+Il964oK2Cp+NZw8Kuvg7iu2Ua3zfbUnZWvWK4aEeooliRd7SXIhKpXkgkwn AB3DGAQ6+/7UVXf9xOeupr1DqtNwKt/sTgC7ZIZyKVLx1HWKleP13UXCD4mabUEb bcBhestrnETKoCg8828wIDAxtY

The DKIM record will normally be of type TXT but it can also be a CNAME especially in a scenario where your email service is hosted - such as with Office 365 - as the sending mail servers will be in a different DNS zone from your public DNS zone. You can also have more than one DKIM record. Office 365, for example, will need two.

Back to the solution. The ecommerce server was then configured to send email via the smtp relay service provider’s server using an SMTP address of mail@web.somecompany.com and the marketing email software was configured to use marketing@web.somecompany.com. Once the DKIM record in DNS in replicated, the DKIM records could now be tested using tools such as MX Toolbox or DKIM Validator.