SMTP Out IP Rotation not rotating between configured IPv4 addresses
Problem reported by Craig Edmonds - Today at 6:47 AM
Submitted
I am trying to configure outbound IPv4 rotation in SmarterMail and am seeing behaviour that I do not understand.

We are running SmarterMail 100.0.9518.30214 on Linux.

We have multiple IPv4 addresses configured on the server, each with its own hostname and matching forward/reverse DNS, for example:

192.0.2.10 → smtp1.example.com
192.0.2.11 → smtp2.example.com
192.0.2.12 → smtp3.example.com
192.0.2.13 → smtp4.example.com
192.0.2.14 → smtp5.example.com
192.0.2.15 → smtp6.example.com

The addresses are configured under Settings → Bindings with the appropriate hostname assigned to each.

Under Settings → SMTP Out, I configured:
Outbound IPv4: Rotate IP List
IP Rotation Type: Time
Minutes per IP: 5

The IPv4 Addresses tab contains multiple addresses.

However, the outbound IP does not appear to rotate.

For example, after restarting SmarterMail, outbound connections continued using the same IP for considerably longer than the configured 5-minute period:

15:32 Connection ... from 192.0.2.20
15:36 Connection ... from 192.0.2.20
15:38 Connection ... from 192.0.2.20
15:45 Connection ... from 192.0.2.20
15:50 Connection ... from 192.0.2.20

There was active outbound mail throughout this period.

Prior to restarting SmarterMail, I had observed the same behaviour.

I also tested IP Rotation Type: Delivery Count.

I initially configured 100 deliveries per IP and later reduced this to 5 deliveries per IP. The selected outbound IP continued to be used for considerably more than the configured number of deliveries.

As a test, I disabled Rotate IP List and explicitly selected one of the alternative IP addresses under SMTP Out → Outbound IPv4.
SmarterMail immediately started using that IP:
Binding to local IP 192.0.2.10
Connection ... from 192.0.2.10
CMD: EHLO smtp1.example.com

The alternative IPs therefore work correctly for outbound SMTP and SmarterMail is able to bind to them. 

The problem appears specifically related to the rotation mechanism.

I also have a question regarding the domain-level Outbound IPv4 setting.

Under Manage → Domains → [domain] → Outbound IPv4, I can select a specific outbound IP address.

However, when the global SMTP Out setting is configured to Rotate IP List, the domain settings display the warning: "Outbound IPv4 has been set in system protocol settings, so this value will be ignored."

I tested this by assigning a particular domain to one of the alternative IP addresses. While Rotate IP List was enabled globally, messages from that domain continued to use the IP selected by the global SMTP Out configuration rather than the IP configured at domain level.

This is important to us because occasionally a particular receiving mail provider may temporarily reject one of our sending IPs while accepting another. In those situations I would like to be able to temporarily assign an affected domain to a known-working outbound IP while retaining rotation for all other domains.

Could someone please clarify:

1. Why would Time-based rotation remain on the same IP beyond the configured number of minutes despite active outbound deliveries?
2. Why would Delivery Count rotation continue using the same IP beyond the configured number of deliveries?
3. Is there another setting or requirement needed to make Rotate IP List advance between addresses?
4. Is the domain-level Outbound IPv4 setting intentionally ignored whenever Rotate IP List is selected globally?
5. Is there a supported way to use global IP rotation while overriding the outbound IP for specific domains?
6. For IP addresses used exclusively for outbound SMTP rotation, do they need SMTP (25) selected under Settings → Bindings → Ports, or is leaving all listening ports unselected correct for outbound-only IPs?
7. Is there debug logging available that shows the rotation engine's current IP, timer/delivery counter and reason for selecting or changing an IP?

For the moment I have disabled rotation and selected a known-working outbound IP globally so that mail delivery remains reliable while I investigate this.

Thanks.

Reply to Thread

Enter the verification text