Hello,
I have the following issue: after every update of Hestia, the A record for mail disappears from the DNS configuration. On some domains, it has been duplicated 10 times.
I checked the template files, and everything seems fine there.
Has anyone experienced a similar issue, and how could it be resolved?
Hi sorry to revive an old thread, but I am having the exact same issue and I see a solution was never proposed.
After every Hestia update the āAā record for mail.domain.xyz gets deleted for every one of my DNS domains. I think it might be occurring as part of the ārebuild mail domainā operation?
Possibly relevant:
In my Hestia configuration, under āMail Serverā, I have āWebmail Aliasā set to āmailā rather than the default āwebmailā.
When I am looking at the Mail Domains screen and click the āDNS Recordsā icon next to any of the domains, it shows the mail.domain.xyz A records twice.
Probably less relevant:
I am running on Ubuntu 22.04, with Hestia installed using the official installer on top of a default OS install.
I am running a bind9 cluster with 2 other hosts; the mail host is the DNS master
I appreciate any ideas on where to look (DNS templates maybe?). I host 8 mail domains that users rely on and have downtime after every update until I manually re-add the A records.
Thank you!
nagr
July 22, 2025, 8:27am
3
I am having the exact same issue that justadri is describing, with the same observations.
Serve this message as a bump, maybe we can get some attention on the issue.
May be related to Hestia updates change custom DNS records
nagr
July 24, 2025, 10:50am
4
Iāve taken a look at the code and I think that Iāve identified the problem.
A pull request has been submitted to the repository for the maintainers to look at.
main ā nicoagr:main
abierto 10:48AM - 24 Jul 25 UTC
### **Problem**
- In a numerous range of installations we can observe that th⦠e webmail alias for accessing the mail interface is set to "mail"
- As part of the update process for hestia, a rebuild of the dns domains is toggled. This triggers the _v-delete-web-domain-webmail_ and the _v-add-web-domain-webmail_ scripts to be executed one after the other.
- The current code in _v-delete-web-domain-webmail_ fails to correctly detect the "mail" alias for the webmail panel, and ends up deleting the DNS A record pointing to mail.domain.com. Afterwards, the _v-add-web-domain-webmail_ also fails to detect (all) aliases and ends up NOT adding back the A record.
Summed up, these two scripts are supposed to simply add (and remove) an alias for accessing the webmail, but end up deleting the main entry point for outgoing and incoming mail for the domain (mail.example.com) after each hestia update in installations with "mail" set as an alias for the webmail.
This issue is mentioned in forum topics [17837](https://forum.hestiacp.com/t/disappearing-mail-record-from-dns-configuration-after-hestia-update/17837) and [18547](https://forum.hestiacp.com/t/hestia-updates-change-custom-dns-records/18547)
### ***Solution***
- First, I've fixed up the matching logic to correctly detect the correct webmail alias record (and not all the records containing "mail", for example)
- Then I've wrapped things up with some extra logic to handle both cases, either when the webmail alias is "mail" and when it is not.
This is the most sense I've made out of the code, given the intended scope for the files and checking out [past](https://github.com/hestiacp/hestiacp/commit/e81a4756d27700507d37db13b7259717e56da382) commits for the file.
Anyways, just a disclaimer, this is my first pull request to the hestia repository, so if I'm missing the point on some statements or I got some assumptions wrong feel free to correct me out. Regardless, a fix for this problem should be implemented because of how inconvenient it is every time hestia updates.
Anuril
August 6, 2025, 4:25pm
5
This issue merits further investigation. Can check what domain template you have selected in the dns domain, and provide the template ?
You can find it here: /usr/local/hestia/install/common/templates/dns
nagr
August 20, 2025, 10:52am
6
I have replied to the comments in the github pull request and provided more explanations.
Regarding the DNS template, the issue is materializing for me using ādefault.tplā
ID='1' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns1%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='2' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns2%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='3' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns3%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='4' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns4%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='5' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns5%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='6' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns6%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='7' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns7%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='8' RECORD='@' TYPE='NS' PRIORITY='' VALUE='%ns8%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='9' RECORD='@' TYPE='A' PRIORITY='' VALUE='%ip%' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='10' RECORD='www' TYPE='CNAME' PRIORITY='' VALUE='%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='11' RECORD='ftp' TYPE='CNAME' PRIORITY='' VALUE='%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='12' RECORD='mail' TYPE='A' PRIORITY='' VALUE='%ip%' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='13' RECORD='webmail' TYPE='CNAME' PRIORITY='' VALUE='mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='14' RECORD='@' TYPE='MX' PRIORITY='0' VALUE='mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='15' RECORD='@' TYPE='TXT' PRIORITY='' VALUE='"v=spf1 a mx ip4:%ip% -all"' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='16' RECORD='_dmarc' TYPE='TXT' PRIORITY='' VALUE='"v=DMARC1; p=quarantine; pct=100"' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='17' RECORD='_submission._tcp' TYPE='SRV' PRIORITY='1' VALUE='0 587 mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='18' RECORD='_imap._tcp' TYPE='SRV' PRIORITY='1' VALUE='0 143 mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='19' RECORD='_imaps._tcp' TYPE='SRV' PRIORITY='1' VALUE='0 993 mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='20' RECORD='_pop3._tcp' TYPE='SRV' PRIORITY='1' VALUE='0 110 mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
ID='21' RECORD='_pop3s._tcp' TYPE='SRV' PRIORITY='1' VALUE='0 995 mail.%domain%.' SUSPENDED='no' TIME='%time%' DATE='%date%'
nagr
February 8, 2026, 1:36am
7
Hello! If any further clarifications are needed from the maintainers, please ping me on the github PR. Letās get this going so we can fix this bug for the next release!
main ā nicoagr:main
abierto 10:48AM - 24 Jul 25 UTC
### **Problem**
- In a numerous range of installations we can observe that th⦠e webmail alias for accessing the mail interface is set to "mail"
- As part of the update process for hestia, a rebuild of the dns domains is toggled. This triggers the _v-delete-web-domain-webmail_ and the _v-add-web-domain-webmail_ scripts to be executed one after the other.
- The current code in _v-delete-web-domain-webmail_ fails to correctly detect the "mail" alias for the webmail panel, and ends up deleting the DNS A record pointing to mail.domain.com. Afterwards, the _v-add-web-domain-webmail_ also fails to detect (all) aliases and ends up NOT adding back the A record.
Summed up, these two scripts are supposed to simply add (and remove) an alias for accessing the webmail, but end up deleting the main entry point for outgoing and incoming mail for the domain (mail.example.com) after each hestia update in installations with "mail" set as an alias for the webmail.
This issue is mentioned in forum topics [17837](https://forum.hestiacp.com/t/disappearing-mail-record-from-dns-configuration-after-hestia-update/17837) and [18547](https://forum.hestiacp.com/t/hestia-updates-change-custom-dns-records/18547)
### **Solution**
- First, I've fixed up the matching logic to correctly detect the correct webmail alias record (and not all the records containing "mail", for example)
- Then I've wrapped things up with some extra logic to handle both cases, either when the webmail alias is "mail" and when it is not.
This is the most sense I've made out of the code, given the intended scope for the files and checking out [past](https://github.com/hestiacp/hestiacp/commit/e81a4756d27700507d37db13b7259717e56da382) commits for the file.
Anyways, just a disclaimer, this is my first pull request to the hestia repository, so if I'm missing the point on some statements or I got some assumptions wrong feel free to correct me out. Regardless, a fix for this problem should be implemented because of how inconvenient it is every time hestia updates.
nagr
April 3, 2026, 4:20pm
8
Iāve catched up a bit on the repositoriesā (and more specifically, the maintainersā available dedication) news. Considering all the aspects that hestia covers and what the priorities have been focused on for the next release, I shall request some attention to this issue.
When the new update rolls out, some installations may be impacted by this bug and the DNS records for the mail.domain.tld will disappear on domains affected by the described configuration. Thus, given the severity of the bug, I strongly recommend selecting this issue to be fixed before the next release.
@sahsanu @Lupu @eris
In case you need any additional help or clarifications, Iām here to shed some more light on my PR ās code and why Iāve made the changes that I submit.
@nagr Sorry, Iām not a dev and I canāt merge PRs.
nagr
May 29, 2026, 7:37am
10
Hello,
Just as expected, the new update rolled out and it removed the DNS A records for mail.domain.xyz for all domains that matched the conditions. This has a major outage for us providers, so please reconsider including this year-old PR in the next release.
main ā nicoagr:main
abierto 10:48AM - 24 Jul 25 UTC
### **Problem**
- In a numerous range of installations we can observe that th⦠e webmail alias for accessing the mail interface is set to "mail"
- As part of the update process for hestia, a rebuild of the dns domains is toggled. This triggers the _v-delete-web-domain-webmail_ and the _v-add-web-domain-webmail_ scripts to be executed one after the other.
- The current code in _v-delete-web-domain-webmail_ fails to correctly detect the "mail" alias for the webmail panel, and ends up deleting the DNS A record pointing to mail.domain.com. Afterwards, the _v-add-web-domain-webmail_ also fails to detect (all) aliases and ends up NOT adding back the A record.
Summed up, these two scripts are supposed to simply add (and remove) an alias for accessing the webmail, but end up deleting the main entry point for outgoing and incoming mail for the domain (mail.example.com) after each hestia update in installations with "mail" set as an alias for the webmail.
This issue is mentioned in forum topics [17837](https://forum.hestiacp.com/t/disappearing-mail-record-from-dns-configuration-after-hestia-update/17837) and [18547](https://forum.hestiacp.com/t/hestia-updates-change-custom-dns-records/18547)
### **Solution**
- First, I've fixed up the matching logic to correctly detect the correct webmail alias record (and not all the records containing "mail", for example)
- Then I've wrapped things up with some extra logic to handle both cases, either when the webmail alias is "mail" and when it is not.
This is the most sense I've made out of the code, given the intended scope for the files and checking out [past](https://github.com/hestiacp/hestiacp/commit/e81a4756d27700507d37db13b7259717e56da382) commits for the file.
Anyways, just a disclaimer, this is my first pull request to the hestia repository, so if I'm missing the point on some statements or I got some assumptions wrong feel free to correct me out. Regardless, a fix for this problem should be implemented because of how inconvenient it is every time hestia updates.
I know the maintainers time is limited, but this bug breaks the email service (because of the missing A record for mail) after each update.
@sahsanu @Raphael @eris
I donāt approve/merge PRs
nagr
May 29, 2026, 7:52am
12
So, please, can you contact any of the maintainers to shed some attention on this issue?
We are already on it, 1.9.6 will follow today.