Three Easy Lessons To Ensure Email Deliverability For Your Membership Site
Any decent marketer is going to use a reputable third party autoresponder service for their marketing emails.
However, there are still occasions when you absolutely must guarantee that your emails will be delivered when sent from your own server and running a membership site is one of them.
Why is this? Because every time you have a new member subscribe then your site is going to send an email to the third party autoresonder you have integrated in order to trigger the verified optin process to add your new subscriber to your list. And if that email is not successfully received and processed then boy, do you have a problem.
I speak from the heart on this one because I have just spent the last six weeks with a recently launched membership site in limbo after discovering that new subscribers were not being registered on the autoresponder list. They were being processed through the payment mechanism on Paypal, registered on the site but very definitely not getting onto the autoresponder list so that I could communicate with them subsequently.
All sorts of things fell by the wayside as a result. Scheduled delivery of lessons by autoresponder, further marketing emails encouraging existing members to ‘tell-a-friend’, you name it, it couldn’t be done. I even discovered that the broadcast function from the membership software on the site, a function that is quite separate from the third party autoresponder, was also not being delivered.
I hasten to add that I am using ‘best of breed’ membership software and autoresponder for this project, both highly recommended by leading players in internet marketing.
I went through the usual process of checking my own work on the integration process, then raising a ticket on the membership software help desk, then raising a ticket on the autoresponder help desk and finally on my host’s help desk.
Time passed and members started reporting problems, I stalled and explained and stalled some more while the ticket correspondence grew and the issue was escalated up to the top programmers on each product – all with no result. Our membership marketing effort comes to a halt as we obviously cannot recruit new subscribers to a membership site that is not working.
You get the picture; an apparently flawless integration with
the payment gateway and the autoresponder given the seal of approval by both of them – but the thing is still not working!
Now we come to the embarrassing part. The autoresponder is triggered by the autoresponder service receiving an email from the site constructed in a specific way. If the autoresponder does not receive the email then there can be no registration for the autoresponder to trigger the verification email so that the customer can double optin and get onto the list.
If there is something wrong with the notification email then the autoresponder ISP is going to generate a bounce message back to the site. So I was asked if I had received any bounce messages?
I manage all my email through Google’s mail service and knew that I had set all the email addresses on the site to forward to my gmail account. So I went into the webmail for each of the small number of named email accounts I had created and checked there was nothing there. I also checked that the Default Address to which any unspecified mails are forwarded was set to my gmail account. What I did not do was to check the default account inbox. After all, why should I when it was set to forward to an account that I monitor all the time?
Well, there’s one of the several lessons contained in this story. Never trust anything! I am still waiting for an answer from my host as to why those bounced emails sat there and were not forwarded. If they had been forwarded then this six week saga would have been over within a few days.
Then came a stroke of good fortune. Dealing philosophically with the situation and trying to remain calm I decided to do some work on an entirely different project. Different project, different domain – but the same shared server on the host.
This also required that emails were generated by the domain, this time they were going out maybe 10 or 15 at a time after I did some research and then sent the relevant mails from a template.
Fortunately, the software involved has an email client built in so you have an In, Out and Sent box withing the software which login to the domain webmail in order to send and receive your mail.
So, having sent a batch on the second day I hit the Receive key to download the replies I was expecting and got 15 bounce messages – all the result of my outgoing mails of the previous day – plus bounces for all the messages I had sent only minutes before.
Suddenly, I was faced with the fact that my list building problem on the membership site was nothing to do with the software or autoresponder on that project but was clearly a problem associated with my own shared server.
For a non technical person like me this was a nightmare. I know all these things are dead easy once you get your head around them. But it is the mental gymnastics of doing so that are so offputting. After all, I’m doing this because I’m interested in marketing – not in rummaging around the inside of some server somewhere in cyberspace.
However, lets look on the bright side because every problem is also a lesson. Now I knew I could stop waiting for responses from various help desks because the problem clearly lay in my webmail. But where?
Within the hour I had uncovered the stack of bounce messages tucked away in the default webmail account on my membership site. What’s more I could identify them as being not only the numerous test subscriptions I had made but also real customer subscriptions as well as the broadcasts from the site without using the autoresponder.
In other words, here was evidence that the notification emails sent by the membership software were being bounced back from Aweber. At last I knew where the problem lay. The next question was why?
The answer seemed to lie in the bounce messages which frequently referred to the lack of a reverse DNS while some also referred to the sender being barred.
It then struck me that I have about 15 domains on this shared server and if this problem existed on one domain then I should check the others. The result was that I found bounce messages referring to both the lack of reverse DNS and being barred going back at least 9 months.
This is the point where every non-techie feels like a lamb being led to the slaughter – yet again! We are told how simple these things are yet how can my business have been jeopardised for so long without my being aware of it?
By this time I am furious with my hosting service who by now have grudgingly admitted to both failings but have not so far come clean about how the situation might have come about, why they didn’t spot it or correct it and why they didn’t tell me about it.
So here’s the rest of the lessons of things you can and should do to protect yourself. They are both very easy and very quick and you can do them yourself. In fact, you absolutely should do them yourself in order to be sure. They are definitely on my checklist now for any new projects.
A memberships site is going to register new members one at a time at any time of the day or night. So the notification email is going to be a single, lonesome little mail all on its own and it absolutely must originate from a server that has reverse DNS properly set up and for which the IP address is not blacklisted.
- Firstly, get a dedicated IP for yourself. That way you know that you are not at risk of some spammer on a site that happens to be on the same shared server getting the IP of the shared server blacklisted.
- Second, check that the dedicated IP you have just been allocated is not already blacklisted. (Notice how cynical I’ve become?) There are a number of free services that are easily found by searching in Google for something like ‘check my domain is not blacklisted’. Some of them are paid services that will monitor your IP in real time but that should not be necessary once you have your own dedicated IP. One quick reference is http://www.dnsbl.info/dnsbl-list.php.
- Third, check that your host has set up the reverse DNS properly. Reverse DNS is a way for the ISP receiving an email to be able to track it back to where it came from. Obviously, if someone is trying to hide the origin of their email by omitting the reverse DNS then thats a big fingerprint of a spammer and any mail without a reverse DNS is likely to be blocked and returned. You can check this very easily by using the website at http://remote.12dt.com/
Just open your cPanel to obtain your IP address, usually from close to the top of the left hand sidebar and enter it into the required field. If the site returns an identifiable server name then you should be fine.
There you are, three simple checks to make to make sure that you give yourself every chance of getting your emails delivered. Long, hard, painful and expensive lessons for me but I hope that by passing them on I might make your life a little easier.