群晖自建邮件服务器要配哪些 DNS 记录？六种记录一次讲透
痛点场景
公司在群晖 NAS 上装好了 Synology MailPlus Server（或 Synology Mail Server），发出去的邮件却石沉大海、或者动辄进对方的垃圾邮件区域；别人发来的信收不到；日志里一堆验证失败。十有八九，问题不在服务器本身，而在域名的 DNS 记录没配齐。
各种类型的 DNS 记录对邮件服务器至关重要。官方知识库把这套配置讲得很系统：A 记录和 MX 记录决定邮件能不能顺畅往来，SPF、DKIM、DMARC、TLSA 四种验证记录帮你守住邮件服务器的声誉、防住垃圾邮件与身份盗用。前提条件只有一个：已在 NAS 上安装并设置好邮件服务器套件。
全景：六种记录各管什么
| 记录 | 作用 |
|---|---|
| A | 把域或子域映射到 IP 地址——别人要能"找到"你的服务器 |
| MX | 声明哪些邮件服务器代表本域收信、投递顺序如何 |
| SPF | 指定哪些服务器有权代表本域发信，防发件人伪造 |
| DKIM | 给每封外发邮件加数字签名，证明邮件确由域所有者授权发出 |
| DMARC | 决定未通过 SPF/DKIM 检查的邮件如何处置，并提供流量报告 |
| TLSA | 把 TLS 服务器证书与域名绑定，供对端做 DANE 校验 |
从 DNS 服务商处获得邮件服务器的域名后，即可通过域的 DNS 服务器设置所有这些记录。
A 记录与 MX 记录：先打通收发
A 记录（地址记录）把域或子域映射到其 IP 地址，让用户键入可读的域名、计算机处理背后的 IP。配置要点只有一句：将 A 记录指向群晖 NAS 的 IP 地址。
MX 记录（邮件交换器记录）说明哪些邮件服务器代表域接受电子邮件、发往本域的邮件应按 SMTP 路由到哪。每条 MX 记录包含主机名和优先级：主机名表示邮件应投递的位置，优先级数字表示服务器使用的顺序——数字越低，优先级越高。要让 alex@example.net 这样的地址有效，就必须为域 example.net 设置 MX 记录，并把主机名指向上面那条 A 记录覆盖的服务器。
SPF 记录：声明谁有权发信
SPF（发件人策略框架）通过指定允许代表域发送邮件的服务器来防止邮件欺骗。它是一条 TXT 记录，基本结构三个标签：
| 标签 | 值 | 示例 |
|---|---|---|
| v | SPF 版本，现用 spf1 | v=spf1 |
| ip4 | 授权邮件服务器的 IP（标准 IPv4 地址或范围） | ip4:邮件服务器 IP |
| all | 接收端如何处置未授权发件人 | -all 或 ~all |
all 的两档口径：
- -all：拒绝并放弃——未授权来源的邮件直接拒收，官方推荐的选项，能更好地确保邮件来自授权发件人；
- ~all：允许但标记为可疑——温和模式，适合过渡期观察。
以域 example.net、服务器 IP 93.184.216.34 为例，完整的 SPF 记录就是：
- 名称：example.net
- 值：
v=spf1 ip4:93.184.216.34 -all
DKIM 记录：先在服务器上生成公钥
DKIM（DomainKeys Identified Mail）通过在每封外发邮件上附加数字签名，提供一种验证邮件是否确实由域所有者授权的方法。配置前，先到邮件服务器上生成公共密钥，生成位置按套件区分：
- MailPlus Server：域 > 编辑 > 常规 > 高级；
- Mail Server：安全性 > 验证。
拿到公钥后，按以下格式添加 TXT 记录：
| 项目 | 格式 | 示例 |
|---|---|---|
| 名称 | DKIM 选择器前缀._domainkey.你的域名 | abc._domainkey.example.net |
| 值 | v=DKIM1; k=rsa; p=DKIM 公钥 | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE |
DMARC 记录：定处置策略、收流量报告
DMARC（基于域的邮件验证、报告与一致性）决定未通过 SPF 和 DKIM 检查的邮件如何处理；它的报告功能还能让域所有者洞察邮件流量，更好地检测欺骗攻击。TXT 记录包含这些标签：
| 标签 | 值 | 示例 |
|---|---|---|
| v | DMARC 版本，现用 DMARC1 | v=DMARC1 |
| p | 对未验证邮件的策略：none 仅监控 / quarantine 送隔离区 / reject 拒绝封锁 | p=none |
| pct | 策略强制实施的邮件百分比 | pct=100 |
| rua | 接收报告的邮件地址 | rua=mailto:报告地址 |
以域 example.net、报告地址 postmaster@example.net 为例：
- 名称：_dmarc.example.net
- 值：
v=DMARC1; p=none; pct=100; rua=mailto:postmaster@example.net
策略节奏官方给了明确建议：p=none 是分析邮件流的良好起点，但它宽松、不封锁可疑邮件；启用 SPF、DKIM 和 DMARC 一段时间后，更改为 p=quarantine，才能更好地防范域欺骗。
TLSA 记录：给 DANE 校验的对端准备
TLSA（传输层安全验证）记录将 TLS 服务器证书与记录所在的域名相关联。当另一台邮件服务器向 MailPlus Server 投递邮件时若使用 DANE，它会验证 MailPlus Server 的 TLSA 记录——没有这条记录，MailPlus Server 无法通过验证，来自那台服务器的邮件就可能收不到。
生成方式二选一：使用在线生成器，或使用 MailPlus 内置生成器（安全性 > 验证 > DANE）。生成后将 TLSA 记录部署到公共 DNS。
四条官方注意事项
- -all 是推荐选项：SPF 用拒绝模式才能更好地确保邮件来自授权发件人；
- DMARC 循序渐进：从 p=none 起步观察，时机成熟收紧到 p=quarantine；
- 本地 DNS 要同步：使用本地 DNS 服务器（如 Synology Directory Server）时，确保更新本地 DNS 视图中的条目，防止因本地解析数据缺失导致 SPF、DKIM 和 DMARC 出问题——内网客户端按本地视图解析，视图里没有新记录，验证链就会在内网断掉；
- 界面以供应商为准：本文示例仅作演示，实际操作界面取决于各 DNS 供应商，配置遇到问题联系域提供商获取协助。
验证
六种记录部署完，用官方配套的"检查邮件服务器 DNS 记录是否配置正确"这类工具做一轮核对（知识中心有专门文章），再从外部邮件服务发测试信进出各验一次。都通了之后把 rua 报告地址里的统计看上一两周——DMARC 报告会告诉你有没有人在冒充你的域名。
预防与注意
- 迁移服务器 IP 或更换邮件域名时，A/MX/SPF 三条记录要一起改，漏改 SPF 里的 ip4 是"换机后发信进垃圾区域"的高发原因；
- DKIM 公钥重新生成后记得同步更新 DNS 侧的 TXT 值，新旧值交接期内两条并存也可以；
- 把 rua 报告的定期查看写进运维日历，DMARC 数据既是安全仪表也是声誉仪表；
- 诚鑫致达科技给企业上线自建邮件系统时，这六条记录会做成一张核对表随交付文档移交——DNS 配置散在域名商后台，没有一张表盯着，半年后连接班的人都说不清哪条记录是谁加的。