How to Hide or Minimize Your SMTP Banner: Step-by-Step by Platform

What "Hiding" the Banner Actually Means

Despite the common phrasing, you can't literally hide or remove the SMTP banner entirely — the protocol requires a 220 response code for a connecting client to proceed correctly, and removing that response breaks the connection for every standards-compliant client, legitimate and otherwise. What "hiding the banner" actually means in practice is minimizing the free-text content that follows the required 220 code, specifically removing software name and version information while retaining a minimal, standards-compliant greeting, typically just the hostname and a generic acknowledgment like "ESMTP." This distinction matters because it sets accurate expectations before you start: the goal is reducing disclosed detail, not eliminating the banner as a concept entirely.

Platform-by-Platform Configuration

The four platforms detailed below cover the large majority of real-world self-hosted mail server deployments encountered in practice. Each follows the same underlying pattern despite differing syntax: locate the specific configuration directive controlling the greeting text, modify it to remove software and version disclosure while retaining a minimal, standards-compliant format, then restart or reload the service and verify the live result rather than trusting the configuration file alone.

Postfix

Postfix controls its banner through the smtpd_banner directive in main.cf. A default, unmodified installation often uses something like:

smtpd_banner = $myhostname ESMTP $mail_name

The $mail_name variable typically expands to include "Postfix" and can include version information depending on configuration. To minimize disclosure:

smtpd_banner = $myhostname ESMTP

After editing main.cf, apply the change and restart:

postfix reload

Exim

Exim uses the smtp_banner option in its main configuration file. A typical default might resemble:

smtp_banner = $smtp_active_hostname ESMTP Exim $version_number $tod_full

To minimize:

smtp_banner = $smtp_active_hostname ESMTP ready

Apply the change and restart the Exim service according to your distribution's service management approach (commonly systemctl restart exim4 or equivalent).

Microsoft Exchange

Exchange configures banner text at the Receive Connector level via PowerShell, since it isn't exposed through a simple text configuration file:

Set-ReceiveConnector -Identity "Default Receive Connector" -Banner "220 mail.example.com ESMTP ready"

Run this from the Exchange Management Shell with appropriate administrative privileges, targeting each Receive Connector individually if multiple exist.

Sendmail

Sendmail's banner is controlled through the SmtpGreetingMessage option in sendmail.mc or the equivalent sendmail.cf directive:

define(`confSMTP_GREETING_MESSAGE', `$j Sendmail ready')dnl

Rebuild the configuration and restart the service following your distribution's standard Sendmail configuration rebuild process.

Additional Platforms Worth Covering: Zimbra, MDaemon, and Others

Beyond the four platforms detailed step-by-step above, several other mail server platforms see meaningful real-world deployment and deserve at least brief mention for completeness. Zimbra, a popular open-source and commercial collaboration suite with integrated mail server functionality, exposes banner configuration through its own administrative console or command-line zmprov utility, typically via a setting controlling the SMTP welcome message displayed to connecting clients — the exact attribute name varies somewhat by Zimbra version, making the official Zimbra documentation the most reliable reference for the current, version-specific syntax. MDaemon, a Windows-based mail server popular in smaller business environments, exposes banner configuration through its graphical administrative interface rather than a text configuration file, generally under SMTP or server settings sections, reflecting MDaemon's broader design philosophy of GUI-driven configuration rather than the text-file-based approach more common among Unix-originated platforms like Postfix and Exim. In both cases, and for any other platform not explicitly detailed in this guide, the underlying principle from earlier in this article remains the universal starting point: search that platform's own documentation for "banner," "greeting," or "welcome message" terminology specifically in the context of SMTP or mail service configuration.

Considerations for Multi-Tenant and Hosting Provider Environments

Organizations running mail server infrastructure that serves multiple distinct customers or tenants — a hosting provider offering mail services to many independent clients, for instance — face an additional layer of complexity when it comes to banner configuration, since a single banner setting typically applies server-wide rather than being independently configurable per hosted domain in most mail server software's default configuration model. This means a hosting provider considering banner hardening needs to think through it at the infrastructure level, applying a single, consistent hardening decision across their entire mail platform rather than allowing individual hosted customers to independently configure their own banner content, which most mail server software doesn't support without more advanced, per-domain routing and configuration setups. For hosting providers specifically, this actually simplifies the decision in one sense — a single hardening change protects every hosted customer simultaneously — while also meaning the decision carries broader impact and should be tested thoroughly across the full range of hosted mail traffic patterns before being applied to a shared, multi-tenant production environment.

Handling Legacy Systems That Resist Modern Configuration Approaches

Organizations occasionally maintain legacy mail server infrastructure running older software versions, sometimes for compatibility reasons with equally legacy internal systems that depend on specific, older behavior. Banner hardening on genuinely legacy infrastructure sometimes requires additional care: older software versions may have different, sometimes less flexible configuration syntax than current documentation describes, official documentation for very old versions can be harder to locate or may no longer be actively maintained by the software's current developers, and testing changes carries somewhat higher risk given the reduced likelihood of readily available community support if something goes wrong. For genuinely legacy systems where direct configuration changes feel too risky to attempt confidently, a reverse proxy or gateway positioned in front of the legacy server — configured to intercept and rewrite the banner independently of the legacy system's own configuration — offers a way to achieve the same hardening outcome without directly modifying software that the organization may already be planning to eventually replace or upgrade, reducing risk during what's often already a higher-risk operational situation given the system's legacy status.

Documenting the Business Justification for Banner Hardening

For organizations where infrastructure changes require formal change management approval, having a clear, concise business justification ready streamlines the approval process considerably compared to a vague or purely technical request lacking business context. A useful, concise justification framing draws directly from the risk-calibration discussion covered in our companion Mail Server Banner Security guide: this change is a low-cost, low-risk configuration update that reduces the ease with which automated reconnaissance tools can identify our specific mail server software and version, contributing to overall security hardening with no impact on legitimate mail delivery, deliverability, or system functionality. Pairing this justification with a brief testing and rollback plan (test in staging, verify with a live connection check, straightforward rollback by reverting the single changed configuration line if any unexpected issue arises) typically satisfies most organizational change management processes without requiring extensive additional documentation for what is, at its technical core, a genuinely simple and low-risk change.

Rollback Planning: What to Do If Something Goes Wrong

Even with careful testing, it's worth having a clear, immediate rollback plan before applying any banner configuration change to production mail infrastructure, given how central mail delivery typically is to normal business operations. For the platforms covered in this guide, rollback is generally straightforward given how contained the change itself is — reverting the single modified configuration line (smtpd_banner in Postfix, smtp_banner in Exim, the Banner parameter in Exchange's Set-ReceiveConnector, or the SmtpGreetingMessage macro in Sendmail) back to its previous value and restarting the affected service typically resolves any issue within minutes. Keep a record of the exact previous value before making any change specifically so rollback doesn't require guessing or reconstructing what the original configuration looked like, and confirm the rollback itself with the same live connection verification process used to confirm the original change, rather than assuming a reverted configuration file alone guarantees the running service has actually returned to its previous behavior.

Choosing What to Keep in a Minimized Banner

Once you've decided to minimize your banner, a practical question remains: exactly how minimal should it be, and what's genuinely worth keeping? The hostname is worth retaining in almost every case — it aids legitimate diagnostic purposes, matches what a receiving server would already know from the connection itself and DNS records, and removing it provides negligible additional security benefit while potentially complicating legitimate troubleshooting for your own team or trusted partners. The generic protocol acknowledgment (a word like "ESMTP" or simply "ready") is worth keeping specifically because some client implementations, while not strictly required to by the specification, may behave more predictably when a recognizable, conventional greeting format is present rather than an unusually terse or non-standard one. What's genuinely worth removing is specific software product names and version numbers — the actual identifying detail that narrows an attacker's search space — along with any internal infrastructure naming conventions, datacenter identifiers, or other operational metadata that provides no benefit to a legitimate external connecting client while potentially revealing more about your internal infrastructure than necessary.

A Deeper Look at Postfix Configuration Variables

Postfix's banner configuration deserves a closer look at the specific variables involved, since understanding what each one expands to helps avoid unintended disclosure hiding inside a variable you assumed was safe. The $myhostname variable expands to the server's configured hostname, generally safe and expected to include. The $mail_name variable, used in many default configurations, expands to a string that by default includes "Postfix" — this is precisely the component responsible for software disclosure in an unmodified default configuration, and it's worth checking your specific installation's exact expansion by running postconf mail_name to see the current value before deciding how to handle it. Some administrators choose to redefine mail_name itself to something generic rather than removing it from the banner directive entirely, which achieves the same practical outcome through a slightly different configuration path — either approach works, and the choice mainly comes down to whether other parts of your Postfix configuration also reference $mail_name in ways you'd want to remain consistent.

Sendmail Configuration Nuances Across Distributions

Sendmail's configuration approach varies more significantly across different Linux distributions than the other platforms covered in this guide, since some distributions use the macro-based sendmail.mc approach requiring a rebuild step, while others allow more direct editing of the resulting sendmail.cf file, and still others package Sendmail with distribution-specific configuration wrapper tools that abstract away the underlying macro system entirely. Regardless of which specific approach your distribution uses, the underlying goal remains the same — locating and modifying the greeting message configuration and ensuring the change is properly compiled or applied through whatever build step your specific packaging requires before a service restart will actually reflect it. Checking your distribution's specific Sendmail documentation for the exact rebuild command (commonly something like make -C /etc/mail on systems using the traditional macro approach) avoids the common frustration of editing the source macro file correctly but forgetting the intermediate build step that actually generates the configuration Sendmail reads at startup.

What to Do If Your Mail Server Software Isn't Covered in This Guide

The four platforms covered in detail throughout this guide — Postfix, Exim, Exchange, and Sendmail — represent the large majority of real-world mail server deployments, but plenty of other mail server software exists, and if you're running something not explicitly covered here, the general principles still apply even though the specific configuration syntax will differ. Start by checking your specific software's official documentation for terms like "banner," "greeting," or "SMTP welcome message" — nearly every mail server implementation exposes this as a configurable option somewhere, even if the exact directive name and file location differ from the examples given throughout this guide. If official documentation doesn't clearly cover it, checking your software's community forums or issue tracker for others who have asked the same question is often productive, since banner minimization is a common enough request that most actively maintained mail server projects have addressed it in some form, even if it isn't prominently documented in the primary configuration reference.

Real-World Use Cases

Related Reading

For the foundational concept, start with SMTP Banner. For an honest assessment of how much this actually matters, read Mail Server Banner Security. For techniques that go beyond the banner itself, see SMTP Fingerprinting. For a complete hardening checklist bringing everything together, read Banner Best Practices. To verify your own change took effect, use the SMTP Banner Checker.