SMTP outgoing mail server: what it is, the settings, and what changes when an agent sends

Outgoing versus incoming

A mail client holds two independent configurations. Sending runs through the outgoing block over SMTP, while retrieval runs through a separate incoming block over IMAP or POP3.

They frequently belong to the same provider, usually have different host names, and always use different ports and protocols. A client configured with only the outgoing block sends successfully while showing an empty inbox, which is the usual symptom when half a configuration was copied.

Sending and retrieval are separate protocols by design. SMTP has no concept of a mailbox, folders, or read state, so nothing about the outgoing server tells you anything about where received mail lives.

What changes when an AI agent fills in the outgoing server

An AI coding agent asked to make an app send email reaches for the outgoing server settings it has seen most often. It guesses a host name such as smtp.yourdomain.com, picks a port, and writes the username and password into the config file beside them.

A mail client shows a person the rejection or the bounce. An agent running a background script has no screen to read. At best it sees a connection error, and when the server accepts the message and the bounce arrives later in a mailbox nobody watches, it sees nothing at all.

An outgoing server suits a mail client with one person behind it. For an app or an agent, an HTTPS API such as the transactional email API or the email API, or the Nitrosend MCP server, replaces the host, port and password with an API key and a signed request.

Nitrosend gives an app or agent no SMTP host name to enter. Sends go through the API or the MCP server, and delivery events come back through webhooks instead of a mailbox.

George Hartley, Co-founder, describes the setup as connecting an agent such as Claude, Codex, ChatGPT or Gemini and setting up the sending domain from there. The guide to sending email from an LLM covers the same flow from the model's side.

Required configuration fields

Four fields complete an outgoing configuration: the server name, the port, the encryption mode and a credential made of a username and password.

The server name is the provider's published SMTP hostname, and hosting providers publish their own pairs the same way, Hostinger and Rackspace included. Use the name rather than an IP address, because providers move infrastructure behind it.

The port is 587 for a STARTTLS upgrade, specified in RFC 3207, or 465 for implicit TLS, reinstated as a recommended submission port by RFC 8314.

The encryption mode pairs with the port and must match it. Selecting SSL on 587, or STARTTLS on 465, produces a connection that hangs rather than returning a clear error, and that mismatch is a common fault on this setting.

The username is normally the full email address including the domain. Many providers reject a local part alone.

The password is increasingly not the account password. Providers with two-step verification issue application-specific passwords for mail clients, and Microsoft 365 accepts SMTP AUTH only on mailboxes where it has been enabled.

Authentication is not optional

Every modern submission server requires authentication before it will relay. A server that accepts and forwards mail from anyone is an open relay, which is the configuration that made large-scale spam viable and which gets a host blocklisted quickly.

Authentication also has to happen after encryption. A client issuing AUTH before completing STARTTLS on port 587 is refused, and the resulting error usually reads as a credential problem rather than a sequencing one.

Common provider values

Gmail and Google Workspace use smtp.gmail.com on 587 with STARTTLS or 465 with implicit TLS, requiring an app password where two-step verification is enabled.

Microsoft 365 uses smtp.office365.com on 587 with STARTTLS at TLS 1.3 or 1.2, per the device and application guide. Port 465 is not supported on that path, and SMTP AUTH must be enabled per mailbox.

Consumer Outlook.com and Hotmail use smtp-mail.outlook.com on 587 with STARTTLS.

Worked example: an agent sets up email for a booking app

Prompt: "Our booking app needs to send confirmations. Set it up and send me a test booking email."

Before, with no tools, the agent writes smtp.yourdomain.com on port 587 into the app config with a mailbox password beside it. The host name resolves to nothing, the first send fails, and the agent switches to a personal Gmail login to get the test through.

After, connected to Nitrosend, the agent runs this sequence.

1. nitro_get_status gets the account context, sender identity and readiness.
2. nitro_manage_domains adds and verifies the booking app's sending domain, and diagnoses it if a DNS record is missing.
3. nitro_manage_template creates a reusable booking confirmation template.
4. nitro_review_delivery gives that template a read-only pass covering validation, spam analysis, preflight and previews. It never sends.
5. Then nitro_send_test_message sends exactly one copy of the template to the test recipients configured with nitro_configure_account. It never sends to an audience.
6. You check the test booking email. Nothing reaches a customer until you do.
7. The app then sends each confirmation through the transactional email API, the same single transactional send as nitro_send_message, with one idempotency_key per booking, reused only for an exact retry.
8. nitro_get_insights reports email analytics with trends, benchmarks and recommendations once confirmations are flowing.

The difference in one line: the agent never types an outgoing server host name, and the first confirmation a customer gets is one a person has already seen.

Where it goes wrong when an agent configures the outgoing server

Agents configuring an outgoing server tend to fail in ways specific to these fields.

• A guessed host name. The agent writes smtp. plus the domain, the name resolves to nothing, and a background job fails without anyone seeing the error.
• The incoming host in the outgoing field. An agent copying settings pastes the IMAP host into the SMTP block, so retrieval works and sending does not. The IMAP versus SMTP split explains why the two blocks are configured separately.
• Credentials in source control. The password the agent stored beside the host lands in a committed config file or a log, and anyone with the repository can send as that mailbox.
• A personal mailbox as the app's outgoing server. The agent falls back to a personal Gmail or Outlook SMTP server login, which works until the per-mailbox sending limit locks the account.
• A retry that sends twice. SMTP has no idempotency key, so a script that retries a timed-out submission can deliver the same confirmation twice. An API send with an idempotency_key makes the exact retry safe.

When an outgoing server is the wrong tool

Configuring an outgoing server points a client at one mailbox, which is correct for a person sending their own mail.

An application sending on behalf of a product hits three limits that no server setting resolves.

• Per-mailbox rate caps sized for a person.
• A sending identity that is an individual rather than a domain you manage.
• No delivery events, bounce classification or suppression state reported back to the app.

A submission service that authenticates as a verified sending domain supplies that reporting layer.

The working rule follows from it: send from your own verified domain, never through a personal mailbox account. That is what keeps deliverability strong when the mail is commercial rather than personal, and it holds for every provider in the SMTP ports and settings guides.

To apply it without hand-configuring an outgoing server, connect Claude, Cursor or Codex to the Nitrosend MCP server. The agent verifies your sending domain with nitro_manage_domains, sends you a test, and nothing reaches a customer until you have checked it.

Go deeper