SMTP relay explained: what it is and how to set one up

The short version

1. What an SMTP relay is. An SMTP relay is a mail server that accepts a message from your application and forwards it to the recipient's server.
2. Why not deliver directly from your server. A server can deliver straight to the recipient, but it rarely works well.
3. What you need to connect. You need the relay's host name, a port, a security mode and credentials.
4. Configuring Postfix to use a relay. Postfix, common on Linux servers, calls this a relayhost.
5. Configuring a web application. Most frameworks and content systems have a mail settings page or a few environment variables for the SMTP host, port, encryption, username and password.
6. When a relay will not send. Work from the outside in.

What an SMTP relay is

An SMTP relay is a mail server that accepts a message from your application and forwards it to the recipient's server. Your application does not need to know how to find the destination, retry a failed delivery or maintain a good sending reputation. It hands the message to the relay and the relay does the rest.

People use the words relay, smart host and SMTP service almost interchangeably. In practice they all mean a server you authenticate to and send through.

Why not deliver directly from your server

A server can deliver straight to the recipient, but it rarely works well. Many hosts block port 25. New server IP addresses have no reputation, and some are already on blocklists. Receivers expect reverse DNS, authentication and consistent behaviour that a lone application server seldom provides.

A relay run by a sending provider has an established infrastructure, handles retries and deferrals, and gives you logs when a message does not arrive.

What you need to connect

You need the relay's host name, a port, a security mode and credentials. For MigoSMTP the relay host is smtp.migosmtp.com, and port 587 with STARTTLS is the usual choice. Use port 465 if your software only supports implicit TLS.

Create credentials per application in your dashboard. If one is exposed, you revoke it without touching anything else.

Configuring Postfix to use a relay

Postfix, common on Linux servers, calls this a relayhost. The lines below send all outgoing mail through an authenticated relay on port 587 with encryption required. Put the username and password in a separate file readable only by root and run postmap on it.

relayhost = [smtp.migosmtp.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Reload Postfix after the change and send a test message. Check the mail log if it does not leave: authentication errors and blocked ports show up there clearly.

Configuring a web application

Most frameworks and content systems have a mail settings page or a few environment variables for the SMTP host, port, encryption, username and password. Enter the relay details, choose a sender address on a domain you have authenticated, and send a test message from inside the application.

If a plugin sends through the web host's own mail function instead, it bypasses your relay. Switch it to use SMTP so that your messages are signed and logged.

When a relay will not send

Work from the outside in. First check that you can reach the port with the command line test in our SMTP server guide. If that works, check that the credentials are correct and active. Then read the response your application received, because most failures print a clear reason.

If the relay accepts the message but it does not arrive, look at the logs on the relay side. A rejection by the recipient's server, such as a bounce for a missing SPF or DKIM record, will be recorded there with the reason.

Moving from one relay to another

Changing relays is mostly changing four values: host, port, username and password. The part that needs care is authentication. Publish the new provider's SPF and DKIM records alongside the old ones, move one application first and compare delivery, then switch the rest.

Keep your suppression list when you move, so you do not mail addresses that already bounced or complained. Our migration guides cover the step-by-step for several common providers.

Relay or API?

A relay is the quickest change, because most software already speaks SMTP. An API gives you finer control, such as sending a template with variables, and richer responses. Many teams use both: SMTP for off-the-shelf software and the API for their own code.

Both can go through the same account and the same authenticated domain, so you can start with one and add the other.

Open relays and why they matter

An open relay accepts mail from anyone and forwards it. Spammers abuse them, and a server found to be one is quickly blocklisted. A properly configured relay requires authentication, so only your credentials can send.

If you run your own mail server, check that it is not an open relay, and never share relay credentials in a public repository.

What to check before you trust a relay

Look at how it handles bounces and complaints, whether you get message logs and for how long, what its ports and TLS support are, and how it treats suppression lists. Find out what support is available when delivery drops.

Authenticate your domain with SPF, DKIM and DMARC, whichever relay you choose. Our free checker shows what is published on your domain, and our guides cover each record.

Rate limits, queues and retries

A relay does not deliver every message instantly. It queues them and retries temporary failures over hours, which is what you want when a recipient's server is busy. Your provider may also limit how quickly you can submit messages, so a loop that sends ten thousand messages in a second can be slowed or rejected.

Make your application tolerate that. Send in batches, handle a temporary failure by retrying with a pause, and do not treat an accepted message as delivered: acceptance means the relay has taken responsibility, not that the recipient has it. Use delivery events or logs to confirm the outcome.

Further reading and sources

• RFC 5321: Simple Mail Transfer Protocol
• RFC 6409: Message Submission for Mail
• RFC 8314: Cleartext Considered Obsolete: TLS for email submission

Related guides and tools

• DKIM, SPF and DMARC setup: Authenticate your domain end to end.
• What is an SMTP server?: Ports, settings and when to use a service.
• Check SPF, DKIM and DMARC: Test your domain's records.
• Bounce code lookup: Decode SMTP and enhanced status codes.