Whether you already implemented all ten steps above or just some of them, there is one thing that you should always do: make your security visible to your users.
Almost every Internet user nowadays knows terrible stories of people being phished and cheated, their computers being infected by viruses or being held captive by ransomware, due to a malicious email message they received. This can even lead people to distrust their Internet connectivity and their email service, and if you make a living out of selling connectivity and/or email services, this is a huge long-term problem for your survival.
This is why you need to invest in security, and you also need to make efforts so that your users know that you do so.
This can be a matter of consumer relations: you could advertise the deployment of new security features on your website, publish blog posts, send out newsletters, etc. But this is also a matter of education; your users need to behave in a secure manner, and you have to explain them again and again how to do. Any investment you make in preventing trouble, by the way, will yield much bigger return in reducing future damages, customer service costs and compensation.
More specifically, if you adopt the technologies that we listed, there will be situations in which some emails will be more secure than others. If you check for DANE when sending out messages, for example, the destinations that support it will have a much higher degree of security; same if you use end-to-end encryption for destinations that support it.
On traditional email clients, in the lack of proper standards, this is almost impossible to do; but nowadays most people use webmail systems, and on them it would be possible to deploy security markers and other icons showing the user the degree of security associated with each destination address.
Several email providers do exactly that: whenever they send a message to a specific destination domain, they keep track of the features of the outgoing SMTP connection, and if they are secure, the next time that a user composes an email to that destination, they will show appropriate security markings (similar to the HTTPS lock).
This can be true for incoming messages as well, and it is even easier to implement, since you already know how it was sent to your server: you could show security markings if you received the message over a secure connection. However, you have to be careful about one thing: an encrypted connection does not give in itself any guarantee over the true identity of the sender/recipient of a message. You would just fool the user into a false sense of security if you declared a message secure only because it was sent over an encrypted connection.
This is what happens with HTTPS: the HTTPS “green lock” shown by most browsers does not just declare that the connection is encrypted, but also that you can be sure that the server on the other side corresponds at least to the declared hostname, and possibly, through third-party verification, to a specific person or company. The same thing should happen with email, thanks to DANE.
