Multi-Server

If your organization runs more than one DeepFilter server (for example servers deployed for scaling out, or servers in different locations), you often notice that a server has stopped only when email flow is disrupted. Multi-Server pairs your servers with each other securely; each paired server checks once a minute whether the other is reachable and sends an email to administrators when an outage occurs.

On this page, a node means a DeepFilter server paired through Multi-Server. Paired nodes see each other's connection and health status: reachability, latency, software version and clock difference. In addition, the SMTP Queue, Email Traffic and Dashboard screens can show the data of several nodes on one screen, to the extent the other node permits (see Shared View and Permissions). Pairing does not change any setting; no settings, quarantine or user data are shared between servers, and email bodies and attachments are never transferred.

You reach the Multi-Server screen through Management → System → Multi-Server.

note

The Multi-Server tab and all pairing operations are available only to users with the Global Admin role; the Access: Global Admin only badge appears at the top right of the screen.

caution

Multi-Server is a monitoring and shared view link; it is not a load distribution, high availability or automatic failover solution. When a node goes down, the other does not take over its work. For load distribution across several servers, see Scaling Out.

Scope and Limits

Topic	Behavior
Visible information	Reachability, latency, version, clock difference and last error reason of the paired node; with view permission, SMTP queue, email traffic and Dashboard data
Settings	Not changed and not synchronized. Each node's settings are configured separately in its own panel
SMTP Queue	The queues of nodes with view permission can be followed in one list; retrying, deleting and bulk deletion on a remote node are possible only if that node allows remote actions
Email Traffic	The email traffic of nodes with view permission can be followed in one list; the remote node's rows are read-only
Dashboard	The indicators of nodes with view permission can be followed together; counts are added up and rates are recalculated
Email bodies and attachments, quarantine, reports	Not shared; the quarantine and report screens on each node show only that node's data
License	Each node runs with its own license; pairing does not affect licensing
Failover	None; nodes do not take over each other's work
View	Each node sees only the nodes it is directly paired with. Pairing A–B and B–C does not connect A and C
Number of nodes	A node can pair with at most 5 nodes (6 including itself)
Software version	Nodes running different versions can pair; the operations available with a node are limited to those both nodes support (see Version Compatibility)
Central connection	Nodes talk to each other directly; no data goes to the DeepFilter central service or the internet
Server without pairing	No effect at all: no additional port is listened on and the firewall is not changed

What's on the Screen

The screen has three tabs: Overview, Pairing and Connection & Security. The badge next to the title shows the total number of nodes, including this node, and the limit (e.g. 2 / 6 nodes).

Overview

The Live topology section shows this node (labeled This node) and the nodes it is paired with; the screen refreshes every 30 seconds. Colors show the result class: green is healthy, orange is a warning, red is an error; a node that has not been checked yet or whose monitoring has stopped appears gray. The legend lists Healthy, Warning and Error. If there is no pairing yet, the tab shows No paired nodes yet with the Add node and Join a node buttons.

Clicking a paired node opens a detail panel: Address, Observed IP (only if the connection comes from a different address, with a NAT badge), Status, Version, Latency, Last seen, Last error, Fingerprint and Paired. Problems with the node are listed in colored boxes in the panel. In the Permissions section below the fields, you change the permissions this node grants to the other node and read the permissions the other node grants to this node (see Changing permissions). The Test connection button tests the connection on the spot; the Remove pairing button removes the pairing.

In the topology, clicking the node tagged This node opens a card with Fingerprint, Internal IP, External IP, Version and Paired nodes; the Add node button on the card starts pairing. Internal IP is the primary local address the server uses when sending network traffic; if the server also has addresses on other network interfaces, +N appears next to it and hovering over it lists those addresses. External IP is the address the server appears with when it goes out to the internet, and is taken from the Server IP Address on the Blacklist (RBL) Monitor screen. This value is refreshed by that screen's check, which runs every four hours, or with Manual Check; if the server's outgoing address has changed, the new address appears after the next check. If the value has not been determined yet, the field shows — and hovering over it shows Not known yet. If the node has never been paired, the Fingerprint field shows Created on first pairing.

A node's status is one of the following:

Status	Meaning
Connected	The last check succeeded.
Connected · high latency	The connection works, but latency is above 100 ms. No email is sent.
Awaiting first check	Pairing has just completed; the first check runs within a minute.
Unreachable	Three consecutive checks failed; an email was sent to administrators.
Identity changed	The node does not respond with the identity verified during pairing. The connection is not used.
Version mismatch	The node runs a version that is incompatible with this node; an update is required.
Monitoring stopped	The node has not been checked for more than three minutes; the information shown may be outdated.
Unpaired by peer	The administrator of the other node removed the pairing.
Not recognized by peer	The other node does not recognize this node as its peer.

Warning banners appear at the top of the tab only when there is a problem: a paired node is unreachable, a node's identity has changed or it runs an incompatible version, the other side removed the pairing or does not recognize this node, the clock difference exceeds 60 seconds, health checks are not running (Monitoring stopped), the address of a paired node is blocked on the Firewall page (Paired node address is blocked), the firewall is not running (Firewall (firewalld) is not running) and the firewall zone does not match (Firewall zone mismatch). The Show node button on node-related banners selects that node in the topology.

Pairing

Used to pair a new node. The tab first offers two options: Add node (a code is generated on this node) and Join a node (another node's code is entered). The selected flow proceeds step by step: Code → Connection → Done. If the number of nodes is at the limit, the Add node option is disabled and hovering over it shows Limit reached (6 / 6 nodes). While a code generated on this node is waiting to be used, an open code banner appears above the Overview and Pairing tabs. For the steps, see Pairing Servers.

Connection & Security

Shows a read-only summary:

• Node port: Listening, Not listening, or Not listening while unpaired when there is no pairing.
• Allow list: The addresses of paired nodes allowed in the firewall.
• Firewall: Active (with the zone name), Not running, or Unknown if the status cannot be read.
• mTLS, Fingerprint (of this node), Alert threshold, Alert recipients and Access.

There are no editable settings on this tab.

Network and Security

Paired nodes talk to each other over port 9441/TCP. This port is separate from the management panel (9443) and user portal (9445) ports; even if those ports are exposed externally, node-to-node communication does not use them.

On a server without pairing, 9441 is closed. The port is listened on only when a pairing starts or when a paired node exists.

Temporary opening during pairing. The node that generates the code opens port 9441 for at most 10 minutes (the code's validity period) and only to the IP address of the joining node. The joining node also opens its own port 9441 only to the address of the node that generated the code. Once the connection is established, the pairing has 10 minutes to complete. If pairing is not completed, is cancelled or times out, the temporary opening is removed automatically.

Permanent rule once pairing completes. When the pairing has completed on both sides, each node adds a permanent 9441 allow rule to its firewall only for the other node's address. The rule is written for the address the other node's connection actually comes from (the observed IP). When the pairing is removed, this rule is deleted; when the last pairing is removed, port 9441 is closed completely.

Mutual TLS and fingerprint. Nodes connect to each other with TLS 1.3 and mutual certificates. Trust is based not on a certificate authority but on the SHA-256 fingerprint verified during pairing. The pairing code is bound to the fingerprints of the two nodes; the fingerprints are verified automatically through this code, and a server that does not know the code cannot insert itself in between. The verified fingerprint is stored on both nodes and checked on every later connection. If a node later responds with a different certificate, the connection is not used and an "identity changed" alert is sent.

Data exchanged. During health checks, only the node identity, node name, software version, supported operations, the permissions granted to the other node, clock and uptime information pass between nodes. When the shared view is used, only the data shown on the screen is read from a node with view permission at the time of the request: on SMTP Queue, queue records (sender, recipient, subject, delay reason, waiting time and delivery attempts); on Email Traffic, traffic rows (sender, recipient, subject, score, action result, sender IP address and delivery information; symbol details excluded); and on the Dashboard, indicator values (counts, top sender lists, sender and subject of the latest emails, server resource usage and uptime). No email body, attachment, quarantine, user or settings data is sent.

Points to watch in your network:

• 9441 must be open in both directions. If there is a firewall other than DeepFilter's between the nodes (corporate firewall, cloud security group), 9441/TCP must be opened in both directions, only between the node addresses. Do not expose 9441 to the internet.
• The address you enter is both the allowed address and the callback address. The node that generates the code connects back to the joining node at the address you entered. Therefore the two nodes must see each other at the address they connect from (the same local network, or a route without address translation). If the connection comes from an address other than the one entered, a NAT badge appears in the detail panel and in the allow list.
• If the firewall (firewalld) is off, DeepFilter cannot restrict the port; port 9441 listens openly while a pairing exists. In this case node access is restricted at the application layer: only requests that carry the paired node's fingerprint and come from its address are accepted. A warning banner appears on the screen for this case. Keeping the firewall on is recommended. If you turn the firewall on after pairing, the allow rules for the paired nodes are added automatically within a minute at most.
• Firewall zone: Rules are added to the server's default firewall zone. If the network interface is in a different zone, a banner reporting that the firewall zone does not match appears on the screen and the connection may fail.

Pairing Servers

Pairing is performed on the panels of both servers at the same time. Below, the node that generates the code is called A and the joining node B.

Prerequisites

• Two administrators signed in as Global Admin on the two servers (or one administrator signed in to both panels) must be ready.
• 9441/TCP must be reachable in both directions between the two servers (see Network and Security).
• The IP address at which A sees B, and the address (IP or server name) B will use to reach A, must be known.
• B's address must not be on the block list of the Firewall page on A, and A's address must not be on it on B.
• The clock on both servers must be correct (see System → NTP).
• No changes should be made on the Firewall screen of either server during pairing; reloading the firewall removes the temporary opening and the pairing times out.

Steps

1. On A, open Management → System → Multi-Server and, on the Pairing tab, select Add node.
2. Enter B's IP address in the IP address of the joining node field and click Generate code. A 12-character pairing code and a 10-minute countdown appear. The code is shown only once, on this screen; if needed you can generate a new one with Regenerate. The information note below the form summarizes the effect of pairing: "Connection and health status, queue and e-mail traffic rows (including subjects) and Overview data are visible; bodies and attachments are not shared; settings are not changed."
3. On B, open the same screen and select Join a node. Enter A's address in the Peer node address field and the code in the Pairing code field, then click Verify code. If you entered a server name as the address, the resolved IP address is shown on the screen. The server name is converted to an IP address only at this moment; the pairing continues with this IP address and is not updated even if the server name's DNS record changes later.
4. While the connection is being established, A shows Peer node is connecting… and B shows Connecting…. Once the connection is established, the code countdown stops; A connects back to B to confirm that both directions work, and the two nodes verify each other's fingerprint automatically through the code. Completing pairing… then appears. These steps take a few seconds and require no further action.
5. Pairing completes on both sides together: both screens show Pairing completed, and a Sunucu eşleştirildi (server paired) email is sent to the administrators of both nodes (see Connection Monitoring and Notifications). The Close button returns to the Overview tab; the new node is briefly highlighted in the topology.
6. If the pairing cannot be delivered to the peer server, the warning The pairing could not be delivered to the peer server. and a Retry button appear instead of Completing pairing…. Try again with Retry within 10 minutes after the connection was established.

Verification — how you know it succeeded

• Both screens report Pairing completed, and the other node is added to the topology on the Overview tab.
• The administrators of both nodes receive a Sunucu eşleştirildi email.
• Within a minute, the other node's status becomes Connected; its version and latency appear in the detail panel.
• The other node's address appears in the Allow list on the Connection & Security tab.
• A pairing record is created on the Audit Logs screen of both servers; the record stores the user who started the pairing on that server and both fingerprints.

Cancelling an open code

While the code generated on A is waiting to be used, a banner that stays even after the page is reloaded appears above the Overview and Pairing tabs; for example An open pairing code exists (Joining server: 192.0.2.20, time left 08:45). The banner's Cancel code button invalidates the code immediately, without asking for confirmation, and removes the temporary 9441 opening made for the code. The Cancel button on the pairing screen also ends the operation; the administrator on B can likewise cancel joining with Cancel.

note

The pairing code is single-use and valid for 10 minutes. If the code is entered incorrectly 5 times it becomes invalid and you need to generate a new one. The code is never written to any log.

Connection Monitoring and Notifications

After pairing completes, each node checks each of its peers once a minute.

Event	What happens
Pairing completes	A Sunucu eşleştirildi (server paired) email is sent to the administrators of both nodes. The email contains the other node's name, IP address, short fingerprint, time and the user who performed the pairing on that node.
3 consecutive checks fail (about 3 minutes)	The status becomes Unreachable and a single critical alert email goes to administrators. No new email is sent while the outage continues.
The node responds again	The status becomes Connected and a "reachable again" email that includes the outage duration is sent.
The node returns with a different version after an update	Instead of the "reachable again" email, a "back after update" email is sent; the old and new versions appear in the subject and body.
The node responds with a different identity	The status becomes Identity changed and a separate critical security email is sent. The connection is not used.
The node responds with an incompatible version	The status becomes Version mismatch and an informational email is sent; this email is sent at most once every 24 hours for the same node.
Latency exceeds 100 ms	The node appears orange. No email is sent.
Clock difference exceeds 60 seconds	A warning banner appears on the screen. No email is sent.
Health checks are not running	A node that has not been checked for more than three minutes appears gray as Monitoring stopped; if checks have not run for more than five minutes, a Monitoring stopped banner appears on the screen. No email is sent.

Emails are sent to the administrator alert addresses on the Notifications screen and to all Global Admin accounts. The email subjects are in Turkish:

• Sunucu eşleştirildi: <node name> (server paired)
• Düğüm erişilemiyor: <node name> (node unreachable)
• Düğüm yeniden erişilebilir: <node name> (node reachable again)
• Düğüm güncelleme sonrası geri geldi (old version → new version): <node name> (node back after update)
• Düğüm kimliği değişti: <node name> (node identity changed)
• Sürüm uyumsuz — güncelleme gerekli: <node name> (version mismatch, update required)

If a node's restart during an update takes longer than 3 minutes, you may receive an "unreachable" email followed by a "back after update" email. This is expected behavior.

If the other node has reported that it removed the pairing, or has responded that it does not recognize this node, no "unreachable" email is sent for the access errors that follow.

To turn off the unreachable, reachable-again and version mismatch emails, switch off the Node Unreachable toggle on the Management → Notifications screen (see Notifications). The toggle is on by default. While it is off, checks continue and the status on the screen is updated; only the email is not sent. The Sunucu eşleştirildi and Identity changed emails are security notifications; they are not tied to this toggle and cannot be turned off.

Version Compatibility

When pairing and at every check, nodes report their software versions and the operations they support to each other. Nodes running different versions can pair and monitor each other; the operations available with a node are limited to those both nodes support.

• Version difference: If one node supports an operation the other does not, the node appears orange and a Version difference warning in the detail panel lists the operations unavailable with that node. Update the node that lacks the operation.
• Version mismatch: If one of the nodes runs a version that is fundamentally incompatible with the other, pairing ends with The other node runs an incompatible version — update required. If an already paired node enters this state, its status becomes Version mismatch, a banner appears on the screen and an informational email is sent. Update the node running the older version; after the update, the status returns to Connected automatically.

If a node running an incompatible version cannot be reached at all, its status becomes Unreachable and the outage email is still sent.

The same rule applies to the shared view: a node running a version that does not support the relevant feature (queue, email traffic or Dashboard) appears disabled in that screen's server selector, with a Version difference mark, and cannot be selected; the tooltip asks you to update the server that is missing the feature.

Shared View and Permissions

You can follow the data of paired nodes from one place on the SMTP Queue, Email Traffic and Dashboard screens. In a Global Admin session, and when at least one paired node exists, a server selector appears on these screens (in the header on SMTP Queue and Email Traffic, next to the time range buttons on the Dashboard). The selector lists each node by name with a color mark; the All row selects every node that can be selected. When a single node is selected the selector shows that node's name; when more than one is selected it shows All. Your selection is remembered in this browser separately for each screen. For how to use the screens, see SMTP Queue, Email Traffic and Dashboard.

On the shared screens, each node is shown with a colored tag carrying its name; in the narrow card lists of the Dashboard, a small dot in the node's color appears instead of the tag, and the node's name appears in the dot's tooltip. This node's color is always blue; hovering over its tag shows the This server tooltip. A paired node's color is assigned when the pairing completes and does not change while the pairing lasts; no two nodes get the same color. Because colors are assigned in each node's own panel, the same node may appear in different colors on two different panels.

Permissions

The node where the data resides decides how its data can be used on the other node. Each node keeps two permissions separately for every node it is paired with:

Permission	Default	What it allows
Can view my data	On	The other node can see this node's SMTP queue (sender, recipient, subject, delay reason, waiting time, delivery attempts and the top queue fillers), its email traffic and its Dashboard indicators.
Can perform remote actions	Off	The other node can retry or delete selected emails in this node's queue, clean up by sender and delete all emails matching a search.

• Permissions are directional: the permission A grants to B is independent of the permission B grants to A. The other node cannot turn a permission on by itself.
• A node whose view permission is off appears disabled in the other node's server selectors and cannot be selected.
• The queue rows of a node with remote actions off are visible in the list but cannot be selected for an action; a lock icon appears on the row's server tag and the bulk deletion buttons are disabled for that node.
• The permission check is performed again on the node where the data resides for every request; a permission change is reflected on the other node's screens within one minute at most.
• Actions on a remote node are performed only on behalf of a user with the Global Admin role; the node where the data resides checks this separately for every request.
• On Email Traffic, the remote node's rows are read-only regardless of permissions; actions such as recall and blocking are performed from that node's own panel.
• Email bodies and attachments are never transferred to the other node.

Changing permissions

Permissions are changed on the panel of the node whose data is shared, by a user with the Global Admin role. When a pairing completes, viewing starts on and remote actions start off.

Steps

1. On the Management → System → Multi-Server screen, open the Overview tab.
2. Click the node you want to grant or revoke permissions for. The Permissions section at the bottom of the detail panel contains the Can view my data and Can perform remote actions switches; hovering over their names shows their scope (Queue, traffic and Dashboard data and Retry and delete in the queue).
3. To turn viewing on or off, change the Can view my data switch. The change is saved immediately without a confirmation.
4. To turn remote actions on, switch on Can perform remote actions. The Allow remote actions? dialog reminds you that the other node can retry and delete messages in this server's queue; confirm with Allow or close it with Cancel. Turning remote actions off does not ask for confirmation.

Verification — how you know it succeeded

• A short notification appears when the change is saved (for example mx2: remote actions enabled or mx2: viewing disabled). If mx2: permission could not be saved appears, the switch stays in its previous position; try again.
• The change is recorded on this node's Audit Logs screen, together with the user who made it, as Multi-server: paired server permissions changed.
• On the other node's panel, the read-only line under the Permissions section of the same node's detail panel shows the new state within one minute at most (for example On the other server: viewing on · actions on). If remote actions were turned on, the lock icon on this node's tag disappears on the other node's SMTP Queue screen.

Remote actions on the SMTP Queue

• Retry and Delete Selected run on the node where each email is. If the selection contains rows of a remote node, a confirmation dialog opens; when deleting, if a remote node has more than one email, the dialog asks you to type that node's name.
• Clean up in the Top Queue Fillers panel (clean up by sender) and Delete All Matching, which appears above the list when you search, also work on remote nodes. On a remote node these actions require the Can perform remote actions permission; if it is off, the button appears disabled and hovering over it shows Remote actions are disabled on the peer server.
• The Null sender (bounce notifications) row in the Top Queue Fillers panel cannot be cleaned up on a node running an older release: the confirmation dialog shows invalid request on that node's row and no email is deleted there. Once the node is updated, the action works.
• For bulk deletion, the confirmation dialog first shows the number of emails to be deleted on each node, then asks you to type the name of each node involved. Deletion runs in the background on each node; progress is reported and the number actually deleted is shown when the job finishes. There is no upper limit: all emails waiting in the queue that match the sender or the search at the moment the confirmation dialog opens are deleted. For the steps, see SMTP Queue.

caution

Emails that enter the queue after the confirmation dialog opens are not deleted on any node; run the action again for the new arrivals. The deletion on a node can stop itself because of an unexpected excess; in that case only that node is affected. For details, see SMTP Queue.

Logging and notification. Viewing and actions performed remotely do not send email notifications; they are recorded on the Audit Logs screen of both nodes:

• On the node that holds the queue, actions are recorded with the name of the user who performed them and the IP address of the node the request came from (for example Alex Smith (192.0.2.10)) as Queued mail retried, Mail deleted from queue, Queued mails cleaned up by sender or Queued mails matching filter deleted. Bulk deletions create one record when the deletion starts and one when it finishes; the finishing record carries the number of emails actually deleted. For an email deleted remotely, the same name and IP address also appear in the Deleted by field of the Email Traffic row details.
• On the node that started the action, a Multi-server: queue action run on a paired server record is created.
• Queue, email traffic and Dashboard views are not recorded one by one but as 10-minute summaries per other node and screen, as Multi-server: paired server viewed this server's data (summary).
• If the other node's name changes, the new name is reflected on the screens within one minute at most and a Multi-server: paired server name changed record is created. The name you are asked to type in confirmation dialogs is always the current name.

Remote actions and reads use the same 9441/TCP mutual TLS connection established during pairing; no additional port is opened.

Removing a Pairing

A pairing can be removed unilaterally from either side; the other side's approval is not required.

Steps

1. On Management → System → Multi-Server, open the Overview tab.
2. Click the node you want to remove and click Remove pairing in the detail panel.
3. In the Remove pairing? dialog, confirm with Remove pairing. The dialog reminds you that a new pairing code is required to reconnect.
4. Do the same on the other node's panel.

Verification — how you know it succeeded

• The Pairing removed notification appears; the node disappears from the topology and from the Allow list on the Connection & Security tab.
• If it was the last pairing you removed, Node port shows Not listening while unpaired.
• If the removal notification reached the other node, its status there becomes Unpaired by peer; the other node stops checking this node and does not send outage emails. If the notification did not arrive, the other node may show Not recognized by peer or Unreachable; remove the pairing there as well.

Removal takes effect immediately: trust and the firewall rule are removed at once and the other side is notified. To reconnect, a new pairing is required.

If a Server's IP Address Changes

A pairing is established with the IP addresses the nodes had at the time of pairing; these addresses cannot be updated afterwards. Even if a server name was entered during pairing, the pairing uses the IP address resolved at that moment; updating the server name's DNS record does not move the pairing to the new address. If the IP address of one of the paired nodes changes, the pairing is removed on both sides and pairing is done again from scratch.

For this reason the Network tab does not allow an IP address change while the server is in a pairing. If you are going to change a node's IP address from the panel, follow this order: first remove the pairing on both nodes (see Removing a Pairing), then change and confirm the IP address on the Management → System → Network tab, and finally pair the nodes again with steps 2–4 below. The symptoms below appear when the IP address is changed outside the panel (for example from the server console or the virtualization platform).

Because the nodes cannot reach each other after the IP address changes, the pairing removal notification does not reach the other side. For this reason, the administrators of both nodes remove the pairing in their own panels.

Symptoms

• About 3 minutes after the IP address changes, the node becomes Unreachable and a Düğüm erişilemiyor: <node name> (node unreachable) email is sent to administrators. This is usually seen on both nodes.
• If the other node's firewall is off, the node whose IP address changed shows the other node as Not recognized by peer, and no email is sent on this node.
• On the node whose IP address did not change, the Address field in the detail panel shows the other node's old IP address.

Steps

1. On both nodes, open the Overview tab on Management → System → Multi-Server, click the other node and remove the pairing with Remove pairing in the detail panel (see Removing a Pairing). If the pairing is removed on only one side, the new pairing ends with This server is already paired.
2. If there is a firewall other than DeepFilter between the nodes, open 9441/TCP in both directions for the new IP address. The new IP address must not be on the blocked list on the other node's Firewall page.
3. Pair again from scratch as described in Pairing Servers. On the node that generates the code, enter the current address in the IP address of the joining node field; on the joining node, enter it in the Peer node address field. You can see a node's current addresses on that node's Overview tab, in the This node card (Internal IP, External IP).
4. Set the permissions again. In a new pairing, permissions start with their default values: Can view my data on, Can perform remote actions off. Even if you had turned off viewing or turned on remote actions in the previous pairing, these settings are not carried over to the new pairing; set them again on both nodes with the Changing permissions steps.

Verification — how you know it succeeded

• Both screens report Pairing completed and the administrators of both nodes receive a Sunucu eşleştirildi email.
• Within a minute, the other node's status becomes Connected.
• On the node whose IP address did not change, the other node's new IP address appears in the Address field of the detail panel and in the Allow list on the Connection & Security tab; the old address no longer appears in the list.
• The Permissions section of the detail panel shows the permissions you want.

Because pairing again creates a new pairing, the node's color on the shared screens may change.

Things to Keep in Mind

• Do not touch the firewall during pairing. A change made on the Firewall screen while pairing is in progress removes the temporary opening and the pairing times out. Changes made after pairing completes do not affect the pairing.
• A reinstalled server comes with a new identity. If you reinstall a node from scratch or restore its backup to a different server, its peers see it as Identity changed. Remove the pairing on both sides and pair again. Restoring a backup on the same server does not affect the pairing.
• Do not clone a paired virtual machine. The node identity is created at the first pairing attempt; a clone taken after that point carries the same identity. Contact our support team before using such a clone with Multi-Server.
• Do not overlook the Sunucu eşleştirildi email. This email is sent to the administrators of both nodes when pairing completes; it shows the other node's name, IP address, short fingerprint and the user who performed the operation. If neither you nor a fellow administrator performed the pairing, remove it immediately.
• Share the pairing code only with the other node's administrator. A server that knows the code and connects from the entered IP address can complete the pairing. Cancel a code you will not use right away with Cancel code.
• Pairing with a blocked address is not possible. A code cannot be generated for an address on the block list of the Firewall screen; if the address of the node that generated the code is blocked on the joining node, joining is rejected as well. Pairing does not change the block list.
• Pairing turns on viewing. The Global Admins of the paired node can see this node's SMTP queue, email traffic (including sender, recipient and subject) and Dashboard indicators. If you do not want this, turn off the Can view my data permission. Pair only with servers that your organization manages.
• Turn on remote actions deliberately. The Global Admins of a node granted the Can perform remote actions permission can permanently delete emails in this node's queue, including cleaning up by sender and deleting all emails matching a search.
• Remote deletion cannot be undone. Emails on a remote node are permanently deleted from that node's queue; when more than one email on a remote node or a bulk deletion is involved, the confirmation dialog asks you to type that node's name.
• Keep nodes up to date. Keeping paired nodes on the same version is recommended.

Troubleshooting

The joining node shows "The peer server is unreachable". The IP address of the joining node may have been entered incorrectly on the node that generates the code, or a firewall between the two servers is blocking 9441/TCP. On the node that generates the code, cancel the code with Cancel code or Cancel and generate a new code with the correct IP address; open 9441 in both directions on the firewall in between.

"Code or address could not be verified" appears. The code was entered incorrectly, or the joining node's connection came from a different address than expected. Re-enter the code carefully. If the code-generating screen shows "The connection came from a different address", generate a new code for that address with Regenerate for this address.

"Could not connect back to the peer server" or "The peer server did not connect back" appears. The node that generates the code cannot reach the joining node at the address you entered. Check the firewall in front of the joining node and whether there is address translation (NAT) in between; use a route on which the two nodes see each other at the same address.

"Too many wrong attempts; the code is no longer valid" appears. The code was entered incorrectly 5 times. Generate a new code on the node that generates the code.

"Time expired" or "Pairing could not be completed, time expired" appears. The code was not entered within 10 minutes, or the pairing could not be completed within 10 minutes after the connection was established. Start pairing again. A change on the Firewall screen during pairing also causes a timeout.

"The pairing could not be delivered to the peer server." appears. The pairing is ready on this node but has not reached the peer server. Click Retry before the time expires. If the problem persists, check the 9441/TCP connection between the two servers.

"This server is already paired" appears. The two nodes are already paired. If the connection has a problem, first remove the pairing on both sides, then pair again.

"The other node runs an incompatible version — update required." appears. One of the two nodes runs a version that is incompatible with the other. Update the node running the older version and start pairing again.

A code cannot be generated, or joining cannot be started. Proceed according to the error text on the screen: If "This address is blocked on the Firewall page." appears, remove the block deliberately or enter the correct address; this check is performed on both the code-generating and the joining node. If "The node limit has been reached." appears, the node has reached 5 peers and no new pairing is possible. If "A pairing operation is already in progress." appears, wait for the other pairing to finish or end it with Cancel or with Cancel code on the open code banner. If "The address could not be resolved." appears, check the server name you entered or the DNS settings. If "The server network configuration could not be applied." appears, the server could not apply the network setting required for pairing; for example, if SELinux is in enforcing mode, pairing cannot be started. According to the DeepFilter installation standard, SELinux must be disabled; contact our support team.

An unexpected "Sunucu eşleştirildi" email arrived. Check the node name, IP address and the user who performed the operation in the email. If neither you nor a fellow administrator performed the pairing, select the node on the Overview tab, remove the pairing immediately with Remove pairing, and treat it as a security incident.

Pairing completed but the node is constantly "Unreachable". The server's network interface may not be in the default firewall zone; a "Firewall zone mismatch" banner appears on the screen. A firewall in between may also be blocking 9441 in one direction. After correcting the firewall zone, remove the pairing on both sides and pair again.

An unexpected "Düğüm erişilemiyor" email arrived; the node shows "Unreachable" or "Not recognized by peer". If the servers are running, the IP address of one of the nodes may have changed. On both nodes, compare the Address field in the detail panel with the other node's current IP address; the old address of the node whose IP address changed appears in the other node's panel. If the address differs, the pairing does not recover on its own: remove the pairing on both sides, pair again and set the permissions again (see If a Server's IP Address Changes).

The node shows "Identity changed". The other node may have been reinstalled, its backup may have been restored to a different server, or another server may have inserted itself in between. If the change is intentional, remove the pairing on both sides and pair again. If there is no known change, treat it as a security incident.

The node shows "Version mismatch". The paired node runs a version that is incompatible with this node. Update the node running the older version; at the first successful check after the update, the status becomes Connected. You do not need to remove the pairing.

A node or the screen shows "Monitoring stopped". Health checks on the server have not run for a while; the states shown may be outdated. Check on the Monitor → System screen that the server services are running. If the state does not recover within a few minutes, contact our support team.

A node cannot be selected on the shared screens, or its queue rows cannot be selected for an action. Hover over the disabled node in the server selector; the hint gives the reason (for example, the node is unreachable, Version difference, permission not granted). If "permission not granted" appears, the other node has not granted this node view permission; the other node's administrator turns it on in that node's panel with the Can view my data switch. If the queue rows are visible but cannot be selected and a lock icon appears on the server tag, remote actions are off on that node; hovering over the row's checkbox shows a tooltip with the node's name (for example, Remote actions are off on mx2 — its administrator can turn them on). Perform the action in that node's own panel or ask the other node's administrator to turn on the Can perform remote actions permission.

The Clean up or Delete All Matching button is disabled. Hover over the button. If Remote actions are disabled on the peer server appears, none of the selected remote nodes has remote actions permission. If the tooltip reports a Version difference with the node's name (for example, Version difference — this action is not available on mx2), update that node; for any other reason, the tooltip also gives the reason (for example, Actions are not available on mx2: unreachable). While another bulk deletion is running, the buttons stay disabled until it finishes.

The node shows "Not recognized by peer". The other node may have removed the pairing without the notification reaching this node. In this case the node may also appear as Unreachable. Check the other node's panel; if the pairing is not there, remove it from this side too and pair again if needed. If the IP address of one of the nodes changed, see If a Server's IP Address Changes.

The screen shows a "Firewall (firewalld) is not running" banner. The server's firewall is off; port 9441 listens without address restriction and access is restricted only at the application layer. Turning on the firewall is recommended. After you turn it on, the allow rules for the paired nodes are added automatically within a minute at most; on the Connection & Security tab, check that the Firewall row shows Active and that the nodes appear in the Allow list.

The "Firewall" row shows "Unknown". The server could not read the firewall status at that moment. Open the screen again a few minutes later; if the state persists, contact our support team.

"Unreachable" and "back after update" emails arrived during an update. The node's update took longer than 3 minutes. This is expected behavior; no action is required.