What is an SMTP server and how to choose one

TL;DR: An SMTP server accepts, routes, and delivers email using a store-and-forward protocol. A message's full journey spans four roles (MUA, MSA, MTA, MDA), and the MUA is client-side software that connects to the server. Self-hosting Postfix or Exim gives you control and no per-email fees, but you pay for your own infrastructure and own IP reputation, DNS records, security patching, and deliverability monitoring. Managed relays trade per-email cost for less operational work, since you don't run your own MTA. Depending on the provider, they may include pre-warmed IPs, suppression list management, and delivery event webhooks. Choose self-hosting for full control at high volume, or a managed relay for faster deployment and lower operational overhead.

An SMTP server is the mail infrastructure that accepts, routes, and delivers email using the Simple Mail Transfer Protocol. It handles routing and delivery once a message is submitted. A message's full journey, however, spans four distinct roles: a Mail User Agent (MUA) that composes messages, a Mail Submission Agent (MSA) that accepts them from clients, a Mail Transfer Agent (MTA) that routes them between servers, and a Mail Delivery Agent (MDA) that places them in recipient mailboxes. The MUA is client-side software, such as your application or a mail app, that connects to the server and sits outside it. Choosing between self-hosting and a managed relay comes down to how much operational risk you're willing to absorb versus outsource.

Most developers don't need to understand SMTP until a delivery fails at 2 AM and the error log says "554 5.7.1 Relay access denied."

SMTP server fundamentals for developers

RFC 5321 defines the protocol and specifies how servers connect, negotiate capabilities, and transfer messages reliably. This section covers the relay workflow, port assignments, and session commands. The role-by-role breakdown of the MUA, MSA, MTA, and MDA appears once, in the delivery workflows section below.

Understanding SMTP relay workflow

When your application sends an email, the message doesn't travel directly to the recipient's inbox. Instead, it moves through a series of servers, each taking responsibility for the next hop. The sender's mail server extracts the domain from the recipient address, queries DNS for MX records of that domain, and receives a list of mail exchangers with priority values.

The protocol distinguishes between three port assignments. Port 25 handles server-to-server relay, port 587 manages client submission with authentication, and port 465 provides SMTPS (SMTP over SSL). Port 587 is the current recommended standard for email client submission. RFC 2476 originally defined it in 1998, RFC 4409 carried it forward, and RFC 6409 now maintains it.

The EHLO command initiates an SMTP session and negotiates extensions. The server responds with a multi-line reply listing which SMTP service extensions it supports, including STARTTLS for opportunistic TLS encryption, AUTH for SMTP authentication mechanisms, and SIZE for maximum accepted message size.

Submission versus relay on port 587

Client submission and server-to-server relay run on separate ports so that servers can apply different policies to each. RFC 6409 maintains port 587 for email submission. Unlike port 25, which was designed to accept connections from anyone, port 587 requires authentication, typically with a username and password or an API key, before the server accepts a message.

Understanding SMTP delivery workflows

The sections below walk through the four roles in the order a message encounters them: MUA, MSA, MTA, and MDA.

Connecting clients to SMTP servers

The Mail User Agent (MUA) is the software that users interact with to send, receive, and manage email. When your application calls smtplib.SMTP() or uses an SDK, the application implements MUA functionality, while the library only handles the SMTP client connection and is not the MUA itself. The MUA connects to an MSA on port 587, authenticates with credentials, and submits the message for processing.

The role of mail submission agents

The Mail Submission Agent accepts outgoing email messages from the MUA and forwards them to the MTA. The MSA handles the initial stage of email submission, checking that the email conforms to standards before sending it further for delivery. This includes verifying that the sender is authenticated, the message format is valid, and the recipient addresses are properly formatted.

The MSA runs on port 587 and requires authentication. This separation of submission from relay (port 25) allows mail servers to apply different policies to authenticated client traffic versus server-to-server relay traffic.

How MTAs route SMTP traffic

The Mail Transfer Agent is responsible for routing emails between servers. When an MTA receives a message from an MSA, it extracts the domain from the recipient address and queries DNS for MX records of that domain. The DNS response returns MX records with priorities, and the sender sorts them by priority (lowest first). For each MX hostname, the sender resolves the hostname to an IP address (a separate A or AAAA lookup), connects to port 25, and attempts the SMTP handshake.

A raw SMTP conversation follows a predictable pattern. The client connects to port 25 and receives a 220 greeting. The client sends EHLO to negotiate extensions, then MAIL FROM to specify the sender, RCPT TO to specify each recipient, DATA to transmit the message body, and QUIT to close the connection. Each command receives a numeric response code: 250 for success, 354 to start mail input, and 221 to close the connection.

telnet mail.example.com 25
220 mail.example.com

EHLO yourdomain.com
250 mail.example.com

MAIL FROM:<sender@example.com>
250 OK

RCPT TO:<recipient@example.com>
250 OK

DATA
354 Start mail input

Subject: Test

This is a test message.
.
250 OK

QUIT
221 Bye


Each command receives a three-digit response code, and the conversation follows a predictable state machine that you can observe and debug.

How MDA handles local email storage

The Mail Delivery Agent performs the final step: writing the message into the recipient's mailbox and running any delivery-time rules. Delivery transfers responsibility from the transfer network to the recipient's mailbox. The MDA handles local message delivery by storing mail into the recipient's environment, typically a mailbox accessible via IMAP or POP3.

Tracing an SMTP message lifecycle

A complete message trace from MUA to MDA follows this sequence: your application (MUA) connects to the MSA on port 587 and authenticates, the MSA validates and forwards to the local MTA, the MTA queries DNS for MX records and connects to the recipient's MTA on port 25, the receiving MTA accepts the message and passes it to the MDA, and the MDA writes it to the recipient's mailbox.

Maintenance costs: self-hosted vs. managed

Self-hosting gives you control and no per-email fees, but you still pay for servers and engineering time, and you own IP reputation, DNS configuration, security patching, and deliverability monitoring. Managed relays trade per-email cost for operational leverage.

Infrastructure requirements for SMTP

Deploying a self-hosted Postfix or Exim server requires specific infrastructure and DNS configuration. You need a server with a consistent FQDN hostname (e.g., mail.example.com), ports 25 and 587 open in the firewall, and access to your domain's DNS records. SPF tells receiving servers which IP addresses are allowed to send mail for your domain, DKIM adds a cryptographic signature to each outgoing message, and DMARC ties SPF and DKIM to the visible From domain with a policy.

IP warm-up is a critical requirement that self-hosted setups often underestimate. A new IP address has no sending history, so receiving servers treat it with suspicion. You need to start with low volume and gradually increase over several weeks to build positive sender reputation. During this period, delivery rates will be lower and more messages will land in spam folders.

Key capabilities of managed relays

Managed relays provide pre-warmed IPs, suppression list management, delivery webhooks, and automatic retry logic without requiring you to run your own MTA. When you send through a managed relay, the provider handles IP reputation monitoring, applies security patches, and manages queue retries with exponential backoff. Blocklist remediation on a dedicated IP varies by provider and often remains your responsibility.

4xx codes indicate temporary failures that may resolve on their own with a retry, such as rate limiting or a full mailbox. Managed relays automatically retry delivery for temporary failures using exponential backoff. Retry windows vary by provider, and some managed relays cap retries at 24-72 hours. They suppress immediately for permanent failures and update suppression lists for hard bounces without manual intervention.

Choosing between custom and managed mail relays

The decision framework for self-hosted versus managed SMTP comes down to four criteria: IP reputation management, hidden maintenance risks, latency requirements, and infrastructure portability. Each criterion has measurable trade-offs that affect your operational burden and delivery reliability.

Optimizing IP reputation for SMTP

Receiving servers accept or reject your messages based on your IP reputation. Shared IP addresses expose infrastructure to neighbor reputation risk: if another sender on a shared IP pool violates sending best practices, your deliverability suffers. Dedicated IPs require sufficient, consistent sending volume to establish positive sender reputation independently, and many providers recommend reaching that volume before moving off a shared pool.

Self-hosting means you start with zero reputation and must warm up your IP gradually. Managed relays provide access to pre-warmed IP pools with established reputation, but you're subject to the behavior of other senders on shared infrastructure unless you pay for a dedicated IP.

Hidden maintenance risks of SMTP relays

Self-hosted SMTP infrastructure fails in predictable ways when you're not watching. Configuration drift causes SPF, DKIM, or DMARC misalignment over time. IP addresses get blacklisted due to reputation damage from compromised accounts or misconfigured forwarding. Unmanaged queue growth during outages can fill disk space and crash the server.

Common failure modes include A record instead of MX misconfiguration, where domains accidentally point the apex at a webmail host rather than setting MX records, and delivery silently fails.

Latency in initial SMTP handshakes

Connection overhead and TLS negotiation add latency to every SMTP session. An unoptimized Postfix server can experience delays from DNS lookup processing, especially without a local caching name server, as well as queue processing and retry scheduling, connection establishment overhead per recipient domain, and spam filter processing, whose cost depends on the filters you configure.

Managed relays optimize for latency by maintaining persistent connections to major ISPs, pre-resolving MX records for common domains, and running spam filters in parallel rather than serially. The actual latency difference between self-hosted and managed varies based on your infrastructure quality and the provider's optimization level.

Portability of SMTP infrastructure

Migration paths between providers matter before you commit to either approach. Moving from one managed relay to another requires updating API credentials, verifying a new sending domain, and updating DNS records. Moving from self-hosted to managed requires the same steps plus decommissioning your server.

API compatibility considerations include:

• Raw SMTP protocol compatibility with existing applications
• API format differences (REST/JSON versus SMTP text protocol)
• Webhook signature verification requirements
• Attachment handling changes (base64-encoded content fields in JSON versus MIME parts in SMTP messages)

Some managed relays accept request formats from other providers to reduce migration effort.

Evaluating popular self-hosted SMTP stacks

Postfix and Exim are the two most widely deployed open-source MTAs. Both handle the MSA, MTA, and MDA roles, but they differ in configuration complexity and typical use cases.

Configuring Postfix for email relay

Postfix is the default MTA on Red Hat Enterprise Linux and current CentOS releases, while Debian configures Exim by default through the exim4 package, which satisfies the mail-transport-agent virtual package. Postfix is also a common choice for self-hosted SMTP. Basic configuration requires setting your hostname, controlling which IPs can relay, and preventing open relay abuse. Postfix works well for straightforward relay scenarios where you need to send email from your application without complex routing rules.

Technical requirements for Exim setup

Exim provides more flexible configuration than Postfix but requires learning its own configuration language. Exim configuration lives in a single file (exim.conf) that uses a custom syntax for defining routers, transports, and ACLs. This flexibility makes Exim suitable for complex routing scenarios, but the learning curve is steeper than Postfix.

Exim makes sense when you need sophisticated routing logic, such as conditional routing based on message headers, integration with external databases for recipient validation, or complex filtering requirements that go beyond Postfix's capabilities.

Use cases for self-hosted SMTP

Self-hosting makes sense in three scenarios. First, high-volume senders (millions of emails per month) can eliminate per-email fees by running their own infrastructure, though they still pay for servers and operations. Second, teams with specific compliance requirements may need full control over mail handling and data residency. Third, organizations with existing mail server expertise and 24/7 operations coverage can absorb the maintenance burden.

Self-hosting is the wrong choice when you need reliable delivery without dedicated operations staff, when your sending volume is too low to justify IP warm-up effort, or when your team's time is better spent on product development than mail server administration.

Production requirements for managed SMTP relays

Managed relays handle rate limits, queue management, and retry logic automatically. Understanding what they handle helps you evaluate whether the operational leverage justifies the per-email cost.

Managing SMTP throughput at scale

Managed relays implement rate limiting per recipient domain to avoid ISP throttling. When Gmail or Microsoft 365 returns a 421 response indicating too many connections, the relay slows delivery to that domain and queues messages for retry. A 4xx code is a deferral: a well-behaved sending server queues the message and retries on a backoff schedule. The retry window depends on the provider or MTA, and some managed relays stop retrying after 72 hours.

Sources by table row: for 421 and 550, see the icemail.ai SMTP error resolution guide, MailChannels SMTP response codes, and SPFwise SMTP error codes. For 450 and 554, see MailChannels and SPFwise only, because the icemail.ai guide doesn't cover 450 and gives no explicit guidance for 554.

The first digit of an SMTP code encodes your action: 4xx means retry, 5xx means suppress immediately. Retrying a permanent rejection actively burns your sender reputation.

Avoiding self-hosted SMTP risks

Managed relays mitigate common failure modes through automated monitoring and response. Deliverability monitoring tracks bounce rates, spam complaint rates, and blacklist status across all major ISPs. Suppression management automatically adds hard bounces and spam complaints to suppression lists to prevent repeated sending to invalid addresses.

When a receiving server returns a 5xx response, the managed relay suppresses that address immediately rather than retrying. When a 4xx response indicates greylisting, the relay retries after the appropriate delay. When blacklist monitoring detects an IP reputation issue, the provider may alert you, but IP rotation and delisting vary by provider. On a dedicated IP, you typically request removal from the blocklist operator yourself and investigate the cause.

Meeting SMTP server delivery benchmarks

Delivery latency expectations vary by receiving ISP and message classification. Time-sensitive sends like OTP codes need to arrive in seconds, while bulk campaign sends can tolerate minutes or hours. Managed relays optimize for latency by maintaining persistent connections, pre-resolving MX records, and prioritizing time-sensitive traffic.

Delivery event webhooks provide real-time notification when messages are delivered, bounced, or marked as spam. This visibility lets you track delivery rates and debug failures without parsing mail server logs. Postmark delivers inbound email as JSON that includes the full body, headers (including a spam score header), and attachments. send.io's inbound routing is designed to deliver the full body, headers, and attachments to your webhook endpoint, and it accepts Postmark's request format, so confirm the payload fields in send.io's documentation and the sandbox. Migration therefore starts with updating credentials and the API base URL, but compare send.io's payload fields against your current parser and regression test before cutover.

send.io provides a managed SMTP relay that handles both outbound delivery and inbound routing under one API. The platform accepts request formats from Resend, Postmark, SendGrid, Mailgun, Mailchimp Transactional, Brevo, and Mailjet, so migration from an existing provider starts with swapping the API base URL and key. Teams should still regression test their templates and webhook parsing against send.io's responses before cutover. For Resend integrations, the starting point is to point the existing resend SDK at send.io by overriding the base URL and API key environment variables (RESEND_BASE_URL and RESEND_API_KEY). Confirm the exact variable names and supported endpoints in send.io's documentation, and test in the sandbox before switching production traffic.

Resend added inbound email support in November 2025, but the webhook is metadata-only and does not include the email body, headers, or attachments. Resend's inbound implementation is webhook-based, and you retrieve the body, headers, and attachments by calling a separate API, with programmatic attachment handling through a dedicated API. send.io's inbound routing is designed to include the message body, headers, and attachments in the webhook payload sent to your endpoint, so confirm the payload fields in send.io's documentation and the sandbox. The send.io homepage describes giving your agents a free inbox, with receive-only mailboxes for verification codes, magic links, and automated tests, and the send.io API documentation covers agent inboxes as a broader capability. The agent inbox creation call returns IMAP/SMTP credentials once, including an inbox-scoped API key, so store them at creation. Because the key is scoped to that inbox, the agent never touches your primary account credentials.

Test inbound routing behavior before committing to an integration. Check send.io's documentation for a sandbox or test mode, or use a non-production domain. Provision a test domain, configure MX records, and verify that webhook payloads include the data your application needs.

FAQs

What port does an SMTP server use?

SMTP uses three ports: port 25 for server-to-server relay, port 587 for authenticated client submission (the current recommended standard), and port 465 for SMTPS (SMTP over SSL). Port 587 requires authentication and supports STARTTLS encryption.

How long does it take to set up a self-hosted SMTP server?

A production-ready self-hosted SMTP server typically requires 1-3 days for the core technical configuration, plus 30 minutes to 24 hours for DNS propagation, depending on your team's experience and DNS provider. This includes Postfix installation, DNS record creation, TLS certificate setup, and security hardening.

Can teams switch from self-hosted to managed SMTP later?

Yes, switching requires updating your application to use the managed relay's API or SMTP endpoint, verifying your sending domain with the new provider, and updating DNS records. Managed relays that accept API formats from other providers reduce the code changes required.

Is a dedicated IP address required for SMTP?

Dedicated IPs make sense when you send high, consistent volume and need isolated sender reputation. Below that volume, shared IP pools from a managed relay provide better deliverability because the provider maintains the pool's collective reputation.

What happens if an SMTP server goes down?

Messages receive 4xx temporary failure responses and are placed in a deferred queue. The sending server retries automatically using exponential backoff, and the retry window depends on the provider or MTA. Some managed relays cap retries at 24-72 hours, while self-hosted MTAs such as Postfix commonly default to a 5-day queue lifetime (maximal_queue_lifetime). When the queue lifetime expires, the server generates a bounce notification to the original sender.

Key terms glossary

MUA (Mail User Agent): The software that composes and sends email. Your application implements MUA functionality when it calls smtplib.SMTP() or uses an email SDK, which provide the SMTP client connection.

MSA (Mail Submission Agent): The system responsible for accepting outgoing email messages from MUAs on port 587 and forwarding them to the MTA after authentication and validation.

MTA (Mail Transfer Agent): The server responsible for routing emails between servers using MX record lookups and SMTP on port 25.

MDA (Mail Delivery Agent): The component responsible for final delivery by writing messages into recipient mailboxes and running delivery-time rules.

MX record: A DNS record type that specifies which mail servers accept email for a domain, with priority values determining the order of delivery attempts.

DKIM (DomainKeys Identified Mail): A cryptographic signature added to outgoing messages that proves the email came from an authorized server for the domain.

SPF (Sender Policy Framework): A DNS TXT record that defines which IP addresses are authorized to send email on behalf of a domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy that ties SPF and DKIM to the visible From domain and tells receivers what to do when neither check passes.

Suppression list: A list of email addresses that should not receive future sends, typically populated from hard bounces, spam complaints, and unsubscribe requests.

Webhook payload: The JSON or form-encoded data sent by a managed relay to your application endpoint when delivery events occur (delivered, bounced, complained).