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 “anyuser@mailserverguru.com” 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.
Responses