How an SMTP server works
An SMTP server does two distinct jobs that often run on the same machine. Submission accepts mail from an authenticated client, which is your 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.
Popular provider configuration examples
There is a reason Gmail examples come first. George pulled all 443 brands (439 users) from our production database and scanned the 252 with a resolvable website, 233 fully. 78% of our users live in a Google mailbox, 52% plain gmail.com signups plus 110 custom domains on Workspace MX, while Microsoft 365 is about 5%.
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. Note that basic authentication on this path is scheduled for deprecation, with OAuth as the recommended replacement. For anyone sending 5,000 or more a day into Outlook, authentication must be SPF, DKIM and DMARC aligned, with DMARC at p=quarantine or stronger.
Key benefits of dedicated SMTP relays
A dedicated relay separates application mail from mailbox mail. The relay authenticates as your domain rather than as a person's mailbox, which removes the per-mailbox sending limit and gives you a reputation attached to a domain you control. A customer-owned domain gives you portable reputation and direct control; we see the deliverability and trust benefit in our own data. Nitrosend can also prepare a protected sender under your brand subdomain on demand, but neither path uses a personal Gmail account or an unverified shared fallback. Verify a subdomain rather than the apex: it isolates DNS and sending reputation from the corporate inbox living on your main domain.
The other three benefits are operational rather than protocol-level: delivery logs and bounce classification per message, suppression handling so a hard bounce is not retried into a reputation problem, and authentication managed as configuration rather than per-client setup.
Bounce classification is the distinction that does the work. A hard bounce is a permanent failure, typically a mailbox that does not exist, and the address should be suppressed immediately. A soft bounce is temporary, such as a full mailbox or a throttled server, and warrants retrying on a backoff. Treating the two identically is how senders either discard recoverable addresses or repeatedly send to dead ones.
The choice between a shared and a dedicated IP is the other decision. Shared pools carry an established reputation built by every sender on them, which helps a new sender and exposes them to others' behaviour. Isolating reputation entirely requires a dedicated IP, warmed from nothing, and that only pays off at sustained high volume.
I will show you what this looks like on infrastructure I run rather than in principle. Behind our own relay, SRS and VERP tie delivery status notifications back to the originating send, ARC carries the authentication verdict validated at ingress across the forwarding hop, and Rspamd inspects the relay's own traffic. The relay port, TCP 2525, is firewall-restricted to our API host, TLS and SMTP authentication are both mandatory, and every one-recipient route and MX snapshot is HMAC-signed so a replayed or altered request is rejected outright.
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. What you are actually taking on is reputation management, blocklist monitoring, bounce and complaint processing, DNS authentication, TLS certificate maintenance and abuse handling, indefinitely.
The cost argument is real at scale. George, our CEO, has run the numbers on it. With decent development resources, bringing your own transport and putting a lightweight automation layer on top can cut costs by 70 to 80 percent compared with an all-in-one platform. At 100,000 contacts sending twice a month, transport runs about 0.80 to 1.00 dollars per 1,000 emails, roughly 160 dollars a month, against perhaps 400 to 600 on a full-service platform.
Those figures are the argument for separating transport from the layer above it, not an argument for operating your own server from scratch. Renting transport and owning the automation is a different decision from running the mail server yourself, and it is usually the better trade. It is the trade we built for: Nitrosend documents and supports five transport providers, SendGrid, Postmark, Resend, Mailgun and Amazon SES, so you keep ownership of the sending infrastructure underneath.
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. For Gmail specifically, domain reputation matters more than IP reputation, and IP reputation carries roughly a 120-day memory, so a mistake made in the first month is still being paid for in the fourth. Switching between two providers is not instant either. George saw at SmartrMail that Gmail and Outlook take a little while to get used to your mail coming from a different place, usually an email or two, so a migration comparison is never immediate. 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. They only start making sense above about a million emails a month, because below that volume there is not enough traffic to establish a reputation on the IP at all, and an unwarmed dedicated IP performs worse than shared infrastructure with an established history.
George's honest summary after a decade of building email tools, including SmartrMail, which sent six billion emails before it was acquired: the server is not the hard part, and treating it as the hard part is how teams end up owning an operational burden that buys them nothing.