A quick tutorial covering what is an email disclaimer, how they are used, what industries use them and what are the international laws requiring disclaimers.
If you are reading this post, you probably are in one of two situations. You either know that you need to add an email disclaimer to the bottom of your signature. If so, skip to the more advanced section. Or you know nothing about email signature disclaimers. If so, read on!
An email disclaimer is the small block of text at the very bottom of an email (beneath the signature and the signature banner) that is usually the place the “fine print” legal language. Below you see how EDF Renewables, one of the largest builders and operators of renewable energy projects in the world, applies a confidentiality disclaimer to their emails.
Sometimes companies or associations use it for mission and value-statement messages, like one you see below from the National Association of REALTORS®. (Check out their email signature Case Study).
In a number of industries, any communication to people outside of the company is required to carry a specific disclaimer. This is true for financial services companies, healthcare companies, and other emails in industries that are closely regulated by the government. Different countries, as well, have different requirements on email disclaimers. We list out all the laws affecting disclaimers further down in this post.
There are many reasons why your legal, compliance, security, or business team may need to attach a disclaimer to emails. Some of the most common high-priority uses include:
Acknowledge and disclaim that content of an email is subject to a specific law (HIPAA for emails that contain health data, for example)
Note: This blog post does not claim to be providing legal advice. You should check with your attorney or compliance team to understand whether your company needs disclaimers.
There are several ways to apply disclaimers to outbound emails. (Note: internal emails usually don’t need disclaimers but it can be good to apply them anyway in case those emails are forwarded). All of the methods have strengths and weaknesses. Most organizations that use disclaimers set up a way to uniformly stamp all emails with approved disclaimers at the email server level. This ensures the disclaimers are applied to all outbound emails and cannot be removed by senders. It also helps maintain a coherent email layout and design; manual changes in font size or colors of disclaimers, for example, can make otherwise beautiful email signatures look amateurish and ugly.
This is by far the worst option. It is possible to ask all of your employees to manually configure email signatures that you send to them. Most email systems (Gmail, Outlook, AppleMail) have a signature setting function. Someone from IT or Compliance can add those manually to each individual users’ email client. This is like pulling teeth. Worse, whenever the disclaimer needs to be updated, you have to repeat the process all over again. We strongly recommend you not try this. It is error-prone and never works at scale.
Many companies try to add email signatures by asking their employees to install plugins on their email clients (Gmail, AppleMail, Outlook). The plugins call back to a server which can centrally admin and distribute email disclaimers and place them in the signatures of any email while it's being composed.
Using plugins for disclaimers generally leads to pain and suffering for all the same reasons that plugins consistently fail to deliver a good signature experience in general.
For all of the above reasons and more, we strongly recommend that you not use plugins for email disclaimers.
A third option is deploying a disclaimer solution that works at the email server level and “stamps” an email at the server level. This ensures that every outbound email gets a disclaimer and removes any responsibility form the client level or the email users. For IT teams, they only have to manage one system, which is much easier and more efficient; whenever a disclaimer needs to be changed, IT can make the change once and deploy it universally. Stamped disclaimers are an excellent choice.
That being said, the reliability of the stamping technology is crucial. If your stamping system goes down at the server level, then your emails will be out of compliance. If your stamping system is also your email signature system, then you will lose all signature capability and be forced to ask users to revert back to creating signatures in their emails. Many email signature and stamping technology products were built before cloud computing and were never designed for true multi-tenancy. These types of products tend to not only crash but also to work very slowly, delaying email delivery and sometimes generate intermittent outages that are particularly hard to troubleshoot. Lastly, not all stamping solutions work on all platforms and clients. Many only work on Windows solutions. Most do not work on newer email clients or on AppleMail. Very work on emails sent out of new sales enablement tools like Outreach.io.
If you go with a stamping solution make sure to ask the following questions:
The final option is using a disclaimer system that works at the server level but offers more flexibility by automatically appending a markup snippet at the end of each email. When that snippet hits the server, the server reads the call for a disclaimer and adds one. However, users can adjust the markup snippet if admins choose to give them this option.
Alternatively, that field can be hidden and added to every email. This option tends to be a more modern software design and is more likely to be cloud-based; most of the companies offering this type of disclaimer solution built their technology in the cloud computing era with newer languages (NodeJS, for example) that can take advantage of the cloud and deliver faster performance and lower downtime. In addition, these systems make it easier for users to add a snippet of markup code to call for a different disclaimer. Unlike stamped disclaimers, which are entirely dependent on information from the employee directory (ActiveDirectory, AAD, G Suite), markup-based disclaimers can actually be modified at the client level to fix errors in employee directory data. This is crucial when you are dealing with errors in the employee directory listings that may not reflect, for example, when an employee has moved one office to another in a jurisdiction that requires a different disclaimer. While these cases may be relatively rare, they tend to be difficult to fix. The best markup-based disclaimer tools take care of this problem.
This being said, all of the questions you ask of a stamping solution you should ask of a Markup-based solution as well. You can even compare the responses side-by-side.
For better or for worse, as your business grows you will need to think about how to tackle disclaimers. Even if it’s adding a nice message at the bottom of emails requesting confidentiality, a disclaimer is a good idea. If you are in a regulated industry where disclaimers are required, then weigh the four options above carefully and ask detailed questions of the disclaimer technology vendor or service provider before you agree to deploy. We would also recommend you talk to a few of their customers (ideally, not reference customers so you can get an honest opinion). You usually find customers by looking up which companies are using disclaimers on a service like Builtwith.
Disclaimers are like air, you don’t really notice it when its around and all is well. But when something goes wrong, not having enough air or good air is no fun at all. Likewise, having an unreliable disclaimer solution can be an operational and legal hassle - one that might even cost really money if regulators issue a fine for non-compliance. Choose wisely and disclaim well.
If you want to learn more about how email signature disclaimers can be reliable, automated and painless, get a demo of Opensense.