Troubleshooting Email

This is a whole new area for me, especially since all I’ve been doing lately is front-end work, so you’re going to have to forgive any rookie mistakes. Email is a tricky bugger in ways that I couldn’t even imagine about a week ago. I encountered a problem that a client/friend of mine was having with his contact form not sending emails to him. They, naturally, called up their web hosts to see what the problem was. They said it could’ve been marked as SPAM after all this time of going unnoticed, which according to my readings, is actually a legitimate reason even after two years of working properly. Shocker. This is when it starts to rapidly get more complicated. So first of all, email is extremely complicated. The solution could literally be so many things that I absolutely can not wrap my head around any of them. It could be marked as spam which means you’re going to be in a world of hurt for a little while until it’s found as legitimate. It could also be some other things to check which I’ll let you know about in the forthcoming paragraphs. Email is almost impossible to troubleshoot without server access, you need to have access to it. Plain and simple.

The Form

My initial thought was that something wrong with the form. After working on their other site, I knew the developer was impractical and messy. Two things that I absolutely abhor when it comes to development. I’m not a neat freak by any means but I stick to my own strict guidelines when I develop something. Anyways, I checked out the form plugin which was Formidable, and everything checked out. I tried to have it send to my email as well and that didn’t even work. So that would make me think that the form was broken. I substituted Formidable with Gravity Forms all to no avail. Grrr…

SMTP

My second thought, was to try SMTP. SMTP, simple mail transfer protocol, is your standard internet email. It’s a way to circumvent the built in WP email function. This is where using a plugin is handy because there’s explanations for the settings which I welcome with a warm embrace and something cold to drink. There’s dozens out there so use whatever works. I added my handy-dandy plugin and I got it to work! It was sent to one of my clients. Success! Yay….me….nope. Originally, the email is sent to two people and my client wasn’t going to have it not sent to him since he’s the integral part of the group (he’s a public speaker). At this point, I’m a little shattered. It’s working, at least partially, and there’s no problem. Functionality is still there so why can’t this be good enough? Here’s the business part, do what the customer wants. End of story. So, I’m back to the drawing board once again and it sucks.

Server Access

Here is where everything was out of my comfort zone. I’m comfortable with installing WordPress and uploading files to a web host, no problem. Editing MX records and DNS zones was so far out of my league that I had a partial panic attack for a few days and I’m perfectly fine with that. One thing that I wanted to check was error logs. If there were any error logs, that’s where I could find a virtual forward operating base. No error logs. Well, I’m stuck. As a “millennial”, Google is my source for everything. It’s my map of the internet but I actually ask for directions this time. I looked up “not receiving emails”, “not receiving emails from domain”, and eventually “not receiving emails from domain on Google Apps.” My search history was so expansive it looked like the colonial occupation of the west only in nerdier terms. Same amount of violence and sickness, but without the Donner party thankfully. It led me to MX or “Mail exchange.” Google(ugh) has a pretty cool tool that lets you know what all should be set up for DNS zones, and everything else mail related. There were a few errors on there which after a while could actually cause damage. Luckily, I did some reading on mail authentication shortly before this and had an idea of what it was talking about.

According to a bounced email, which is basically the same as a person getting bounced out of a bar, the email wasn’t authenticated and was marked as SPAM. That sends off a huge flair in that it needs to be authenticated, that’s what my reading said anyways. Well, that wasn’t all it needed. I found out that not only was it not authenticated, the MX records and Google Apps were not set up correctly. Now, I didn’t have access to their cPanel until June 5th so everything before it went defunct could’ve been changed or messed with without my knowledge. Some things happen, even as egregious as somebody going in and tampering with it. There’s a back story to that but let’s just say someone got jealous and it led to suspicion, which is not good.

MX Records

Upon looking at the mail settings on the server side, and getting some help I found out that the priorities were wrong. Now according to, none other than, Google Apps, the priorities for their email was out of whack. Gmail has different servers that handle email and it handles those servers according to priority. The lowest number is the highest priority so if one record has a priority of 10 and another of 1, the record with 1 as the priority will be the first. Now Gmail has specific instructions for the priorities, the server “ASPMX.L.GOOGLE.COM.” will always, always, always^20 be the highest priority at 1. Well, this record was at 10 and the others were even higher at 50 and 100 so it wasn’t getting priority treatment. It was being passed over through the different priorities through their other servers and eventually would be passed around through a queue. How I know it ended up in a queue is because my client sent me an email that they just received of all test emails I tried with Gravity Forms. Anyways, I changed the MX records to the correct priorities.

DKIM and DMARC

DKIM and DMARC are the standard protocols for mail authentication which can be found in an email header. These two not being set up correctly or not set up at all can lead to your domain mail being flagged as SPAM. In this case it’s partially what happened. The original form plugin (formidable) had over 1700 entries. The first two visible pages were riddled with SPAM entries, so from a glance, that meant to me that being marked as SPAM was a legitimate hazard. That’s what led me to DKIM and DMARC. These were not set up at all and since there was over 1700 entries, with a measurable amount of SPAM getting sent to them from their domain to their email account it was getting recognized as SPAM. That’s tremendously bad for business, especially since that’s your primary source of business contact. It’s inexplicably bad. What I did was use the same tool as the MX records and used the guidelines for the DKIM and DMARC to authenticate it. These are all done in the DNS zone editor. I used the advanced DNS zone editor. It’s where you’ll have the most success.

Solution

The ultimate problem has yet to be determined. There’s still multiple reasons as to why something like this happened. I can’t definitively say this fixed the problem yet. The domain email is getting their email which is a good sign of progression because two days ago there was nothing. I’m still waiting on the DNS zones to be propagated which could take anywhere between 12-72 hours. I have 0 patience so that’s going to drive me insane while waiting. Since only the domain email is now responsive, that means to tell me a setting is off on Gravity Forms which is certainly a possibility at this point in time. Again, rookie mistakes, leave me alone. This problem has been haunting me for about a week and half and it’s led me through a wicked journey through front end to server level development.

Here’s the link to the tool that helped out a lot:
Troubleshoot MX