Setting up DNS and email for WordPress on NameCheap

I recently purchased some shared hosting with NameCheap.com and I wanted to get a multi-subdomain WordPress (3.8.1) site up and running. My first two challenges had to do with getting DNS management and emailing working the way I wanted it to.


I have been using NameCheap for a few years now to manage my domain’s DNS host records. They have a nice, powerful interface for doing so and their name servers are very reliable.

The instructions they sent for getting started included, as a first step, switching my domain  over to the web hosting name servers. I didn’t much like that idea. Their shared hosting is a typical cPanel based solution and I really didn’t want to use the DNS record interface of cPanel. I confirmed with customer support that switching to the web host name servers would cause me to lose the NameCheap interface but the good news is they also confirmed I didn’t have to do so.

When I received my welcome email from them it included the IP address of the shared server where my site would live. All I needed to do was change the DNS A record for the @ (which stands for the root domain e.g. mydomain.com) and www entries to point to that IP address. At first it didn’t work but customer support informed me that the IP address in the welcome letter was wrong and when they gave me the right one everything started working fine. I did have to clear my browser cache too, though.

Google Apps Email

Google no longer offers Apps for Domains for free but I signed up years ago and have been using it ever since. Using Google as your email provider requires you to enter several MX domain records. I have had this setup fine for years now. The problem comes in with the new web host. Since I check my mail through gmail I don’t want emails delivered to the server where my new web hosting is. That doesn’t seem like a huge problem since I have no MX records pointing at that server but it gets in the way of things like WordPress being able to email out to addresses on my domain and even to any address at all.

cPanel MX Entry and Email Routing

cPanel is a fairly popular web hosting management tool and it is the one used by NameCheap. The main screen contains a link called “MX Entry” where you can manage your mail exchanger (MX) DNS records. It also has a setting section labeled “Email Routing” with the following options:

Configure server to always accept mail. Mail will be delivered locally on the server when sent from the server or outside the server.

Configure server as a backup mail exchanger. Mail will be held until a lower number mail exchanger is available.

Configure server to not accept mail locally and send mail to the lowest MX record.

It seems like the “Remote Mail Exchanger” option would be the one to use but it doesn’t work. If you do this WordPress (and PHP in general) will not be able to send any outgoing mail at all. This doesn’t make a lot of sense as sending mail out is a completely different thing than receiving mail but that’s how it works for some reason. I think all cPanel installations are like this.

“Local Mail Exchanger” will work in that sending mail won’t fail, but it will get delivered locally on the web host. Not what I wanted.

“Backup Mail Exchanger” almost works! It allows WordPress to send emails to my domain but unfortunately it fails when sending to an address outside my domain. With this setting I added a subdomain through cPanel’s DNS zone editor. Keep in mind that the outside world can’t see it in my case since my name servers are still the default NameCheap servers, but the web host still looks here first so it doesn’t know that. Then I added the Google MX records required to have mail sent to the Google Severs. The cPanel at NameCheap actually has an icon you can click that will do this for you automatically. Finally, I added the new subdomain I added in the DNS zone editor as the lowest priority (highest number) MX record.

With things setup this way, when PHP sends a mail to the local system it is accepted and sent on to the Google servers. For some reason though, when it tries to send to an outside address it thinks I am trying to “relay” mail which it disallows. This doesn’t make sense to me. Relaying means trying to get the server to send mail from a domain it doesn’t control, but it does control my domain. Makes no sense but that’s what happens. It thinks you are trying to relay mail and fails.

Technical Support and WP-Mail-SMTP

To get this situation resolved I had to contact customer support. What it eventually required was for them to open port 465 so I could log in to Google’s outgoing (SMTP) server and just send mail that way.

To get WordPress to send mail this way a plugin called WP-Mail-SMTP is required. The plugin adds a sub-menu under Settings where you can fill in all the necessary info. You enter the return address, tell it to send using SMTP, to authenticate with SSL on port 465, and enter the Google SMTP settings. If you are hosting more than one WordPress blog then you have to do this for each of them.


This part isn’t technically necessary with the solution of using the Google SMTP server. I set this up in the course of trying to get the “Backup Mail Exchanger” option to work. Even though I don’t need it setup that way anymore I’ve left it. That way if WordPress or some other PHP program ever tries to send an email through the web host’s email system it will still arrive in my Google inbox (if it is addressed to an email within my domain).

For the mail to be accepted however, I needed to make sure email received from the web host would be accepted as valid. Many email systems use the Sender Policy Framework (SPF) which allows a receiving server to check if the sending server is authorized to send email for a domain. This was fairly easy to do. I already had a record setup for Google’s outgoing servers so I just had to add a section to it that looks like +ip4:xxx.xxx.xxx.xxx (where the x’s are replaced with the ip of the web host’s server). I did this at the same time I completed the steps under “cPanel MX Entry and Email Routing” above.

Good to Go

To summarize, the solution was to get tech support to open port 465 and then use the WP-Mail-SMTP plugin to send outgoing mail through Google’s SMTP server. Now I’m all set and get all my WordPress notifications as expected.

Related Posts

About the Author:

Leave a comment