Root user email not getting redirected

[webbasica]

While troubleshooting a clients' issue, I stumbled on this little problem. My Mail queue shows a bunch of frozen emails intended for the root user. This is the message I picked up from the Exim mainlog

2025-07-25 15:12:53 cwd=/root/ 4 args: send-mail -i -- [email protected]
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu <= [email protected] U=root P=local S=532 T="test" from <[email protected]> for [email protected]
2025-07-25 15:12:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1ufPin-00000008RHH-0SKu
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu ** [email protected] F=<[email protected]> R=virtual_aliases:
2025-07-25 15:12:53 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1ufPin-00000008RHH-0SKu
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 <= <> R=1ufPin-00000008RHH-0SKu U=mail P=local S=1862 T="Mail delivery failed: returning message to sender" from <> for [email protected]
2025-07-25 15:12:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1ufPin-00000008RHM-0bh6
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu Completed
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 ** [email protected] F=<> R=virtual_aliases:
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 Frozen (delivery error message)

I already added/created a forward using /root/.forward and I edited the file at /etc/aliases, but nothing works.

 

[Richard G]

You don't still use the xx-xx-xx.da.direct as hostname right? If yes, you need to change that.

Root should be sending from the hostname something like [email protected] (and not use the -da.direct domain just to be clear. But I guess you do have a decent hostname.

This issue might be also caused by the sender spoofing protection I answered in your other thread. Fix that first and then see if root mails still get stuck.

 

[webbasica]

I just found out Directadmin creates a default hostname using the server's IP. And no, I didn't use that at the beginning. I've been through a few subdomains and landed on "da.domain.com" a few months back. Should I change it back to something else? Is it because it's easy to guess, or something else?

The fix you suggested didn't solve the issue. And it makes sense, I never have received mail from the root user, so I'm sure it's not related to the latest update.

 

[Richard G]

Is it because it's easy to guess, or something else?

No it's becasue the ip-ad-ress.da.direct hostname is not owned by the license holder but by Directadmin.
So at a certain moment, this will cause some odd issues or problems, mostly with sending mail as we experienced and sometimes also with certificates. At least that is what we've seen happening fairly often here.
As a host you should use your own FQDN hostname anyway. DA only provided the ip-ad-ress.da.direct hostname so users could easily access DA and setup stuff.

However, if domain.com is a (masked) domain of yourself and you just use da.domain.com as a hostname, then that is perfectly fine, no need to change that.
Only change if you're still using the da.direct hostname.

Now to the root mails problem. That is most likely caused by the hostname changes. I wonder if you have a seperate DNS entry for the hostname. It's best that you put not that da hostname record in your domain.com dns but create a seperate entry for da.domain.com as admin in DNS administration itself, so not under a user.
If you did (or going to) then the hostname directory must be present in /etc/virtual for you to be able to get the root mails through (local mail).

I made a manual that you can check, for the hostname, where the put the hostname record and to check owner and permissions (and if required create) the hostname directory in the /etc/virtual directory.

Check and compare here: https://forum.directadmin.com/threa...e-your-servers-hostname-in-directadmin.70371/

I'm almost sure if the hostname is set correctly and it can send local mail, you will also start seeing your root mail.

 

[webbasica]

Well, now I feel dumb. As soon as I added the root: [email protected] line to the aliases file in /etc/virtual/da.domain.com, messages started pouring in. I'm getting a few issues because of the PTR record, but that's secondary, we can call this issue officially fixed.

Thanks a lot!

 

[Richard G]

we can call this issue officially fixed.

Well in fact no. You created a workaround.

If you have a /etc/virtual/da.domain.com directory, then you created the da.domain.com under a domain name, which is not what I wrote. I wrote to not create that da.domain.com under an account, but only in DNS administration as admin.
This way real root e-mails from [email protected] (might be send from firewall) still get a timeout. Or you could run into other odd issues in the future, maybe not, but one never knows.

So I would suggest to remove that domain name under the account you created it in, and then create this record as suggested.

In DNS adminstration, you will have 4 fields to fill in yourself, nothing more.
1.) domain name = da.domain.com
2.) ip address = your server ip
3.) nameserver 1, for example ns1.domain.com or ns1.da.domain.com depending on what you use
4.) namserver 2. Similar.
And that's it.

After that, check the existance of /etc/virtual/da.domain.com and if not create it like shown in the manual I linked to.

After that you can also create dkim for your domain name and ssl record too as shown in the manual too.

Only thing you need is to put your address in the /etc/aliases file like:
root: [email protected]
and restart exim and it works and then also [email protected] send by for example firewall will be send and not delayed.

As for the PTR record, that is an easy fix. Go to the panel of your vps/server provider and change the PTR/rDNS ip to your hostname and ready. If you also use ipv6 then do the same for ipv6.

Ofcourse, it's a suggestion, feel free to do what you think is best.

 

[webbasica]

Well, I can't remember how or when did I create the user "admin". But I'm pretty sure I never combined it with the user that owns domain.com.

I understand what you mean by creating the DNS record using the "DNS Administration" page as the admin user. However, I'm not sure how should I "remove that domain name under the account you created it in". Should I delete the whole zone or go in edit and remove all the records?

For reference, these are the records in that zone:

A records for:
da.domain.com.
ftp
mail
pop
smtp
www

Nameservers:
ns1.domain.com.
ns2.domain.com.

MX:
mail.da.domain.com.

TXT:
"v=spf1 a mx ip4:xxx.xxx.xx.xxx ~all"

Also, this domain is actually managed by Cloudflare DNS. So, do I enter the Cloudflare nameservers or use the default nameservers (ns1.domain.com and ns2.domain.com)? Is there something else I should do in Cloudflare afterwards?

 

[Richard G]

But I'm pretty sure I never combined it with the user that owns domain.com.

Doesn't need to be the user that owns domain.com, but if you have content in that directory like passwed and alias file then it's done via some user account and not via DNS administration. Because then you would not have alias and other files in that directory.

Should I delete the whole zone or go in edit and remove all the records?

First I would look under which account it's present at the moment. Then remove it from there, everything.
The same DNS zone with those contents will be re-created if you create the hostname again via the DNS adminstration.

Once created, it should look like this in DNS administration:

if you see a NO NO here, then that means you have to create the da.domain.com directory manually like stated in the manual.

When afterwards you open da.domain.com in DNS administration again, then you will see it will have the same records as shown in your reference above.

As for nameservers, just use the ones which are used on the DA server, because the DA server needs to know what to do locally. So ns1.domain.com and ns2.domain.com are fine.

However, you can not create a seperate DNS record for the server in Cloudflare like you can do in Directadmin.
So for da.domain.com you have to copy the SPF record for the "subdomain" da in DNS for domain.com. Unless it's the same record, then it doesn't need.

If you plan to use DKIM for domain.com then it would be wise to either copy your dkim record for domain.com to your /etc/virtual/da.domain.com directory too or create a DKIM for your hostname da.domain.com and then add x._da.domain.com. next to x._domain.com. in Cloudflare's DNS.
Might be easier to copy your domain.com dkim.private.key and public.key to your hostname in DA itself, less work.