Bindings

The Bindings page (Settings > Bindings) controls how SmarterMail listens for incoming connections. It ties three things together: the physical IP addresses available on the server's Network Interface Card (NIC), the network ports used by mail and collaboration protocols (SMTP, IMAP, POP, LDAP, XMPP, and Submission), and the encryption applied to each port. Getting these three pieces configured correctly is what allows a single server to host multiple domains, each potentially with its own IP address, hostname, and set of secure ports.

Binding IPs to specific ports and domains also has a practical security benefit: it limits the blast radius of a blacklisting event. If a single domain or user starts sending spam and gets that specific IP blacklisted, only the mail flowing through that IP is affected — the rest of the server, and every other domain hosted on it, continues to send and receive normally.

The Bindings page has three tabs, each covered in detail below: IP Addresses, Ports, and Hostnames. Each tab header displays a running count of how many items (IPs, ports, or hostnames) are currently configured.

IP Addresses

This tab lists every IP address SmarterMail has detected on the server's NIC — both IPv4 and IPv6. Because the list is pulled directly from the operating system, IP addresses cannot be added here manually; if an address is missing, it needs to be added to the NIC (or the server's network configuration) first, then it will appear on this tab automatically. For each IP address, the tab shows its assigned hostname, its description (if one has been entered), and the number of ports currently bound to it.

Clicking an IP address opens its configuration options:

• IP Address – The address itself, as pulled from the NIC. This field is read-only and cannot be edited from within SmarterMail.
• Hostname – The hostname that SmarterMail should associate with this specific IP address (e.g., mail1.example.com). This is more than a label: SmarterMail uses the assigned hostname as the EHLO/HELO string it presents when opening SMTP sessions from that address, whether it's an inbound session banner or an outbound message being relayed out through that IP. If no hostname is set for an IP, SmarterMail falls back to the server's global hostname (or the default outbound sender hostname for outgoing mail).
  
  Example: if 192.0.2.10 is assigned to marketing.example.com and its reverse DNS (PTR) record also resolves to marketing.example.com, outbound mail sent from that IP will present a HELO/EHLO that matches its PTR record — a detail many receiving mail servers check before accepting a connection. A mismatch between the HELO hostname and the PTR record is a common cause of deliverability problems, so this field should always be kept in sync with DNS.
• Description – A friendly, internal-only note describing the binding's purpose (e.g., "Backup MX for northeast region" or "Dedicated IP for AcmeCorp domain"). This has no effect on mail flow; it exists purely to help administrators keep track of why an IP is configured the way it is.
• Ports – A checklist of every port defined on the Ports tab. Select each port this IP address should listen on. A port that isn't assigned to at least one IP address won't accept any connections at all, so every active protocol needs to have its port checked here for the relevant IP(s).

Because the same port checkbox can't be selected twice for the same address, and the same port/IP combination can't be assigned to more than one binding record, SmarterMail will reject a save if it detects a duplicate port-to-IP assignment elsewhere in the configuration.

Removing IP addresses: Entries on this tab are meant to mirror the server's NIC, so an IP address that is still actively bound to the NIC cannot be deleted from here — SmarterMail will simply skip it, since removing it would create a mismatch with the underlying network configuration. Only IP addresses that are no longer present on the NIC (stale or orphaned entries) can actually be removed using the Delete button. If an IP address continues to appear after being removed from the NIC, double-check that it has also been fully removed from the server's registry, as leftover registry entries can cause SmarterMail to keep listing an address that no longer physically exists.

Note for High Availability (HA) environments: If the server is part of a SmarterMail HA cluster, the IP Addresses and Ports tabs become read-only. Bindings must be managed centrally at the HA hub level rather than on individual nodes, so any attempt to add, edit, or remove a binding on a clustered node will be rejected.

IPv6 Deployment

SmarterMail supports IPv6 alongside IPv4, but a few requirements and current limitations should be understood before planning an IPv6-only or dual-stack deployment:

• Outbound IP preference is configured outside of Bindings. The Bindings page only controls which addresses SmarterMail listens on for inbound connections. Which address SmarterMail uses to send outbound mail is a separate setting found under Domain Settings > Outbound IPv4 Address (per-domain) and Settings > Protocols > SMTP Out > Outbound IPv4 (server-wide). Both locations expose a similar set of options for how the outbound IP is chosen: use the domain/server's primary IP, use a specific IP, use the domain's assigned IP, rotate through available IPs, or disable that IP version entirely.
  
  By default, outbound delivery over IPv4 is enabled (using the primary IP), while outbound delivery over IPv6 is disabled out of the box. For an IPv6-only or IPv6-preferred deployment, IPv6 must be explicitly enabled in these settings, and administrators may want to explicitly disable IPv4 there as well so that IPv6 is used consistently.
• IPv4 is preferred when both are available. If a server has both IPv4 and IPv6 addresses configured and neither has been explicitly disabled, SmarterMail will prefer IPv4 for outbound connections.
• DNS lookups can default to IPv4. When a remote host publishes both an A (IPv4) and AAAA (IPv6) record, SmarterMail may default to the A record. If a remote host publishes only an AAAA record, delivery will depend on SmarterMail successfully resolving and connecting over IPv6 — test AAAA-only MX resolution before relying on it in production.
• Reverse DNS (PTR) matters even more on IPv6. Mail servers sending over IPv6 need a PTR record that resolves to the exact sending IPv6 address — not a range or CIDR block. Work with the hosting or IP provider to get this configured correctly, since many receiving servers will reject or heavily penalize IPv6 senders that lack a matching PTR record.

Before cutting production domains over to IPv6, test both inbound and outbound delivery using IPv6-only test domains, and monitor logs closely for session terminations or failed MX lookups during the transition.

Ports

Use this tab to define the ports SmarterMail listens on, the protocol each port serves, and any SSL/TLS encryption applied to it. Every port that should accept connections needs an entry here, which is then assigned to one or more IP addresses back on the IP Addresses tab.

Each port in the list shows its name, protocol/type, and how many IP addresses it's currently bound to. Click New to add a port, or click an existing entry to edit it. The following fields are available:

• Protocol – The communications protocol the port serves: SMTP, POP, IMAP, LDAP, XMPP, or Submission.
• Port – The port number to listen on for the selected protocol. Choosing a protocol and encryption combination automatically fills in the conventional port number as a starting point (see the table below), though it can be changed if the environment requires a non-standard port.
• Name – A friendly label for the port (e.g., "SMTP Submission – Secure") to make it easy to identify in the list.
• Encryption – Whether the port requires SSL or TLS, or allows unencrypted connections (see Encryption below).
• Certificate Path / Password – Required whenever SSL or TLS encryption is selected: the full path to the SSL/TLS certificate file and the password protecting its private key.
• IP Addresses – Every IP address available on the server, so the port can optionally be assigned directly from this dialog instead of switching to the IP Addresses tab.

Example default ports (auto-filled when a protocol/encryption combination is chosen, but fully customizable):

• SMTP – 25 (none/StartTLS), 465 (SSL)
• Submission – 587 (none/StartTLS), 465 (SSL)
Note: A Submission port still uses SMTP. However, it has the added requirement that the session must be authenticated or whitelisted before it can accept messages.
• IMAP – 143 (none/StartTLS), 993 (SSL)
• POP – 110 (none/StartTLS), 995 (SSL)
• LDAP – 389 (none/StartTLS), 636 (SSL)
• XMPP – 5222 (none/StartTLS), 5223 (SSL)

There is no "listen on all IP addresses" wildcard option for a port — each port must be explicitly assigned to one or more specific IP addresses, either from this dialog or from the IP Addresses tab. A port with no IP addresses assigned to it will not accept any connections.

Encryption

Three encryption behaviors can be selected for a port. By default, choosing an encryption type also updates the port number to the conventional value for that combination:

• None – Allows unencrypted connections. Appropriate for legacy compatibility or internal/trusted networks only; not recommended for general internet-facing use.
• SSL/TLS – Sometimes called "implicit SSL." The encrypted handshake happens immediately upon connection, before any protocol commands are exchanged. This is used by clients that expect the connection to be secure from the first byte — often labeled "Force old-style SSL" or "Use legacy SSL" in mail client settings.
• StartTLS – The client connects in plaintext on the standard port and then issues a StartTLS command to upgrade the existing connection to an encrypted one. This is the modern standard for mail protocols and, since the connection begins in plaintext, it uses the same port number as an unencrypted connection until the upgrade occurs.

Because SSL/TLS and StartTLS are technically implemented as two independent options rather than a single choice, only one should be selected per port – if both were somehow enabled at once, SSL/TLS takes priority. In practice, an administrator should simply pick the one encryption mode intended for that port.

Not every mail client offers a way to force StartTLS on a non-default port. For example, eM Client has no setting to force StartTLS specifically on port 5223 (the SSL/TLS port for XMPP) — so when configuring a port for StartTLS, confirm the client software actually supports negotiating it on that port number.

Regarding SSL Certificates

Whenever a port is set to SSL/TLS or StartTLS, a Certificate Path and Password are required – even if SmarterMail is already managing SSL certificates automatically (for example, through an ACME/Let's Encrypt integration). This is because some older mail clients don't support Server Name Indication (SNI), which is what normally allows a single IP to serve certificates for multiple hostnames. Without SNI, SmarterMail needs a fallback certificate explicitly configured on each encrypted port binding so it always has something to present to clients that can't request a certificate by hostname.

The same certificate file can be reused across multiple port bindings if a single certificate already covers all the relevant hostnames (e.g., a wildcard certificate for *.example.com). Whatever certificate is chosen, confirm it is a file that includes the private key – a certificate file without its private key will fail validation and prevent the port from accepting encrypted connections.

A couple of practical notes when working with this field: if the certificate file selected ends in .cer, the password field is hidden automatically, since that format doesn't use one. And when editing an existing port, the password field won't display the actual stored password for security reasons – leave it as-is unless the certificate's password has changed.

Hostnames

This isn't a separate configuration tab so much as a read-only summary view: it shows every IP address on the server alongside the hostname and description assigned to it (from the IP Addresses tab) and the number of ports bound to each. It's a convenient way to audit, at a glance, whether every domain that should have a dedicated IP and hostname actually does – which, as noted above, directly affects how resilient the server is to blacklisting and how mail servers on the receiving end evaluate the HELO/EHLO hostname against reverse DNS.

To review this list, log in as the system administrator, open Settings, click Bindings, and select the IP Addresses tab. Any changes to hostname or description are made the same way as described above: by clicking into the IP address entry itself.