Web to email with Mailgun

A migration story

Web to email with Mailgun

- 3 minute read

We recently migrated a number of of our client websites over to Mailgun for sending emails from web forms and components with a data to email requirement.

When we hook up web to email we generally use authenticated SMTP servers tied to the domain name. These as you might expect vary widely depending on requirements and are supplied by the client. Often servers are provided by clients so that domain email is kept within a known set of walls. Others are left to us to sort out.

These others can be managed in a wide variety of ways. One popular option is Gmail. And why not. A free email account at which you point your website and talk to Gmail’s SMTP server. Sounds simple. Well, yes and no. It all works nicely for a while, then suddenly it stops, the server complains about not being authenticated and error logs get generated. The trick is in the “Less secure apps” setting, buried in the privacy controls. Toggling this gets things moving again, but the real question is how and why did it change and will it change again. We’ve seen this happen quite a bit and its hard to track down. Our guess is it’s a process deep inside Google doing some routine housekeeping and making sure all the doors and windows are firmly locked. Google undoubtedly have an incredible email system, but being unable to control this setting does present an issue of resilience if you’re using Gmail for these purposes. Gsuite accounts seem to suffer the same affliction (although interestingly much less often), and while we would agree there may be better alternatives to email for some things, its still often the most convenient for the client and their customers.

So, in the interests of improving resilience and our ability to controls and review, we set about looking at various third party APIs. We spun up a couple of test websites and hooked them up to a number of different API’s to see how they worked and how they integrated with and reacted to our tools of choice. Most of the APIs we tested were rock solid, but we pretty quickly whittled it down to a couple which gave us little to choose between the two in terms of sending email and integration. We eventually settled on Mailgun because we felt they gave us more breathing room to grow into their service, and we appreciated the thought and control afforded to domain reputation.

We also liked that it’s quick and simple to get a clear understanding of what’s going on collectively with both incoming requests and deliverability, something that can often be harder to decipher when there are multiple originating websites. To top it off there is a lot for us to grow into, we’re not going to be running into any glass ceilings here anytime soon.

So having made our selection, hooked our servers up to the service, all that was left to do is to hook up our client websites. A few settings updates later and we’re siting back enjoying our trim flat whites while watching customer emails flow out to client inboxes.

Aaaand there goes another one...


Previous article   Blog home   Next article