Troubleshooting a Weird SiteLock + Email Conflict

This (admitted) rant describes and may resolve an email-related conflict that occurs between automatic configuration of SiteLock and shared hosting accounts with multiple websites hosted on a single server.

I use Bluehost with dedicated IP for my shared hosting server, and I’ve recommended their service highly over the years to many clients and friends for one solid reason: their support.

I’ve had an account with Bluehost since probably 2007, and in that time, various tech issues have arisen and, hand-in-hand with their lovely tech support team, we have resolved them. If there was something they could do on their side to help out, they would go right ahead and do it, leaving my little brain plenty of time and space for tasks that I actually need to focus on: like running a business and taking care of my clients.

Until recently…

Hacking: It’s Not an “If,” It’s a “When”

A couple weeks ago, my Bluehost account was suspended for nearly a week—meaning 4 websites went entirely offline and I had to pay $250 to have their Site Doctor service clean my server—because of a malware attack.

Their response to this Event of Pure Hell was to tell me that it’s the account owner’s responsibility to make sure that doesn’t happen. OK, despite my utter frustration and the nah-care attitude of their tech support staff, fair enough.

As a result, I paid them to have SiteLock installed across multiple domains and advised my clients to do the same.

But wait… there’s more.

SiteLock Setup Woes

• Purchasing SiteLock did result in a number of payments to Bluehost and other hosting companies.
• Purchasing SiteLock did not result in any instructions as to what to do after you purchase SiteLock.

Last week, a day or so after I (thought I had) installed SiteLock on my own server, I logged into Bluehost to see if it had found anything. But it didn’t appear to be tracking…

I then revisited the SiteLock Security dashboard in Bluehost and saw that there was a link in the dashboard where I needed to add a DNS record in order for SiteLock to track.

OK, let’s talk customer service for a second: After you purchase SiteLock, an email should be sent either from them or the hosting company telling you what needs to be done to turn it on.

But OK, I admit some ignorance in this area, took a deep breath at what seems like basic customer service common sense, and went back to all the accounts to configure the DNS.

Hiccough

Within about 2 days, nearly every client, including myself, who had heeded my advice and purchased SiteLock couldn’t get or receive email.

I contacted Bluehost support. The main correlation seemed to be that the sites that were having the problem were the same sites that had just had SiteLock installed. I mentioned that right away.

We went several rounds of what I like to call “You must be an idiot, customer,” one of my favorite tech support dances, while I patiently waited for them to run through their script and figure out that everything they would ask was irrelevant.

You want to ruin someone’s day? Take their email offline.

You want to ruin my day? Tell me your email is offline.

You want to ruin my sleeping and eating schedule for days, and cause me to go into a cerebral tailspin for which wine is no salvation? Have everyone on your staff tell me their email isn’t working, and how upset and inconvenienced they are.

Because unlike Bluehost’s support, and even though I’m not an IT person, I actually care when my clients are having difficulty.

Do and Redo

After talking to 3 different Bluehost tech support people on 3 separate occasions, none of them addressed the SiteLock correlation. And the email problem continued to be intermittent yet present.

(One support person, Kendall, was actively trying to help, but I’m not sure Bluehost’s tech staff are given the right tools to think beyond the source of the single issue, to think beyond the scope of “they can’t get email” to “what else has happened to the account over the past few days.”)

Instead, their support staff stood behind the claim that if a person could get email through webmail, then it must be a setup / configuration problem locally—therefore not their problem.

I persisted: “No one has changed any settings, though, and this is multiple Bluehost accounts, multiple email addresses using all different email programs and devices. That doesn’t make sense. Are you SURE there isn’t something either happening on your end, or that there might be a connection to installing SiteLock…?”

No comment on the last point, but surely still: our problem, not theirs.

If everyone deleted the accounts from Outlook or Mac Mail, and re-added them with the SSL setup, it appeared to fix the bug, so that’s what I had everyone do. But I wasn’t satisfied.

The Plot Thickens

Then a message from SiteLock came through on one account: SMART scan cannot read your files. So I logged into the SiteLock dashboard and saw, no, it’s all set up properly. The recommended setting is to have the FTP login information automatically pulled from the hosting company, and it wasn’t giving me any red flags other than the email, which recommended to see if it happened again…

I gave it a day. Got another email. Got 3 more emails on 3 other shared hosting accounts, each of which have multiple sites on a single server. Multiple sites. On a single server. Shared hosting with automatic configuration…

This morning, another client texted to say he wasn’t getting email. I thought my head was going to explode.

I bypassed Bluehost all together and called SiteLock, and we took a look at the settings. We tried a single change: Disabling the “pull this information automatically from your host” setting and instead entering the FTP login information manually for each website on the account, together with identifying the root directory for that particular website.

Within minutes, my client was receiving email.

The SiteLock tech support guy, Martin, was both sympathetic and proactive. He asked his manager about my suspicion of the email–SiteLock correlation, and they confirmed that such a thing might happen if… the hosting company didn’t have the correct settings in place for the firewall.

***********************

Update: 8/16/15

Just when you thought it was safe, no. One client popped up after I published this blog post and indicated that he was having email problems. His email had worked intermittently, and then not at all.

You can imagine the state of my nerves as I hoped grimly that this was NOT about to spread to all my other clients with a similar setup.

First, I called SiteLock, had them check the settings one more time, and then asked them to temporarily disable the firewall when they confirmed that everything was set up properly. They recommended that I contact Bluehost because it was likely a server problem.

I grimaced… and dialed. I spoke to Kyle in Bluehost support who, to my amazement—and almost to my teary-eyed relief by this point—said he was familiar with this problem. He said that the change to the DNS settings when SiteLock was added to the domain made it so that email was now pointing to the firewall. And since that’s not a mailbox, it was simply disappearing, of course.

I was effusively excited, bowled over by the fact that someone over there not only didn’t try to make me feel like an idiot, but also was able to set me on the right path. Understanding that propagation could take a few hours, I made the changes, checked my other accounts, and waited.

And waited. And tested. And waited. And tested. 550 bounce back message after 550 bounce back message. Patience turned to suspicion turned to frustration…

After six hours, the sinking feeling was back: Why was my client STILL not getting email, when the email on the same server to other domains was working just fine?

I got on live chat with Bluehost, fire in my eyes and belly. I had absolutely no confidence that I would get anything but “It must be your problem.”

I explained where I was, and the Bluehost tech came back and said, “Fixed.” I ran a test and, indeed, it was fixed. I had to ask her THREE times to tell me what she had done so I could ensure it was set up properly across all my clients’ accounts, to be 100% certain that this wasn’t going to spring back into my life again. Finally, she did (see #6 below).

6 Steps to Installing SiteLock Through Bluehost WITHOUT Email Conflict

So for anyone else who happens upon this ultimate exercise in frustration, I give you the 6 steps & checks to purchasing and installing SiteLock through your web host (or at least through Bluehost):

1. Purchase SiteLock and create the DNS record in the hosting dashboard, which you can find by clicking the SiteLock icon in the cPanel.
2. Ensure that all email accounts gathering into local programs (Outlook, Mac Mail, Thunderbird, etc.) are using the SSL configuration to get and send email.
3. From that same screen, log into the SiteLock dashboard. Reconfigure the SMART Settings so that FTP is configured manually (not automatically from hosting provider) for each domain.**
4. In cPanel, view the MX records. Check that the primary MX record is mail.domain.com. If it isn’t (i.e., if it’s just domain.com), first delete the ‘mail’ CNAME, then edit the existing MX to mail.domain.com.
5. Create a new A record with ‘mail’ as the name and pointing to the IP address of the hosting account.
6. Then next to MX, click the More button and ensure that the selection is either Local or Automatic.

**Please note: If you have Spam Experts installed on certain domains, which routes email through a server other than your host’s, those domains should not be affected by #4-6. In other words, just doing #1-3 should prevent email conflicts.

***********************

Do I Stay or Do I Go?

I alone am on the hook for at least a year of SiteLock across 4 domains, plus hosting and domain fees, not to mention the cost of Site Doctor that initiated this entire ordeal. My clients, too, are locked in with their hosting companies (not all of whom are Bluehost, by the way).

But do you start over with some other shared hosting company, where these problems will likely be just as bad? Is there a way to avoid this type of issue while keeping costs low and sanity in check?

I guess the real Seth Godinesque question is: Do these companies want our business at all?

Photo Credit: UWW ResNet via Compfight cc