While Vini7 is right about DKIM not being required, I'm afraid he is incorrect as to why.
First, understand that spam filtering is not a technique that is described in an RFC. This means that pretty much everyone does something different, resulting in a large fragmentation about what possible solution to adopt.
First, pretty much all systems works as a Bayesian decision-making tree with a few shortcuts built-in: you start with a base probability that a mail is spam (called credence) and feed that mail through a series of tests that will update that probability. In the end, depending on the probability you end up with, the mail is rejected, accepted but flagged for further vetting (placed in the spam folder) or accepted as legitimate. The shortcuts are some of the tests that can, on their own, have the mail rejected altogether.
What test are used, exactly, vary from domain to domain but here are the most frequently used ones:
- IP reputation check: this is typically done at SMTP level before the mail is even transmitted. The receiving server will check the "reputation" of the sender system IP address against one or more online databases and will typically (but not always) reject connections coming from IP that have been sending spam recently altogether.
Headers check: The headers that comes with he message are checked for consistency. This is where DKIM and SPF work: if setup properly, it can allow the receiving system to know if the sender email is valid or not. Again, depending on how everything is setup, it can result in an outright rejection or simply update the credence (positively or negatively).
Content analysis The full content of the mail is analyzed. How it is done varies a lot but, basically, this step typically updates the credence one way or another.
Rule-based filtering This is usually a last step where a user can specify keywords, senders or other properties of the email that will tell the system to treat it as ham, spam directly or update the credence.
(there are plenty of other tests that are performed in some situations and domains. I couldn't possibly list them even if I knew them all. Just expect some of them to be really, really bonkers).
After all check have been evaluated and, unless the mail has already bee rejected by a shortcut rule, the final credence will be compared with configured value: under a specific threshold, it will be rejected. Between this value and another threshold, it will be redirected to the spam folder and higher than that it will be treated as legitimate.
Some system have a last step: the user can manually mark a message as "ham" or "spam" and the system will use that information to update its analysis engine: it will attempt to learn from the result of its estimations.
So, how do you optimize the chances of your mail not being sent to the spam folder?
First, be sure to have a "good" IP reputation for your outgoing SMTP gateway. You can easily check the reputation of your IP using SMTP blacklist checker services (for instance, this one or this one). If your IP is in a blacklist, make sure you understand why (and, if possible, fix it).
Second, make sure your infrastructure is 100% clean: many system have weird or dated rules that will, for instance, reject your mail if the sending system does not have a reverse DNS entry or if that reverse does not match your SMTP MX record (the fact that this is idiotic does not prevent people from doing it).
Third, use all possible ways for your recipient to check that your mail is legitimate: if possible, use SPF and DKIM. If you can't do both, do at least one. As you mentioned, digitally signing your mails will sometimes help. Avoid sending the same mail to a large number of recipients. make sure that your return path (the email address that would be used if someone replied to you email) is somewhat valid (at least make sure the domain resolves and that it has an MX record in your DNS).
When all else fails, contact the admins of the recipient's domain and ask them for assistance: it is their job to make sure legitimate email is not misqualified.
