Jun 11 2019 01:00 PM
Our group supports many agencies with in one tenant and with one sending domain. That said there are many outside vendors that send as "ourdomain.com". Is there a limit to the number of DKIM entries and keys that I could add to our DNS? Without compiling all the research I am guessing we have over 40 different vendors sending email as "ourdomain.com"
Jun 11 2019 01:50 PM
@Michael Wehking You can only have one DKIM per domain. If external vendors are spoofing your domain, DKIM will not work for you. You will need to use just SPF records.
Jun 11 2019 02:10 PM
Jun 12 2019 04:57 AM
@Juan_CUMC Thats not really true. DKIM is governed by selectors. Each third party sender could use a unique selector for the same domain and that would work.
Jun 12 2019 04:59 AM - edited Jun 12 2019 05:02 AM
Thats what SPF macros are for @Michael Wehking .
But really you arent hostage to that limit. The RFCs allow multiple strings in the SPF record
Example:
Jun 12 2019 05:50 AM
@andydavid1True but I don't believe SPF is going to check 40 to 50 addresses. I think 10 is the limit.
Jun 12 2019 06:55 AM
@Michael Wehking 10 DNS lookups. You mitigate that by not doing includes. Instead expand out all the allowed sending IPs and add those to the SPF record instead.
Jun 13 2019 01:44 PM
This is correct, we do it constantly. We created a subdomain off our main domain to keep things organized like email.yourdomain.com. This does not affect the header from value on the message which would stay as yourdomain.com. (alignment for dmarc compliance). Each vendor would be given their own selector value. s=vendor1 vendor2... etc by you. It has to be unique for each vendor but is an arbitrary value you can make up.
When THE VENDOR generates the dkim key, THE VENDOR would specify the values you give them: s=vendor1 d=email.yourdomain.com.
the dns record you create in your dns becomes vendor1._domainkey.email.yourdomain.com. You would then take the dkim key that they generate and then sent back to you and import it into your domain record in your dns. When the message are sent from the vendor, the dkim key contains the s=value d=value you told them to use when they generate the key. The recipient of the email looks up the value after the d= to get to the doman and the the txt record using the s= value. The key pairs are verified and the mail is accepted.
**Note you can simplify the management of the dkim key by letting the vendor host the key in their own dns instead of you hosting it in your dns. You would get from the Vendor the cname value of where they are storing the key in their dns, then you would add that as a cname to your dns record as a cname instead of the key. I would recommend the second scenario if possible.
Jun 13 2019 01:49 PM
@john nixon Agree. CNAME is the best option.
Jun 13 2019 01:57 PM
Thanks Andy. That answers my question. One other item that crossed out mind is if we go down this road then we will be relying on the Vendors to have messaging Hygiene. The other option we are considering is to create sub address in DNS vendor1.yourdomain.com, vendor2.yourdomain.com, etc. then have the mail routed back through O365 EOP for hygiene.
Michael
Jun 14 2019 12:17 PM
With the possibility of showing off my ignorance. Usually dkim is for external to external impersonation of your domain or authentication. How would you get the mail to route through o365 when it originates from an external sender and is going to an external sender. Assuming that you can, does o365 put a limit on the number of messages you can route through their system per day?
Jun 15 2019 12:19 AM
@john nixon I do believe that if it routes through MS then it will hit the 10K external cap for externally sending. If its the same sender.
Jun 19 2019 06:02 AM
We have a few 3rd parties that send info internal, those would be the ones I was thinking of. You are right about the external sending however. Also agree with the 10,000 cap.
Jun 19 2019 06:03 AM
Do or should SPF records need to be created for all these sub domians?