Common providers
Published hostnames are the fastest route, and the major providers document theirs.
Published hostnames by provider
the fastest route to the answerGmail 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, both listed in Microsoft's settings reference. Yahoo uses smtp.mail.yahoo.com, in Yahoo's server settings page.
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.
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 goes to die quietly. Chong, on our team, unblocked a customer whose sending domain would not enable, and the whole fix was two DNS entries, an MX for the bounce subdomain and a TXT record carrying the SPF include for the provider actually sending the mail. Enabling a sending domain is always that pattern. 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.
The alternative is a submission service authenticating as a verified sending domain, which supplies the reporting layer a mailbox cannot.
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, and a settings page that says "your domain" does not say which one.
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. Chong flagged exactly this against our own settings page, and the change we specified lets you choose a separate sending domain explicitly even when it shares the root with the domain recipients see.
MX records are the other reliable source of confusion, because they answer a different question entirely. They govern where your mail is received, not where you submit it, so reading a submission host off an MX lookup produces a hostname that will not authenticate you.
When settings look correct and mail still misroutes, check what is actually being used rather than what is configured. We have had sends routed through a configuration set that did not exist while the stored configuration looked entirely correct, which is invisible until you inspect the send path rather than the settings page.