How to set up SMTP: host, port, authentication, and what changes when an agent does it

What "setting up SMTP" actually means

SMTP is the protocol your application uses to hand an email to a mail server for delivery. Setting it up means giving your app four things so it can log in to that server and send: the host, the port, the encryption type, and a username and password. When an AI agent such as Claude, Codex or Cursor does the setup, it writes those four values unattended, so a stale host or a pasted password goes straight into the code.

If you searched for setting up an SMTP server, you rarely need to run one. You need an account on one, and this page covers that. Every provider-specific search is a variation on those four values, and the SMTP ports hub covers each one. If you do not know the host yet, start with how to find your SMTP server.

For most setups it looks like this:

• Host: the address of the outgoing server, for example smtp.gmail.com or smtp.office365.com
• Port: 587 for TLS (the modern default) or 465 for SSL (legacy)
• Encryption: STARTTLS on 587, or implicit SSL on 465
• Authentication: your account username and a password or app password

Ports: 587, 465, and the one to avoid

Three ports come up constantly. Only two of them are worth using.

• Port 587 (submission, STARTTLS): the one you want. Your client connects in plaintext and upgrades to TLS before sending credentials. Nearly every provider supports it.
• Port 465 (implicit SSL): encrypted from the first byte. It was deprecated, then un-deprecated, and it still works everywhere. Use it if 587 is blocked on your network.
• Port 25: the original relay port. Almost every residential ISP and cloud host blocks it outbound to stop spam. Don't build on it.

If sending fails and everything else looks right, the port is the first thing to check. The full set of values per client is in SMTP configuration.

What an agent does differently when it sets up SMTP

Ask a coding assistant to make an app send email and it will often reach for SMTP, because SMTP is all over its training data. It works unattended, so the mistakes a person would catch on the second try go straight into the code:

• Settings from memory. The agent writes the host, port and login from what it has seen before. That can mean a stale host, or basic-auth code for a Microsoft 365 tenant where SMTP AUTH is switched off, or a normal Gmail password where an app password is required.
• A password in the code. To make the first send work, it pastes the mailbox password into a config file, a test script or a log line, and the credential ends up in version control.
• Retries in a loop. When a send times out, it tries again, and again. Without a key that marks the retry as the same message, each attempt can deliver another copy.
• Port cycling. When port 25 is blocked on a cloud host, it tries 25, then 465, then 587, then other ports, instead of asking whether this host should be sending SMTP at all.

A personal mailbox is also a poor home for an agent. Gmail will not let an agent hold its own address, and mailbox plans are priced per person. Sending a transactional email through an agent with the email API or MCP removes the boilerplate and the SMTP settings together.

Provider settings you're probably looking for

Most people searching for SMTP setup are wiring one specific mailbox into one specific app. The values you need:

Gmail. With 2-Step Verification on, Gmail rejects a normal password over SMTP. Generate an app password from your Google account security page and use that. The steps are in Gmail app password for SMTP.

The full values are in Gmail SMTP settings. For a Workspace domain that sends from devices or apps, Google SMTP relay is the other route.

Microsoft 365. Many tenants have SMTP AUTH disabled by default, and an admin has to turn it on per mailbox. The full values are in Office 365 SMTP settings, enabling SMTP AUTH is covered in SMTP authentication for Office 365, and personal Outlook.com and Hotmail accounts are in Hotmail SMTP settings.

Yahoo. The full values are in Yahoo SMTP settings.

A sending service on your own domain. Some give you an SMTP host with an API key as the password. Nitrosend gives you an API key and MCP instead. Either way, the scaling comes from the verified domain, not the port.

Worked example: an agent is asked to set up SMTP for app mail

The prompt: "Set up SMTP so our app can send signup emails."

Before. Left unguided, an agent puts one person's mailbox address and password in .env, points the app at smtp.gmail.com on port 587, and resends on every timeout. The first signup works. The mailbox send limit, the password and the reputation all belong to one person.

After. The app gets a verified sending domain and an API key instead of SMTP settings. The agent reports there is no SMTP credential to configure and sets up the API path instead, through a fixed sequence of Nitrosend MCP calls:

1. nitro_get_status gets the account context, sender identity and readiness.
2. nitro_manage_domains adds and verifies the company's customer sending domain.
3. nitro_manage_template creates a reusable signup template.
4. nitro_review_delivery inspects that template read-only, returning validation, spam analysis, preflight results and previews. It never sends.
5. One real copy goes out next, via nitro_send_test_message, and only to the test recipients saved with nitro_configure_account. It never sends to an audience.
6. A person checks the test before any new user gets a signup email.
7. The app sends each signup email through the transactional email API with one idempotency_key per signup, so a retry of the same signup never sends twice.
8. nitro_get_insights then reports email analytics with trends, benchmarks and recommendations.

Adding the DNS records for that domain is usually the step a person does, because domain setup is the one part an agent cannot finish alone.

Where it goes wrong when an agent sets up SMTP

• Credentials committed or logged. A mailbox password pasted into a config file or printed in a debug log ends up in the repository and in log storage. Keep credentials in a secret store and out of anything the agent prints.
• Port cycling when port 25 is blocked. Cloud hosts block outbound port 25, and an agent that keeps trying other ports is working around the block instead of moving the send to an API over HTTPS.
• A retry loop with no idempotency key. A loop that resends on every timeout delivers the same email two or three times, and repeat sends look like abuse to filters.
• Product mail on one person's mailbox limits. A personal mailbox caps daily sends and carries one person's reputation, so signup and reset emails stop when the cap is hit.
• The wrong thing in the sending domain field. A new user who did not know what a sending domain was typed their own email address there. The field wants a domain the company controls, such as a subdomain of its website.
• Sending limits. On the Free plan, recipients per rolling 24 hours run from 100 to 5,000, tiered by sender standing, so an agent that batches catch-up sends can run into the limit. The tiers are on the pricing page.

Why the mailbox route breaks down

Gmail and Outlook SMTP are fine for a contact form or a low-volume script. They fall apart the moment you're sending on behalf of a product.

Personal mailboxes cap daily sends, they aren't authenticated for your own domain, and the deliverability is tied to a reputation you don't control. Once you're past "the occasional automated email" you need a real sending path: your own verified domain, SPF and DKIM, and a server built to send at volume.

At volume the bar rises. Outlook requires SPF, DKIM and DMARC from senders above 5,000 messages a day. Have all three align, with DMARC at p=quarantine or stronger. SMTP authentication covers the login side of this.

Why there is no Nitrosend SMTP host

Nitrosend does not hand out SMTP credentials. Apps send through the API, the CLI or MCP.

The SMTP step is one people do once, forget, and look up again the next time. Nitrosend removes it. An account is connected from inside the AI agent, in Claude, Codex, Cursor or any client that speaks MCP, and a test email can go out in the same session. The order is to connect the agent, set up a sending domain, then send a test.

For code that sends without an agent, the same sending runs through the REST API from any language, covered in send email programmatically and Python email automation.

FAQ

Go deeper