There are multiple aspects to your question:

- What are your inbound SMTP encryption standards?

- What are your outbound SMTP encryption standards?

- What are your client encryption standards (web, smtp, pop, imap, eas, ews, mapi)?

- What are your DKIM encryption standards?

As to the cipher-suite details, I think all of that tuning needs to occur at the operating system level.   More detailed questions should be a support ticket.

Encryption Strategy:

There is good reason to separate inbound gateway, outbound gateways, and mail store functions onto three separate machines.   Our design:

- Inbound SMTP:   We accept some weak protocols and plain text.   If a sender cannot support optimal protocols, I do not know if he will try again in plain text, or give up entirely.   Neither of those options seem like an improvement.  So I monitor the encryption of my accepted messages and only tighten restrictions after weak configurations are no longer needed.  This approach is only appropriate for Inbound SMTP, so we receive traffic using an inbound gateway server that accepts no other protocols other than internal System Administrator connections.

- Outbound SMTP:   We require encryption.  Traffic for destinations that cannot accept will bounce, and thereafter all traffic for that recipient will be routed to secure web relay.   SmarterMail cannot do mandatory outbound encryption and does not provide secure web relay functions, so these features are implemented in a commercial product acting as outbound gateway.

- Web Traffic:   Is routed through IIS on Windows and Kestrel on Linux, so encryption depends on your operating system or the web server.   I am currently reconfiguring our IIS URL Rewrite rule to distinguish between internal and external traffic, so that we can then restrict external access from unwanted user agents and also restrict external access to some HTTPS sub-protocols (MAPI, XMPP, EWS).

- Other client protocols:  We do not allow external client access using IMAP, POP, and authenticated SMTP, so these are not an issue for us.   If you do allow them, I expect the encryption configuration to follow the operating system settings.

- Inbound DKIM:   A long time has passed since DKIM was extended to support new elliptic curve, but no one is using it.   For about two years, I have been logging every DKIM signature on every accepted message.  I mostly see RSA-256, and rarely RSA-128 as encryption protocols -- nothing else.   Someday, the world's DKIM-based defenses may collapse as a result, but mercifully we are not there yet.

- Outbound DKIM:  You must provide dual signatures if you want to embrace the better ciphers.    SmarterMail only does RSA signatures at present.   To be ready for post-quantum on outbound DKIM, you will need to find an outbound gateway product to provide the secondary signature.  But don't expect many recipients to understand them.