Imagine your vehicle starts making a noise that is unusual, so you take it into a mechanic for troubleshooting. You take care to explain what you hear, when you notice it the most, and how you’ve been able to reproduce it. A few hours later the mechanic calls you back with a happy tone: “Great news! Your vehicle is ready for pickup. Oh, and we couldn’t find anything wrong with it.”
The “sometimes works” issues are always frustrating, even when not directly related to technology. Often times we find ourselves going in troubleshooting circles because we find a sign that points to a possible cause, but then the next step seems to rule out that exact possible cause.
Recently we ran into an issue with a client’s website where a “Contact Us” web form was working correctly…for some recipients. As always, “your milage may very” – if you are experiencing this symptom, hopefully this will prove useful in your situation.
Reported Issue
A client submitted a ticket their online store had a simple “Contact Us” page, and they were not receiving any emails from that page.
Initial Testing & Environment Checks
Visiting the site, a simple test of the Contact Us page yielded a peculiar result right from the start. Using the “send me a copy” check mark that common web forms include, a copy of the message was in fact received to the “copy” email address (one of our SysDrive emails), but did not arrive at the client’s inbox as expected.
Confirming their setup:
- website is running on Joomla! (PHP-based CMS), fully updated
- website is running on a shared hosting service, including cPanel for management
- the global configuration of Joomla is configured to use PHP mail function (instead of local sendmail function or an external SMTP server)
- Joomla is configured to mark outbound messages (“send from”) as [email protected]
- the client uses Exchange/Office 365 for their email system
- the inbox that should be receiving the form result is a shared mailbox ([email protected])
Check Joomla! Logs
Our first step was to enable debugging on the site and check for any clues. Unfortunately, the debug console would provide “No messages to display” after the web form was submitted.
Checking Exchange Message Trace
This is where things started to make us scratch our collective heads. The thinking is that by checking the Message Trace logs in the client’s Exchange environment, we could see 1 of a few options:
- the emails were correctly delivered, but being deleted or moved by a mailbox rule
- the emails were being marked as spam/junk by Exchange
- some other anomaly that Exchange was handling the emails in a way they couldn’t be easily found
Unfortunately, the incoming messages could not be found at all in the Message Trace logs. The form submission was correctly received by the “send me a copy” email address, so it appears the PHP function is working correctly…so why wasn’t it sent to this Exchange tenet?
With no indication the messages were being received by the Exchange server, we could start to rule out spam filtering, custom mail transport rules, user inbox rules – anything on the client’s email system.
Narrowing Down the Issue
At this point, we appeared to have conflicting evidence. On one hand, it seems like the issue was with the client’s Exchange setup since our other inbox did receive the message. On the other hand, the Exchange Message Trace logs showed no sign of the message ever hitting the Exchange server.
Running a few more tests:
This let us narrow down the issue to occurring only when both the sending email address and the receiving address are both within the client.com domain.
The Culprit
Now that we know the issue only occurs when both the sending and receiving domain name match, we can begin to confirm a theory that this is related to DNS – or in a way, lack of using DNS as we expect.
Similar to servers and desktops that can use “localhost” when traffic needs to stay on the local device and not go to the outside network, many Linux-based servers with mail functions enabled will by default use the configuration of local mail exchanger. This means that the server will try and keep mail locally in that server if possible, which it does by matching domain names.
In our situation, the server running the web host is not the same system being used for email hosting. We need all sent emails to go out to the mail host on public record, as identified by our MX DNS settings (in this case, Office 365). To force the server to send all emails out to the Internet, we need to configure the server for Remote Mail Exchanger.
Since this is a shared hosting environment, we can use cPanel to check and update the mail routing options.
After logging into cPanel on the web host, click to open the Email Routing options
After selecting your domain with the impacted website, be sure to change from Local Mail Exchanger to Remote Mail Exchanger, and click Save.
If you experience a similar issue with a website or server failing to send emails where the “from” and “to” emails are of the same domain, we hope this will help save you some time!