Who delivers your app's email?Your app just sent a password reset. It arrived in two seconds. Question: who actually carried it there? Not your ESP. Probably not your server. Meet the SMTP relay.
⬡ journey-flow, an envelope labeled "password reset" pops out of an app icon, hops to a relay node that pulses, then on to an inbox node that lights greenAn SMTP relay is a server that accepts email from you and passes it along to its destination. That's the whole job. You hand it a message, it handles the routing, the retries if something fails, and the final handoff to the recipient's mail server. It doesn't store your contacts, doesn't design templates, doesn't track opens. It just moves mail.
⬡ journey-flow, the envelope hits a red "temporary failure" on the recipient node, loops back to the relay, the relay retries, second attempt lands greenThe name comes from how SMTP actually works. Your message can pass through more than one server on its way. Server A accepts it from you, relays it to Server B, which relays it to the recipient's server. Each hop is a relay, like a bucket brigade passing water down the dock. When people say "SMTP relay service," they mean a company that runs those servers for you, so you never have to captain your own mail infrastructure.
⬡ journey-flow, three server nodes in a row, the envelope passes hand to hand across them, each hop briefly labeled "relay"ESP builds it. Relay ships it.Here's where people get tangled. An ESP like Mailchimp or Brevo gives you templates, list management, segmentation, campaign analytics, the whole shipyard. An SMTP relay like Postmark, SendGrid, or Mailgun is just the delivery engine. You build the email yourself, usually in code or through their API, and they handle transport. That's why developers and SaaS apps use relays for transactional email: password resets, receipts, shipping notifications.
⬡ app-grid, provider tiles fly in and sort themselves into two columns, ESP side (Mailchimp, Brevo) grows a template-and-charts dashboard, relay side (Postmark, SendGrid, Mailgun) stays a bare engine pumping envelopesAnd this split isn't just tidiness. Marketing email collects complaints and unsubscribes, that's normal. Transactional email usually doesn't. Mix both on the same sending setup, and one rough campaign can drag your password resets down with it. So many companies run marketing through an ESP and transactional through a dedicated relay. The full story is called stream separation, it has its own video, linked below.
⬡ split-compare, LEFT lane "marketing" sails along then collects red complaint flags that spread backward, RIGHT lane "transactional" keeps sailing clean because the lanes never touchSo: building an app that sends email? You need an SMTP relay, unless you want to run your own mail servers. You don't. Sending newsletters? That's ESP territory. Doing both? Keep them on separate lanes. One more thing, good relays also hand you the SPF and DKIM records to authenticate your mail, and put you on shared or dedicated IPs. Both of those are the next videos.
Next up: shared IP pools, and how a stranger's spam can sink your delivery. If this cleared it up, subscribe, there's a whole series.
⬡ end-card, Subscribe + Next: "What is a shared IP pool" (001.008.003)SMTP relay explained: the server that accepts your email and delivers it, handling routing, retries, and the final handoff. How relays differ from ESPs like Mailchimp (templates and lists vs pure delivery engine), why apps use relays like Postmark, SendGrid, and Mailgun for transactional email, and why marketing and transactional mail belong on separate infrastructure.
Next: What is a shared IP pool → [link 001.008.003]
Stream separation, the deep version → [link 001.007.001]
Full written guide → reviewmyemails.com/emailalmanac/…/what-is-an-smtp-relay
#email #smtp #deliverability