Mail autoreply sending nothing and nothing arriving

OS type and version Ubuntu Linux 20.04.5
Virtualmin version 7.1-1

LEMP install
Only just installed on fresh Linux 5.4.0-126-generic on x86_64 VPS
Everything seemed ok.
Web page working as expected so DNS and SSL just fine. Also I can FTP as user root and other users as required.
I created 2 mail users through Virtualmin and tested them from other server accounts including - All OK - messages received and replied to using usermin So I created a 3rd user as above with an autoreply and attempted the same test. Not only did I not receive the autoreply but the messages did not arrive in the usermin mailbox!

Does setting an autoreply block arrival of messages?

I haven’t a clue where to start looking
Thanks in advance for any help. No knowledge of Postfix or Dovecot and minimal Ubuntu ie very raw newb


The best place to look for diagnosing mail issues is the “mail.log” file. This is located at /var/log/mail.log

I would open a terminal which remains visible on screen, then run:

tail -F /var/log/mail.log

This will cause the log to be read in real time so you can track what is going while you conduct the next step.

Go ahead and test sending and receiving. See if you notice any errors or odd behavior being logged as you do. It’s important that you keep the log screen visible while doing the above tests so something happen nearly in real time so you’ll want to catch what is going on.

If you would like to schedule a support session I can work with you over a screen sharing session to further diagnose things at a Virtualmin exclusive intro rate. Drop me a line if you desire or require more in depth assistance.

*** Professional, Affordable, Trusted Virtualmin assistance ***

1 Like

Many thanks,

I am sure that has helped find the problem:

Sep 22 18:56:56 ********* postfix/pickup[70460]: CBABD89DD6: uid=65534 from=<>
Sep 22 18:56:56 ********* postfix/cleanup[73710]: CBABD89DD6: message-id=<1663873012.73715@
Sep 22 18:56:56 ********* postfix/local[73711]: 01B4B89DC2: to=<>, orig_to=<>, relay=local, delay=4.9, delays=0.11/0.01/0/4.7, dsn=2.0.0, status=sent (delivered to command: /etc/webmin/virtual-server/ /home// /var/virtualmin-autoreply/
Sep 22 18:56:56 ********* postfix/qmgr[1918]: 01B4B89DC2: removed
Sep 22 18:56:56 ********* postfix/qmgr[1918]: CBABD89DD6: from=<garry@
.com>, size=775, nrcpt=1 (queue active)
Sep 22 18:56:56 ********* postfix/smtp[73652]: CBABD89DD6: host[] refused to talk to me: (mxeue012) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record.
Sep 22 18:56:57 ********* postfix/smtp[73652]: CBABD89DD6:,[]:25, delay=0.2, delays=0.07/0/0.12/0, dsn=4.0.0, status=deferred (host[] refused to talk to me: (mxeue110) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record.

So I pressume a missing PTR record, but why?

My test email was sent to 2 of the users and one got through just like before the other didn’t. Both users were created by Virtualmin only one has a autoreply. (the one who did not get the test) I have checked the DNS records on the “box” and there is no PTR record and no obvious easy way to add one (a Digital Ocean VPS)

Port 554 must be open as the one user did get the test and when I did a reply through usermin the reply arrived back at the original tester.

I have also tried an original outgoing email from the (one not autoresponding) to the test originator and that email arrived.

So it looks like outbound mail has no issues. Inbound mail falls over with newly created user. I am going to try creating a 4th user but not setting an autoresponder to see if that goes ok. It will be the same as the first 2 users that are working.


If the server you are sending from does not have a proper PTR record associated with the IP address sending the mail, it will be a problem with many ISPs who require this as a validation method.

PTR records are managed at the service provider level, and not within your own DNS records as you don’t own the IP address.

Fortunately, many VPS and dedicated server providers make it easy to manage the PTR via their control panel. For instance DigitalOcean adjusts the PTR when you adjust the hostname of the droplet. Other’s offer a dedicated area for managing this. Some update the record fast, and others take a bit longer.

For the providers who don’t offer a self serve option for this like my ISP for my business Internet, an email or phone call with your request should do the trick as they’ll often set it for you upon your request.

1 Like

Sorry if this sounds like I’m stupid but.
and I do appreciate the help

So despite the fact I own the domain that is hosted on my DO box and is the current “hostname” presented in Virtualmin I have no ability to correct/add this PTR record.
So the problem lies with the provider of my email (eg. my broadband provider) who has absolutely nothing to do with my VPS and who I am certainly not going to give access to my DNS records.
So given the problem lies with the provider of an email service I have no control/access over presumably this problem will be global and any/everyone who sends to my domain will have the same problem (i.e. my user will not receive any email).

In that case I really do not understand why sending from the same user the other mailboxes receive email and can reply with Usermin !!

Thats not exactly what he meant,

your rDNS can be only set by owner of your server’s IP which in your case looks like digitalocean so look for the same on Digitalocean dashboard not your client side ISP.

Looks like here is your answer on how to do that on digitalocean dashboard

1 Like

So I went to the DO help page that you linked to. But I guess that is so out of date it is useless (I think DO have changed their Console as none of that worked) However I did check the FQDN is correct in the records and if I go into the droplet as root the hostname states correctly the FQDN as does Virtualmin’s Dashboard.

I also went to Domain Health Check - Online Domain Tools - Blacklist, Email, Website, DNS - MxToolBox and it displayed 2 errors and 5 warnings. “No DMARC record found” dns “Serial numbers do not match” “SOA Serial Number Format is Invalid” “SOA Expire Value out of recommended range” “Reverse DNS Resolution - No PTR Record found” mx “DMARC Quarantine/Reject policy not enabled”

given those issues and I’ve no idea how to fix them I am goint to resort to a support ticket.

Just discussed withe rest of the team and conclusion is that it is all a time waste.
The client not happy, so we have rebuilt the DO box from ISO and are reinstalling from scratch.
we will then test again as before - DO were no help given the time frame but will leave the question with them. It remains a puzzle to me why it only affected one email setup. Thank all who contributed. I’m hoping that next week I can add better news.
have a good weekend


Drop me a line on WhatsApp, if you are using DO I can offer you a bit more detailed assistance as I use them for my own and a few clients hosting.


*** Anyone reading this can also reach out if they ever want to chat ***

@ tpnsolutions

Thanks - not on Whats App, tried to respond to the Virtualmin email that was sent but that seemed to get blocked by the system " Email issue – Auto Generated Reply" remember I’m new here and I seem to be falling foul of all the moderator bots. I’m out of the office till Monday and do not have full access to the droplet from here. In my reply to you I added a copy of the issues from mxtoolbox which lead me to expect the new droplet to be failing with the same errors.
Thanks again for the offer of help
Have a good weekend. I’ll be back Monday am UK time

OK - solved - Destroyed the DO VPS and rebuilt from scratch. Did setup slightly different (not sure if that did it) also asked DO support to create PTR (apparently there was a PTR - it was just pointing to an old IP ??? !!!

the new install of Virtuualmin was receiving email but after much digging found in Postgres that the outgoing were stuck in the Queue! A simple click on requeue fixed that.

Thank all for the help … now I have a separate but related problem → for a new topic (one problem per topic)

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