Third party email vendors and DKIM

Copper Contributor

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"

13 Replies

@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.

@Juan_CUMC 

 

SPF records have a limit of 256 characters. Not near enough for all the vendors we have.

@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.

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:

https://kb.isc.org/docs/aa-00356

@andydavid1True but I don't believe SPF is going to check 40 to 50 addresses. I think 10 is the limit. 

@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.

@andydavid1 

 

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. 

 

@john nixon Agree. CNAME is the best option. 

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

 

@Michael Wehking 

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?

@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.

@john nixon 

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.

 

Do or should SPF records need to be created for all these sub domians?