Telnet SMTP test: the manual session, and what changes when an agent runs it

What is a telnet SMTP test?

A telnet SMTP test manually connects to a mail server over the command line to test the SMTP conversation step by step, useful for low-level diagnosis of sending problems. In practice you open a session to the server on port 25, or 587 for submission, send EHLO, and read the reply code the server returns to each command after it.

Over an encrypted session on the submission port, the commands look like this, with the host and addresses replaced by the ones under test.

openssl s_client -crlf -quiet \
  -connect smtp.example.com:587 -starttls smtp
EHLO client.example.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
QUIT

The -quiet flag matters. Without it, openssl reads a typed line that starts with a capital R as its own renegotiate command, so RCPT TO never reaches the server. -crlf sends the line endings SMTP expects. Port 465 is TLS from the first byte, so there you drop -starttls smtp and connect to smtp.example.com:465.

Without a login, a submission server usually answers MAIL FROM with 530, and that is a finding in itself: the host is up, TLS works and it wants authentication. Add an AUTH PLAIN <base64-credentials> line after EHLO only when the login itself is under test, and rotate that password afterwards.

To send one real message, carry on past RCPT TO with your own mailbox as the recipient. This sends a real email.

RCPT TO:<[email protected]>
DATA
Subject: SMTP session test

One line of test body.
.
QUIT

The single dot on its own line ends the message, and a 250 after it means the server accepted it. A coding assistant or an agent working over MCP runs unattended and treats whatever it reads as the answer, so how it runs the test matters as much as the result.

What changes when an AI agent runs a telnet SMTP test

An agent with terminal access can do what a sysadmin does by hand. It opens an encrypted session with openssl s_client -starttls smtp, sends EHLO, and reads every reply verbatim. Those codes are the diagnosis, and an agent reading them directly gets the detail a library would have thrown away.

The same access makes the session riskier. Past DATA it sends real mail, port 25 often times out from a cloud workspace, and a typed AUTH line stays in the agent's transcript. The failure list below covers each one.

What a manual SMTP session is for

Telnet (or openssl for encrypted connections) lets you type the SMTP commands by hand, EHLO, MAIL FROM, RCPT TO, and read the server's raw responses. It's the lowest-level way to see exactly where a send fails, favored by sysadmins debugging a stubborn server issue. A sending library usually reports a failure as one generic error, while the session shows which command the server rejected and the text it gave for rejecting it.

Why plain telnet on port 25 rarely works now

Plain telnet on port 25 rarely works from a typical network now. Many cloud hosts block outbound 25 by default, and most servers require TLS and authentication before they accept any mail command. In practice you use openssl s_client as above, on 587 with -starttls smtp or on 465 with TLS from the start.

The SMTP test page covers testing a mail setup before an app goes live. The manual session is the tool when one send fails and you need the server's own reply to a specific command. The SMTP commands reference covers what each command does and the replies to expect.

What a manual SMTP test does not prove

A manual SMTP test proves the server talks, not that mail reaches the inbox. That still depends on authentication and reputation.

Once the socket is proven, the useful next steps move up the stack. Sending a real test email to a seed set answers where the message lands, and a Mail-Tester score reports what the content and authentication look like from the receiving side. The testing hub covers the order to run them in, and email deliverability is the wider problem they are all sampling.

Worked example: an agent diagnoses a password-reset email that never arrived

The setup: the app sends each password-reset email through Nitrosend with nitro_send_message.

The prompt: "Users say the password-reset email never shows up. Find out why."

Before. Left unguided, the agent ignores the account, looks up a mail host and probes it by hand with openssl s_client. It types a full DATA block to its own address and reports success on a 250, which proves that host takes mail and says nothing about why users never got their resets.

After. With the Nitrosend MCP server connected, the agent asks the account instead of opening a socket.

1. nitro_get_status reads the account context and readiness, and confirms which sender identity the reset email goes out from.
2. nitro_get_insights pulls the account's email analytics, with trends and recommendations, so the agent can see whether resets are going out at all and when the numbers changed.
3. nitro_manage_domains diagnoses the sending domain behind the reset email. In this example it finds a DNS record missing on that domain, which is the cause, and the fix is to publish that record at the domain's DNS host.
4. nitro_review_delivery checks the reset template's content and readiness once the record is in place. It sends nothing.
5. nitro_send_test_message sends a single real reset email from that template to the account's test recipient, never to users.
6. A person opens the test reset, follows the link and confirms it works before the app's next nitro_send_message call goes out.
7. nitro_get_insights is read again once the app resumes sending, to confirm the resets are going out and being delivered.

The agent's report names the cause, the missing record on the sending domain, the fix, and the delivery numbers after it, instead of a reply code from a session it did not need to open.

Where it goes wrong when an agent tests SMTP by hand

• A timeout read as "server down". Telnet to port 25 from a cloud VM or CI runner usually hangs, because the host blocks outbound 25. An agent that reads the silence as an outage sends the whole investigation the wrong way. The guard: test the submission port from a network that allows it, 587 with -starttls smtp or 465 with TLS from the start, and report a timeout as a timeout.
• A real DATA block sends a real email. Past DATA the session is no longer a test. The body the agent types, ended with a single dot, goes to whatever address it gave in RCPT TO. The guard: stop at RCPT TO, then QUIT, and go past DATA only to your own mailbox.
• AUTH PLAIN base64 left in logs. AUTH PLAIN takes the username and password as one base64 string, which is encoding, not encryption. Typed into a terminal, it lands in the shell history, the agent's transcript and any CI log. The guard: leave AUTH out unless the login itself is under test, since a 530 on MAIL FROM already shows the server wants one, and rotate the password if it was typed.
• The MX host tested instead of the submission host. The MX host receives mail for a domain, while the submission host accepts mail from the app. An agent that looks up MX records and tests those proves the domain can receive mail, which says nothing about why the app cannot send. The guard: test the host and port in the app's own mail settings.

How Nitrosend takes the socket out of the test

With an email API there is no socket to test. Running transactional email over your own SMTP plumbing means every port block and TLS mismatch is yours to diagnose by hand. An email API turns the same send into one authenticated request that returns an error the code can read when it fails.

That matters more with an AI agent in front of it, because typing raw SMTP commands into a socket is manual configuration at its most literal. Describe the send in Claude, ChatGPT or Cursor and the agent calls nitro_send_message through Nitrosend's MCP server. A failure comes back as an error, and an exact retry reuses the same idempotency_key, so a retry cannot send twice.

The larger risk with agent-run email is a silent failure: a send path that quietly stops and is caught days later. A socket test run once does not catch that. Catch it with failure events through email webhooks, or with a recurring health check of what did not send.

Reset links, receipts and other app mail go through the transactional email API, so a failed send comes back to the code as an error it can act on.

FAQ

Go deeper