The hazards of emailing your aMember members

Photo of author

Rob Woodgate

Published:

Updated:

Every year, the war on spam escalates, making it harder for legitimate businesses to get email through to their customers too.

Gone are the days where you could simply send email from your web server and expect it to land in the inbox.

Now, you have to be an expert in email hosting, deliverability and security, as well as blessed with faultless IP addresses.

And frankly, even when you are, it’s hard work keeping on top of it all.

For those of us using aMember Pro, it means you pretty much have to use a transactional email service like Amazon SES, MailGun or Sendgrid.

I faced up to this reality this year, after moving web host and getting a new batch of IP addresses.

Suddenly, after 6 years, all the work I’d done to build the reputation of my server IPs was gone, and I was effectively starting over.

After some research, I decided to go with MailGun.

They are developer friendly, have great deliverability, and aMember supports them out of the box.

Happy days!

But as I started migrating my aMember sites to use MailGun, I realised there was a potential problem, especially with this website, where I sell my aMember plugins.

Defunct Customer Accounts

I’d built up a database of HUNDREDS of customer accounts over the last 11 years writing and selling aMember plugins, but many of them had not interacted or purchased anything for a while, and I’d not been emailing regularly.

Chances were, there would be a lot of defunct emails in my aMember system. So much so, I was actually too frightened to connect it to MailGun!

So I wrote a plugin that would do a basic email validation of all the members emails, weeding out all the domains that were no longer registered.

It was kind of demoralising to see my customer list go down from nearly 1000 to just under 200, but at the same time, it felt good to be able to get this site back on track.

Bounce / Complaint Feedback Loops

The key advantage of using a transactional email provider is that they handle all the bounce / complaint feedback loops for you.

So if a customer email becomes defunct, or they report an email as spam, then you can get their aMember account unsubscribed ASAP.

The aMember implementation of MailGun doesn’t include feedback loops, so I enhanced my plugin so that in the event of a bounce or spam complaint, I could automatically unsubscribe and lock out the customer account.

Why lock out? Two reasons:

  • A genuine customer may not notice they have a bad email address if they can continue to login without issues, and may even just re-subscribe themselves, so I want customer accounts with bad email addresses to contact me to get unlocked.
  • Spam complaints hurt your business, so any customer who reports an email from my membership system as spam rather than unsubscribing is a bad customer who needs to be banished from purchasing anything else from me for life.

Like many small businesses, my time is limited, so having a zero tolerance policy for bad behaviour like spam complaints has helped ensure my customers are all decent human beings who are a pleasure to serve.

But the lock out setting is optional in case you don’t feel the same way 🙂

Anyhow, with the feedback loops in place, I felt confident to complete the move to MailGun and send a plugin update email to my remaining customers.

That’s when I noticed another problem.

MailGun API Sending Limits

The aMember implementation of MailGun uses their API, but sends emails individually. This means you can hit MailGun’s hourly API limit of 100 emails per hour.

It LOOKS like emails send ok, but the aMember error log shows messages as failed!

So if you use MailGun with aMember, you need to use the “E-Mail Throttle Queue” feature (aMember admin > Setup/Configuration > Email) and set a limit of 100 or less per hour.

Once you have passed MailGun’s probation period, your hourly limits may increase, but you still risk emails being silently discarded with an error if you hit the API limits.

My preferred solution is to use the default internal mail sending function sending method, but set up MailGun as an Exim SMARTHOST. That way, the email server mail queue handles any throttling measures as it would to any other SMTP relay.

I haven’t tested this with the other sending methods (like SendGrid, Amazon SES) but something to be aware of!

I hope this helps you avoid similar pitfalls emailing from your aMember site.

Leave a Comment