The shop currently sends none. What it needs, and why not to run a mail server.
Working. Order confirmation, despatch, cancellation, password reset and
welcome all send through Resend from info@autoxspare.com.
What sends, and when
| Fires on | |
|---|---|
| Order confirmation | order.placed |
| On its way | shipment.created — the parcel actually leaving, not the fulfillment being created |
| Cancelled | order.canceled |
| Password reset | auth.password_reset |
| Welcome | customer.created |
Templates are React components in apps/backend/src/modules/resend/emails/,
rendered at send time. The copy lives in the repository, goes through review, and
cannot drift from what the shop does. A plain-text alternative is rendered
alongside every message.
Every send happens in a subscriber rather than inline in a workflow, so a mail outage can never fail a payment.
Do not run medusa exec over railway ssh without passing the environment.
Those sessions do not inherit service variables, so the notification module
loads without Resend — and syncDatabaseProviders disables providers absent
from the current config. It silently switches email off for the live shop
until the next deploy.
How Medusa sends email
Medusa does not send mail itself. It has a Notification module that
dispatches to a provider, and ships @medusajs/notification-sendgrid and
@medusajs/notification-local (the latter only logs). Nothing is registered.
Two pieces are needed:
- A provider registered in
medusa-config.ts - Subscribers that listen for
order.placedand friends and send something
Neither exists yet.
react.email
react.email is a good choice, with one clarification: it does not send
email. It is a component library for authoring templates in React that render
to HTML. Something still has to deliver that HTML.
So it is not an alternative to a third party — it is the template layer that sits in front of whichever transport is chosen. It also keeps templates in the repo, under review, with no vendor lock-in on the design.
Should we run our own mail server?
No. It is technically possible and practically a bad trade for a shop whose receipts must arrive:
- A new IP has no sending reputation, so Gmail and Outlook will spam-folder or reject outright until it is warmed over weeks
- SPF, DKIM, DMARC, reverse DNS and TLS all have to be correct, and a single misconfiguration silently sends receipts to spam
- One spam complaint or a compromised form can land the IP on Spamhaus, taking every email down with no warning
- Most hosts, Railway included, block outbound port 25 — so it would not even be deliverable from where the backend runs
- It is a second production system to keep alive, forever
The failure mode is the bad one: mail that silently does not arrive. You find out from an angry customer, not from a monitor.
Recommendation
react.email for templates, a delivery API for transport.
| Transport | Why |
|---|---|
| Resend | Built by the react.email team, so the pairing is native. Simple API, generous free tier. Needs a small custom Medusa provider. |
| SendGrid | Medusa ships a provider already, so it is the least code. |
| Amazon SES | Cheapest at volume, more setup. |
Whichever is chosen, the sending domain must be verified — SPF and DKIM
records on autoxspare.com in Hostinger. Budget for that; it is not optional and
it is the step people skip.