SMTP Relay Address: How to Find, Configure, and Test It

An SMTP relay address is the outgoing mail server address that an application, device, or mail server connects to when it needs a provider to deliver email. Getting it right means more than copying a hostname: you must match the address with the correct port, encryption mode, authentication method, sender domain, and provider-side authorization.

What an SMTP relay address actually means

In most setup screens, an SMTP relay address is a fully qualified domain name (FQDN) such as smtp-relay.gmail.com or a regional provider endpoint such as email-smtp.us-west-2.amazonaws.com. It is sometimes labeled SMTP host, outgoing mail server, smart host, relay host, or simply server.

Your software opens a TCP connection to that host and port, negotiates encryption if required, authenticates or proves its network identity, and submits a message. The relay then applies its own permissions, policy checks, queueing, signing, reputation controls, and delivery attempts. SMTP itself is the protocol used to transfer mail, while a relay is the trusted intermediary that accepts your message and forwards it toward its final destination. (rfc-editor.org)

The word address creates confusion because email has several addresses in play:

• SMTP relay address: the hostname of the server you connect to, such as smtp-relay.gmail.com.
• TCP port: the network service port, such as 587 or 465.
• From address: the address recipients see, such as alerts@example.com.
• Envelope sender / MAIL FROM: the SMTP-level return address used for bounces, which may differ from the visible From address.
• Recipient address / RCPT TO: the delivery target used by the SMTP transaction, which can also differ from the visible To: header. (rfc-editor.org)

If a form asks for an SMTP relay address, it almost always wants the server hostname, not your own email address and not the recipient's domain MX record. The exception is a provider whose relay instructions explicitly tell you to use your organization-specific MX endpoint, as Microsoft 365 does for its connector-based SMTP relay option. (learn.microsoft.com)

SMTP relay address vs. SMTP submission vs. direct delivery

The phrase “SMTP relay” is used loosely, but the distinction matters when you are choosing settings or debugging an error.

SMTP submission

SMTP submission is the usual model for an application, email client, or SaaS product sending a message through an authenticated sending provider. Internet standards separate submission from mail relay so the submission service can enforce its own security and policy rules. Port 587 is the normal submission port in that model. (rfc-editor.org)

A transactional-email provider may call its endpoint an “SMTP relay,” even when your application is technically submitting email to it. That terminology is normal in product documentation; what matters is that your app is authorized to use the service.

SMTP relay through an organization’s mail platform

An organization may run a relay for printers, scanners, monitoring systems, ERP software, or older line-of-business applications. Those systems hand mail to the relay, and the relay sends it through Google Workspace, Microsoft 365, an email delivery service, or directly to recipient mail servers.

Google Workspace, for example, offers an SMTP relay service for devices and applications and identifies its service host as smtp-relay.gmail.com. Its configuration can authorize devices using IP addresses, which suits hardware and software that cannot safely store a user mailbox password. (support.google.com)

Microsoft 365 distinguishes authenticated client SMTP submission from SMTP relay. Its SMTP relay method uses an inbound connector to authenticate a sending server or device rather than treating it as a normal mailbox client. (learn.microsoft.com)

Direct-to-MX delivery

A self-managed mail transfer agent can discover the recipient domain’s MX records and attempt delivery itself. In this case, there may be no configured relay address at all. This approach adds operational obligations: stable sending IPs, reverse DNS, TLS, spam and abuse controls, queue management, bounce handling, and domain authentication.

For most web applications, dedicated sending providers and authenticated relays are easier to operate because they provide an existing submission endpoint, credentials, deliverability tooling, and delivery events. If you are evaluating options, compare the operational model as well as transactional email pricing.

The settings that must accompany the SMTP relay address

A hostname alone cannot make email send. Treat an SMTP configuration as a set of values that must agree with one another.

The common ports are not interchangeable. A provider can support one, several, or none of the familiar SMTP ports. Amazon SES, for example, supports STARTTLS on 25, 587, and 2587, while its TLS-wrapper connections use 465 or 2465. Its SMTP service requires TLS-encrypted connections. (docs.aws.amazon.com)

STARTTLS versus implicit TLS

With STARTTLS, the client initially connects using SMTP, sends EHLO, sees whether the server advertises STARTTLS, then upgrades that connection to TLS before credentials and message content are sent. With implicit TLS—sometimes called TLS wrapper—the TLS handshake happens immediately when the TCP connection opens.

This distinction is one of the most common configuration failures. A client configured for “SSL/TLS” on port 587 may fail if the provider expects STARTTLS, while a client configured for STARTTLS on port 465 may fail if that endpoint expects an immediate TLS handshake. Amazon SES documents both modes and the ports associated with each one. (docs.aws.amazon.com)

Do not select an “unencrypted” option simply because a test works on a private network. TLS protects the SMTP session, including SMTP authentication credentials and message data in transit between your application and relay. (postfix.org)

Authentication is provider-specific

An SMTP relay can identify your system in several ways:

1. SMTP AUTH with a username and password. This is common with delivery providers. The username may not be an email address; it can be a provider-generated credential.
2. OAuth-based authentication. This is more common for mailbox submission than for infrastructure devices, and support varies by provider and client.
3. IP allowlisting. The relay accepts mail only from configured public IP addresses. This is useful for printers and fixed servers but requires a stable outbound IP.
4. Mutual TLS or certificate-based authentication. This is usually used in organization-to-organization or hybrid mail flow configurations.

Never assume that your dashboard login, cloud access key, or personal mailbox password is automatically a valid SMTP password. Amazon SES explicitly uses SMTP credentials that differ from AWS secret access keys, and those credentials are specific to an AWS Region. (docs.aws.amazon.com)

How to find the right SMTP relay address

The reliable way to find an SMTP relay address is to start with the service that will send your mail, not with a generic internet list. Generic lists frequently mix together mailbox SMTP, Workspace relay, Microsoft relay, old ports, and settings that only work for a particular account type.

For an email delivery provider

Open the provider’s SMTP or API documentation and find these items together:

• SMTP endpoint hostname
• region or data-center requirement, if applicable
• supported ports
• STARTTLS versus implicit TLS instructions
• how to create SMTP credentials
• domain or sender verification requirements
• sending limits, sandbox restrictions, and production-access requirements

For Amazon SES, the endpoint is regional, so an address such as email-smtp.us-west-2.amazonaws.com is only an example—not a universal SES hostname. SES documentation directs senders to use the endpoint for their selected Region, create Region-specific SMTP credentials, and use a verified identity. (docs.aws.amazon.com)

For Google Workspace devices and applications

Google Workspace documents smtp-relay.gmail.com as its SMTP relay FQDN and lists ports 25, 465, and 587. The Google Admin console policy determines which devices can relay, whether authentication is IP-based or otherwise permitted, and which sender addresses or domains are allowed. (support.google.com)

This is different from using a consumer or mailbox-oriented Gmail SMTP configuration. Do not substitute one host for the other because the two models have different authorization and administrative controls.

For Microsoft 365 relay

Microsoft’s connector-based SMTP relay requires an inbound connector and directs you to use the MX record target for your accepted domain as the smart host. Therefore, the right SMTP relay address is organization-specific, often resembling a domain ending in mail.protection.outlook.com, rather than a single generic address copied from another company’s setup. (learn.microsoft.com)

Microsoft also requires the device or server to send from a static IP address for this relay scenario, and recommends ensuring the organization’s SPF record includes that address. (learn.microsoft.com)

A worked SMTP relay address example with Postfix and Amazon SES

This example shows the moving parts in a concrete, reproducible setup. It uses Postfix on a Linux server to submit application email through Amazon SES in the us-west-2 Region. Use it as a pattern; replace the region, credentials, domain, and sender identity with your own values.

1. Verify the sender domain or address

Before SES can send mail for an identity, you must verify the email address or domain used as the From, Source, Sender, or Return-Path identity. Verifying a domain lets you send from addresses and subdomains under that domain; verifying one email address limits sending to that address. (docs.aws.amazon.com)

For example.com, verify the domain in the SES console and publish the DNS records SES provides for verification and DKIM. If your SES account remains in the sandbox, SES also requires verification of recipient addresses except for its mailbox simulator addresses. (docs.aws.amazon.com)

2. Create SMTP credentials in the same Region

Generate SES SMTP credentials for us-west-2; do not paste an AWS access key secret into the SMTP password field. Save the generated username and password in a secrets manager or a root-readable credentials file. SES SMTP credentials are unique to each Region. (docs.aws.amazon.com)

3. Set the relay host and TLS options

Add the following to /etc/postfix/main.cf:

relayhost = [email-smtp.us-west-2.amazonaws.com]:587
smtp_use_tls = yes
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

The brackets around the hostname are intentional. In Postfix, brackets prevent a lookup of MX records for the relay host, ensuring Postfix connects to the hostname you explicitly supplied. Postfix documents relayhost = [smtprelay.someprovider.com] as this pattern. (postfix.org)

The settings above use port 587 with STARTTLS. Postfix supports a SASL password map for its SMTP client; your Postfix package must include the relevant SASL client support. (postfix.org)

4. Store credentials safely

Create /etc/postfix/sasl_passwd with this single line, replacing the placeholders:

[email-smtp.us-west-2.amazonaws.com]:587 SMTP_USERNAME:SMTP_PASSWORD

Then build the lookup database, restrict the plaintext file, and reload Postfix:

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl reload postfix

Treat both the source file and generated lookup database as secrets. Do not commit them to Git, paste them into tickets, or leave them readable by unprivileged users.

5. Send a controlled test

From the server, send a small plain-text message using a local command-line mail client configured to hand mail to Postfix:

printf 'Subject: SMTP relay test\n\nRelay test from Postfix.' | sendmail -v you@destination.example

Then inspect Postfix’s mail log and SES sending activity. A successful local handoff only proves that your application gave Postfix a message. A successful provider response proves the relay accepted it. Inbox delivery and authentication results provide the final evidence that the whole route behaved as intended.

You can test the TLS connection separately with OpenSSL before troubleshooting application code:

openssl s_client -crlf -quiet -starttls smtp \
  -connect email-smtp.us-west-2.amazonaws.com:587

AWS documents this form of command for testing a connection to its SMTP endpoint over STARTTLS. It confirms reachability and the TLS negotiation path, but it does not by itself prove that your application is using correct credentials or an authorized From identity. (docs.aws.amazon.com)

SMTP relay address configuration for applications

Most CMS plugins, frameworks, automation platforms, and monitoring tools expose essentially the same fields. Translate the provider documentation into the application’s labels rather than guessing based on their wording.

A typical application configuration looks like this:

SMTP Host: email-smtp.us-west-2.amazonaws.com
SMTP Port: 587
Encryption: STARTTLS
Authentication: enabled
Username: SMTP_USERNAME
Password: SMTP_PASSWORD
From Email: alerts@example.com
From Name: Example Alerts

The values look simple, but every field has a job:

• The host identifies the relay service, not your website’s domain.
• The port must match the encryption method your relay supports.
• Authentication enabled tells the application to issue SMTP AUTH after TLS is active when the provider uses username/password authentication.
• The From Email must be a sender your provider permits and your domain authentication supports.
• The From Name changes the display name only; it cannot authorize an otherwise invalid From address.

For direct application integration, an email provider’s HTTP API can be preferable because it exposes structured error messages, templates, idempotency options, webhooks, and event data more naturally than a basic SMTP library. SMTP remains useful when you need compatibility with existing applications, legacy software, or a standard mail transfer agent. See the email API reference and setup guides when deciding whether SMTP is the right integration surface for your workload.

Make the sender domain authenticate correctly

A valid connection to the SMTP relay address does not guarantee good delivery. Receiving systems evaluate authentication, IP and domain reputation, content, recipient signals, and policy compliance.

SPF

SPF publishes which hosts are authorized to use a domain in SMTP MAIL FROM and HELO/EHLO identities. The protocol exists because SMTP alone does not restrict what domain a sending host can claim in those commands. (rfc-editor.org)

If your delivery provider tells you to add an SPF include or use a custom MAIL FROM domain, use its exact record. Do not add multiple unrelated v=spf1 TXT records: SPF is evaluated as a single policy record, so consolidate authorized senders into one valid record.

DKIM

DKIM signs messages so recipients can verify that the signed content and domain identifier have not been altered after signing. Most sending providers provide DNS records to authorize their DKIM signing for your domain. Publishing those records is usually a provider-specific setup step, not a setting in your SMTP client.

DMARC alignment

DMARC lets a domain owner publish handling preferences and request reports about authentication results. It uses SPF and DKIM in relation to the visible RFC 5322 From: domain, which is why a technically accepted SMTP message can still have delivery problems when the visible From domain is not aligned with authenticated sending. (datatracker.ietf.org)

Start conservatively: ensure all legitimate systems—including your website, support platform, CRM, billing software, and relay—send with aligned SPF and/or DKIM before raising DMARC enforcement. Google warns that missing SPF or DKIM can cause delivery issues when setting up DMARC. (support.google.com)

How to tell whether your SMTP relay worked

“Email sent” is not a single outcome. Check each stage so you can locate the failure quickly.

Stage 1: The application connected

Your application log should show whether it resolved the hostname, opened a connection, completed the TLS handshake, and authenticated. Connection errors such as timeout, connection refused, or certificate verification failure usually point to a firewall, blocked outbound port, incorrect hostname, or TLS mode mismatch.

Cloud environments can impose port restrictions. For example, Amazon EC2 restricts outbound email traffic on port 25 by default, so AWS advises using another SES SMTP port or requesting removal of that restriction. (docs.aws.amazon.com)

Stage 2: The relay accepted the message

A successful SMTP transaction ends with a 250 response after message data is accepted. That means the relay accepted responsibility for processing the message; it does not promise inbox placement.

Permanent failures are commonly in the 5xx range, while temporary failures are commonly 4xx. Preserve the exact enhanced status code and provider text in logs. Gmail’s SMTP error documentation, for example, explains that the returned message and code are intended to help troubleshoot delivery problems. (support.google.com)

Stage 3: The provider attempted delivery

Use your provider’s delivery events, message logs, suppression list, or webhooks to find whether the message was delivered, deferred, bounced, or rejected. The relay’s accepted response is the dividing line: errors before acceptance are usually configuration or authorization issues; errors after acceptance may involve destination policy, recipient address quality, or content.

Before high-volume sends, validate addresses at collection time and before campaigns. Invalid or abandoned recipients produce bounces that can damage list quality and complicate diagnosis; an email address verification tool can help catch obvious address problems before you send.

Stage 4: The recipient mailbox shows correct authentication

Send a test to an inbox you control and inspect the full message headers. Look for an Authentication-Results header showing results for SPF, DKIM, and DMARC. The exact formatting differs by receiver, but you want aligned, passing authentication for the domain in the visible From address.

Also confirm these practical details:

• The visible From address is the one you intended.
• Reply-To goes to a monitored mailbox.
• The envelope sender handles bounces appropriately.
• The relay did not rewrite a sender unexpectedly.
• Links, images, and unsubscribe handling work as expected for the message type.

Common SMTP relay address errors and fixes

“Connection timed out” or “Could not connect to SMTP host”

Check that the host is spelled exactly as the provider documents, DNS resolves from the application host, and egress firewall rules allow the chosen port. Try an alternate provider-supported submission port only when the provider documents it; changing random ports often masks the real issue.

Use openssl s_client for TLS-enabled endpoints or a TCP test tool to separate network reachability from application configuration. SES specifically documents command-line connectivity testing for its SMTP interface and lists ports commonly used with its service. (docs.aws.amazon.com)

“Authentication failed” or 535 errors

Confirm that you created SMTP credentials, not a general account password or cloud access key. Check for accidental spaces, stale secrets, a credential generated in the wrong region, and an application that is attempting authentication before STARTTLS has completed.

If the relay uses IP allowlisting, username/password authentication may be irrelevant. Instead, verify the actual public egress IP seen by the relay—especially when your server sits behind NAT, a load balancer, VPN, or cloud egress gateway.

“Sender address rejected” or “Identity not verified”

The relay accepted your login but does not allow the chosen From or envelope sender. Verify the domain or address with the provider, use the exact authorized identity, and publish the provider’s requested DKIM or custom MAIL FROM DNS records.

SES requires verification for identities used as From, Source, Sender, or Return-Path addresses. In sandbox accounts, recipient verification requirements can make an otherwise correct test fail. (docs.aws.amazon.com)

“Relay access denied” or “Unable to relay”

This usually means the server does not recognize your client as authorized to send to external domains. On a self-managed relay, do not fix it by allowing all clients and all destinations. An unrestricted relay becomes an open relay that spammers can abuse.

Postfix’s access-control guidance emphasizes allowing known local networks and authenticated clients while rejecting arbitrary relay attempts. Restrict access by authenticated identity, trusted network, connector, certificate, or tightly controlled IP range. (postfix.org)

“Sent successfully” but the message is in spam or missing

First determine whether the provider logged the message as delivered, deferred, or bounced. Then inspect headers for SPF, DKIM, and DMARC results; verify the From domain; check the recipient’s spam and quarantine areas; and review any provider suppression or complaint events.

For Gmail recipients, senders that deliver more than 5,000 messages per day to Gmail accounts must meet additional bulk-sender requirements, including SPF or DKIM, valid forward and reverse DNS for sending domains or IPs, and TLS for email transmission. (support.google.com)

Choosing SMTP relay, direct SMTP, or an email API

Choose a relay based on what you are actually operating.

Use SMTP relay when:

• You need a printer, scanner, NAS, monitoring system, or legacy application to send email.
• Your framework or plugin already supports SMTP but not a provider API.
• You want a central organization-level control point for outbound device mail.
• You run a local mail transfer agent such as Postfix and need it to forward outbound messages through a delivery provider.

Use a provider API when:

• You control the application code.
• You need granular delivery events, webhooks, templates, tags, idempotency, or structured errors.
• You want to avoid long-lived SMTP credentials in multiple systems.
• You need to distinguish transactional, marketing, and system traffic programmatically.

Use direct-to-MX sending only when:

• You have mail-server expertise and can operate reputation, DNS, security, queues, bounces, abuse controls, and monitoring.
• You understand the deliverability implications of using your own IP addresses.
• You have a clear reason not to use a managed relay.

The best option is not inherently the one with the fewest configuration fields. It is the one that lets you authenticate your domain, limit who can send, monitor delivery outcomes, rotate secrets, and recover safely when a provider or network path fails.

SMTP relay address checklist

Before putting an SMTP relay configuration into production, verify all of the following:

1. The hostname is copied from the provider’s current official documentation.
2. The port matches the selected encryption mode.
3. TLS certificate validation is enabled rather than bypassed.
4. The selected authentication method matches the provider-side policy.
5. SMTP credentials are stored as secrets and have a rotation process.
6. The application’s From address is authorized by the relay.
7. SPF, DKIM, and DMARC are configured for the sending domain.
8. Your relay is restricted so it cannot become an open relay.
9. You have tested a delivery to an external inbox and reviewed its headers.
10. You capture SMTP errors and provider delivery events for troubleshooting.

A correct SMTP relay address is the starting point, not the entire email-delivery system. Pair the correct endpoint with TLS, least-privilege authorization, authenticated sender domains, and observable delivery results, and your application email will be much easier to maintain.

FAQ

What is an SMTP relay address?

An SMTP relay address is the hostname of the outbound mail server that accepts email from your app, device, or mail server and forwards it for delivery. Examples include a provider SMTP endpoint or an organization-specific smart host.

Is an SMTP relay address an email address?

No. It is normally a server hostname, such as smtp-relay.gmail.com. Your sender email address, such as notifications@example.com, is a separate setting.

What port should I use for an SMTP relay address?

Use the port and encryption mode the provider documents. Port 587 with STARTTLS is a common submission pattern, while port 465 is commonly used for implicit TLS. Some providers also support alternatives such as 25, 2465, or 2587. (rfc-editor.org)

Why does my SMTP relay accept mail but recipients do not receive it?

Relay acceptance only means the provider took responsibility for the message. Check provider delivery logs, bounce or suppression events, recipient spam folders, and message headers for SPF, DKIM, and DMARC results.

Can I use my personal Gmail SMTP server as an application relay?

It may work for limited mailbox-oriented use cases, but it is not the same as Google Workspace’s managed SMTP relay service for devices and applications. For business systems, use the documented service and authorization model that fits your account and sending workload. (support.google.com)