You Can’t Receive Emails to Your Own Domain from Your Joomla Website? Read This!

Last Monday, we received an email from a company (which is a client of ours) stating that any email sent from their Joomla website to an email to their domain isn’t being received. For example, assuming that their Joomla website is ourclientjoomlawebsite.com, and the Joomla website tries to send an email to admin@ourclientjoomlawebsite.com (the email, in the case of our client, was a notification email from an RSForm form), then that email doesn’t get delivered.

When they first told us about the problem, we insisted that the problem was caused by missing SPF settings, and so we told them to add the IP of their server to the SPF record in their DNS (they were using Office 365 for their mail), but they didn’t do that. The next day (Tuesday), the IT Manager working for the client called us and told us that the email wasn’t even caught in a spam filter by the mail server – so, most likely – the email wasn’t even sent by the server which was hosting the Joomla website, so it’s definitely not an SPF issue. He then mentioned that they receive notifications from their Joomla website to Gmail and Yahoo accounts, but they don’t receive them when they are sent to company emails. We thought, that was strange, but we insisted that they add the IP of the server to their SPF records, just to see if that solves the problem. Finally, they did – but, to our regret (and shame, and humiliation, and embarrassment, and disgrace, and…), that didn’t fix the problem.

The IT Manager then emailed us the negative results, urging us to see if the issue is caused by RSForm, the Joomla website, or the server. So we did (today), and the first thing that we examined was the exim logs the following way:

• We ssh’d to the server.

• We changed to the /var/log/ directory by issuing the following command:

  cd /var/log

• We searched the log for any entries pertinent to the affected email address:

  grep -R "admin@[ourclientjoomlawebsite].com" *

• We saw the following results:

  exim_mainlog:2016-09-23 15:11:20 1bn9Oy-000DDQ-73 <= no-reply@[ourclientjoomlawebsite].com U=**** P=**** S=1662 id=cfc73da22404d08163d64fbbab9316b5@www.[ourclientjoomlawebsite].com T="New submission from 'Contact Us'!" for admin@[ourclientjoomlawebsite].com exim_mainlog:2016-09-23 15:11:20 1bn9Oy-000DDQ-73 ** admin@[ourclientjoomlawebsite].com R=virtual_aliases: No Such User Here

Hmmm! Looking at the above was enough for us to explain what was going on. The server hosting the Joomla website had its own mail server, and that server thought that it was responsible for all email accounts belonging to ourclientjoomlawebsite.com (which was wrong, since Office 365 was responsible of these email accounts), and so the exim mail application was checking the internal (server) database for the existence of these accounts, and then silently failing when it’s not able to find them.

So, how did we fix the problem?

Fixing the problem was quite easy:

• We logged in to the cPanel account of the domain.

• We clicked on MX Entry under Email.

• We selected our client’s domain and we chose Remote Mail Exchanger in the Email Routing section.

• We clicked on the Change button.

• That’s it!

After doing the above, we tried sending a notification email from the Joomla website (we did that by filling out an RSForm form), and, guess what? It worked! In fact, we knew that it worked because the client sent us an email a few seconds after we submitted the form telling us that the problem was solved! We were happy and the client was happy, which is always ideal in our line of job!

How come the fix worked immediately?

Technically, the fix didn’t consist of any DNS changes which usually take time to resolve. The fix consisted of a small setting change on the server, telling it that it’s not responsible for routing emails (and that the routing of emails is handled by an external server). These kind of setting changes take effect immediately, and they don’t even require restarting the mail server.

What about our ego?

We admit it – we started this task with an inflated ego. We were confident that the problem was caused by SPF settings and we didn’t listen carefully to what the client was saying. That was a mistake but the consequences of that mistake were not. In fact, we were humbled when we found out that we were wrong (after insisting that we were right), and we were gently reminded that an inflated ego attitude is a bad thing in our business, and that we should always, always, listen very carefully to the client.

We hope that you found this post informative and that it helped you solve your problem. If it didn’t, then please make sure that your SPF settings are correct. If they are, or if you feel that this whole thing is a bit over your head, then fear not, we’re here to help! Just contact us and we’ll take care of this issue for you in no time and for a very affordable fee!