Note: This is quite a specific technical issue, but one that took some serious research to solve that we had for one of our clients recently. I’m sure that this problem is relatively commonplace given the combination of technology used and the information on how to fix it is scarce, so hopefully this will answer a real head-scratcher for anyone out here experiencing the same problem!
We were experiencing a very strange issue with one of our clients recently in that they were unable to send email from any of their mail forms on their website to email at their own domain. In short, when they filled in an email form on example.com that was intended to send an email to email@example.com it just failed silently. If they had it email example2.com instead it worked fine. The setup they have is as follows:
- PHP Website on shared hosting with a cPanel admin system.
- Google Apps email.
- Domain and nameservers hosted by their domain registrar.
- DNS records on registrars nameservers pointing to shared hosting for the website (@ and WWW records).
- DNS records on registrars nameservers pointing to google apps for the email (MX records).
This was clearly an issue with the hosting company (who shall remain nameless!) and they were completely unaware of how to fix the problem after several conversations, so we took on the task of diagnosing the issue. The first thing to do was check what happened when email was sent from the website to the domain. This was achieved by using the “Email Trace” tool in their cPanel.
Typing firstname.lastname@example.org into the email trace showed us the actual root of the issue. The email trace gave us an error of “virtual_aliases via virtual_aliases router forced address failure”. This particular issue would actually have identified itself as “PHPMAILER_RECIPIENTS_FAILED” if the error were not being suppressed by the web hosts server configuration when the enquiry form was filled in on the website.
Now the root of the problem was clear. Essentially the web server was misconfigured. Due to the site of the domain being hosted on the web server it was also assuming that it was handling the email for that domain as well which wasn’t the case.
The way to solve this on most linux servers that you have root access to would be as follows:
- Edit the /etc/localdomains file.
- Remove example.com from the file.
- Edit the /etc/remotedomains file.
- Add example.com to this file, ensuring that you enter it in the same way it was listed in the localdomains file.
This would make the server check for the MX records on the registrars nameservers before sending the email, rather than assuming the settings on itself were the ones to be used. However this wasn’t possible on this clients website due to the use of cPanel for server admin and the lack of root access to the server as it was shared. Fortunately we can use a workaround of duplicating the domains MX records in the cPanel to achieve the same effect. To do this just do the following:
- Click the MX Entry tool in cPanel
- Select the problem domain
- Add the same MX records that are specified in the registrars DNS. Ensure that any that were there originally are deleted.
- Now you can go back to the Email Trace tool and try again – you should see a success message, and any emails sent from enquiry forms on the site will work perfectly!