SMTP Relay: What It Is, How It Works, Free vs Paid, Setup and Security

"SMTP relay" is one of those terms that sounds simple and is used to mean several different things. To a system administrator it can mean the way a printer or application hands its mail to the company mail server. To a developer it can mean an external service that accepts mail from an app and delivers it to the world. To a security person it can mean a dangerous misconfiguration that lets strangers send spam through your server. This guide explains what an SMTP relay is, how it works, the difference between a relay, a mail server and a full email service, the three common situations in which people use one, what to look for in a relay service, why "free SMTP relay" needs careful reading, how to set one up and test it, and how to keep it secure. It is written to be practical, with the technical details you need and none that you do not.

What is an SMTP relay?

SMTP, the Simple Mail Transfer Protocol, is how email moves between servers. A relay is a server that receives a message on behalf of a sender and passes it on to the next server on the way to the recipient. In practice, "SMTP relay" usually describes a server or a service that your application, device or mail system connects to for sending, instead of delivering directly to each recipient's mail server. Your software hands the message to the relay; the relay worries about looking up the recipient's mail server, queuing, retrying, encrypting and handling errors. You can read the basics in what SMTP stands for and how a mail transfer agent works.

How an SMTP relay works

1. Your application connects to the relay's hostname and port, and the two sides negotiate encryption. With our relay, you connect to smtp.migosmtp.com on port 587 and upgrade the connection with STARTTLS.
2. Your application authenticates with a username and password or another credential issued by the relay.
3. It submits the message: sender, recipients and content.
4. The relay accepts and queues the message, signs it with DKIM when configured, and looks up the recipient's mail server in DNS.
5. The relay delivers to the recipient's server, retrying temporary failures and recording permanent ones.
6. Results are reported as bounce messages, logs, webhooks or a dashboard.

The value of a relay is that it takes over the hard parts of delivery: connection handling, reputation of the sending IP addresses, retry logic, feedback processing and reporting.

SMTP relay versus SMTP server versus email service

For a fuller comparison of self-run servers and hosted services, see SMTP servers versus SMTP services.

When do you need an SMTP relay?

1. Your application sends email

Websites, shops and software send sign-up confirmations, receipts, password resets and notifications. Sending these directly from a web server is unreliable: many hosting and cloud providers restrict outbound connections, and mail from an unknown address with no reputation often lands in spam. A relay service gives you a trusted path. See the MigoSMTP relay and the email API for the two ways to send.

2. Devices and legacy software need to send

Printers, scanners, monitoring tools and old business applications often only support basic SMTP settings. A relay gives them a simple endpoint. Check what encryption and authentication each device supports before you choose a service, because some older devices cannot use modern methods.

3. Your mail system needs a smart host

Mail servers such as Postfix or Exchange can be configured to hand outgoing mail to another relay, called a smart host, instead of delivering directly. This is common when the server's own IP address has no reputation, sits on a residential or cloud range that is blocked or has no reverse DNS. See how to configure Postfix to use a relay.

What to look for in an SMTP relay service

• Encrypted connections and strong authentication, with clear documentation of ports and methods.
• Domain authentication support: SPF, DKIM and DMARC alignment. See authenticating your sending domain.
• Reputation management: how sending IP addresses are monitored, what happens when a customer abuses the service and whether dedicated addresses are available. See dedicated IPs.
• Bounce and complaint handling that updates your suppression list automatically.
• Reporting and logs that let you see what happened to each message. See email analytics.
• Webhooks or events so your application learns about deliveries and bounces. See webhooks.
• Clear limits and honest policies on volume, content and acceptable use.
• Support that answers questions about delivery.

Is there a free SMTP relay?

Searches for "free SMTP relay" are common, and the honest answer has three parts. First, some providers offer a free tier with a small daily allowance, which can be fine for testing or very low volume. Second, if you already pay for a mailbox service such as Google Workspace or Microsoft 365, it includes a relay feature intended for your own users and devices; see the Google Workspace relay guide and the Office 365 relay guide. These have sending limits and are not designed for marketing volume. Third, free open relays on the public internet are dangerous and should be avoided: they are usually abused, quickly blocklisted and may expose your messages to others. A relay that costs nothing but delivers nothing is not free; it costs you time and reputation.

How to set up and test an SMTP relay

1. Create credentials in your relay account and note the hostname and port.
2. Authenticate your sending domain using the records shown in your dashboard domain settings. Copy them exactly.
3. Configure your application with the host, port, encryption setting, username and password. See the Nodemailer guide for a Node.js example.
4. Test the connection from the command line or a test script. Our guide to testing an SMTP connection shows how with OpenSSL, Swaks and PowerShell.
5. Send a real test message to addresses on several providers and inspect the headers for SPF, DKIM and DMARC results.
6. Monitor logs, bounces and complaints from the first day.

Choosing the port

Port 25 is for server-to-server delivery and is commonly blocked for clients. Submission ports are intended for clients. Our relay uses port 587 with STARTTLS. If your hosting network blocks outbound traffic on the submission port, ask the host or use the email API over HTTPS. See which SMTP port to use.

Open relay: the security risk

An open relay accepts mail from anyone and forwards it to anyone. Spammers search the internet for open relays and use them to send huge volumes, which leads to blocklisting of the server's address and sometimes to the loss of the hosting account. Modern mail software is not open by default, but misconfiguration can open it, for example by trusting a wide network range. To protect a relay you run yourself:

• Require authentication for relaying, or restrict by specific IP addresses.
• Accept relayed mail only from networks you control.
• Use encryption for client connections.
• Rate-limit senders and monitor queues for sudden growth.
• Test from outside your network to make sure unknown senders are refused.

If you find you are listed, see how to check and remove a blacklist listing.

References and further reading

• RFC 5321: Simple Mail Transfer Protocol
• RFC 6409: Message Submission for Mail
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS