SMTP server: how it works, and what an agent should send through instead

How an SMTP server works

An SMTP server is the software that accepts outgoing email from a client and relays it toward the recipient's mail server. It authenticates the sender, looks up the destination domain's MX records, and hands the message on, following the transaction defined in RFC 5321. An AI agent wiring email into an app usually does not need to run or even log in to an SMTP server. It needs an API or MCP tools with an idempotency key, a review step and limits, because an agent holding SMTP credentials retries blindly and pastes the password into code. Whether to run a private SMTP server or use a third-party SMTP server is weighed under Running one against renting one.

An SMTP server does two distinct jobs that often run on the same machine. Submission accepts mail from an authenticated client, which is the application or mail app connecting on port 587. Relay passes mail between servers on port 25, unauthenticated, on the strength of the sending domain's reputation and DNS records.

The server confirms the sender is permitted, queues the message, resolves the recipient domain's MX records, and attempts delivery. Temporary failures come back in the 4xx range, and the server retries those on a schedule. Anything in the 5xx range is permanent, which ends the attempt and generates a delivery status notification back to the return path.

Common network ports

Port 587 is the submission port and the correct default for an application. It expects authentication and a STARTTLS upgrade, specified in RFC 3207.

Port 465 carries implicit TLS, where the connection is encrypted before any command is sent. It was deprecated and then reinstated as a recommended submission port by RFC 8314, which is why guidance written between those dates contradicts itself.

Port 25 is for server-to-server relay, not submission. Most cloud and residential providers block it outbound to limit spam, so an application attempting to send on port 25 usually fails with no useful error at all.

Each port, with the settings that go with it, is covered in the SMTP ports guide.

What changes when an AI agent sends through an SMTP server

SMTP gives an agent a password and a socket. There is no idempotency key, no preview, no test lane and no read-back beyond a bounce. A person sending from a mail app works around those gaps without noticing. An agent running unattended does not.

Three problems follow. An agent that hits a timeout retries, and if the first attempt had already been accepted, the recipient gets the message twice. An agent that needs the credential on every run stores it where it can read it again, which usually means the code, a config file or a log. And the relay's 250 means accepted, not delivered. After that the only signal is a bounce, so the agent cannot tell accepted from delivered.

The alternative is an API or MCP tools. A transactional email API takes an idempotency key per message, so an exact retry does not send twice, and delivery events such as delivered, bounced and complained come back through webhooks. The Nitrosend MCP server adds a review step and a single test send before anything reaches a customer. Nitrosend's position, as co-founder George Hartley puts it, is that transactional email should go out directly from Claude and ChatGPT agents without extra tools in between. The wider pattern is covered in sending email from LLMs, and the full developer surface is on the email API page.

Popular provider configuration examples

Gmail uses smtp.gmail.com on port 587 with STARTTLS or 465 with implicit TLS, and requires an app password rather than the account password.

Microsoft 365 uses smtp.office365.com on port 587 with STARTTLS at TLS 1.3 or 1.2, documented in the guide for devices and applications. Microsoft is retiring basic authentication on this path, so use OAuth.

Running one against renting one

The build-or-rent question usually gets argued on software, and the software is the easy part. Anyone can install a mail transfer agent in an afternoon, and a free SMTP server will run on almost any machine. What the operator is actually taking on is reputation management, blocklist monitoring, bounce and complaint processing, DNS authentication, TLS certificate maintenance and abuse handling, indefinitely.

Most teams that compare transactional email services end up separating transport from the layer above it. Renting transport and owning the automation is a different decision from running the mail server, and it is usually the better trade.

A dedicated SMTP relay is what that rented transport usually looks like. It separates application mail from mailbox mail and authenticates as a domain rather than as a person's mailbox, which removes the per-mailbox sending limit and attaches reputation to a domain the sender controls. Verifying a subdomain rather than the apex isolates DNS and sending reputation from the corporate inbox on the main domain. A relay also brings delivery logs per message, authentication managed as configuration, and suppression handling so a hard bounce is not retried into a reputation problem. A hard bounce is permanent, typically a mailbox that does not exist, and the address should be suppressed at once. A soft bounce is temporary, such as a full mailbox or a throttled server, and warrants a retry on a backoff.

Reputation is the part that does not respond to engineering effort. It accrues to the domain and to the sending infrastructure over time, and a new server starts with none. Ramp the first sends and authenticate the sending domain with SPF and DKIM before volume, and the new reputation starts on the right side.

Dedicated IPs are the clearest case of this being misunderstood. Shared pools carry an established reputation built by every sender on them, which helps a new sender. A dedicated IP starts from nothing, needs enough sustained traffic to build a reputation at all, and an unwarmed one performs worse than shared infrastructure with an established history.

For a team that sends with AI, the running-versus-renting question matters less than whether a person needs to be in every send. Nitrosend's view is that a team should ship email directly from the agent it already uses. The Nitrosend app runs inside ChatGPT, and connecting from ChatGPT or Codex lets the whole email stack run inside the agent, on an authenticated domain, with a review and a test before anything reaches a customer.

Worked example: an agent adds order emails without an SMTP server

The prompt, in the developer's own words: Add order-confirmation emails to our app. Do not put SMTP passwords in the code, and show me a test first.

Before. Left unguided, an agent usually writes smtplib code with the SMTP password inline and sends its first test to a real customer address. Nobody reviews the message, and the password now lives in the repository.

After. With the Nitrosend MCP tools connected, the same prompt runs as a gated sequence.

1. nitro_get_status reads the account context, sender identity and readiness.
2. nitro_manage_domains adds and verifies the sending domain the order emails will come from.
3. nitro_manage_template creates the order confirmation as a reusable email template.
4. nitro_review_delivery reviews the template with validation, spam analysis, preflight and previews. It never sends.
5. nitro_send_test_message puts one genuine send of the template in front of the test recipients named in nitro_configure_account. It never sends to an audience.
6. A person checks the test in the inbox and approves the wording.
7. The app sends each order email through the transactional email API when the order is placed, with an idempotency_key per order so an exact retry does not send twice.
8. nitro_get_insights returns email analytics with trends, benchmarks and recommendations once orders are flowing.

The trigger for each message is the app's own order event. Delivered, bounced and complained events come back through email webhooks, which is the read-back SMTP never gave the agent.

Where it goes wrong when an agent holds SMTP credentials

The same failures recur when an agent is handed a username, a password and a port.

• Credentials pasted into code, config commits or logs, where anyone with access to the repository can send as the domain.
• A retry loop that double-sends, because SMTP has no idempotency key and a timeout after the server accepted the message looks the same as a failure.
• A volume spike that trips the relay's rate limit, and after the move to the API the same spike hits the plan limit (Free is 100 to 5,000 recipients per rolling 24h by sender standing). The current allowances are on the pricing page.
• Test sends to real recipients that nobody reviewed, because SMTP has no test lane and the first send is the live one.

Go deeper