SMTP Relay: How Does It Work? A Practical Setup Guide

SMTP relay is the answer when an application, website, printer, CRM, or internal server needs to send mail without operating a full internet-facing mail server. Understanding smtp relay how does it work means separating the initial handoff from the later journey through DNS, recipient mail servers, authentication checks, and inbox filtering.

What SMTP relay means

SMTP stands for Simple Mail Transfer Protocol. It is the protocol mail systems use to submit, transfer, and deliver email. A relay is a mail server that accepts a message from one system and passes it onward rather than being the recipient mailbox itself.

In a typical application-email setup, your app is the SMTP client. It connects to a relay provider, proves it is authorized to send, submits a message, and receives an acceptance or rejection response. The relay provider then takes responsibility for attempting delivery to the recipient domain's mail server. SMTP was designed for transfer of complete messages between mail systems; the standards distinguish message submission from inter-server relay. (rfc-editor.org)

The word “relay” can describe two related things:

• Outbound SMTP relay: Your software sends through a provider or company mail gateway, which delivers mail to the public internet. This is what most developers mean when configuring SMTP_HOST, SMTP_PORT, a username, and a password.
• Internal SMTP relay: One mail system passes mail to another system inside an organization—for example, an on-premises Exchange server relaying through Microsoft 365, or an email security gateway forwarding mail to a mailbox provider.

The practical purpose is the same: place a controlled, authenticated mail system between the sender and the next delivery hop. That relay can apply rate limits, inspect messages, sign DKIM, manage queues and retries, record events, and protect its network from abuse.

SMTP relay vs. email API vs. receiving email

SMTP relay is an outbound sending interface. It is not an inbox, and it does not retrieve messages. IMAP and POP are mailbox-access protocols; SMTP is for sending and transfer.

An email API solves the same outbound problem through HTTPS requests instead of SMTP commands. With an API, your app typically posts JSON to a provider endpoint. With SMTP, your app uses a long-established protocol supported by frameworks, CMS plugins, scanners, printers, and legacy software. Amazon SES, for example, offers an SMTP interface specifically so SMTP-capable software can send through the service. (docs.aws.amazon.com)

Choose SMTP relay when:

• The software already supports SMTP but not a provider-specific API.
• You need a standard connection method for several systems, such as WordPress, a helpdesk, a POS system, and a scanner.
• You are migrating providers and want less application-specific code.
• You need to route all application mail through one governance and observability layer.

Choose an email API when you need provider-specific capabilities exposed directly in code, such as advanced audience management, template APIs, per-message metadata, or rich event queries. An API is not automatically more deliverable than SMTP; the sender domain, authentication, recipient engagement, content, and provider practices matter much more.

How SMTP relay works, step by step

A real SMTP delivery path usually has more than one hop:

Application, website, device, or mail client
        ↓ SMTP submission with TLS + authentication
Your SMTP relay provider or organization gateway
        ↓ DNS MX lookup and SMTP transfer
Recipient domain's inbound mail server
        ↓ filtering, mailbox rules, and storage
Recipient's mailbox and email client

1. Your application opens a connection

Your app connects to a hostname such as smtp.your-provider.example and a port selected by the provider. The server presents a TLS certificate when the connection is encrypted, and the client should validate that certificate and hostname.

For mail submission, port 587 is the standards-defined conventional port. SMTP transfer between mail servers commonly uses port 25. Port 465 is also widely used by providers for SMTP submission where TLS begins immediately when the connection opens, rather than being upgraded after connecting. Exact hostnames, ports, and TLS modes are provider-specific: use the settings in the provider documentation rather than guessing. (rfc-editor.org)

2. The client and relay negotiate capabilities

The client identifies itself with EHLO, and the server responds with supported extensions. One possible response advertises STARTTLS, AUTH, message-size limits, or internationalized-email support.

With STARTTLS, the client first opens a regular SMTP connection, sends EHLO, confirms that the server advertises STARTTLS, sends STARTTLS, and then performs a TLS handshake. The client should send EHLO again after encryption begins because the available capabilities can change. This sequence is defined by the SMTP TLS extension. (rfc-editor.org)

3. The client authenticates or is otherwise authorized

A public relay must not accept arbitrary mail from arbitrary systems. That configuration would be an open relay, which can be abused to send spam and is unsafe.

A relay normally authorizes senders through one or more controls:

• SMTP username and password, often a provider-generated SMTP credential rather than an account password.
• OAuth-based authentication, where supported.
• A static sending IP allowlist.
• A private network, VPN, or cloud-network rule.
• A connector authenticated by IP address or TLS certificate in enterprise mail systems.

For example, Microsoft 365 SMTP relay uses an inbound connector to identify approved on-premises servers by sending IP address or certificate. Amazon SES uses SMTP credentials that are separate from AWS access keys, and SES credentials are tied to the AWS Region in which they were created. (learn.microsoft.com)

4. The application supplies the envelope sender and recipients

SMTP uses an envelope, which is separate from the visible message headers. The key commands are:

MAIL FROM:<bounce@mailer.example.com>
RCPT TO:<customer@example.net>

MAIL FROM is the envelope sender, sometimes called the return path. It is where delivery status notifications and bounces are ordinarily directed. Each RCPT TO adds one envelope recipient. A server can accept one recipient and reject another in the same SMTP transaction.

This distinction matters because the visible From: field may say Acme Receipts <receipts@example.com>, while the envelope sender uses bounce@mailer.example.com. SPF evaluates the envelope sender domain or the SMTP identity; DMARC evaluates alignment with the visible From: domain through SPF and/or DKIM. A relay configuration that only “looks right” in the visible sender field can still fail authentication or make bounce handling difficult. (rfc-editor.org)

5. The application transfers the message content

After at least one recipient is accepted, the client sends DATA. The message itself follows: headers first, a blank line, then the body. The client finishes the message with a line containing only a period.

A minimal transaction looks like this. The values are illustrative; do not paste real credentials into a terminal transcript or source-control repository.

S: 220 smtp.relay.example ESMTP ready
C: EHLO app.example.com
S: 250-smtp.relay.example
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
   [TLS handshake occurs]
C: EHLO app.example.com
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: AUTH ...
S: 235 Authentication successful
C: MAIL FROM:<bounce@mailer.example.com>
S: 250 2.1.0 Sender OK
C: RCPT TO:<alex@example.net>
S: 250 2.1.5 Recipient OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Acme Receipts <receipts@example.com>
C: To: Alex <alex@example.net>
C: Subject: Your receipt
C: Date: Tue, 14 Jan 2025 12:00:00 +0000
C: Message-ID: <receipt-4821@mailer.example.com>
C:
C: Thanks for your order. Your receipt is attached.
C: .
S: 250 2.0.0 Message accepted for delivery
C: QUIT
S: 221 Bye

A 250 after the message body means the relay accepted responsibility for the message. It does not guarantee that the recipient saw it in the inbox. The relay may still need to resolve DNS, connect to the recipient system, retry temporary failures, or process a later bounce.

6. The relay looks up the recipient domain

For a recipient at alex@example.net, the relay looks up the DNS MX records for example.net. An MX record names the mail exchanger that receives mail for that domain. The relay connects to an eligible recipient mail server and starts a new SMTP exchange, usually on port 25.

If there is no MX record, SMTP rules provide fallback behavior using the domain's address record in some circumstances. In practice, let the relay manage these routing rules rather than coding them in your application. The point of using an outbound relay is that your app only needs to submit mail reliably to one trusted service; the relay handles internet delivery mechanics. (rfc-editor.org)

7. Recipient systems authenticate and filter the message

The recipient server checks technical and policy signals before deciding whether to accept, reject, quarantine, or place the message in spam. Important signals include sending-IP reputation, domain reputation, TLS behavior, message content, complaint patterns, list-unsubscribe behavior for bulk mail, and email authentication.

The core authentication controls are:

• SPF: A DNS TXT policy that authorizes hosts to use a domain in the SMTP envelope identity. SPF helps a receiver evaluate whether the connecting sender is permitted by that domain. (rfc-editor.org)
• DKIM: A cryptographic signature added to a message. The receiving system obtains the public key from DNS and verifies that a responsible domain signed the message and that signed content has not changed in transit. (rfc-editor.org)
• DMARC: A domain policy and reporting mechanism built around SPF and DKIM results, with alignment to the visible From: domain. A DMARC pass requires an SPF or DKIM pass with appropriate alignment. (rfc-editor.org)

These controls are not a magic inbox-placement switch. DMARC itself explicitly does not grant elevated delivery privilege. It does, however, establish clearer domain identity and lets a domain owner publish handling preferences and receive reports. (rfc-editor.org)

The SMTP settings you actually need

Most software asks for the same small set of settings. Your relay provider supplies the exact values.

Do not assume one provider's configuration works at another. Amazon SES, for example, supports STARTTLS on ports 25, 587, and 2587, while it documents TLS-wrapper connections separately; it also requires TLS for its SMTP interface. Some networks block or restrict outbound port 25, particularly in cloud environments, so port 587 or 465 is often the appropriate application-to-relay choice when your provider supports it. (docs.aws.amazon.com)

For developer-owned services, put the values in environment variables or a secret manager—not directly in code:

SMTP_HOST=smtp.provider.example
SMTP_PORT=587
SMTP_SECURE=false
SMTP_USERNAME=your-provider-smtp-username
SMTP_PASSWORD=your-provider-smtp-password
MAIL_FROM="Acme Receipts <receipts@example.com>"

In many libraries, SMTP_SECURE=false means “start unencrypted and upgrade with STARTTLS.” In others, the property name and semantics differ. Check the library documentation carefully: confusing implicit TLS on port 465 with STARTTLS on port 587 is a common connection failure.

If you are integrating sending into a product, use the provider's email API reference and setup guides to confirm its supported authentication method, TLS setting, sender-domain requirements, and event model.

Worked example: relay an order receipt from an application

Assume you run shop.example.com and want the application to send receipts from receipts@example.com. You have selected an SMTP relay provider and created an SMTP credential in that provider's dashboard.

Step 1: verify the sending domain

Add the DNS records the provider supplies for domain verification and DKIM. Providers commonly give you one or more CNAME records for DKIM rather than asking you to type a DKIM public key yourself. Wait until the provider marks the domain as verified before treating sending as production-ready.

For SPF, publish one TXT record for the root domain, not several competing SPF records. The exact mechanism depends on the relay. A syntactically valid IP-based pattern is:

example.com. TXT "v=spf1 ip4:198.51.100.25 -all"

The address above is documentation-only and should not be used in production. A hosted relay normally gives you an include: value or uses a custom return-path domain; copy its published instructions exactly. SPF is evaluated against the envelope-sender domain or SMTP identity, so make sure the domain you authorize matches your actual sending architecture. (rfc-editor.org)

Start DMARC in monitoring mode while you confirm every legitimate sender:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none asks receivers to monitor rather than request quarantine or rejection. Review the aggregate reports, identify all legitimate sources, then decide whether a stronger policy is appropriate. DMARC is a reporting and policy framework, not merely a DNS checkbox. (rfc-editor.org)

Step 2: configure the app

Use the host, port, encryption choice, and SMTP credential provided by the relay. In a Node.js-style configuration, the shape is commonly similar to this:

const transport = createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  secure: false, // typical for port 587 with STARTTLS; provider-specific
  auth: {
    user: process.env.SMTP_USERNAME,
    pass: process.env.SMTP_PASSWORD
  }
});

await transport.sendMail({
  from: 'Acme Receipts <receipts@example.com>',
  to: 'test-recipient@example.net',
  subject: 'Receipt #4821',
  text: 'Thanks for your order.',
  html: '<p>Thanks for your order.</p>',
  headers: { 'X-Message-Type': 'receipt' }
});

The code sample intentionally does not hard-code a provider hostname or a credential. Your library, provider, and port determine whether secure should be true, false, or expressed through another TLS option.

Step 3: send to a mailbox you control

Use a real inbox that you can inspect. Check all of the following:

1. Your application logs a successful submission and stores the provider message ID if one is returned.
2. The relay dashboard or event webhook records an accepted event.
3. The recipient receives the message, either in Inbox, Promotions, Spam, or quarantine.
4. The message headers show the expected From:, Return-Path:, and Received: chain.
5. The recipient's authentication results show SPF and DKIM passing and DMARC passing with alignment where your configuration is intended to support it.

Do not stop at “the code returned success.” A completed SMTP submission proves only the first handoff. Event logs, bounce/complaint handling, and inbox-header inspection prove progressively more of the delivery path.

TLS and authentication: the settings that most often break

SMTP was originally cleartext, so modern deployments must make an intentional encryption choice. STARTTLS upgrades an existing SMTP connection to TLS after EHLO; implicit TLS starts TLS before SMTP commands. Both patterns exist in deployed services, and the port alone does not excuse skipping certificate validation. The relevant standards recommend TLS for mail submission and define server identity verification for email-related protocols. (rfc-editor.org)

Avoid these weak patterns:

• Turning off TLS certificate checks to “fix” a certificate error.
• Sending SMTP passwords over an unencrypted connection.
• Reusing a personal mailbox password in a production app.
• Sharing one credential among unrelated services without a rotation plan.
• Granting a relay permission to send from every domain when the app only needs one sender domain.

Use a unique SMTP credential per environment or service where the provider permits it. Store secrets in a dedicated secret manager, rotate them after suspected exposure, and restrict the credential's sending scope if the relay supports sender-domain or IP restrictions. If a provider uses separate API and SMTP credentials, do not substitute one for the other; SES explicitly documents that its SMTP password is different from an AWS secret access key. (docs.aws.amazon.com)

Deliverability: relaying mail is not the same as reaching the inbox

A reputable SMTP relay solves infrastructure work: authenticated submission, queues, retries, outbound network operations, and provider visibility. It cannot make unwanted, deceptive, or poorly authenticated mail welcome in recipient inboxes.

Build a sender identity that recipients and mailbox providers can recognize:

• Send transactional messages from a domain and display name connected to your product.
• Use a stable From: address; do not rotate identities without a reason.
• Configure SPF, DKIM, and DMARC for each sending domain.
• Use a dedicated subdomain, such as mail.example.com, if you want to separate application-mail reputation from corporate correspondence.
• Process bounces and complaints quickly, and do not continue mailing addresses that permanently fail.
• Keep transactional receipts, password resets, marketing campaigns, and cold outreach operationally separate where their expectations and engagement patterns differ.

Your delivery telemetry should distinguish accepted by relay, delivered to recipient server, bounced, deferred, complained, and opened or clicked when your provider can measure those events. “Delivered” typically means the recipient mail system accepted the message, not that a human read it.

As volume grows, compare sending plans based on the events, retention, dedicated IP options, authentication support, and sending limits you actually need—not on SMTP access alone. Review transactional email pricing alongside the operational requirements of your application.

Common SMTP relay errors and what they mean

SMTP responses have a three-digit status code and may include an enhanced status code such as 5.7.1. Enhanced codes give more structured diagnostic information than the basic SMTP code alone. (rfc-editor.org)

Test basic connectivity without sending credentials or a message where possible. For a STARTTLS endpoint, OpenSSL can show the TLS negotiation and server certificate:

openssl s_client -starttls smtp \
  -connect smtp.provider.example:587 \
  -servername smtp.provider.example

A successful TLS connection only proves that you reached a server and negotiated encryption. It does not prove your account is authorized or that mail will deliver. Then run an application-level test with a controlled recipient and inspect the relay's logs.

How to know your SMTP relay setup worked

A working setup has four separate proofs, not one.

1. Transport proof

The application connects using the intended host, port, and TLS mode. It authenticates successfully and gets a success response after DATA.

2. Relay proof

The provider records the message as accepted and associates it with your account, credential, or event ID. If it records a rejection, deferral, or bounce, capture the complete diagnostic text instead of relying only on your application's generic “send failed” error.

3. Authentication proof

Inspect raw message headers in a receiving inbox. Look for Authentication-Results: and confirm the domain relationships you planned: SPF authorization for the envelope path, DKIM signature verification, and DMARC alignment for the visible From: domain.

4. Recipient proof

Confirm the message arrives in the intended mailbox category and renders correctly on desktop and mobile. Test links, attachments, plain-text fallback, reply handling, and unsubscribe behavior where relevant. Also test a deliberately invalid address so you can see how your system records and suppresses a permanent bounce.

When an SMTP relay is the wrong solution

SMTP is widely supported, but it is not always the cleanest integration. Use a provider API when you need idempotency controls, structured request validation, templates stored at the provider, fine-grained event metadata, or features that are difficult to express through SMTP headers.

Do not use a consumer mailbox SMTP setting as the long-term delivery engine for high-volume product email. Consumer and workspace services can have account-specific limits, authentication requirements, and policies that do not fit application traffic. For example, enterprise relay products may require connectors or IP/certificate authorization, while cloud email providers can require verified identities and provider-specific SMTP credentials. (learn.microsoft.com)

If you operate your own mail transfer agent instead, be prepared to manage reverse DNS, IP reputation, TLS certificates, abuse handling, queue tuning, authentication, and recipient-specific delivery behavior. For most product teams, an authenticated relay provider is the lower-maintenance choice.

A practical SMTP relay checklist

Before production, verify this list:

1. Domain ownership: Your sending domain is verified with the relay provider.
2. DNS authentication: SPF is valid, DKIM is enabled, and DMARC starts with a policy appropriate to your confidence level.
3. Correct route: Your app uses the provider-issued SMTP hostname, supported port, and correct TLS mode.
4. Scoped credentials: SMTP credentials are stored outside source code and are unique to the environment or service where possible.
5. Sender alignment: The visible From: address, envelope sender, DKIM signing domain, and DMARC domain are intentionally designed rather than accidentally mixed.
6. Observability: You collect provider events or webhooks for delivered, bounced, deferred, and complained messages.
7. Bounce handling: Permanent failures are suppressed so the application does not repeatedly mail invalid addresses.
8. End-to-end test: You have tested a controlled recipient, inspected headers, and verified rendering and reply behavior.

The simplest mental model is this: your application does not deliver an email directly to every recipient. It submits the email to a relay it trusts. That relay authenticates the app, accepts the message, applies sender policy, finds the recipient's mail server through DNS, attempts delivery, and reports what happened. Good SMTP relay configuration makes that path secure, observable, and aligned with your domain identity.

FAQ

Does SMTP relay send email directly to the recipient?

Usually, no. Your app sends to its configured relay first. The relay looks up the recipient domain's mail route and transfers the message to the next mail server, potentially with retries if delivery is temporarily unavailable.

Is SMTP relay the same as an SMTP server?

A relay is a type of SMTP server performing a forwarding role. A mail system can also act as a submission server, an inbound recipient server, a mailbox server, or several of these roles at once.

What port should I use for SMTP relay?

Use the port and encryption mode documented by your provider. Port 587 is the conventional submission port and normally uses STARTTLS; port 465 is commonly used for SMTP submission with TLS from the start. Port 25 is primarily associated with server-to-server relay and may be blocked on some networks. (rfc-editor.org)

Why did SMTP return 250 but the email went to spam?

250 means the SMTP server at that stage accepted the message. Inbox placement happens later and is influenced by authentication, sender and IP reputation, content, recipient engagement, mailbox rules, and the receiving provider's filters.

Do I need SPF, DKIM, and DMARC if I use an SMTP relay?

Yes. The relay handles transport, but your domain still needs a credible authenticated identity. Configure the provider's DKIM records, authorize the applicable sending path in SPF, and publish DMARC so recipients can evaluate aligned authentication and send you reports. (rfc-editor.org)