无论邮箱系统用的什么软件，都绕不开邮件相关的域名解析，只要搞邮件就需配置以下域名解析：

MX 记录 ：域名系统基础记录，指向邮件服务器
SPF 记录 ：指定哪些服务器可以使用你的域名发送邮件
DKIM 记录 ：防止发送的电子邮件内容篡改
DMARC 记录 ：当 SPF 和 DKIM 验证失败时，指定接收方的处理策略并向指定邮箱报告

PTR 记录 ：即 IP 反解析，根据 IP 反查域名，需供应商来做

MX 记录
收发邮件时，MX 记录指定了自己的邮件服务器地址，可以设置优先级，一般建议 2 条以上 mx 记录（
域名 类型 值 优先级
example.com mx mx1.example.com 10
设置对应 MX 子域名的记录：
mx1.example.com A 10.2.3.4
设置好后使用 dig 命令验证一下：
dig mx example.com
PTR 记录
将域名映射到 IP 地址是正向解析，从 IP 地址到域名的映射就是反向解析，在公网上，反向解析无法由 DNS 提供，因为 IP 地址的管理权限属于运营商，所以需要向运营商申请添加反向解析，运营商通过 PTR（Pointer Record）记录将 IP 地址指向域名。邮件服务器 IP 不做 PTR 记录，发送邮件后会有很大概率被当成垃圾邮件。

联系供应商加好后，可以用 dig 命令验证：

dig -x mx1.example.com
SPF 记录
SPF 全名是 发件人策略框架，主要作用是将发信的邮件服务器和发信域名进行绑定，防止伪造发件人。在 SPF 记录中使用 TXT 记录指定允许发信的服务器，当对方收到邮件后，系统会验证发信域名并读取 SPF 记录中的 IP，验证是否一致后采取进一步动作。

以谷歌 SPF 记录为例：

dig txt gmail.com

gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"

dig txt _spf.google.com

_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

dig txt _netblocks.google.com

_netblocks.google.com. 300 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
SPF 记录以 v=spf1 开头，以 all 结尾，中间可以使用 ip4/ip6/a/mx/include/redirect 等关键字进行 ip 范围指定。SPF 记录的匹配机制会结合 限定词 来告诉服务器匹配记录时的动作。常见的限定词有：

• 放行，如果没有明确指定限定词，则为默认值。
• 硬拒绝，直接拒绝来自未经授权主机的邮件。
  ~ 软拒绝，邮件可被接受，也可被标记为垃圾邮件。
  ? 中性，不考虑邮件是否被接受。
  个人邮件设置允许 mx 记录中的服务器发信即可，最终设置 SPF 记录为：
  example.com txt "v=spf1 mx -all"
  DKIM 记录
  DKIM 记录主要作用也是防止邮件被恶意篡改，保证邮件内容的完整性，使用的方式是与 SSL 类似，服务器产生一个公私钥对，私钥为每一封外发的邮件签名并在邮件头中插入 DKIM 签名（DKIM-Signature 头），公钥则保存在域名的记录中，邮件接收方接收邮件时，通过 DNS 查询获得公钥，并使用公钥解密邮件签名， 从而验证邮件有效性和完整性。
  default._domainkey.example.com txt "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0......"
  DMARC 记录
  DMARC 基于现有的 SPF 和 DKIM 协议，并声明对验证失败邮件的处理策略。邮件接收方接收邮件时，首先通过 DNS 获取 DMARC 记录，再对邮件来源进行 SPF 验证和 DKIM 验证，对验证失败的邮件根据 DMARC 记录进行处理，并将处理结果反馈给发送方。
  _dmarc.nixops.me txt "v=DMARC1; p=quarantine; ruf=mailto:[email protected]v"
  p：reject 拒绝该邮件；none 为不作处理；quarantine 标记为垃圾邮件。
  ruf：检测到伪造邮件，接收方报告的邮箱地址
  MTA-STS 和 TLS 报告
  MTA-STS 是 MTA 严格传输安全协议，作用是确保发送给我们的电子邮件通过 TLS 安全地传输，防止中间人攻击。启用 MTA-STS 后，发送方邮件服务器只有在满足以下条件时，才会向我们发送邮件：

使用有效的证书通过身份验证
使用 TLS 1.2 或更高版本进行加密
当然如果发送方不支持 MTA-STS，仍然可以发送邮件（可能会有中间人攻击）,主要是为了兼容。

启用 MTA-STS 所需条件：

创建策略文件，并提供 HTTPS 方式访问
通过 DNS 设置 txt 记录，告诉其它邮件服务商支持 MTA-STS

策略文件 mta-sts.txt 的内容为：

version: STSv1
mode: enforce
mx: mx1.nixops.me
mx: mx2.nixops.me
max_age: 86400
创建子域名并启用 https,最终的访问路径为：
https://mta-sts.nixops.me/.well-known/mta-sts.txt
配置 MTA-STS 的 TXT 记录：
_mta-sts.nixops.me TXT "v=STSv1; id=20211031T010101;"
一般 id 为时间戳。

DNSSEC, DNAME, CAA
启用了 MTA-STS 后，DANE 可以确保 TLS 证书是有效的，实际上是通过 DNS 的方式扮演了 CA 的角色。 DANE 通过 TLSA 记录，来声明某个证书的是可信的，由于 DANE 是基于 DNS 协议，可能会有被挟持的可能，因此需要启用 DNSSEC 来保障传输过程中不被修改。
启用 DNSSEC 需域名注册商及 dns 服务商都支持，在 DNS 服务商处选择开启 DNSSEC，然后将提供的 DS 记录填写到域名注册商即可
使用 TLSA 证书生成工具 及 PEM 格式的 TLS 证书生成 TLSA 记录
使用CAA Record Helper生成的 CAA 记录
为了保障 TLS 证书安全：

DNSSEC 保障 DNS 记录传输过程中的安全
DANE 在客户端侧阻止不当签发的证书
CAA 指定域名允许哪个证书颁发机构为其颁发证书