One question I see a lot is “How can I let 3rd party vendors send as our organization using DKIM?” It’s a lot easier than you think.
The trick is in the selector. Per RFC 6376: To support multiple concurrent public keys per signing domain, the
key namespace is subdivided using “selectors”.
Implementing this is pretty straight-forward, so let’s get started.
Suppose you have your existing DKIM infrastructure handled by Office 365/ EOP.
When sending a message through Office 365/EOP, the header of the message is stamped with the required DKIM fields.
Check out the sample header in the received message below. Note the s=selector1. This tells the receiving server to check : selector1._domainkey.contoso.com.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qwJgpoXgR3MRDrSVO91kT+tYSpE//LjikNGicqlKjU0=; b=FnK8HjJFfEKHMq5EoIGJVzty4w+v7uE0UmQVFrVYr348e4tqfE66U/pZanlNfS7guhj2T5g5sqva7w1Wc1/+NOlC6CEBMrQiuFVDo0Akk8narhX9r9xs99Yniv…
In your organization’s external DNS, you have a CNAME record of that selector:
selector1._domainkey.contoso.com canonical name = selector1-contoso-com._domainkey.contoso.onmicrosoft.com
Following the DNS pointer…
In the Office 365 DNS is something like this text record with the public signing key:
selector1-contoso-com._domainkey.contoso.onmicrosoft.com text =
“v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBFDKKLKLKGNADCBiQKBgQDLODjPzMtm1EVPXU3OgPWgW+ABPqDtoHLnzmyTXdl+abC5M13ZovMLIrTbEJTT…
The receiving server can now run it’s calculations against the message knowing the public signing key.
So you can see where we are going with this.
If you want a 3rd party vendor authorized to send as your company and apply a DKIM key to each message, you have a few options:
Create a unique selector CNAME – different from the one you use for messages coming from your organization – in external DNS that points to the 3rd party vendor’s DNS which contains the public DKIM signing key. This is similar to what Office 365 tenants do.
or
Use a unique selector and create the DNS text record that has the public DKIM signing key provided by the vendor. Remember: They are generating the messages, so the 3rd party vendor has the private key, you do not!
Each method will work and it’s really up to you. Note that if you decide to create the text record in your DNS with the public key signing key, it will break DKIM for those messages if the 3rd party vendor decides to change the private signing key that they hold.
I think it goes without saying that the one thing you don’t want to do is provide “your” private signing key to a 3rd party vendor and have them sign messages using your “regular” selector – the one you use for messages that actually do come from your domain. At least I wouldn’t recommend that.
Once this is all setup, then it’s up to the 3rd party to set the selector correctly in the message header. So, if EOP is stamping “selector1” on all outbound messages, the 3rd party vendor can use anything allowed by RFC except selector1.
As an example, headers received from the vendor, sending as you, may stamp it with:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com; s=contosoBULK
Receiving servers will now check the text record: contosoBULK._domainkey.contoso.com and depending on how you set it up, obtain the public signing key or get redirected by CNAME to another DNS.
This also works great for subdomains – i.e. have the 3rd party send as mail.contoso.com and setup the DKIM records for that specific SMTP domain.
There is no real limit to the number of selectors one domain can support, just ensure they are unique to each sender and are configured properly so receiving systems can correctly access the DKIM public signing key.
With the advent of so many cloud services, I suspect just about every organization has at least one 3rd party sending as their SMTP domain, so get your DKIM ( and SPF records!) right. I hope this helps understand that process a little bit better.
EHLO, Ergo Sum 