aaPanel
Domain Name Processing Problem
Type: Bug Fix + Feature Enhancement Version: 1.5 Affected Scope: Third-level domain handling, DNS record verification logic, TXT record customization Core Problem Description:
1.DKIM Record Truncation Error
Symptom: After adding domain mail.example.com, the generated DKIM record shows d=example.com (incorrectly truncated to second-level domain).
Consequence: DKIM validation fails.
2.DNS Record Display Anomalies
Problem A: DNS resolves correctly, but system displays "Not Set".
Problem B: After clicking "Verify DNS Settings", all record values erroneously duplicate subdomains:
- Original Records (Content A)
+ After clicking the Verify button Records (Content B)
Content A:
```
记录类型 主机记录 记录值
A mail.example.com 1.1.1.1
记录类型 主机记录 记录值 MX优先级
MX @ mail.example.com 10
记录类型 主机记录 记录值
TXT @ v=spf1 +a +mx +ip4:1.1.1.1 -all复制
TXT default._domainkey v=DKIM1;k=rsa;p=MIGfMA0GCS.... 复制
TXT _dmarc v=DMARC1;p=quarantine;rua=mailto:[email protected] 复制
```
Content B:
```
记录类型 主机记录 记录值
A mail.mail.example.com 1.1.1.1
步骤2：添加MX记录
记录类型 主机记录 记录值 MX优先级
MX @ mail.mail.example.com 10
步骤3：添加TXT记录
记录类型 主机记录 记录值
TXT @ v=spf1 +a +mx +ip4:1.1.1.1 -all复制
TXT default._domainkey v=DKIM1;k=rsa;p=MIGfMA0GCS.... 复制
TXT _dmarc v=DMARC1;p=quarantine;rua=mailto:[email protected] 复制
```
Impact: MX/SPF/DKIM/DMARC validation completely fails due to invalid host records.
3.Lack of TXT Record Customization
Current SPF/DMARC records use rigid templates.
Cannot flexibly adjust fields (e.g., SPF mechanisms, DMARC policies).
No, we do not recommend using mail.example.com for your domains because it conflicts with the MX hostname (we default to 'mail.your_domain_name' as the MX record).
Uh, I noticed that there are many places in the code that are hard-coded. This is not realistic, right? If you must hard-code, wouldn't it be better to use the prefix "mx" as the mx record in the code and leave "mail" to the web? Most cloud vendors seem to use "mx+sequence number" as the mx record.
I changed the domain name to a third-level domain name that does not start with "mail", but the "d=" in the DKIM signature will still be truncated to the second-level domain name.
I too have come across the issue with the third-level domain not being set in the DKIM-Signature correctly. Is there any planned fix for this specific issue which truncates third-level domains to second-level domain?
i found a work around based on what is being said here: https://lists.rspamd.com/pipermail/users/2023-April/002696.html
editing the conf/rspamd/local.d/dkim_signing.conf, add the option use_esld = false;
https://docs.rspamd.com/modules/dkim_signing/