SMTP Banners: What They Reveal About Your Mail Server Security (2026)

What Is an SMTP Banner?

An SMTP banner (also called an SMTP greeting) is the first response a mail server sends when a client connects on port 25 (or ports 465/587 for submission). According to RFC 5321, when a connection is established, the server responds with a 220 status code followed by the server's fully qualified domain name and optional additional information.

Here is what a typical SMTP banner looks like:

220 mail.example.com ESMTP Postfix (Ubuntu)

This single line tells a remote client (or attacker) several things: the hostname is mail.example.com, the server supports Extended SMTP (ESMTP), the software is Postfix, and the operating system is Ubuntu. That is a lot of information from a single line.

What Information SMTP Banners Expose

Different mail servers include varying amounts of detail in their banners. Here are examples of real-world banners and what they reveal:

Verbose Banners (High Risk)

220 mail.example.com ESMTP Postfix 3.5.6 (Debian 11)
220 mail.example.com Microsoft ESMTP MAIL Service, Version: 15.2.1118.26
220 mail.example.com ESMTP Exim 4.96 #2 Tue, 01 Apr 2026 10:00:00 +0000
220 mail.example.com ESMTP Sendmail 8.17.1/8.17.1; Tue, 1 Apr 2026 10:00:00

These banners expose the exact software and version. An attacker can immediately look up known vulnerabilities (CVEs) for that specific version and craft targeted exploits.

Minimal Banners (Lower Risk)

220 mail.example.com ESMTP ready
220 mx.google.com ESMTP - gsmtp
220 example-com.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready

These banners still identify the hostname and sometimes the provider, but omit version numbers. Google's and Microsoft's banners are generic enough that they do not help attackers target specific vulnerabilities.

Security Risks of Information Disclosure

SMTP banner information disclosure is a recognized security concern. Here is how attackers use this information:

• CVE exploitation. Knowing the exact software version allows attackers to search vulnerability databases for known exploits. For example, if a banner reveals Exim 4.92, an attacker knows it is vulnerable to CVE-2019-15846 (a critical remote code execution vulnerability).
• Targeted attacks. Different mail servers have different attack surfaces. Knowing whether a target runs Postfix, Exim, Exchange, or Sendmail lets attackers focus on software-specific exploits, misconfigurations, and weaknesses.
• Reconnaissance automation. Attackers use automated scanners (like our Port Scanner, but maliciously) to harvest SMTP banners across thousands of servers, building databases of vulnerable targets.
• OS fingerprinting. The banner often reveals the operating system, which expands the attack surface beyond just the mail server software.
• Internal hostname leakage. Some misconfigured servers expose internal hostnames (like exchange01.corp.internal) that reveal internal network structure.

SMTP Banner and EHLO Response

Beyond the initial 220 greeting, the SMTP EHLO response reveals additional information about server capabilities:

250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

This EHLO response reveals that the server supports STARTTLS (good), has VRFY enabled (bad — allows email address enumeration), and accepts AUTH PLAIN (which sends credentials in base64, not encrypted, unless wrapped in TLS). Each capability line is a potential attack vector.

How Attackers Use Banner Information

The attack workflow typically follows this pattern:

1. Banner grabbing. Connect to port 25 and read the 220 response. This can be done with a simple telnet or nc command, or at scale using tools like Nmap or Masscan.
2. Software identification. Parse the banner to identify the MTA software, version, and OS.
3. Vulnerability lookup. Cross-reference the version against CVE databases (NVD, Exploit-DB, vendor advisories).
4. EHLO probing. Send an EHLO command to enumerate supported extensions. Check for VRFY (user enumeration), EXPN (mailing list expansion), and the absence of STARTTLS.
5. Open relay testing. Attempt to relay mail through the server. Use our Open Relay Checker to verify your server is not an open relay.
6. Exploit execution. Deploy the appropriate exploit based on the gathered intelligence.

Hardening Your SMTP Banner

The principle of least information applies here: your SMTP banner should reveal only what is required by the protocol and nothing more. Here is how to harden the banner for popular mail servers:

Postfix

Edit /etc/postfix/main.cf and set a custom banner:

smtpd_banner = $myhostname ESMTP

The default Postfix banner includes the software name and version. Removing these reduces information leakage. The $myhostname variable is required by RFC 5321 and should match your PTR record.

Exim

In the Exim configuration, set the smtp_banner option:

smtp_banner = $primary_hostname ESMTP

Sendmail

In sendmail.mc, modify the greeting message:

define(`confSMTP_LOGIN_MSG', `$j ESMTP')dnl

Microsoft Exchange

In Exchange, modify the SMTP receive connector banner using PowerShell:

Set-ReceiveConnector "Default Frontend" -Banner "220 mail.example.com ESMTP"

Additional SMTP Hardening Steps

Beyond the banner, consider these additional hardening measures:

• Disable VRFY and EXPN. These SMTP commands allow user enumeration. Disable them unless specifically needed. In Postfix: disable_vrfy_command = yes.
• Enforce STARTTLS. Require TLS for all connections where possible. This encrypts the SMTP conversation, including the EHLO capabilities exchange. Check your TLS setup with our SMTP Banner tool.
• Close unnecessary ports. Only expose ports 25 (MX delivery), 465 (implicit TLS submission), and 587 (STARTTLS submission) as needed. Use our Port Scanner to verify.
• Keep software updated. The most important defense is patching. Even a hardened banner does not protect against vulnerabilities in outdated software. Subscribe to your MTA vendor's security advisory list.
• Implement rate limiting. Throttle connections from individual IPs to slow down banner-grabbing scanners and brute-force authentication attempts.
• Monitor SMTP logs. Watch for unusual connection patterns, repeated EHLO/HELO commands without mail delivery, and VRFY/EXPN attempts. These often indicate reconnaissance activity.

What the RFC Says

RFC 5321 (Section 4.2) specifies that the 220 greeting must include the server's FQDN (fully qualified domain name). Beyond that, any additional information is optional. The RFC even includes a note that software name and version are "sometimes useful for debugging but may be a security concern."

The minimum compliant banner is simply:

220 mail.example.com ESMTP

This reveals nothing beyond the hostname (which is also visible in MX records and is required for proper SMTP operation) and the fact that Extended SMTP is supported.

How to Check Your SMTP Banner

Use our free tools to inspect your mail server's SMTP banner and overall security posture:

• SMTP Banner Checker — Connect to any mail server and view the SMTP greeting, EHLO capabilities, and TLS support.
• Port Scanner — Check which SMTP-related ports (25, 465, 587) are open on your mail server.
• Open Relay Checker — Verify your mail server does not allow unauthorized relay.