How does DKIM work when sending emails from multiple sources/servers

authenticationdkimemailspamspf

So if I'm understanding DKIM correctly, it basically is a public/private key type of service. However, how does this work if you send emails from multiple servers/sources? For instance, I have a split domain where I send some emails (under the same domain) from a hosted Exchange server and some from a cPanel shared hosting account. And on top of that, I've allowed some emails to be sent by 3rd parties (billing service, marketing emails service, etc.) so they can send using my domain. Even worse, some of these services don't even provide DKIM support. My SPF records are correct, but I want to get DKIM working as well (since Google right now is marking a lot of my emails as spam and apparently you need to enable DKIM to get things to start flowing smoothly at their end). Any help is greatly appreciated. Thanks!

P.S. If I'm able to enable DKIM on some servers I use, will doing so cause emails sent without DKIM signatures to get flagged? For example, will inbound email servers ALWAYS query my domain for DKIM public key, and then if they don't find a DKIM signature in the header then the email will be potentially flagged or discarded?

Best Answer

Explanation

The purpose of DKIM is to sign message headers and body, enabling validation of the origin of the message and that it hasn't been modified. A better reputation on some spam filters is just a by-product, and not the main reason for implementing DKIM.

For allowing DKIM signing for the same domain from multiple systems without sharing private keys DKIM has selectors (RFC 5376, 3.1): the signature header has a s=someselector tag that is used in the DNS query for the public key, someselector._domainkey.example.com. TXT.

  • As the selector could be anything, it enables you to add the signatures on multiple services as long as they don't use overlapping selector names. Some services have poor implementations of using fixed selector name: e.g. Microsoft 365 always users selector1 and selector2, whereas G Suite allows you to modify the selector and default to google.

  • Using selectors has a disadvantage: a weakness of DKIM is that it can only be used for validating messages that have been signed, but it alone doesn't have a method to tell whether messages should be signed or not: if an email server receives a mail without a signature, it can't check whether the DNS has DKIM keys or not, because it doesn't know the addresses. From this perspective it's also perfectly fine to sign messages from some sources, but leave some messages unsigned, which is what you were asking.

The DMARC is a technology you could use to tell that the messages should be either signed with an aligning DKIM header or pass SPF with an aligning envelope sender. It can also be used for collecting insights on whether messages send from your domain as the From address would be passing DMARC or not, and whether they align using SPF, DKIM or both.

While yagmoth555's answer might be one solution for your problem, and a very suitable alternative, it's not a typical solution. More importantly, for the reasons I've described above, it's not necessary to take that path in order to start implementing DKIM.

Suggestions

  • Enable DKIM signing for the services you can, and remember to add the DNS records.
  • Don't worry about the services that lacks the ability for DKIM signing at this point. You could start suggesting or demanding that they should soon add this functionality. If they get this kind of feedback from customers, they could realize that their competitors might be ahead of them.
  • Add a DMARC policy with p=none and rua=mailto:aggrep@example.com to get reports on how things are going. This enables you to adjust the systems leisurely: you could continue DKIM implementations, switch to systems that supports DKIM or start sending incompatible messages with another From domain. Once all your legitimate mail starts to pass DMARC tests, you could move to a more strict DMARC policy.
Related Topic