SMTP Out
The SMTP Out page lets system administrators configure how the SmarterMail server behaves when it connects to other mail servers to deliver outbound messages — as opposed to the SMTP In page, which governs connections made to this server. Settings here cover which IP address(es) are used for outgoing connections, delivery threading and throughput, TLS certificate validation for outbound connections, and, for servers that send from a pool of IPs, the rules for rotating between them. The page is organized into four tabs: Options, IPv4 Addresses, IPv6 Addresses, and RBL Providers.
Options
The Options tab contains three cards: Options, Delivery Settings, and IP Rotation Settings (the last of which only appears once IP rotation is enabled for IPv4 or IPv6).
Options
- Outbound IPv4 - Selects which IPv4 address SmarterMail binds to when connecting out to a remote SMTP
server to deliver a message. If more than one IPv4 address is bound to the server, each one appears in this
dropdown alongside the following special options:
- Use Primary IP on NIC - Sends outbound mail using whatever IPv4 address is assigned to the server's Network Interface Card (NIC). This is the default setting and is the right choice for most single-IP servers, since there's no pool of addresses to choose between.
- Use the Domain's IP - Sends outbound mail using an IPv4 address assigned to the specific sending domain, rather than a single server-wide address. This is useful on a shared server hosting many domains: for example, a hosting company running 200 domains on one SmarterMail instance might assign each higher-volume domain its own dedicated outbound IP, so that if one domain's sending reputation takes a hit (say, a customer's compromised account starts sending spam and that domain's IP ends up on an RBL), the other 199 domains — sending from their own separate IPs — are unaffected.
- Rotate IP List - Spreads outbound delivery across a pool of IPv4 addresses defined on the IPv4 Addresses tab, using the rules configured in the IP Rotation Settings card. This suits a single-domain server sending high volume: rather than concentrating every outbound connection on one IP (where a temporary delivery problem or an aggressive RBL listing can stall or block all outgoing mail), the load is distributed across several IPs so that no single address absorbs the server's entire sending reputation risk.
- Disable - Prevents SmarterMail from using IPv4 at all for outbound connections. An administrator might select this on a server where only IPv6 delivery routes are desired.
- Outbound IPv6 - The IPv6 equivalent of Outbound IPv4, controlling which IPv6 address (if any) is used
for outbound connections. The same four options are available and behave the same way as their IPv4
counterparts:
- Use Primary IP on NIC - Uses the IPv6 address assigned to the server's NIC.
- Use the Domain's IP - Uses an IPv6 address assigned to the specific sending domain, following the same reputation-isolation logic described above for Outbound IPv4.
- Rotate IP List - Rotates outbound IPv6 connections across the pool of addresses defined on the IPv6 Addresses tab.
- Disable - This is the default setting, and prevents SmarterMail from attempting outbound delivery over IPv6 at all. Many administrators leave IPv6 disabled unless they have a specific reason to send over it, since not every receiving mail server handles IPv6 delivery as reliably as IPv4.
- Enable DNS Caching - When enabled, SmarterMail stores the results of its outbound DNS lookups (such as MX and A record lookups used to find a destination mail server) locally for the duration of that record's configured time-to-live (TTL), rather than performing a fresh DNS query for every message. This reduces the load placed on external authoritative DNS servers and speeds up delivery, since subsequent messages to the same destination domain can reuse the cached answer instead of waiting on a new lookup. The tradeoff is that if a receiving domain's mail server changes (a new MX record, or a changed IP behind an existing A record) before the cached TTL expires, SmarterMail may continue trying to deliver to the old, now-stale, answer until the cache entry ages out.
- Append X-SmarterMail-Authenticated-As Header - When enabled, any outbound message that was submitted by a user who authenticated via SMTP (rather than arriving from an anonymous or relayed connection) has an X-SmarterMail-Authenticated-As header added, containing the authenticated user's address, before the message is sent on to the remote server. This gives the receiving side a header confirming that the message passed through authenticated submission on this server; some downstream antispam systems may take that into account as one signal among others when evaluating the message, though how (or whether) any particular receiving system uses this header is entirely up to that system.
- Disable Remote Bounces - Controls whether a sender is notified when their message fails to reach an
external (non-local) recipient. With this setting enabled, a failed delivery to a remote recipient produces
no bounce message back to the sender, while local-to-local delivery failures are unaffected and still bounce
normally. For example:
- user@yourdomain.com sending to external@other.com: if delivery to other.com fails, no bounce message is generated when this setting is enabled, since the recipient is remote.
- user1@yourdomain.com sending to user2@yourdomain.com: if delivery fails (e.g., user2's mailbox is over quota), user1 still receives a bounce message regardless of this setting, since both addresses are local to the same server.
- Enforce strict certificate validation - Controls whether SmarterMail validates the TLS certificate
presented by a remote server before completing an encrypted outbound SMTP connection. With this enabled,
SmarterMail will refuse to connect over TLS to a remote server whose certificate is expired, not yet valid,
issued by an untrusted or self-signed authority, or does not match the hostname being connected to.
Note: Disabling this setting is not recommended, since it removes all outbound certificate validation and could allow a third party to intercept outbound connections using a rogue or fraudulent certificate.
- Relaxed certificate name validation - This setting only has an effect while Enforce strict certificate validation is enabled above; if strict validation is turned off entirely, this setting is disabled and irrelevant, since there's no certificate validation left to relax. When strict validation is on and this setting is also enabled, SmarterMail continues to reject remote servers presenting expired, not-yet-valid, or untrusted/self-signed certificates exactly as before — this setting loosens only the hostname-matching check, not those other checks. Specifically, a certificate name mismatch is tolerated as long as the connecting hostname shares the certificate's root domain. For example, a wildcard certificate issued for *.domain.com would still be accepted when connecting to mail.domain.com, www.mail.domain.com, or mail17.email.domain.com, since all of them fall under the domain.com root — provided that root certificate itself is not expired and is otherwise trusted.
Delivery Settings
- Command Timeout (Seconds) - If a remote server accepts a command and begins sending or receiving data but that data stops flowing for this number of seconds, SmarterMail aborts the command and the connection. By default, the command times out after 60 seconds.
- Max Delivery Threads - The maximum number of outbound messages SmarterMail will attempt to deliver at the same time to non-local (remote) email addresses. Because SmarterMail is multi-threaded, if one message can't be sent right away (for example, the remote server is slow to respond), SmarterMail moves on to the next message in the queue rather than letting that one delivery attempt block the rest of the spool, circling back to the delayed message later. By default, Max Delivery Threads is 50; the field accepts values from 1 to 200. A server sending very high outbound volume might raise this value (within that range) to increase overall delivery throughput, at the cost of higher concurrent CPU, memory, and network use on the server.
- Max Recipients Per SMTP Session - The maximum number of recipients SmarterMail will include in a
single outbound SMTP session to a given remote server. For example, with the default of 500, a message
addressed to 600 recipients at the same destination domain is split across two outbound sessions — one
carrying 500 recipients and a second carrying the remaining 100. This is useful when a receiving server
enforces its own per-session recipient cap and would otherwise reject a session that exceeds it.
Note: Setting this to Unlimited is not recommended unless there is a specific, identified need to do so, since very large single sessions are more likely to run into a receiving server's own limits or timeouts.
IP Rotation Settings
This card only appears once Rotate IP List is selected for Outbound IPv4 or Outbound IPv6 above. Its purpose is to spread outbound sending volume across the pool of IPs configured on the IPv4 Addresses and/or IPv6 Addresses tabs, which helps manage the server's sending reputation: rather than every outbound connection accumulating against a single IP's reputation, load (and risk) is distributed across multiple addresses, and an IP that starts showing delivery failures or turns up on a blacklist can be temporarily pulled out of rotation without stopping outbound mail entirely. The following settings are available:
- IP Rotation Type - Selects which mechanism triggers a switch from the current IP to the next one in
the list:
- Time - Rotates based on how long the current IP has been actively in use. The Minutes per IP field sets that duration; this is the default rotation type, with a default of 60 minutes per IP (the field accepts 1–1440 minutes).
- Delivery Count - Rotates based on the number of messages successfully delivered through the current IP. The Deliveries per IP field sets that count, defaulting to 100 deliveries per IP (the field accepts 1–100,000).
- Enable Failure Tracking - When enabled (it is disabled by default), SmarterMail additionally pulls an
IP out of rotation based on recent delivery failures, independent of the rotation type above:
- Failure Count in Window - The number of delivery failures that must occur on a given IP, within the Failure Time Window, before that IP is temporarily skipped. Defaults to 10.
- Failure Time Window (Minutes) - The trailing time window over which failures are counted toward the Failure Count in Window threshold. Defaults to 60 minutes.
- Failure Time Skip (Minutes) - Once an IP is pulled from rotation for exceeding the failure threshold, this is how many minutes it stays out before SmarterMail makes it eligible for use again. Defaults to 60 minutes.
- Enable RBL Tracking - When enabled (it is disabled by default), SmarterMail periodically checks each
IP in the rotation against the RBL providers configured on the RBL Providers tab, and temporarily pulls
any IP that comes back listed:
- RBL Check Interval (Minutes) - How often each IP is re-checked against the configured RBL providers. Defaults to 30 minutes (the field accepts a minimum of 5 minutes).
- RBL Skip Duration (Minutes) - How long an IP that came back listed on an RBL is held out of rotation before being checked again. Defaults to 120 minutes (the field accepts a minimum of 30 minutes).
- Use Primary IP if all other IPs are unavailable - When enabled, if every IP in the rotation pool is currently skipped (due to failures, an RBL listing, or an active time/delivery-count window), SmarterMail falls back to the server's primary IP rather than failing the delivery outright, attempting the connection only once on that fallback address.
As a worked example: an administrator running a high-volume single-domain server might change IP Rotation Type from the Time-based default to Delivery Count and raise Deliveries per IP to 500, so each IP in the pool handles a predictable chunk of outbound volume before handing off to the next. Enabling Failure Tracking and tightening Failure Count in Window to 5 failures within a 10-minute Failure Time Window means that if one of those IPs starts bouncing messages rapidly (say, a receiving network is temporarily blocking it), it's pulled out of rotation for the configured Failure Time Skip period — 60 minutes by default — rather than continuing to hammer a connection that keeps failing. Layering Enable RBL Tracking on top, using the defaults of a 30-minute check interval and a 120-minute skip duration, closes the loop: if one of the pool's IPs ends up listed on an RBL mid-campaign, it's automatically withdrawn from rotation for two hours while the remaining IPs continue sending, protecting the rest of the domain's outbound reputation in the meantime.
IPv4 Addresses
This tab lists the IPv4 addresses SmarterMail will cycle through when Rotate IP List is selected for Outbound IPv4 on the Options tab. Only IPv4 addresses already bound to the server are available to add here. To add an IP to the rotation pool, click New, which opens the Add IP Address modal:
- IP Address - A dropdown listing the IPv4 addresses available on the server. Select one and click Add to include it in the rotation pool. To remove an IP from the pool, select it in the list and click Delete.
IPv6 Addresses
This tab lists the IPv6 addresses SmarterMail will cycle through when Rotate IP List is selected for Outbound IPv6 on the Options tab. Only IPv6 addresses already bound to the server are available to add here. To add an IP to the rotation pool, click New, which opens the Add IP Address modal:
- IP Address - A dropdown listing the IPv6 addresses available on the server. Select one and click Add to include it in the rotation pool. To remove an IP from the pool, select it in the list and click Delete.
RBL Providers
This tab defines the RBL (Realtime Blackhole List) providers SmarterMail checks against when Enable RBL Tracking is turned on in the IP Rotation Settings card. SmarterMail ships with a small default list of providers already configured (including UCEPROTECT, Backscatterer, and Hostkarma), which can be restored at any time from this tab's menu using Reset RBL Providers if the list is ever modified or cleared. Each entry has the following fields:
- Hostname - The DNS hostname of the RBL to query (e.g., BRBL, the Barracuda Reputation Block List).
- Required Lookup Values - The response value(s) that indicate a listing. An RBL is queried as a DNS lookup, and a “hit” typically comes back as an address in the 127.0.0.0/8 range, where the specific address returned indicates the reason for the listing; this field determines which returned addresses SmarterMail treats as a match. For example, Barracuda's BRBL and Spamhaus's Zen blocklist both use 127.0.0.2 to indicate a spam-related listing, so entering 127.0.0.2 here would trigger on that response. Some providers return more than one meaningful code, in which case multiple values can be entered as a comma-separated list (for example, 127.0.0.2,127.0.0.4). A value of * can also be used to treat any returned response from that provider as a match, which is how SmarterMail's own default UCEPROTECT entry is configured. The exact codes and their meanings vary by provider and are defined in that RBL's own documentation.