How do I find my SMTP server, and should your agent use one at all

Common providers

Published hostnames are the fastest route, and the major providers document theirs.

Gmail and Google Workspace use smtp.gmail.com, documented in Google's mail client setup guide. Microsoft 365 uses smtp.office365.com, and consumer Outlook.com uses smtp-mail.outlook.com, listed in Microsoft's Outlook.com settings reference. Yahoo uses smtp.mail.yahoo.com, in Yahoo's server settings page, and the Yahoo SMTP guide walks through the setup.

A custom domain does not change this. A business running its mail on Google Workspace still submits through smtp.gmail.com, because the hostname belongs to the mail operator rather than to your domain name.

Port and encryption travel with the hostname. Submission is port 587 with STARTTLS or port 465 with implicit TLS, and every provider above requires authentication. The guide to SMTP ports covers which one to use.

When an AI agent asks for your SMTP server

A coding agent asked to send email from an app often stops and asks for an SMTP host, port, username and password, because that is the shape most email libraries expect. It wants the four values so it can write them into a config file or an environment variable and carry on.

For a person's own mailbox, handing over those values is fine. The provider's published hostname from the table above, port 587 and the account's credentials are exactly what a mail client needs. If the mailbox is Outlook, how to find the SMTP server in Outlook walks through the client screens.

For an app or an agent that sends on its own, the same values tie every message to one mailbox. The app inherits that mailbox's sending limits, its password sits in code, and the mail goes out under one person's account rather than the business's domain.

The alternative is to skip the lookup. The transactional email API and the wider email API take the message over HTTPS with an API key, and the Nitrosend MCP server lets an agent call sending tools directly. Nitrosend has no SMTP host to look up, so when an agent asks for one, the answer is an API key or an MCP connection. Sending email from an LLM covers that setup end to end.

Check in an email program

An already-working mail client holds the answer, and reading it there avoids guessing.

In Outlook on Windows, the value sits under account settings, in the server settings for the account, listed as the outgoing or SMTP server. Apple Mail on macOS keeps it under the account's server settings, in the outgoing mail server list. On iPhone and iPad it is under the mail account's advanced settings, in the outgoing server entry.

Read the port and encryption mode at the same time. A hostname without its matching port and security setting is half the configuration, and the pairing is what most connection failures come down to.

Copy the username exactly as the working client has it. Some providers expect the full address and others accept a local part alone, and this is not something to infer.

Ask your host or check DNS

For a domain with its own mail infrastructure, the hosting provider or IT administrator holds the value. Shared hosting control panels typically publish it in an email accounts section, often as mail.yourdomain.com.

DNS gives a strong hint but not a direct answer. An MX lookup on your domain returns the servers that receive mail for it, which frequently identifies the operator: a domain whose MX records point at Google or Outlook is almost certainly submitting through those providers too. MX records are for inbound routing, so this is inference rather than the setting itself.

The distinction worth holding on to is that receiving and sending are separate systems. MX records say who accepts mail addressed to you, while the SMTP submission host is where your client hands mail out. Those two can belong to entirely different providers.

DNS is also where sending stalls quietly. A sending domain has to be set up in DNS before mail goes to a list, and Nitrosend checks the domain's DNS before a first send so SPF problems show up before anything goes out. The records are trivial one by one and useless unless all of them are present.

When the answer is that you should not use one

Finding a personal mailbox's SMTP server solves the problem of configuring a mail client. It does not solve the problem of an application that needs to send.

Mailbox submission carries per-user rate limits sized for a person, sends as an individual rather than as your domain, and provides no delivery events, bounce classification or suppression handling. An application outgrows it quickly, and the failure at that point is a throttled account rather than a clear error.

Use an email API that sends as your verified domain and reports what happened to each message.

Worked example: an agent sets up invoice email for a domain with no SMTP server

A small company hosts its website on a static host that runs no mail. There is no mail. hostname to find, and whatever MX records the domain has point at a separate mail provider. The team asks a coding agent to wire up invoice email.

Prompt: "We host our site on a static host with no mail. Set up invoice emails from billing@ our domain and send me one to check."

Before, unguided: the agent reads the domain's MX record, puts that incoming server into the app as the SMTP host, and the first send fails. The server accepts mail addressed to the domain, but it does not take submissions from the app.

After, the gated sequence:

1. nitro_get_status reads the account context, sender identity and readiness, so the agent knows whether a sending domain is ready before it writes any code.
2. nitro_manage_domains adds and verifies the customer sending domain. Nitrosend's sending domains guide advises a subdomain such as send.yourdomain.com, never the bare domain, because inbox providers like Gmail expect a subdomain setup. A person publishes the DNS records at the domain host, and the agent verifies again until the domain is ready. Invoices then go out from a billing address on send.yourdomain.com.
3. nitro_manage_template creates a reusable invoice template with fields for the invoice number, amount and due date.
4. nitro_review_delivery runs the read-only review of the template: validation, spam analysis, preflight and a preview. It never sends.
5. nitro_send_test_message sends one real test of the invoice template to the test recipient set with nitro_configure_account, never to a customer.
6. A person opens the test and checks that the from address is the billing address on send.yourdomain.com, then the amounts and the layout.
7. The billing system sends each invoice as one transactional send through the transactional email API, the same single send an agent makes with nitro_send_message. Each invoice carries its own idempotency_key, reused only for an exact retry of that invoice, so a timeout and retry never sends the same invoice twice.
8. nitro_get_insights reports email analytics with trends, benchmarks and recommendations once invoices are going out.

Result: no SMTP host appears anywhere in the app, and a person saw the invoice before a customer did.

Where it goes wrong when an agent goes looking for an SMTP server

Most wrong answers to this question are real hostnames that belong to a different job. These are the ones that show up when an agent searches for the server on its own.

• The MX host taken for the outgoing server. An MX lookup is the easiest DNS query to run, and it returns the server that receives the domain's mail. Written into the app as the SMTP host, it refuses the app's login, because receiving and submission are separate systems.
• A guessed smtp.yourdomain.com. Having seen smtp.gmail.com and smtp.office365.com, an agent can invent the same shape for any domain. On most domains that name has no DNS record at all, so the app fails with a lookup error rather than a mail error.
• The web host's shared mail server used for app mail. The mail.yourdomain.com from a hosting control panel does accept submissions, but it is sized for a few people's mailboxes. Password resets and invoices run into the host's daily sending cap, and mail stops partway through the day with nothing in the app to say why.
• A personal account's credentials reused for the app. The agent finds a working mail client, copies its username and password into an environment file, and the app now sends as one employee. When that person changes the password or leaves, every app email stops, and the credential has been sitting in code and logs.

The fix is the same in each case. Give the app a verified sending domain and an API key or MCP connection, as in the worked example above, instead of a hostname found by searching.

The settings are published, and the confusion is usually about which domain

Finding a submission host is a documentation lookup rather than a discovery process. Every provider publishes theirs, and reading it from the provider beats inferring it from a third-party article that may describe a different service.

The genuine confusion is about which of your domains is involved, and it catches experienced people. The domain in your email address, the domain that gets verified for sending, and the domain in the MX records that receive your mail can all be different.

A sending domain sharing a root with your main domain is where this bites hardest. Choosing a separate sending subdomain while both sit under the same root is a legitimate configuration that interfaces routinely obscure, and users end up unsure whether they have configured one thing or two. Pick the separate sending subdomain explicitly, even when it shares the root with the domain recipients see.

When settings look correct and mail still misroutes, check what a sent message actually used rather than what the settings page shows. The send path can differ from the stored configuration, and only a sent message shows which one won.

This whole class of confusion, a sending domain versus a receiving domain, a submission host versus an MX record, exists only because a person has to read documentation and match it to a settings field by hand. An agent sending through Nitrosend has no SMTP host to look up. The sending domain is verified once with nitro_manage_domains, using DNS records a person publishes, and sends go out from it after that.

Go deeper