If your website is hosted on cPanel but your email is hosted externally, such as Google Workspace, Microsoft 365, Zoho Mail, Fastmail, or another email provider, contact forms and website-generated emails can fail even when the website itself is working correctly.

This can happen with virtually any website platform, including:

• WordPress web design agency
• Drupal
• Joomla
• Magento
• WooCommerce
• Custom PHP applications
• Other CMS and website frameworks

A particularly confusing situation occurs when:

• The website successfully processes a contact form or other transaction.
• The website-generated email is created successfully.
• Emails to external addresses work.
• Emails addressed to the website’s own domain fail.
• cPanel Delivery Report shows “No Such User Here.”
• The domain’s MX records point to Google Workspace, Microsoft 365, or another external email provider.
• cPanel is nevertheless configured to treat the domain as a local mail domain.

In this situation, don’t immediately change your CMS, form plugin, or website mail configuration.

First check:

cPanel → Email → Email Routing

The typical setup

A common hosting arrangement looks like this:

Website
example.com
    ↓
cPanel hosting
    ↓
Web server

while email is hosted separately:

Email
example.com
    ↓
Google Workspace

or:

Email
example.com
    ↓
Microsoft 365

or:

Email
example.com
    ↓
Other external mail provider

This is completely normal.

The website and email do not have to be hosted on the same server.

This can affect any CMS or website

The problem isn’t specific to Drupal.

For example, a WordPress contact form might send:

From: info@example.com
To: info@example.com

A Drupal Webform might send:

From: info@example.com
To: info@example.com

A Joomla contact form could do the same.

A custom PHP application might also generate:

From: info@example.com
To: info@example.com

The application generating the message doesn’t change the underlying mail-routing requirement.

If info@example.com is hosted by Google Workspace or Microsoft 365, the cPanel server needs to route the message to that external mail service.

The clue: “No Such User Here”

Suppose a website sends an administrator notification to:

info@example.com

The cPanel Delivery Report (go to cPanel > Track Delivery) may show:

Recipient:
info@example.com

Result:
No Such User Here

But a message sent to an external mailbox might show:

Recipient:
admin@example.net

Result:
Accepted

This difference is important.

It suggests that the website itself may be functioning correctly and that the failure is occurring specifically when the server tries to deliver mail to its own domain.

Why this happens

Consider:

example.com
A record
    ↓
cPanel web server

while:

example.com
MX record
    ↓
Google Workspace

The public DNS configuration correctly tells the Internet:

Website traffic goes to the cPanel server.

and:

Email goes to Google Workspace.

However, cPanel may still consider the domain a Local Mail Exchanger.

When the website sends:

info@example.com

the local mail server may attempt to find info as a mailbox on the cPanel server.

If it doesn’t exist there:

No Such User Here

The message never reaches Google Workspace.

You may also use tools like https://mxtoolbox.com/ to further check issues with your DMARC, SPF, DKIM.

The fix: Remote Mail Exchanger

If email for the domain is hosted externally, go to:

cPanel → Email → Email Routing

Select the domain.

If the configuration shows:

Automatically Detect Configuration: Local

select:

Remote Mail Exchanger

and save the change.

The resulting flow becomes:

Website / CMS
      ↓
cPanel mail server
      ↓
Remote Mail Exchanger
      ↓
Domain MX record
      ↓
External email provider
      ↓
Recipient mailbox

Google Workspace, Microsoft 365 and other providers

The same principle applies regardless of the external email provider.

Google Workspace

Website
   ↓
cPanel
   ↓
Remote Mail Exchanger
   ↓
Google Workspace

Microsoft 365

Website
   ↓
cPanel
   ↓
Remote Mail Exchanger
   ↓
Microsoft 365

Zoho Mail

Website
   ↓
cPanel
   ↓
Remote Mail Exchanger
   ↓
Zoho Mail

Fastmail

Website
   ↓
cPanel
   ↓
Remote Mail Exchanger
   ↓
Fastmail

The provider changes, but the cPanel principle remains the same.

Don’t change your MX records just because the website is on cPanel

This is one of the most important points.

Your website can use:

A record
example.com
    ↓
cPanel server

while email uses:

MX record
example.com
    ↓
External mail provider

That’s perfectly valid.

A records and MX records have different jobs.

• A/AAAA records determine where website traffic goes.
• MX records determine where email is delivered.

If Google Workspace, Microsoft 365, or another provider hosts your email, don’t change the MX record to the cPanel server simply because your website is hosted there.

Why “Automatically Detect” isn’t always enough

cPanel provides an:

Automatically Detect Configuration

option.

However, automatic detection can determine that a domain is local based on the server’s own DNS and mail configuration.

This can become problematic after:

• Website migrations
• cPanel account migrations
• DNS changes
• Email migrations
• Moving email to Google Workspace
• Moving email to Microsoft 365
• Changing hosting providers
• Restoring an old hosting account

The domain may therefore have:

Public DNS:
MX → External provider

while cPanel still has:

Mail Routing:
Local

When those two configurations don’t agree, website-generated emails can behave unexpectedly.

The website application may be completely fine

Before changing the website’s email system, verify whether the application is actually generating the message.

This applies to:

WordPress

Check the contact form/plugin logs and cPanel Delivery Report.

Drupal

Check Webform submissions and email handlers.

Joomla

Check the contact form/mail configuration.

Magento or WooCommerce

Check transactional email configuration and mail logs.

Custom PHP

Check PHP mail/SMTP configuration and server mail logs.

The principle is the same:

First determine whether the application generated the email. Then determine where the mail server attempted to deliver it.

Use an external mailbox as a diagnostic test

One useful troubleshooting technique is temporarily sending the website notification to an external mailbox you control.

For example:

From:
info@example.com

To:
admin@example.net

The sender and recipient being on different domains is not a problem.

The important part is that the sender remains an address belonging to the website’s domain.

If the message arrives successfully, you’ve established that:

Website
   ↓
cPanel
   ↓
External recipient

is working.

Then restore:

To:
info@example.com

and test the actual business mailbox.

Keep the website’s domain as the From address

Avoid using the visitor’s email address as the sender.

For example, don’t normally configure:

From: [visitor email]

Instead:

From: info@example.com
Reply-to: [visitor email]

This is better for:

• SPF
• DKIM
• DMARC
• Sender reputation
• General email deliverability

It also means the business can simply click Reply to respond to the person who submitted the form.

Don’t create duplicate notifications

A contact form can also accidentally send multiple copies to the business.

For example:

Confirmation:
To: [visitor email]
CC: info@example.com

and:

Notification:
To: info@example.com

The business then receives two copies.

A cleaner configuration is:

Customer confirmation
To: [visitor email]

and:

Business notification
To: info@example.com

Keep the purposes separate.

Local vs remote mail exchanger

This is the simplest way to remember the setting:

The rule is:

If the mailbox is hosted externally, cPanel should normally use Remote Mail Exchanger.

What not to do

When you encounter this problem, avoid immediately:

• Reinstalling the CMS
• Reconfiguring the contact form
• Rebuilding the Webform
• Changing the website’s From address to a visitor’s email
• Changing the domain’s MX records to cPanel
• Installing an SMTP plugin/module without first diagnosing the routing
• Assuming an SPF or DMARC warning is responsible for No Such User Here

Start with the actual delivery evidence.

Troubleshooting checklist

Website or CMS

Form submission is successfully processed.
Email handler/plugin is enabled.
Recipient address is correct.
From uses the website’s domain.
Visitor address is used as Reply-to.
Duplicate CC/notification settings have been checked.

DNS

Website A/AAAA records point to the web server.
MX records point to the actual email provider.
No unnecessary duplicate MX records exist.
SPF is reviewed.
DKIM is reviewed.
DMARC is reviewed.

cPanel

Open Email → Email Routing.
Determine whether the domain is Local or Remote
If email is externally hosted, select Remote Mail Exchanger.
Don’t rely blindly on Automatic Detection after migrations or DNS changes.

Delivery

Test an external recipient.
Check cPanel Delivery Report.
Test the actual business mailbox.
Check the external provider’s spam/junk folder.
Review mail authentication separately if necessary.

A successful delivery report would then look something like below in your cPanel > Track Delivery showing all emails from the website form is sending and successful.

The takeaway

If your website is hosted on cPanel but email is hosted externally, such as Google Workspace, Microsoft 365, Zoho Mail, Fastmail, or another provider, a website-generated email can fail even though the website and contact form are working correctly.

When cPanel reports:

No Such User Here

for an address that actually exists with the external email provider, check:

cPanel → Email → Email Routing

If cPanel is treating the domain as Local while email is actually hosted externally, change the configuration to:

Remote Mail Exchanger

The issue isn’t necessarily WordPress, Drupal, Joomla, Magento, WooCommerce, or the contact form itself.

The website may be doing its job. The problem may simply be that the cPanel mail server is trying to deliver externally hosted email locally.