What Is an SMTP Relay? How It Works and When You Need One

An SMTP relay is a mail server that accepts outgoing email from you, whether from an app, a website, a device or your own mail server, and passes it on to the recipients' mail servers. You use one when you want reliable delivery without running and maintaining your own sending infrastructure.

How a relay fits in

Without a relay, your server looks up each recipient's MX record and connects to it directly. With a relay, there is one more hop:

Your app or server  ->  SMTP relay  ->  Recipient's mail server  ->  Inbox

Your app authenticates to the relay and hands over the message. The relay then:

• Looks up the recipient's MX records.
• Connects and delivers the message.
• Retries if the receiver returns a temporary error.
• Records bounces and, with most services, reports them back to you.

Common types of SMTP relay

Type	Examples of use	Notes
Mailbox provider relay	Google Workspace SMTP relay, Microsoft 365 SMTP relay	For devices and apps inside your organisation; subject to the provider's limits
Transactional email service	Amazon SES, SendGrid, Postmark, Mailgun	For app emails like receipts and password resets; usually SMTP or API
Smart host for an on-premise server	Exchange or Postfix sending via a provider	Your server hands everything to the smart host
ISP relay	Older home or office setups	Rarely used for business sending today

For marketing campaigns, people normally use an email marketing platform rather than raw SMTP, but underneath the platform is doing the same job.

Why not send directly?

Running your own outbound mail server is possible but demanding:

• Port 25 restrictions. Many cloud providers block outbound port 25 by default. Cloud providers that block port 25 explains why.
• IP reputation. A new server IP has no history, and shared cloud IP ranges often have poor reputations.
• Reverse DNS. Receivers expect a matching PTR record for the sending IP.
• Retries and bounce handling. You need queues, retry logic and bounce processing.
• Blocklist monitoring. If your IP is listed, you need to notice and fix it.

A relay service handles most of this, which is why apps almost always send through one.

Ports and encryption

Port	Use
587	Mail submission with STARTTLS; the standard choice for apps and devices
465	Submission with implicit TLS; widely supported
25	Server-to-server delivery; often blocked outbound on cloud and home connections
2525	Alternative offered by some services when others are blocked

The SMTP settings lookup shows common server names and ports for popular providers.

Authentication to the relay

A relay must know who is allowed to use it. Common methods:

• Username and password or API key sent over an encrypted connection.
• IP allowlisting, where only your server's IP can relay.
• Both, for stronger control.

The danger of open relays

An open relay forwards mail from anyone, with no authentication. Spammers scan the internet for them. An open relay will be found, abused and blocklisted, often within days, and its legitimate mail will be blocked too. If you run your own mail server, make sure it only relays for authenticated users or trusted IPs.

Relays and authentication records

Sending through a relay does not authenticate your domain automatically. You still need:

• SPF that includes the relay service.
• DKIM signed with your domain, set up in the relay service's settings.
• DMARC with alignment between your From domain and SPF or DKIM.

If you skip DKIM setup, recipients may see your mail as sent "via" the relay's domain and DMARC may fail. Why Gmail shows "via" explains the label. Check your records with the bulk email authentication checker.

Relays and bounces

Relay services watch your bounce and complaint rates closely, because your mail affects their reputation. Sending through a relay to a list with many invalid addresses can get your account reviewed or suspended; SES accounts under review for bounces is a common example. For app email, verify addresses at signup so fake and mistyped addresses never become bounces later.

Choosing a relay

Questions to ask:

• Is it built for your type of mail: transactional, marketing or internal devices?
• Does it support custom DKIM and a custom return-path?
• What are its sending limits and how do they grow?
• How does it report bounces and complaints back to you?
• Does it offer SMTP, an API, or both?

Common relay mistakes

• Using a personal mailbox as a relay for an app. Mailbox providers set daily limits and are not built for automated sending. Use a transactional service instead.
• Hard-coding credentials in a website plugin. If the site is compromised, the credentials can be used to send spam as you. Use API keys with limited scope and rotate them.
• Skipping DKIM because "the relay handles it". The relay signs with its own domain unless you set up yours.
• Ignoring bounce reports. Most relay services report bounces through webhooks or a dashboard. If nobody processes them, invalid addresses keep getting mailed.
• Running an unauthenticated internal relay. Even inside a company network, a relay that accepts anything can be abused by a compromised device.

Quick glossary

• Smart host: a relay that an on-premise mail server forwards all outgoing mail to.
• Submission: handing a message to a relay, usually on port 587.

Clean recipients, smoother relaying

A relay delivers whatever you hand it. If the address does not exist, the relay records a bounce against your account. Verifying addresses first keeps bounce rates low with any relay. Upload a list on the verify page; you get 100 free email checks when you sign in with Google, no card.