📜 SMTP Banner Checker

Look up a domain's mail servers, then get the exact command to read their real SMTP banner — the greeting line that can reveal server software, version, and hostname the moment a connection opens.

✍️ Author: ToolsNovaHub • 📅 Last Updated: 16 August 2026
Enter a domain to look up its MX mail servers, or a specific mail server hostname to generate banner-read commands directly.

Why Even a Free, One-Line Check Deserves a Dedicated Tool

It's fair to ask why a check this simple — one that a comfortable command-line user could run in a single line without any tool at all — warrants a dedicated interface. The honest answer is accessibility: not every site owner, marketer, or small-business operator managing their own domain's email is comfortable opening a terminal, remembering the correct flag syntax for openssl's STARTTLS mode, or knowing which port to target for a submission server versus a relay server. This tool removes that barrier by handling the MX lookup and command construction automatically, so the only remaining step is copying a single line into a terminal — genuinely lowering the effort required to check something that matters for basic security hygiene, without requiring memorized syntax or prior networking expertise.

Why This Tool Generates Commands Instead of Connecting Directly

Every modern browser maintains a list of ports JavaScript is simply not permitted to open connections to, and every standard SMTP port is on that list, specifically to prevent web pages from being used to probe or relay mail traffic. This is true of every browser-based tool, not something specific to this site. Rather than pretending otherwise, this tool does the next most useful thing: it resolves the domain's actual MX records via DNS (a query type browsers can make) and generates the precise, platform-correct command for reading the real banner yourself, giving you a genuine, live result in seconds rather than a simulated one.

What a Banner Typically Reveals

ElementExampleWhat It Discloses
Response code220Confirms the service is ready and responding normally
Hostnamemail.example.comThe server's configured hostname, often matching its MX or PTR record
Software namePostfix / Exim / Microsoft ESMTP MAIL ServiceWhich mail server software is running, narrowing the scope of relevant known vulnerabilities
Version number3.7.2The exact release, letting an attacker check directly against known CVEs for that version
Extra commentary"ready" / custom textUsually harmless, though occasionally includes internal naming conventions worth reviewing

Not every field appears on every server — a well-hardened configuration often shows only a hostname and a generic "ready" message, deliberately omitting software name and version entirely.

How to Read the Response Once You Run the Command

What You SeeWhat It Means
220 mail.example.com ESMTP Postfix readyFull disclosure — software name and, depending on config, version may follow on request
220 mail.example.com readyMinimal, hardened banner — hostname only, no software identification
No response / timeoutPort may be blocked, filtered, or nothing is listening — see our SMTP Connection Errors guide
Connection refused immediatelyNothing listening on that port, or a firewall is actively rejecting the attempt

Interpreting a Banner Alongside DNS and Certificate Information

The banner is most informative when read alongside a couple of other quick, free checks rather than in isolation. Cross-referencing the hostname shown in the banner against the domain's actual MX record confirms you're looking at the server you expect, rather than an intermediate relay or a misconfigured record pointing somewhere unexpected. Checking the SSL certificate presented on the same host (if the server supports encrypted connections) can independently confirm the server's identity and sometimes reveals additional infrastructure details, like a hosting provider's own naming conventions, that complement what the banner itself shows. None of this requires specialized tooling — a domain's MX records and a server's certificate are both public, standard pieces of information any diagnostic session can quickly gather alongside the banner itself.

Step-by-Step: Checking Your Own Domain

Enter your domain above and let the tool resolve your MX records first, since a banner check is only meaningful against the actual server(s) handling your mail. Run the generated command from an actual terminal — telnet for a quick plain-text read, or openssl s_client if the server expects an encrypted connection immediately. Note exactly what the banner reveals, then compare it against the table above: if it includes a specific software version, that's worth addressing through your mail server's own banner configuration, covered in full in our Hide SMTP Banner guide.

How This Compares to Automated Vulnerability Scanners

Dedicated vulnerability scanning tools often automate exactly this banner-reading step as part of a much larger, more comprehensive scan covering dozens of checks simultaneously — port enumeration, banner grabbing, known-CVE matching, and configuration review all in one automated pass. This tool deliberately does one specific thing well rather than attempting to replicate that full scope: it gets you the live banner quickly, transparently, and without requiring any software installation or account signup. For a genuinely comprehensive security assessment, a dedicated vulnerability scanner remains the more thorough choice; for a quick, specific check of exactly what your mail server's greeting reveals, a targeted tool like this one is faster and simpler to reach for.

Frequently Overlooked Detail: Banners on Non-Standard Ports

Most banner checks reasonably focus on the standard ports — 25, 587, 465 — since that's where mail servers are expected to listen. Some organizations, particularly those that have previously dealt with aggressive automated scanning, run SMTP services on additional non-standard ports as well, sometimes for internal or partner-specific relay purposes. If you administer infrastructure with mail services on non-standard ports, extending your own banner review to cover those as well is worth doing explicitly, since a security review that only checks the well-known ports can miss a verbose banner sitting on a less obvious, but still reachable, port.

Security Considerations

A banner check reads only information the server voluntarily sends to any connecting client — the same data any legitimate mail server sees during normal delivery. This is a standard, non-intrusive diagnostic action. Only run repeated or automated checks against domains you own or have explicit permission to assess; a single manual check against a third party is generally considered reasonable, but treat any system you don't operate the way you'd want your own treated.

Interpreting Multiple MX Records With Different Banners

A domain publishing several MX records at different priority levels is a common, entirely normal redundancy configuration — but it means a single banner check against the primary (lowest-priority-number) server doesn't necessarily tell you about the secondary or backup servers that would handle mail if the primary were unavailable. It's worth explicitly checking each listed MX host individually, since a backup server provisioned at a different time, by a different team, or through a different hosting arrangement can easily end up with a meaningfully different — often less carefully hardened — banner configuration than the primary. This gap is easy to miss precisely because backup servers see far less day-to-day attention than primary infrastructure, making them a genuinely common place to find an overlooked, verbose default banner nobody got around to addressing.

Banner Information in the Context of a Broader Security Assessment

A banner check is rarely performed in isolation during any genuine security review — it's typically one early data point feeding into a broader picture that includes open port enumeration, SSL/TLS configuration review, security header analysis, and email authentication status. Treating a banner finding in isolation, disconnected from this broader context, risks either overreacting to a modest information-disclosure finding or underreacting because "it's just a banner." The realistic way to weigh it: a verbose banner revealing an outdated, known-vulnerable software version is meaningfully more concerning than the same verbose banner on current, actively patched software, since the actual risk comes from the combination of disclosed information and genuine underlying vulnerability, not the disclosure alone.

Expert Tips for Using This Tool Effectively

💡
Check Every MX Record, Not Just the Primary
If your domain has multiple mail servers at different priorities, each can have its own banner configuration — check each one individually rather than assuming they match.
💡
Re-Check After Any Mail Server Migration
Moving to new infrastructure or a new provider often means starting from that platform's own default banner configuration, which may be more verbose than your previous, hardened setup.
💡
Pair This Check With a Known-Vulnerability Lookup
If a banner reveals a specific software version, checking that exact version against a current vulnerability database tells you whether the disclosure is a genuine, actionable risk or a low-priority cleanup item.
💡
Don't Stop at Port 25
Submission ports (587, 465) can have separate banner configurations from the relay-facing port 25 — check the port your actual concern applies to specifically.

A Note on What Counts as a Meaningful Fix

Changing a banner's wording without addressing the underlying software version doesn't reduce actual risk — it only reduces how easily that risk is discovered through this one specific technique. A genuinely thorough response to a verbose banner finding treats it as a prompt to check two things together: first, whether the disclosed software version has any known, currently unpatched vulnerabilities worth addressing directly, and second, whether minimizing the banner itself is a reasonable additional step once the underlying software is already current and properly maintained. Doing only the second without ever checking the first is a common, understandable but incomplete response — cosmetically resolving a scan finding while leaving the actual software exposure unaddressed underneath it, which is worth stating plainly since it's an easy mistake to make when a tool's output nudges toward the quicker, more visible fix rather than the more important underlying one.

Real-World Use Cases

🔍
Pre-Audit Self-Check
An administrator checks their own server's banner before a scheduled security audit, fixing any obvious information disclosure ahead of time rather than discovering it during the formal review.
🎓
Security Training Demonstration
An instructor uses a live banner check to concretely demonstrate the reconnaissance concept to students, rather than only describing it abstractly.
🛠️
Post-Migration Verification
A team migrating mail infrastructure to a new provider checks the new server's banner configuration, catching a more verbose default before it becomes a lingering, forgotten issue.
📈
Vendor Security Questionnaire Response
An organization responding to a client's security questionnaire uses this check to accurately document their current banner configuration as part of a broader security posture summary.

Related Reading

For the foundational concept, start with SMTP Banner. For how attackers use banners as part of broader reconnaissance, read SMTP Fingerprinting. For the specific risks a verbose banner introduces, see Mail Server Banner Security. For step-by-step configuration instructions, read Hide SMTP Banner. For a broader hardening checklist, see Banner Best Practices.

🔗 Related Tools

📧
SMTP Tester
Look up mail servers & test connectivity
📧
MX Lookup
Check mail exchange records & priority
🛡️
DMARC Lookup
Check any domain's live DMARC record
🔒
SSL Certificate Checker
Certificate issuer, validity & history

Frequently Asked Questions

The very first line a mail server sends the instant a connection is established — before any command is even issued — typically starting with the response code 220, followed by the server's hostname and, on many default configurations, the specific mail server software name and version, all sent automatically with no request needed from the connecting client.
Web browsers explicitly block JavaScript from opening connections to standard mail ports (25, 465, 587 and others) for anti-abuse reasons, so no browser-based tool — including this one — can open a live SMTP connection. Instead, this tool looks up the domain's mail servers via DNS and generates the exact command to reveal the real banner yourself, in seconds.
A banner revealing specific software and version information lets an attacker instantly narrow their search to known vulnerabilities affecting that exact version, skipping the reconnaissance step entirely — this is precisely why banner information disclosure is treated as a real, if modest, security finding rather than a purely cosmetic detail worth ignoring.
Not on its own — it's an information disclosure issue that lowers the effort required for an attacker who has already found or is looking for a vulnerability in that specific software, rather than a vulnerability in itself. It's worth fixing, but shouldn't be treated as equivalent to an actual exploitable flaw.
Most security guidance recommends minimizing unnecessary detail (specific version numbers particularly) rather than removing the banner information entirely, since a banner is expected, standard SMTP behavior and some monitoring and interoperability tooling relies on at least a minimal, standards-compliant greeting being present.
A port scan determines whether a port is open at all; banner grabbing goes a step further, connecting to an already-known-open port specifically to read the identifying information the service voluntarily offers upon connection — banner grabbing typically happens after a port scan has already confirmed the port is open.
Yes — telnet or openssl s_client, both free and included with most operating systems (or trivially installable), let you connect directly and read the banner in seconds. This tool generates the exact, correctly formatted command for your specific mail server, port, and platform so you don't need to remember the syntax yourself.
No — the banner is purely about the mail server software itself, not the domain's authentication configuration, which lives in entirely separate DNS records. Checking authentication status requires a different tool, like our DMARC Lookup or SPF Lookup.
If a domain has multiple MX records (multiple mail servers with different priorities), each server can run different software, different versions, or different banner configurations independently — checking a domain's banner isn't necessarily checking every server that could accept mail for it.
Reading a banner that's voluntarily offered upon a standard connection — the same information any legitimate mail server would see when delivering mail — is generally considered a normal, non-intrusive diagnostic action, similar to a basic ping. Automated or repeated probing beyond a single diagnostic check is a different matter and should be avoided against systems you don't operate or have explicit permission to assess.
This typically indicates the server administrator has deliberately configured a minimal or custom banner specifically to avoid disclosing software details — generally considered a reasonable, low-effort hardening step rather than anything unusual or suspicious.
Only indirectly — the banner might reveal a specific software version, and you'd then need to separately check whether that exact version has any known, unpatched vulnerabilities. The banner itself doesn't confirm vulnerability, just narrows down what to check.
After any mail server software update or configuration change is the most important time, since an update can sometimes silently revert a custom banner configuration back to a default that reveals more detail than intended — periodic checks alongside other mail server maintenance are a reasonable habit beyond that.
No — banner content has no bearing on deliverability, spam filtering, or how receiving servers evaluate your mail. It's purely a reconnaissance-reduction security measure, unrelated to authentication or reputation.
220, indicating the service is ready. A banner starting with a different code, or no response at all, typically indicates either a non-standard configuration or that what you connected to isn't actually a standard SMTP service on that port.
Yes, in some configurations — a security appliance or reverse proxy sitting in front of a mail server can be configured to substitute a generic banner in place of the real server's own greeting, specifically as an additional obfuscation layer beyond what the mail server software itself controls.
For a static configuration it's typically consistent across every connection to the same server on the same port, though some setups deliberately randomize or rotate slight variations specifically to make automated fingerprinting less reliable.
Configuration steps differ by mail server software — our companion Hide SMTP Banner guide covers the process for the most common platforms directly, alongside the broader reasoning for why and how much detail to actually remove, since going too minimal can occasionally interfere with legitimate diagnostic tooling that expects a standards-compliant greeting.