Mailu DNS 配置实战指南：从 A/MX 记录到 DKIM、SPF 与 DMARC 的完整落地-育师

后端
通信

【免费下载链接】Mailu

Insular email distribution - mail server as Docker images

项目地址：https://gitcode.com/gh_mirrors/ma/Mailu

本篇技术指南以 Mailu 官方文档 docs/dns.rst 为主体，系统讲解自建 Mailu 邮件服务器上线前必须完成的 DNS 配置：邮件服务器主机名（A 记录）、MX 记录、反向 DNS（PTR）以及 DKIM/SPF/DMARC 记录，并深入源码说明每条记录的精确格式与后台生成机制。读完本文，你将能独立完成 Mailu 域名 DNS 的全套配置，并通过管理后台或 CLI 正确导出与核验所有邮件认证记录，确保邮件可正常收发而不被对方判为垃圾邮件。

为什么邮件投递离不开 DNS

电子邮件采用去中心化架构：互联网上几乎每个邮件服务商都能与其他服务商互通投递邮件，类似于不同城市、不同国家的邮局之间互递普通信件。但邮件模型在"发现"与"责任归属"上依赖一套显式机制：绝大多数情况下，一封邮件的投递最多涉及两到三个角色——发件方（emitter）、可选的中继（relay）和收件服务器（recipient server）。更复杂的架构要么可以简化为上述模型，要么极为罕见。

抛开中继不谈，发件方要找到收件服务器在互联网上的位置，靠的就是DNS：先通过目标域的MX记录找到负责收件的服务器主机名，再通过该主机名的A记录解析出 IP 地址。

因此，配置 DNS 域是 Mailu 在互联网上收发邮件的（几乎）前提条件。在开始使用 Mailu 之前，你必须至少配置一个可接收邮件的域名。这一步与 docs/setup.rst 中"准备环境"一节的要求相互印证：该文档明确要求"至少拥有一个 DNS 主机名和一个用于接收邮件的 DNS 名称"。

邮件服务器主机名：HOSTNAME、A 记录与 BIND_INTERFACE

你的邮件服务器需要一个唯一的主机名（hostname）。它是一个完全限定域名（FQDN），指向你服务器的 IP 地址。主机名的选取完全由你决定，但它必须属于你拥有或管理的域名，并且可以属于该服务器负责收信的域名之一。

建议选择一个有实际意义的主机名，方便你把 Web 界面等邮件服务地址告知用户。例如，如果你的主邮件域是mydomain.com（即配置文件中DOMAIN的值），那么可以用mail.mydomain.com作为邮件服务器主机名。

配置项：HOSTNAME 与 DOMAIN

在 Mailu 配置中：

DOMAIN：主邮件域，用于退信（bounce）邮件、生成 postmaster 地址及其他技术性地址（见 docs/configuration.rst）。其默认值在源码 core/admin/mailu/configuration.py 中为mailu.io。
HOSTNAMES：服务器所有公开主机名的逗号分隔列表，第一个主机名即主主机名（HOSTNAME），用于对外暴露 SMTP、IMAP 等端口。默认值为mail.mailu.io,alternative.mailu.io,yetanother.mailu.io（见 core/admin/mailu/configuration.py）。配置加载时，ConfigManager会把HOSTNAMES按逗号拆分、去除空白后重组，并取第一个作为HOSTNAME（见 core/admin/mailu/configuration.py）。

将选定的主机名写入HOSTNAME配置后，根据你的域名服务商，确保存在一条指向服务器公网 IP 的A记录：

mail.mydomain.com. IN A a.b.c.d

同时，a.b.c.d也应写入BIND_INTERFACE配置，除非你的服务器位于 DMZ 中、通过端口转发对外暴露服务。

最后，务必为邮件服务器主机名准备一份有效的TLS 证书，并按 docs/setup.rst 中的说明安装。Mailu 通过TLS_FLAVOR配置决定证书的获取方式（默认cert），更详细的说明见 docs/configuration.rst 与配置默认值 core/admin/mailu/configuration.py。

补充：HOSTNAMES是逗号分隔的多主机名列表，HOSTNAME自动取第一个。这意味着 Mailu 支持一台服务器绑定多个公开主机名，但对外提供邮件协议的主机名始终是第一个。

MX 记录：其他服务器发现你的收件入口

当服务器运行起来、并且可以通过邮件服务器主机名访问之后，你就可以在 Mailu 的 Web 管理界面中直接添加新域名。

对于 Mailu 负责收信的每个域名，都必须在其 DNS 配置中建立对应的MX记录。该记录用于让其他邮件服务器发现负责收件的主机名，再借助前面配置的A记录解析出 IP。以mydomain.com为例，在 zone 文件中添加：

mydomain.com. IN MX 10 mail.mydomain.com.

数字10是MX 优先级（preference）。运行单台邮件服务器时优先级几乎无关紧要；但如果你另外运行一台独立的备份服务器（backup MX），就需要调整优先级来区分主次。另一个域名myotherdomain.com也指向同一台服务器：

myotherdomain.com. IN MX 10 mail.mydomain.com.

注意：多个域名都指向同一个邮件服务器主机名——该主机名对你的服务器而言是唯一的。

后台校验：check_mx 与界面图标

Mailu 管理后台并不会盲目信任你填写的记录，而是会实时校验 MX 是否正确指向 Mailu 主机。在 core/admin/mailu/models.py 中，Domain.check_mx()通过dns.resolver.resolve(self.name, 'MX')解析域名的 MX 记录，并将每条 MX 的 exchange 主机名（去掉末尾点）与配置的HOSTNAMES集合比对，只要有一条匹配即视为通过；解析失败则返回False。

这一校验体现在两个地方：

域名详情页：在 core/admin/mailu/ui/templates/domain/details.html 中，MX 条目旁会显示绿色对勾（fa-check-circle）或红色感叹号（fa-exclamation-circle），取决于domain.check_mx()的结果；
域名自助注册：在 core/admin/mailu/ui/views/domains.py 中，若开启域名注册（DOMAIN_REGISTRATION），提交新域名时会调用domain.check_mx()，不通过则提示 "The MX record was not properly set" 并拒绝创建。

也就是说，MX 记录是否正确直接影响 Mailu 能否接受该域名的邮件，而这一判断在后台是自动完成的。

反向 DNS（PTR 记录）

邮件系统强烈建议同时配置反向 DNS：如果主机名mail.mydomain.com解析到a.b.c.d，那么 IPa.b.c.d也应能反向解析回同一个主机名。验证方式：

nslookup a.b.c.d

反向 DNS 必须由IP 地址的"所有者"配置，通常是你的托管服务商；大多数情况下可用下面的命令查询归属：

whois a.b.c.d

反向 DNS 配置不正确时，大多数邮件系统会把你的邮件直接判定为垃圾邮件，因此这一步虽然"强烈建议"而非强制，却是邮件可达性的关键一环。

DKIM / SPF / DMARC：最后一块拼图

完成上述 DNS 变更后，你还需要访问Mailu 管理后台（或使用 CLI）重新生成（或首次生成）DMARC、SPF 和 DKIM 记录。

等主机相关的 DNS 变更传播完成（并确认 SSL/域名规则配置正确）后，访问管理后台的域名详情页：

https://example.com/admin/domain/details/example.com

点击"Regenerate keys"（重新生成密钥）按钮，把页面给出的记录逐条添加到你的 DNS 服务商。如果你已启用 DKIM/SPF/DMARC 却没有添加这些记录，邮件很可能无法正常投递。

详情页展示的完整记录集

域名详情页（core/admin/mailu/ui/templates/domain/details.html）会展示以下记录，每条均提供复制按钮：

DNS MX entry：<domain>. 600 IN MX 10 <hostname>.，并附 MX 校验状态图标；
DNS SPF entries：<domain>. 600 IN TXT "v=spf1 mx a:<hostname> ~all"；
DNS DKIM entry（生成密钥后）：<selector>._domainkey.<domain>. 600 IN TXT "v=DKIM1; k=rsa; p=<公钥>"；
DNS DMARC entry：_dmarc.<domain>. 600 IN TXT "v=DMARC1; p=reject; ... adkim=s; aspf=s"；
DNS TLSA entry：当TLS_FLAVOR为letsencrypt/mail-letsencrypt时展示_25._tcp.<hostname>. 86400 IN TLSA ...记录；
DNS client auto-configuration entries：RFC 6186 风格的_imap._tcp、_pop3._tcp、_submission._tcp、_imaps._tcp、_pop3s._tcpSRV 记录，以及autoconfig.<domain>.、autodiscover.<domain>.的 CNAME 记录。

这些记录的精确生成逻辑全部集中在 core/admin/mailu/models.py 的Domain模型中（dns_mx、dns_spf、dns_dkim、dns_dmarc、dns_dmarc_report、dns_autoconfig、dns_tlsa），其中：

MX 与 SPF 记录的 TTL 固定为600，SPF 采用~all（soft fail）策略；
DKIM 记录的 selector 取自配置项DKIM_SELECTOR（默认dkim，见 core/admin/mailu/configuration.py），公钥由私钥派生；
DMARC 策略为p=reject，强制adkim=s; aspf=s（严格对齐），并可依据DMARC_RUA/DMARC_RUF配置（core/admin/mailu/configuration.py）附带rua=mailto:/ruf=mailto:报告地址；
当域名不是主DOMAIN时，还会额外生成一条_report._dmarc聚合报告接收记录（dns_dmarc_report）。

Regenerate keys 的底层实现

"Regenerate keys" 按钮对应后台路由/domain/genkeys/<domain_name>（见 core/admin/mailu/ui/views/domains.py），该路由受domain_admin权限保护，并需二次确认。它调用Domain.generate_dkim_key()（core/admin/mailu/models.py），底层由 core/admin/mailu/dkim.py 的gen_key()生成2048 位 RSA 密钥（指数 65537），以 PKCS#8 无加密 PEM 格式存储；strip_key()（core/admin/mailu/dkim.py）则提取公钥的 base64 部分用于生成 DKIM TXT 记录。生成的私钥会按DKIM_PATH（默认/dkim/{domain}.{selector}.key）落盘，供 Rspamd 签名使用。生成或更换密钥后，需要在 DNS 服务商处同步更新 DKIM 记录的公钥部分。

注意：重新生成密钥会使 DNS 中的 DKIM 公钥失效，必须同时更新 DNS 记录，否则这段时间发出的邮件 DKIM 校验会失败。

用 CLI 导出 DNS 记录

除了后台页面，Mailu 还提供 CLI 方式导出包含 DNS 记录在内的完整配置。在容器内执行（参见 docs/cli.rst）：

docker compose exec -T admin flask mailu config-export --dns

--dns（即-d）选项会把dkim_publickey、dns_mx、dns_spf、dns_dkim、dns_dmarc等字段包含在导出结果中（见 core/admin/mailu/manage.py 与 core/admin/mailu/schemas.py）。可选参数还包括：

-f, --full：包含默认值属性；
-s, --secrets：包含机密属性（如 dkim-key、密码）；
-o, --output-file FILENAME：保存到文件；
-j, --json：以 JSON 格式导出（默认 YAML）。

此外，后台还提供"Download zonefile"按钮（路由/domain/details/<domain_name>/zonefile，见 core/admin/mailu/ui/views/domains.py），直接把该域及所有 alternative 域名的 MX、SPF、DKIM、DMARC、TLSA、autoconfig 记录汇总为一个可直接导入的 zone 文件文本，适合快速批量落地到 DNS 服务商。