Lets say, we are using subdomain srv1.XXX.ru for the mail:
The DKIM record for srv1.XXX.ru should be mail._domainkey.srv1, but it is mail._domainkey in HestiaCP:
Please create an issue on Github…
I don’t think that is an error, if you use subdomain.domain.tld Hestia should assume (as it does currently) that your zone is subdomain.domain.tld instead of domain.tld In my opinion that should not change.
1 Like
If you create mail for a subdomain and a domain at the same time, you get two DKIM records with the same ID mail._domainkey
Are you talking about records added into DNS system included in Hestia?
Yes, it is DNS records in Hestia.
Google recomendations for DKIM for subdomains: Add a DKIM key for a subdomain - Google Workspace Admin Help
Github bug is here: [Bug] Incorrect DNS for DKIM if using subdomain · Issue #4113 · hestiacp/hestiacp (github.com)
But you are assuming that subdomain.domain.tld is not an independent zone and it is part of domain.tld and it is not (or at least couldn’t be).
So, in your screenshot, mail._domainkey will be translated to mail._domainkey.subdomain.domain.tld but if you add mail._domainkey.subdomain it will translate to mail._domainkey.subdomain.subdomain.domain.tld which is wrong.
1 Like
In my case subdomain.domain.tld and domain.tld are two independent zones and belongs to different hestia users. All other DNS records created in right way with using subdomain, but not DKIM record.
It depends if you add it to the sub.domain.com zone of domain.com zone
Assuming the the first it should be correct…
1 Like
Guys, maybe I’m wrong and Hestia is creating the records correctly, but I see in the screenshot above that the DKM for subdomains doesn’t match the recommendations. Or the record is not created at all for subdomain.
Here’s another link: domain name system - Setting up SPF and DKIM records of a subdomain - Server Fault
There are all talking to add them to the domain.com zone in that case it is correct you should use:
mail._domainkey.subdomain
But when you add tot he
subdomain.domain.com zone it should be:
mail._domainkey
Assuming we don’t know how a user is going to use the DNS how the hell are we supposed to know what we should display…
2 Likes
I think that if subdomain.domain.tld is created as a mail domain in Hestia, the DKIM DNS should be mail._domainkey.subdomain anyway
It depends if you use subdomain.domain.com or domain.com as zone…
I think it is hard to know the difference for us… What a user is going to use …
1 Like
If, for example, we create two mail domains in the Hestia interface:
domain.tld
subdomain.domain.tld
And switch off DKIM support on domain.tld and switch on DKIM support on subdomain.domain.tld?
Then, with only one DNS record mail._domainkey, mail will probably stop coming.
Did you have created a DNS zone for subdomain.domain.tld
I just wanted to use my own server with the Hestia panel as an ns server and thought Hestia creates the correct DNS records automatically.
If I create records on a 3rd party DNS provider manually, then of course I create DNS zones for each domain/subdomain.
I didn’t create anything manually on the server, just used the panel to create a web server and a mail server independent for the domain and subdomain.
By now we create all DNS records with the domain name registrar, but we have been tasked to use our own NS servers with Hestia.
This is where I saw that visually the DKIM records in Hestia are not created correctly.
Then again, maybe it’s all visual and the records themselves are correct. Sorry for that.
Then setup the name servers first…
DNS records under the mail tab are only for info… Not used for DNS …
1 Like