SMTP Load Balancing for Outbound email

In this design, we’ll look at how to set up email load balancing for outbound emails.

If we have thousands of emails to send every hour, we’ll need a load balancer to distribute the outbound email across multiple machines. This is typically found in ISPs and large corporations.

During outbound email delivery, we used to scan the mail to check if they are spam or included any viruses with it. If the recipient servers get spam or viruses from us we could get blacklisted as a result.

Email scanning is a time-consuming process, and if we are to scan thousands of emails per hour, we’ll need several computers, or else sending will be impractically delayed.

Why load balance outbound emails?

The main purpose is to spread the load of outbound emails to multiple machines, so that outbound email scanning and sending don’t cause any noticeable delay.

How does this Design Work?

Here, Mail Sending Process is very simple, Our Load Balancer’s hostname is “smtp.mailserverguru.com”, and there are three upstream SMTP servers named “mailx1”, “mailx2” and “mailx3”

1. clients will send mail to “smtp.mailserverguru.com”.
2. The load balancer will receive mail, and send it to the one of upstream SMTP servers for sending.
3. The upstream mail server will send to the intended recipient servers.

Another outbound email scenario:

this is the practical picture of the ISP environment, where multiple organizations taking SMTP service, all are sending their mail to the ISP’s SMTP Load balancer to send to the internet.

In this article, We’ll look at how to set up or integrate spam filtering applications during inbound email communications.

During anti-spam system deployment, we can use both open-source and proprietary technologies. Both have advantages and disadvantages.

A good level of skill is necessary to administer and debug open-source systems. Proprietary systems are expensive, but they are user-friendly and easy to manage. Alternatively, we can use third-party hosted solutions.

The deployment strategies outlined here are not equally applicable to all sizes of businesses. It relies on a variety of factors, including the size of the business, the volume of email, the number of users, and the investment.

Some of the deployment scenarios are as follows:

1. On-premise deployment, If we want to control our systems, we can purchase a Spam Filter Appliance and deploy it with our existing servers. Most of the small business demands can be met with the virtual appliance deployment. But if we are deploying for a large business and the mail flow is too high, it would be advisable to use specialized hardware for this or multiple servers will be required to handle the email load.

2. Deploying at Local Provider, We will be able to set up a Spam Filtering Server/Appliance at Our Local IT Service Provider, because we are already connected to them and using their IT services. Server co-location and VPS rental services are typical business for them, and we can deploy our own server or VPS there as our local system. We can also use the provider’s Hosted Spam filtering solution. These services are typically subscription-based, and subscription-based solutions are viable for small organizations, due to the high cost it is not efficient for large organizations with a high volume of mail.

3. Cloud-based deployment, Cloud providers have a plethora of offerings, including hosted filtering solutions and a variety of deployment choices, including physical appliances, virtual appliances, managed VPS, and dedicated hardware. Hosted Filtering Solutions are entirely maintained by the Provider and are based on a subscription model.

Let’s explore the deployment’s design and requirements at these three locations.

Design-1,  On-Premise  Spam Filter Deployment

On-premise deployment for large enterprises comprises of many different types of hardware. This is the most simplistic design for on-premise deployment, only to get the idea. “mx1.mailserverguru.com” can refer to a physical server, a physical appliance, or a virtual appliance in this case.

When we can deploy On-premise:

1. When we are managing our Servers and we have enough technical expertise.
2. Our organization is big, and we have a high volume of emails. no rented solutions are cost-effective for us.
3. We are a Service provider, and we need to scan millions of customer emails.

How This Design will Work:

1. our organization’s domain name is  mailserverguru.com
2. We deployed a server (either physical or virtual) to scan Incoming Emails, the server’s hostname is “mx1.mailserverguru.com”
3. at the domain’s DNS server, we set an MX record and pointed to this server’s IP. (for example 202.191.120.1)
4. Now, any mail sent to “[email protected]”  will come to this server.
5. The server will scan the email for spam & viruses and deliver the clean mail to the Primary Server (mailer.mailserverguru.com)
6. Filtering server can be multi-homed with 2 LAN cards, one for a Public Network to receive mail from the internet and another for delivering mail to the local Mail server with a Private IP.

If we understand the concept, we may utilize the same server to scan different domains’ mails by referring to this server as the MX at the DNS’s. We can transport emails to their relevant servers by configuring “email routing.” We can also load balance here by using different servers as scanners and load balancing through DNS RR; you can read more about how incoming mail load balancing works in my other blog post here.

Design-2,  Spam Filter Deployment at the service Provider end

When we can deploy at the Local Service Provider:

1. We prefer co-location of the server because, we can manage the applications and services but not the Physical Host, Power and Cooling.
2. We do not want to invest on Hardware, that’s why Renting a VPS from the local service provider.
3. Our organization is small, we have few accounts and low volume of Inbound email, that’s why using their Spam filter.

How This Design Will Work:

1. If we co-locate our physical box at the ISP or rent a VPS from them, our design will work like an on-premise deployment. Simply set the MX record of our domain’s DNS to the IP address of our co-located server, however, that server cannot be multi-homed like before, and it must route mail to our organization’s mail server. Our mail server must be configured with a Public or Private IP to receive mail from the co-located server.

2. If we use an ISP’s mail server or a hosted mail scanner, we must point our MX record to their server’s hostname/IP address so that they can receive our domain’s mail and transmit it to our local server after scanning.

Design-3, Spam Filter Deployment in the Cloud

When we can use Cloud Hosted Spam Filter:

1. We do not want to invest on Hardware, that’s why Renting a VPS from the cloud provider.
2. we don’t want to manage spam filter, we choose Hosted solution which is managed by the Cloud Provider.
3. We liked the payment method for the hosted service, bulk, volume based or pay per mail etc.
4. We liked Other facility provided by the Provider like Redundancy, High availability, archiving etc.

How This Design will Work:

1. VPS rented from Cloud Provider will work like the on premise deployment. We need to Set the MX record of our Domain’s DNS to the Cloud VPS IP, VPS must route mail to our Organizations Mail Server, Our mail server must be configured with a Public IP ( as we are not directly connected with them) to receive mail from ISP.

2. If we Use Cloud hosted Scanner, We must Set our MX record points to the respective scanning systems Hostname/IP, after scanning they will deliver to our Mail Server.

Why load balance inbound emails?

if we have thousands of emails to receive per hour, one single server may get exhausted by queuing and processing all these emails.

by deploying multiple MX servers we can evenly distribute the inbound email load to all of them. MX servers at the front, are responsible for email protection also, the email filtering process is time-consuming.

If there is a heavy load like spam attacks, mail delivery will delay, and email missing can occur, to overcome these situations, we must load balance the inbound flow to the other servers for quick processing and smoother delivery.

Design1, Load balancing with MX Record

Email load balance with DNS round-robin

in the above diagram, we have three MX servers mailx1, mailx2, and mailx3. For DNS round-robin to work, we have to declare all of them with the same MX priority. if MX records have the same priority values, DNS will deliver the server IPs in a round-robin fashion. whenever any sender tries to find our mail server, it will ask our DNS server, and the DNS will answer with all these 3 servers in a round-robin fashion, later we will see this in practice.

Let’s say these servers’ IPs are, 202.191.120.1,  202.191.120.2, and 202.191.120.3. and we want to receive emails for the domain mailserverguru.com. We have to setup the DNS A and MX record’s this way:

mailx1             IN           A               202.191.120.1
mailx2             IN           A               202.191.120.2
mailx3             IN           A               202.191.120.3

@             IN           MX         10           mailx1.mailserverguru.com.
@             IN           MX         10           mailx2.mailserverguru.com.
@             IN           MX         10           mailx3.mailserverguru.com.

Configure Email Routing

After setting up the DNS Part, we need to configure the Email routing to deliver the inbound emails to the respective mailbox server because all user’s inboxes are in the mailbox server. In the 1st diagram, we received mail for a single domain. all the MX servers routed mail to the backend mailbox server.

Email Routing for multiple domains

in this 2nd diagram, we are receiving mail for multiple domains, now all the MX servers must make a routing decision based on the recipient’s domain name or recipient email address. Here, we can see all incoming servers are delivering emails based on the recipient domain to a different server.

Later I will show you how to configure the email routing on the servers.

Thanks !!

In this design, we are going to talk about incoming mail server failover or MX failover. We intend to protect email loss during receiving. we need two mail servers for the design. from the DNS we will designate one as the primary or master server and the second one as the secondary or backup MX. if the primary server goes down, the secondary server will receive all emails.

When a sending server sends an email to a receiving server, it selects the domain’s primary MX server. normally email delivery will fail if the primary server is unreachable. But if there is a backup MX, the email will be received by the backup MX server. The adoption of Backup MX will eliminate the single point of failure scenario for inbound emails.

One thing to note, backup MX will not hold any mailboxes so it cannot deliver mail to inboxes, rather it will store mail to its queue and wait for the primary mail server to come alive, when available, it will deliver all emails to the primary one for the inbox delivery. Here on the diagram, we declared two servers at the DNS as the primary MX and Backup MX.

How this Design Works:

Design Preparation:

1. here, we have two servers named   “mailx1.mailserverguru.com” and “mailx2.mailserverguru.com” Both must have public IP and be connected to the internet.

2. both systems must be able to receive mail from the internet, that’s why we have to set up an MX record at our DNS server. we have to assign MX with different Priority values, though, we can set the same priority to both servers but that is for load balancing scenario, I will describe that in the latter article, here in this design, MX priority is the main issue, let’s say

mailx1.mailserverguru.com Priority  10
mailx2.mailserverguru.com Priority  20

This Priority value means, that whenever the sender’s mail server asks for our domain mail server address, our DNS server will respond with the above 2 server names, and with the priority value, it will deliver the mail to the lowest priority server, this is the rule for the mail servers, if the primary server is down, then the sender will deliver mail to the higher priority mail server.

Let’s See Another Primary and Backup MX Scenario:

This design is more practical than the previous one because most organizations do not provide two dedicated servers for mail server deployment. In this design, our backup MX server is at an ISP environment, most ISP companies or hosting providers provide email services or we can rent a dedicated VPS from them to store our emails for this temporary period.

Mail Storage at Backup MX Server:

Regarding storing mail at the backup server, we have two options, either we can configure Backup MX to store email in its queue, or we can store emails in its storage directly if we want to store email on Backup MX storage, we have to configure the server with a configuration called “Domain Catchall Address”, which will receive all email and store on a single common email address for the whole domain, all recipients mail will be saved on this single mailbox at the backup MX server, in this case, the backup MX server will not try to deliver mail to primary one when alive, it will be primary servers responsibility to pull all email from that remote mailbox and deliver to the local users inbox. In Linux Environment this type of setup is done with two known email programs named “fetchmail and procmail”, I will try to show you later this configuration.

In this scenario, we are planning to set up our email environment with multiple servers, each one dedicated to a specific task.

Our email operation has two main parts: receiving and sending. We receive emails from the users and we send emails to various destinations.

We are separating these two tasks to be performed by two different servers.

Please See the Topology Below:

Why Separating Incoming and Outgoing Server ?

1. Single server creates “central point of failure”, if the server goes down, all email operation will be down A single server creates a “central point of failure,” meaning that if the server goes down, the entire email system goes down with it.

2. If we don’t need to deal with a lot of email, we can usually use a single email server to handle everything. However, if we have a large amount of email to process, it is advisable to divide the incoming and outgoing operations with dedicated servers to reduce email processing time, whether it is for incoming or outgoing email.

3. Another major reason for the split is the issue of blacklisting; if our single server is banned, both incoming and outgoing operations would be hampered; but, if our outgoing server is blacklisted, our incoming operations will not be hampered.

Server Preparations:

Incoming mail server configuration:

1. To receive email we must configure our DNS server first. here, our incoming mail server “mailx.mailserverguru.com” is the only MX for our domain, so any mail sent for [email protected] will come to our incoming server.

2. To receive email, server must listen on 25 port to communicate with other mail server. On this server we have to install any MTA like postfix, sendmail, exim etc.

3. As we have only two servers, incoming mail server must be configured to store email also, local users will retrieve mail from this server, that’s why we have to install POP/IMAP service too.

4. Our user will use webmail also, so we have to install webmail software in this server.

5. Before receiving any email, we can configure our incoming server to scan all emails. If we can scan email prior receiving, users will get less spam. Though it is not mandatory for mail servers, but recommended.

Outgoing Mail Server Configuration:

1. Our outgoing mail server is only for sending emails. It will work as the smtp server only, or relay server for the users.

2. Server has to listen on 25 port to receive local users email. so we must install MTA like postfix, exim, sendmail etc..  here. Before sending any mail to outside, server will check the authenticity of the user, either sender is permitted or authenticated person to send mail by using our server.

3. Before sending emails, we should filter for spam and viruses, if we try to deliver spam emails or virus attached, it has greater chance to get blacklisted, recipient server will drop or deny our emails. so we better install an email scanner for outgoing email filtering.

So, here we are using two server separately for distinct functions, we can also make more complex setup with two servers only, we will move forward to those step by step.

Thanks !!

Email server setup, for an organization depends on many things like, the organization’s size, business requirements, volume of email etc.

An emal server can be of a standalone machine. or it could be a complex distributed one.

Here, we will discuss the email server setup requirements, specially the design and deployment requirements to configure a complete email server with a single box.

This setup is ideal for small organizations, where the server is being used for all the basic operations mentioned below.

Email server can be deployed as internet-facing or behind a firewall. both scenarios have different preparations, advantages and disadvantages. we will try to describe the requirements for both scenarios. Now, lets talk about email server’s basic operations, an email server tipycally performs these basic operations:

1. Send/Receive Emails
2. Provide Email Storage
3. Provide Webmail Service
4. Spam & Virus Filtering

So, Our configured email server must provide the above services. Email server setup can be done in both Linux and windows platform. here, we will describe linux server requirements for example.

To setup an email server on Linux, we need to follow these basic steps:

1. Install the Preferred OS
2. Assign static IP
3. Assign Hostname as FQDN.
4. Install MTA
5. Install POP/IMAP Service
6. Install Webmail.
7. Install Email filter App, and Finally
8. Configure DNS A and MX record for the domain.

Now, Lets see the detail diagram and explanations of the two email server scenarios.

1. Internet Facing Email Server

In this diagram, we deployed our server as internet-facing, with a public IP (202.191.120.1). the server hostname is “mailer.mailserverguru.com”. this mail server is performing the basic operations mentioned above.

Email flow and delivery:

3. Users are pulling email to their Outlook by connecting to the POP/IMAP service. POP/IMAP service will retrieve email from the inbox and delivers to user’s desktop.

4. Users can access the webmail to send/receive emails from the web browser.

5. Users will send email through this server, it will receive email from the local user and deliver it to the destination server.

6. during send/receive all emails are scanned & filtered by the email scanner installed at the server, this is an optional service because sometimes organizations liked to take email filtering services from third-party providers.

2. Email Server Setup Behind Firewall

In this scenario, Our server configuration has slight change. Now it has two Lan cards, one for the local network and the other for the public internet. Email will be received by the public ip from the internet and private ip will be used for the local email receiving.

design Advantage:

The key advantage of this design is that local users can send/receive email to the server with a private IP address, even if the internet connection is down. They can also mail each other within the office without using the public internet because they will have wire-speed access to the server. To set up the email server with this design, we must set up all of the services to listen on all of the server’s available IPs.

design requirements:

To access the server with the same hostname from both public and private network, we can setup local DNS server for name resolution with private IP, as we already mapped hostname with public IP in the Public DNS.

Email flow and delivery:

email flow and delivery will be the same like the previous diagram. only it is capable to send/receive email using the private network.


Thanks !!