Bug? Send emails with Usermin to a domain hosted in same server BUT with external MX server

Debian 10 REQUIRED

If sending an email from Usermin to an address in other domain also hosted in the same Virtualmin server BUT with DNS MX pointing to an external service, (i.e. Zoho Mail Server) the email is not delivered.

My Virtualmin hosts 2 domains: domain1.com and domain2.com
I have domain1.com using DNS MX to an external provider. So, the domain1.com does NOT uses Virtualmin email. The email is working just fine.
The domain2.com is using Virtuamin email (DNS MX is also from domain2.com). If I send an email from domain2.com using Usermin to a valid email address in domain1.com, the email is NOT delivered.
If I send an email from domain2.com using Usermin to other email address (i.e. Gmail) the email is sent.

Is this a possible bug?


Have you checked your mail log to see what’s happening?

*** Professional, Affordable, Trusted Technical Support – tpnAssist.com ***

Is DNS for the receiving domain being hosted by Virtualmin?

If DNS for the receiving domain is being managed by a third party DNS service and also by Virtualmin then Virtualmin will treat the DNS records of its own DNS server as authoritative so you should ensure that the MX record for the receiving domain in Virtualmin’s DNS server also points to the external service.

Yes, I did. It seems to be working fine. However, I do not receive the email in Zoho. If I send to the same email address from Google, it is delivered as expected. So I guess there is some conflict with hosting domain1.com and domain2.com in the same server BUT when one of the domains is using an external MX server.

This is my log:

Oct 5 12:21:02 srv1 postfix/smtp[20910]: B21E26C0A32: to=<email@domain1.com>, relay=mx.zoho.eu[185.20.xxx.xxx]:25, delay=5.6, delays=0.1/0/5.2/0.31, dsn=2.0.0, status=sent (250 Message received)

The DNS of receiving domain is hosted by Virtualmin (domain1.com) BUT the MX server is an external provider (Zoho Mail). The DNS of the sender domain (domain2.com) is hosted in the same Virtualmin as domain1.com BUT is using Virtualmin Email server.

My guess is the email server checks the sending domain and receiver domain are hosted in the same server (local) and bypass the MX external server and tries to locally deliver the email.

Hmm. Curious. In the situation you describe, mail should have been delivered correctly.

Try this: edit the virtual server of the receiving domain and uncheck the box for mail. Basically disable the mail feature of the virtual server.

That may solve the problem if anything will.


Does your sending server have a correctly setup PTR record?

Does your sending server have DKIM and SPF setup and running correctly?

These two situations if not setup correctly could be causing Zoho to turf your mail on receipt.

Based on your logs the message is reaching the Zoho network correctly, however if they are doing strict validation they may be treating the mail as spam.

Yes. Both domains have PTR, DKIM, SPF and DMARC running correctly.

The logs displays" message received "BUT how is that possible to know if this was received if the receiver MX server is in other server?

I am wondering if server noticed the sending domain and receiver domain are both hosted in the same server (local) and, despite the MX server from receiver domain is an external address, it bypasses the MX external server and tries to locally deliver the email.


If you look at your log entry, the relay was “mx.zoho.eu”. This is the server the mail was sent to. Therefore it left your server and was further received by that server. However if they do checks or scans against the message before delivering to the inbox of recipient, then the message could get turfed out right or sent to the “spam” folder. This is why I asked about stuff that can cause false positives with antispam software on remote server.

*** This concludes my FREE consult on this matter. If you’d like further assistance from me we can setup a private consult at my Virtualmin exclusive rate. ***

Ok, thanks for the help, @tpnsolutions .

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.