Returning to Mailgun

A little while ago I wrote a post about switching from the default ShipFast Mailgun integration to Resend.

I had a few reasons for doing this, but the number 1 reason was the limit of 5 routes for rerouting replies to another email address.

Email Flows

Here’s the normal flow in a ShipFast app:

1. The user triggers some action, login, buying the app, signing up for updates, etc.

2. Your application sends an email automatically through next-auth or you send a programmatic email via the sendEmail function.

3. Mailgun receives the request based on the credentials setup for your domain

4. Mailgun sends the email to the user

That flow of events will work for any domains you setup in Mailgun. Currently I have over a dozen and I’m using the pay as you go Flex Plan.

This setup is covered on the ShipFast documentation page under “Email”.

However, there is another flow that’s covered on the optional step in the documentation. That flow is:

1. User receives an email from your app.

2. User replies to your email using the reply-to address which by default is the “fromAdmin” address in the config.js file and is usually something like: [email protected]

3. Mailgun receives that email and routes it back to your application’s Mailgun webhook and/or another email address (like your personal Gmail address) using a “Route” setup in Mailgun for your domain.

4. If your application’s webhook receives the request, your application will send the reply onto the “forwardRepliesTo” address from the config.js using Mailgun.

The key piece in this flow is step 3. Under the Mailgun Flex Plan, there is a limit of 5 routes that can be setup across all your domains.

Even though you can setup more than 5 domains to send email, you can only setup 5 routes for receiving email.

I assumed that I would want to setup the optional routing for every domain without really thinking it through.

I was watching this video from Marc (the creator of ShipFast).

At 3:18 he shows the projects he has setup in Mailgun, which was more than 5, and he says he’s on the pay as you go Flex Plan.

Lightbulb

If your application just uses email to send the magic login link, you won’t need a route at all. That email typically comes from a “noreply” email address and you can probably ignore all the emails coming to it.

There are two cases where you probably want a route setup:

1. If you set your supportEmail to use the mg.domain.com scheme you would also want a route setup.

2. If your application uses the Mailgun sendEmail function you normally would want a route setup.

In the first case you can set your “supportEmail” to a non-Mailgun email address. In my case I’d use “[email protected]“ since I purchased an email address on my domain at my registrar.

Any place on the site using the ButtonSupport or Footer components would use that email address which does not use Mailgun and therefore wouldn’t need a route.

In the second case you can use the “replyTo” optional parameter on the sendEmail function. In my case I want to send an email to the user after purchase like so:

This uses Mailgun to send the email, but the user will reply to the supportEmail which doesn’t use Mailgun and also won’t need a route setup.

Why change back?

I could have left my apps on Resend without issue but I chose to move them back to Mailgun.

The main reason is because ShipFast uses Mailgun and the code for that is maintained by ShipFast and not me. They say the best code is the code written and maintained by someone else.

If I wasn’t using the ShipFast template I would probably stick with Resend since their admin interface is much nicer.

The switch back took about 5 minutes per app and now I don’t have to think about it again.