6

I am currently gathering requirements for a small (hopefully) project of migrating from SendGrid to Mandrill as a transactional email service provider. We have been using SendGrid for close to 3-4 years now and average about 5k-10k emails per day. We have SPF and DKIM records configured appropriately and, as a result, have very low bounce / spam rate and quite a good reputation as a sender.

There has been a decision to move to Mandrill and now I must ensure the migration happens smoothly with as few service interruptions as possible, thus starting the approval / reputation process all over again.

I know for SPF entries, it's possible to add multiple items, so, for the time being I'll keep both for SendGrid and Mandrill. However, I'm not 100% sure about DKIM entries. Some services recommend CNAME entries while others suggest TXT entries.

This leads me to wonder if it's possible to have a CNAME DKIM entry for one service and a TXT DKIM entry for the other. I'm curious about the effects of such a change. Is the vetting/verification of this entry wholly dependant on the intermediary / recipient? Or, do they generally see both and just pick the first one?

Essentially, what I'd like to do is find some way to slowly transition from one service to the next with as little interruption as possible. We have had issues before with ISP blacklisting and I'd very much like to avoid that.

Thank you so much for your time!

Wilhelm Murdoch
  • 173
  • 1
  • 6

3 Answers3

3

Multiple DKIM records are a viable option.

DKIM keys and records should be replaced periodically. During the update process the old record remains for a period of time to allow verification of in transit messages. This can also allow re-validating received messages.

I don't see any value in using CNAME for DKIM records. It will only add additional DNS lookups before the required TXT record is read. DKIM records should be added each time the key changes. This requires new TXT records and might require new CNAME records as well.

BillThor
  • 27,354
  • 3
  • 35
  • 69
  • 1
    Bill that is how sendgrid and O365 handle key rotation, the customer has a cname, sector._domainkey.example.com. http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx – Jacob Evans Nov 23 '15 at 12:44
  • @JacobEvans Use of CNAMES allows the user to rotate two names, and works if you have multiple domains or sending hosts using the same keys. The TXT records still need to be updated. This come at the cost an additional DNS lookup for each client that wants to verify a signature. For a single signer, it is simpler to publish the key as a TXT record rather than a CNAME and a TXT record. – BillThor Nov 25 '15 at 01:18
  • Your grammar, I'm fully aware of how dkim works – Jacob Evans Nov 25 '15 at 01:52
  • I should've marked this as solved a few months back. Thanks again! – Wilhelm Murdoch Feb 28 '16 at 23:18
2

To answer your question.

CNAME for the DKIM record is just a method for the ESP to handle key rotation without having access to your DNS or requesting you to change your DNS TXT Record every time they rotate the key.

sector._domainkey.example.com. IN TXT "DKIM KEY"

sector._domainkey.example.org. IN CNAME sector._domainkey.example.com.

If you add the TXT Record, either the provider does not rotate keys for you or you are the one rotating keys.

You can also setup multiple key selectors per service, and run sendgrid and mandrill in parallel, this also lets you test mandrill before switching to them. Note: There is no limit to the number of DKIM sectors, there are limits to the number of DNS lookups for SPF (10).

Jacob Evans
  • 7,636
  • 3
  • 25
  • 55
0

This is one of the primary uses of the selector field. It's very common to see ISPs have domain key records like the following -

201604._domainkey.mydomain.com

201604 refers to the year & month the key was created in this example (but could be anything really) and would be set as the selector when signing outbound emails.

When replacing the key, or migrating somewhere else, you can then just create a new DKIM record (e.g. 201705._domainkey.mydomain.com). Any emails going through the old system would still reference the 201604 selector, and emails from the new system will reference the new one. Both DKIM records can obviously exist in DNS without any issue and recipient servers will query the one specified in the headers of the email.

This is how most providers change their dkim keys regularly without any email being incorrectly signed or verified during the dns/server updates.

USD Matt
  • 5,321
  • 14
  • 23