While you are working, sleeping, or just chilling, the virtual post services are working day and night to deliver your mail. They don’t take breaks or days off, and they can never go on a strike. They’re effortlessly passing your emails between SMTP relay servers to make sure a recipient can see them seconds after you hit ‘send’. These guys are really doing an extraordinary job. Let’s explore what really happens behind the scenes!
What is an SMTP relay?
According to the most common definition, SMTP relay is the process of transferring emails between email servers on their way to the final destination. Oftentimes, these mail servers are called Mail Transfer Agents or MTAs – software that transmit messages between the computers of the sender and the recipient.
SMTP relay is the virtual equivalent of mail planes and trucks and is an essential part of nearly every email delivery.
What is an open relay?
An open relay is an SMTP server that allows anyone to send emails. It doesn’t have proper authentication mechanisms that would prevent the server from spam and phishing abuse.
Back in the day, an open SMTP relay was the default configuration for email servers. While it was a viable option when the internet was virtually unknown to the masses, it isn’t any longer.
As a result, nearly all open SMTP relays have been shut down, with the remaining ones sitting proudly on famous blocklists.
Comparing SMTP relay to SMTP, SMTP server, SMTP relay service, and smart host
SMTP relay can sometimes be confused with SMTP, SMTP server, SMTP relay service, or smart host. Let’s clarify the differences between them.
SMTP relay vs SMTP
SMTP or Simple Mail Transfer Protocol is an email protocol that defines the terms for secure email transmission. Mail servers and transmission agents use it to route outbound emails. Naturally, SMTP relay follows this protocol while relaying messages from one server to another.
SMTP relay vs SMTP server
An SMTP server is an app or computer that is responsible for sending emails.
Sometimes, popular definitions interpret SMTP relays as email relay servers that messages move between before reaching the recipients. In that context, SMTP relay servers are the same as SMTP servers.
However, we usually refer to SMTP servers when talking about computers that transfer messages and SMTP relay when describing the process of transferring emails between computers.
To learn more about different email servers, check out our guide on IMAP vs POP3 vs SMTP.
SMTP relay vs SMTP relay service
SMTP relay service usually refers to email service providers (ESPs) or email clients that offer their own SMTP servers. That way, outgoing emails are routed to ESPs’ SMTP servers that deliver emails to the inboxes successfully.
SMTP relay vs smart host
SMTP relay and smart host are essentially the same things, but the main difference lies in their security levels. Smart hosts usually require SMTP authentication (SMTP-auth) to relay emails, which makes them less susceptible to spam.
SMTP relays may or may not require authentication depending on their specific settings and configurations. Plus, there are issues with SMTP security itself as it doesn’t have inherent mechanisms (that’s why additional security layers – SSL and TLS were created in the first place).
For that reason, internet service providers (ISPs) sometimes block SMTP connections via SMTP relay port 25. Instead, they set up smart hosts to relay messages from their users’ IP addresses.
How does an SMTP relay work?
To understand the role of SMTP relays in the whole process, let’s start from the beginning and demonstrate how emails are sent and delivered via SMTP.
SMTP resembles real-life postal services or snail mail, although it may be a tad faster than even those ultra-fast same-day delivery companies.
If you were to send a letter to your long-forgotten soulmate, you would likely put it in an envelope and specify their name and address. You would also include your own address so the message is returned to you if the delivery fails.
When sending emails, this process is represented by including the email address of your recipient and an optional return-to address (a.k.a. Return-Path header). The return-to address will be used by internet service providers (ISPs) to return the email to you if it fails to get delivered.
If the paper mail is properly addressed, you’ll stick a stamp on an envelope (as proof of the payment you have made for the service). Finally, you’ll drop your mail at a nearby mailbox, at a local post office, or have someone pick it up. In a virtual environment, you’ll just hit the ‘send’ button in your email client (Gmail, Microsoft Outlook, etc.).
An envelope will then travel to a distribution center of a postal company to be sorted and routed further, according to the address specified on the envelope. Then, it will arrive at another distribution center closest to the recipient’s address. It will be sorted again and sent to a local post office or directly to the recipients.
If everything checks out (you put the right stamp, the address exists, and a nuclear war hasn’t started in the meantime), your soulmate is probably reading your message already. If not, the return address will be used to return the message right into your mailbox (passing the same route again, just in the opposite direction). If a nuclear war did break out after all, this part might be a bit tricky.
In email communication, the moment you hit ‘send,’ your Mail User Agent (MUA) i.e. email client passes an email message to your server’s Mail Submission Agent (MSA). It checks it for errors and shares it with MTA. Think of MSA as an employee that manually checks each transmission and MTA as a local branch of your postal service.
If the recipient uses the same server as the email sender, the email will just be passed to the Mail Delivery Agent (MDA) and delivered straight to the recipient. In this case, the SMTP relay doesn’t happen at all.
In most cases, however, a message needs to be sent to another server, even when the recipient and sender addresses are both Gmail (Google uses multiple servers to handle its over one billion accounts).
This is when SMTP Relay comes into play. First, MTA checks the MX records of the recipient’s domain as though it was looking up an address book where your mail should be routed. When it finds a match, it transmits the message to another MTA. Depending on the destination and the number of recipients, a message is moved between two or more MTAs.
Then MDA receives emails from MTA, converts them to the proper format, and passes them to the recipient’s MUA. MUA again is an email client in which the message is displayed, to the joy of your recipient.
Why is SMTP relay important for mass emails?
To prevent spam, ISPs are usually suspicious of the high volume of emails coming from public domains (such as @gmail.com, for example) because they are easily accessible to illegitimate senders. So, they either block them or send them directly to spam folders. This means that your emails could trigger the yellow light even if you’re sending legitimate messages.
Moreover, if you’re using a public domain, you most likely don’t have access to the DNS records. You won’t be able to set up SPF, DKIM, DMARC, or BIMI authentication mechanisms to prevent email spoofing and improve your domain reputation. Such email accounts also have low daily and monthly sending limits.
You’ll encounter deliverability issues even if you set up your own SMTP server and an email client. Your server will be unknown to the servers on the other end of the relay. It won’t have an established reputation either. As a result, thousands of emails you send from your own email server will inevitably end up in spam folders.
So, the solution is to use an SMTP relay, ideally provided by a sending solution or a reliable ESP. That way, you’ll be able to use a dedicated domain or even IP, access higher SMTP relay limits, set up email authentication, and most importantly, deliver marketing emails or notifications to your users’ inboxes.
How to choose an SMTP relay service provider?
An SMTP relay provider should have a robust and reliable email infrastructure with no downtime. It should also have a track record of high delivery rates and additional functionalities to boost those numbers. Flexible pricing plans with generous sending limits and value for money are also important factors when choosing a provider. After all, you won’t be able to use the SMTP relay unless you can afford it.
One such reliable solution is Mailtrap – an Email Delivery Platform to test, send, and control the performance of your email infrastructure. The platform combines Email Testing and Email Sending to take care of all your email-related needs.
Email Sending is the email infrastructure with high deliverability rates by design. With both Email API and SMTP service, the integration is quick and easy. You just need to follow an in-app wizard to set up your domain and start sending emails. Once the emails are sent, you can monitor their performance with actionable in-depth analytics. Drill-down reports for mailbox providers and categories can give you much-needed insights into your deliverability metrics.
Email Sending also has transactional email templates that you can host right on the platform and reference with the API. You can do so by uploading HTML, using ready-made templates, or coding your own. Templates operate on the handlebars engine and support variables and images. You can preview and test each template before sending them to the recipients.
Speaking of testing, devs can use Email Testing (Email Sandbox) to inspect and debug their emails before sending them to the inboxes. It’s particularly useful for testing the SMTP relay server in a safe environment. Email Testing operates using a fake SMTP server to capture all your SMTP traffic in a virtual inbox and avoid spamming users.
Additionally, Email Testing makes it possible to check HTML/CSS, find faulty lines of code, inspect spam score and blacklists, and validate headers.
This means that you can test the email-sending functionality of your app with Email Testing, use Email Sending as an SMTP relay, and then control your infrastructure – all in one place.