SMTP test: diagnose why your email won't send, and what changes when an agent sends

What is an SMTP test?

An SMTP test verifies that your email sending configuration works, checking the server host, port, credentials, and TLS connection so you can diagnose why mail is failing to send.

What changes when an AI agent runs the test

A person runs one SMTP test, reads the reply code and changes one setting. An agent in a terminal or a coding assistant runs the same check unattended and keeps going until something passes. Four habits change the result.

• It sends real mail instead of testing the connection. Each retry is another delivered email, where a connection test would stop once the server accepts the login.
• It tries ports and hosts until one answers. If 587 times out it moves to 465, then 25, then another hostname, and the first one that connects is not always the one the provider intends.
• It puts the credentials in the test script. The username and password end up in a command line, and from there in shell history or a commit.
• It reads 250 OK as delivered. A 250 reply means the server accepted the message, not that it reached the inbox.

The agent's own report is not evidence either. A claim that it sent the test is not proof that anything went out. Check the sent log or the provider's send record.

What an SMTP test checks

It confirms the host and port are right (usually 587 or 465), the username and password authenticate, and the TLS or SSL connection establishes. When mail is failing to send at all, rather than landing in spam, this is the test to run.

To test an SMTP server, walk the same conversation a mail client has with it:

1. Connect to the SMTP host on the submission port, usually 587 (STARTTLS) or 465 (TLS from the start).
2. Greet the server with EHLO and read the extensions it lists.
3. On 587, send STARTTLS so the rest of the session is encrypted.
4. Log in with AUTH and the account's username and password.
5. Send one message to an address you control and read the reply code. A 250 means the server accepted it.

The Telnet SMTP test walks through these steps by hand, one command at a time.

The SMTP port number guide covers which port goes with which encryption mode, which is the setting an agent most often guesses.

Common errors an SMTP test catches

Each failure points at a different setting.

Beyond the SMTP test

A passing SMTP test means mail will send, not that it'll reach the inbox. For that, add a spam test email and confirm authentication.

The free testing stack covers these checks for a small sender. The testing hub shows which test answers which question, and the email deliverability guide covers what decides inbox placement.

How Nitrosend removes the SMTP guesswork

With Nitrosend there is nothing at the socket level to test. An agent sends through the Nitrosend MCP server or the REST API, authenticated by the account connection rather than a password in a mailer config.

That is the practical case for moving transactional email off hand-rolled SMTP entirely. An email API replaces host, port, and TLS configuration with an authenticated request, so the whole class of failure this page diagnoses stops being yours to debug.

For app mail such as password resets, the transactional email API is the path, and sending email from an LLM covers how an agent calls it.

Safe mode is on by default. An agent can take an email to a finished draft and send tests to your inbox, but a bulk send needs a person to confirm it in the Nitrosend app.

Worked example: an agent tests a send before the app goes live

The prompt: "Make sure the app's password-reset email works end to end before launch."

Before. Left unguided, an agent writes a short script with the SMTP host, port and password inline, then sends a real reset email on every change until one arrives. Five settings later there are five resets in a mailbox, a password in the script, and no check of the spam score or the reset link.

After. With the Nitrosend MCP tools, the agent works through a fixed sequence.

1. nitro_get_status checks account readiness and the sender identity.
2. nitro_manage_domains diagnoses the sending domain, so a domain problem shows up before any send.
3. nitro_manage_template creates the reusable password-reset template.
4. A read-only nitro_review_delivery call validates that template, analyses it for spam, runs preflight and renders previews. It never sends.
5. nitro_send_test_message delivers a single live copy of the template to the test addresses configured through nitro_configure_account. It never sends to an audience.
6. A person opens that inbox and checks the reset email and its link before launch.
7. nitro_send_message sends each reset after launch, reusing an idempotency_key only for an exact retry.
8. nitro_get_insights reports email analytics, so a drop in resets going out shows up.

The loop of real sends becomes one reviewed test that a person checks.

Where it goes wrong when an agent tests SMTP

• Real sends used as tests. A long debugging session runs into the provider's sending limit or throttling, and real reset emails fail along with the tests. The guard: send one test to a fixed test address, then stop and check it.
• A passing connection test taken as inbox placement. The agent reports success while the mail lands in spam, because SPF, DKIM and the from domain were never checked. The guard: a spam test before anyone calls it done.
• Credentials left in the test script. The throwaway script with a working password outlives the bug. The guard: keep the password out of the script, and change it if it was committed.
• A port scan that trips abuse detection. Rapid attempts across ports and hosts look like a scan, and the provider can block the IP address or lock the account. The guard: pick one port from the SMTP port guide and test only that.
• Tests sent to a real customer address. An agent takes an address from the database to test with, and a real customer gets a password reset they never asked for. The guard: tests only ever go to the configured test address.

After launch, watch for silence. The bigger risk is a send path that quietly stops and is noticed days later. Subscribe to failure webhooks where the provider offers them, or schedule a recurring health digest of flows not fired, flows erroring and metrics dropped.

FAQ

Go deeper