PHP mail not sending domain emails to external mail server

Recently, I’ve done some work for a client with an odd issue: the contact forms on their website (let’s call it client-website.com) — which delivered completed form enquiries using PHP’s mail() function — could not send emails through to email addresses containing their own domain.

This means that, if we were to set the form to deliver enquiries to an address like hello@client-website.com, the email would be completely dropped — you would neither find it in the junk or spam folders, nor find any trace of the email in their admin and mail logs. If we delivered the email to our own personal email addresses (e.g. personal@gmail.com), or to emails from another domain (e.g. mail@terresquall.com), then the email would go through (and skip right past the spam folder too).

For weeks, this problem confounded me, until now… and it’s actually a really simple fix.

The client’s web and email setup

To understand why this was happening, we need to first understand how the client’s website and email service is set up. Basically:

Their web service (i.e. HTTP and HTTPS) is provided by a mass hosting server. This server runs the website, so it’s the one that is working when you visit their website at client-website.com.
Their mail service (i.e. for when you send emails to their domain) is provided by Google Workspace, so the MX records for their domain are pointed to Google’s SMTP servers.

Here’s the catch: The server that provides their web service also provides an email service, like many mass hosting services. However, because their MX records are not pointed to this server, it does not receive any of their domain emails.

Finding the problem

For weeks, it didn’t occur to me that the above-mentioned catch could be what’s causing the problem. I was wrongly certain that Google Workspace must’ve been rejecting the emails sent from the contact form as spam because something was set up wrongly, like the domain’s SPF record. If these emails were getting rejected, however, Google Workspace’s mail logs should still indicate this, and they weren’t!

This meant that the emails were not getting delivered by the web server at all. It could deliver emails to other domains with no problem, but it couldn’t deliver emails to its own domain!

The problem, it turns out, was the web server’s email routing policy — because the web server was also configured as a mail server for client-website.com, it considers itself the mail server for the client-website.com domain. This meant that it routed all emails to the domain into the mailboxes under its own mail service. More concisely, we can also say that the server was routing domain emails locally.

Fixing the problem

Once the problem was identified, fixing it was simple. The specific way will depend on the server control interface that your mass hosting service provides. Here, I’m listing the fixes for 2 platforms:

Plesk, and;
cPanel

Article continues after the advertisement:

Plesk

If your hosting provider is using Plesk, what you want to do is deactivate the mail service on the domain(s) that your hosting provider is providing web service for.

Once you’ve logged in, find the relevant domain(s) under your Websites and Domains tab, and access the Mail Settings page.

Find your Mail Settings in Plesk — When in the **Website & Domains** tab, click on **Mail Settings**.

Then, in the Mail Settings page, deselect the Activate mail service on this domain checkbox, and click on the Apply button to save this change. This should stop the server from routing emails back into its own mailbox.

Note: Depending on how your hosting provider configures their servers, it may take awhile for these settings to update, so do give it some time to see if this fixes the deliverability issue. Also remember to check your spam or junk folders after making this change if your mail is still missing.

Deactivating the mail service on Plesk — Remember to click on **Apply** after unchecking the **Activate mail service on this domain** checkbox.

cPanel

If your hosting provider is using cPanel, you need to instruct cPanel to use the Remote Mail Exchanger to route emails, so it will not route emails locally.

To get to the page where you can change that, you need to find the Email Routing item in your cPanel home page after logging in.

Find the Email Routing icon in cPanel — If you can’t find the icon, that means that your hosting provider hasn’t allowed you to modify it, or your hosting plan does not provide a mail service.

Once in the Email Routing page, select the Remote Mail Exchanger option, and click on Change to save your settings.

Routing local emails to an external mail server — Remember to click on the **Change** button to save the change after updating your settings.

Conclusion

Once your settings are updated, your web host should stop routing emails from PHP mail() (as well as other emails it sends out coming from the domain it identifies itself as) back into its own mailbox.

Let us know in the comments section if this article was helpful for you, or if we’ve made any mistakes with our information or instructions above.

If you need more technical help beyond what we have in this article for your website or organisation, do feel free to contact us too — we provide web support and email hosting as part of our service offerings, and might just have what you need.