Of the many pieces that make a successful website, one of the commonly overlooked is its ability to send email. This isn’t just an oversight by project managers or those tasked with requirement planning for the site, but rather all levels of the technical build. Email has been around for so long (about as long as the modern internet), that most users just assume it’s built in and just naturally works.
The truth is, email servers can be hosted in a variety of ways, with different requirements and capabilities. They can be given multiple purposes (hosting/storing email, managing calendars, sending marketing materials, and even more recently, sending text messages/alerts).
The basic email server is typically made of multiple components. The ability to send messages through Simple Mail Transfer Protocol (SMTP) and the ability to receive/process incoming messages (POP/IMAP). When it comes to your website, the functionality which is most commonly needed is outbound only, or SMTP, which will allow you to let your end users know when they’ve completed a task or need a friendly reminder.
One area to note, before we get too much further, is to watch for a few common misuses of email services. First, always make sure you have a proper “return” email address. Many email servers/services will block your mail if they believe it is coming from an email address which isn’t valid (such as a no-reply@somedomain.com address). Next, ensure all email sent has the ability to “unsubscribe” to ensure end users who did not require notification can remove themselves. Finally, avoid utilizing the same email service for both marketing materials as well as end user notifications (password resets, etc). Marketing material has a higher probability of being labeled as spam, meaning you’ll want to ensure the most important messages/usability functionality of the site is unaffected by this potential issue.
Since mail services don’t have to be directly hosted without your website’s environment, this opens up a variety of options. Some of these may already exist within your current network infrastructure, while others may be new/added functionality. Depending on the requirements of your abilities to send email, it can greatly affect which solution may be right for your new/existing web site. Let's break down a few of the most common email solutions utilized by web sites today.
Common email solutions utilized by websites
Localhost server
On most web hosting environments, if you are able to install software, you’ll have the ability to add an email service. These are typically very small installs and provide a quick way of adding email sending abilities to your website. The software is typically free to use and can be installed by your hosting provider or development team. However, there are some strong drawbacks. First, because this email will be coming from an IP address which other mail servers have not seen before, it will likely be "greylisted" or "blacklisted" quickly.
The process of getting your mail server approved by most commonly used email servers (Google, etc) can take time and persistence from your hosting team. Second, this type of installation requires technical knowhow in the utilization of Mail/SMTP services, which may be beyond the capabilities of your developers.
Finally, these are not typically setup in a failsafe/redundant manner. If the mail server fails, your team will need to monitor it to ensure service can be restored.
| Pros |
Cons |
| Typically free to install/utilize |
Mail will be Greylisted/Blacklisted easily because the web server will not have any authority with other mail servers (most commonly an issue with Yahoo and other large free providers) |
| |
Requires technical knowledge to manage mail queues and ensure mail is sending properly. |
| |
Not typically setup as a failsafe/redundant environment. If the mail service stops, all new mail needing to be sent is rejected and not stored for later delivery. |
Company Mail Server
Another common method of managing your outbound email is via an existing company email infrastructure. These servers can vary from a locally hosted Exchange server to a cloud-based solution such as Office365. Most companies already have this infrastructure setup and prefer to utilize it because they already have an "email" administrator on staff.
If you do proceed with this method, you’ll need to ensure your webserver is “whitelisted” to ensure it is allowed to send email without restrictions (commonly referred to as "relaying"). The drawbacks can be similar to the Localhost method with the added risk of affecting your existing ability to send company email to end users, if the website causes the mail server to be "blacklisted."
| Pros |
Cons |
| Most companies utilize an email server of some type (Internally Hosted, Office365, Google Business, etc) |
If mail is not vetted prior to sending, it can cause your mail server to be flagged as a SPAM address. This in turn would affect your business email accounts. |
| |
Most company mail servers have relay limitations ("From addresses", Messages Per Hour limits, etc) |
| |
If server is hosted on-site, would require opening the network to allow mail traffic from web server) |
Dedicated Mail Server
If you will be sending a lot of email and need the ability of excellent logging and delivery control, setting up a dedicated email server in your new hosting environment might be for you. This is the most complex build and will require the most oversight/maintenance but will allow you to monitor email being sent and determine where errors may be occurring. It also allows you to control your monthly email sending costs because you are paying for the server and not on a per-email basis. There are similar drawbacks to the previous options; however, when it comes to the initial "greylist" and "blacklist" and if you don’t plan to send very large volumes of email, it may be a huge overbuild. These servers used to be very common for large scale websites, but have faded in popularity over time in favor of a more cloud-based solution.
| Pros |
Cons |
| Allows full control over email queueing, processing and delivery |
Can take time for new server to build "authority" and avoid Greylist/Blacklist |
| Provides a set monthly cost for email services (hosting fees are typically fixed) |
Requires technical ability to manage email services (SMTP, AV, Spam Filtering, etc) |
| Ensures administrators have full control over start to finish communications (mail is never on a 3rd party platform) |
If only a single server is configured, can result in low redundancy |
SMTP Service
The last option is typically the preferred option for most of our larger clients. This involves utilizing a cloud-based solution for sending your outbound emails. There are large, well-established providers which have years of experience and have already gotten past the initial graylist/blacklist growing pains. These systems have multiple layers of redundancy and can handle a variety of email volumes to ensure they are the right fit for most situations. In addition, they can offer added capabilities for your web developers to utilize the email services in a more "programmatic" manner via API services. Trust me, your developers will appreciate the flexibility.
If you are already hosting with a cloud provider such as Amazon Web Services, the ability to utilize their Simple Email Service (SES) may be included in your contract. The only drawback to this approach can be some limitations on the type of email being sent (for example, Amazon SES does not want users to send marketing material using their service). Lastly, if you have concerns about the type of email you are sending (such as order information, or secure information) and need to ensure the information is encrypted from start to finish, this option will be the wrong route for you to go.
Some examples are:
- Amazon's SES
- SendGrid
- Postmark
| Pros |
Cons |
| Typically utilizes large cloud services which feature layers of redundancy |
May have restrictions on the type of mail sent to users (marketing emails vs client notifications, etc) |
| Costs are typically lower than hosting a dedicated mail server |
Mail can be rejected with limited information on why it wasn't accepted for sending |
| Does not require an IT team to manage the service full time |
From a security perspective, the mail message may be stored and handled by servers which do not meet your organizations security requirements. |
| May allow use of API calls to create email messages (can be more secure and developers will appreciate it). |
|
Conclusion
In the end, it really depends on the type of email you are sending, what is in its contents and how much technical support you have in your current infrastructure. There are a variety of solutions out there and most of them will work at their most basic level. When you start running into the question of "did my users get this email" or "is the email working on our site right now", you may need to start looking into the more advanced options. In any case, please feel free to reach out to us if you have any questions or would like help evaluating while solution is right for you.
