Scaling Out (above 200,000 emails/day)

A single DeepFilter server is recommended for traffic of up to 200,000 emails per day. Actual capacity varies with the hardware and the traffic profile. In organisations that run above this volume permanently, the preferred approach is to install several independent DeepFilter servers and distribute the incoming load across them, rather than growing a single server. This page explains how scaling out is put together and what falls outside its scope.

caution

Scaling out is a load distribution method; it is not a high availability solution. There is no shared state, automatic failover or mutual backup between the servers. When one server goes out of service, the records that landed on it cannot be reached; only the sending side's retry behaviour comes into play. When the servers are paired through Multi-Server, some screens can show them together; this is a live read, not shared state or failover.

When it is needed

Consider scaling out in the following situations:

Situation	Assessment
Daily email volume below 200,000	A single server is enough; a second one is not needed
Daily volume permanently above 200,000	Split the load onto a second server
Short-term campaign/seasonal peaks	Review the hardware resources first (CPU, RAM, disk)
Separate email infrastructure in different locations	A separate server per location is a natural choice

Before deciding on a volume increase, update your disk plan as well: every 10,000 daily emails requires at least 50 GB of additional disk for a year of log retention. This calculation is made separately for each server, based on the share of traffic it will take.

How it works

The method relies on the behaviour of the SMTP protocol itself. When more than one MX record is defined for a domain with the same priority value, sending email servers choose among these addresses and the traffic spreads out roughly evenly over time. No additional load balancer appliance or software is needed.

The setup consists of three steps:

1. Install the servers. Install each server from scratch, using exactly the same steps as a single server installation. Each has its own hostname, its own IP address and its own setup wizard.
2. Write the DNS records. Create a separate A record for each server and define the MX records with equal priority. Request a separate PTR record for each IP and add all server IP addresses to your SPF record.
3. Repeat the same configuration on every server. Domain definitions, the delivery destination, block/allow lists and scanning preferences are entered separately in each server's own panel.

An example DNS setup:

mail1.alanadi.com.   IN A   203.0.113.10
mail2.alanadi.com.   IN A   203.0.113.11

alanadi.com.   IN MX 10 mail1.alanadi.com.
alanadi.com.   IN MX 10 mail2.alanadi.com.

alanadi.com.   IN TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ~all"

tip

If you give the priority values different numbers (10 and 20, for example) the load is not distributed; the server with the lower value takes all the traffic and the other is tried only when the first does not respond. If you want distribution, the values must be equal.

Limits

These points are by design and cannot be changed through configuration. Confirm that they are acceptable for your organisation before going live.

Topic	Behaviour
License	Each server requires a separate license
Quarantine	Not shared. An email is quarantined on whichever server it landed on
Quarantine retention period	Works separately on each server; by default email is deleted automatically after 30 days
User digest	The user receives the quarantine notification from the server that processed the email
End user portal	To see a quarantined email, the user signs in to the portal of the server that processed that email
Management	Each server has its own management panel; settings are made separately on each one
Reports and analytics	Each server reports only its own traffic; servers paired through Multi-Server can be viewed together on the Email Traffic, Dashboard and SMTP Queue screens (reports stay per server)
Backup	Each server is backed up and restored separately
Failover	There is no automatic failover or state sharing between the servers

note

In practice, quarantine not being shared means this: a user may receive quarantine notifications from two different servers, and performs the release through the portal that the relevant notification came from. Inform your users about this in advance.

caution

Quarantined email is not kept indefinitely. The default retention period is 30 days; once it expires, the email is deleted automatically. The period can be changed from the management panel (minimum 1 day, no upper limit) and is set separately on each server. Keep the retention periods of the servers at the same value; otherwise users will run into an email that is still accessible on one server but has been deleted on the other.

Operating recommendations

• Apply setting changes to all servers on the same day. Configuration differences between servers cause the same sender to pass on one server and be quarantined on another.
• Perform version updates separately on each server as well, and keep the versions at the same level.
• Track reputation separately for each server's IP address; one IP being blacklisted affects only the deliveries leaving that server.
• When you add or remove a server, do not forget to update the SPF record and the PTR requests.
• By pairing your servers through Management → System → Multi-Server, you can monitor each other's connection and health status, receive an email when a server stops responding, and view the servers' data together on the SMTP Queue, Email Traffic and Dashboard screens. Pairing does not change load distribution, licensing or quarantine behaviour; settings are still made separately on each server. For details, see the Multi-Server page.

For network, port and DNS details, see the Network Requirements page.