一、为什么需要一个域名邮箱
在拿到 loopnull.com 之后，这个域名一开始主要承担的是“网站入口”的作用：别人可以通过一个稳定、可读、可记忆的地址访问我的博客，而不是直接面对一串服务器 IP。
但随着站点逐渐成型，另一个问题也变得明显：如果网站、域名、服务器都已经属于自己的基础设施体系，联系邮箱却仍然完全依赖普通个人邮箱，那么整个身份体系其实是不完整的。
例如，一个个人网站底部如果写的是：
[email protected]它当然可以正常使用，但它和站点本身没有直接关系。 而如果是：
[email protected]它表达的含义就不同了：这个邮箱属于 loopnull.com 这个域名，也就自然和这个站点、这个个人基础设施体系绑定在一起。
所以，域名邮箱的意义不只是“看起来更正式”，而是把域名从一个单纯的网站地址，扩展成一套可以对外识别的身份系统。
简单来说：
loopnull.com 负责作为网站入口
[email protected] 负责作为对外联系身份这样一来，域名就不只是浏览器地址栏里的字符串，而开始成为一个统一的命名空间。以后无论是网站联系、服务注册、系统通知，还是一些和个人项目相关的邮件，都可以逐渐收束到这个域名下面。
这也是我给 loopnull.com 配置域名邮箱的主要原因：不是为了替代所有个人邮箱，而是为这个站点补上一层正式、稳定、可扩展的身份入口。
二、选择邮箱服务：为什么用 Lark Mail
域名邮箱有两种大方向：
第一种是自建邮件服务器。 第二种是使用现成的邮箱服务商。
一开始看，自建邮件服务器似乎更符合“个人基础设施”的思路：服务器是自己的，域名是自己的，邮箱也完全由自己控制。但真正了解之后会发现，邮件系统并不是一个适合新手一开始就自建的服务。
邮件系统的问题不只在于“能不能发出去”，而在于：
能不能稳定收信
能不能稳定发信
会不会进垃圾箱
会不会被大厂邮箱拒收
发信 IP 有没有信誉
DNS 认证是否完整
反垃圾策略是否正确也就是说，邮件不是简单跑一个 SMTP 服务就结束了。 它背后涉及 MX、SPF、DKIM、DMARC、PTR、TLS、IP 信誉、域名信誉、黑名单、灰名单、反垃圾评分等一整套系统。
对于个人博客来说，如果把精力过早投入到自建邮件服务器，很容易陷入一个问题：技术上能跑起来，但实际投递质量很差。尤其是新域名、新服务器、新 IP，很容易在 Gmail、Outlook 这类大厂邮箱面前表现不稳定。
所以我最终没有选择自建邮件服务器，而是选择把域名邮箱托管给成熟的邮件服务商。
这里我使用的是 Lark Mail，也就是飞书海外版的邮件服务。它可以绑定自定义域名，让我创建类似下面这样的邮箱：
[email protected]对我来说，Lark Mail 的价值主要有三点：
第一，它接管了复杂的邮件收发基础设施。 我不需要自己维护 SMTP、IMAP、反垃圾、邮件队列和服务器信誉。
第二，它支持自定义域名邮箱。 这可以让 loopnull.com 拥有自己的正式邮箱地址，而不是停留在普通第三方邮箱。
第三，它适合当前阶段。 我的重点仍然是建设个人网站、记录基础设施实践，而不是把大量精力放在维护一套完整邮件服务器上。
所以这一步的选择其实很明确：
不自建邮件服务器
使用 Lark Mail 承接域名邮箱
通过 DNS 记录把 loopnull.com 接入 Lark Mail对个人基础设施来说，这是一种比较现实的方案。 先把域名邮箱稳定跑起来，再去理解背后的邮件协议与认证机制，而不是一开始就把自己拖进邮件服务器运维的复杂度里。
三、域名邮箱的基本工作流
在配置之前，首先要弄清楚一封邮件是怎么送到域名邮箱里的。
假设别人要给我发送一封邮件：
[email protected]对方的邮件服务器首先要解决一个问题：
loopnull.com 这个域名的邮件应该送到哪里？它不会直接把邮件发到我的网站服务器，也不会自动知道 Lark Mail 的存在。 它需要通过 DNS 查询来获得答案。
这里起作用的就是 MX 记录。
MX 是 Mail Exchange 的缩写，用来指定一个域名的邮件接收服务器。 也就是说，MX 记录告诉全世界：
如果你要给 loopnull.com 发邮件，请把邮件交给这些邮件服务器处理。在我的配置里，loopnull.com 的 MX 记录指向 Lark Mail：
mx1.larksuite.com
mx2.larksuite.com
mx3.larksuite.com于是整个收信流程可以简化成这样：
别人发送邮件到 [email protected]
↓
对方邮件服务器查询 loopnull.com 的 MX 记录
↓
DNS 返回 Lark Mail 的邮件服务器地址
↓
对方邮件服务器把邮件投递给 Lark Mail
↓
Lark Mail 把邮件放入 [email protected] 的邮箱这里有一个容易混淆的点： 网站访问和邮件投递虽然都依赖域名，但它们走的是不同的 DNS 记录。
网站访问通常依赖：
A 记录
AAAA 记录
CNAME 记录邮件投递依赖：
MX 记录
TXT 认证记录所以，一个域名可以同时承担多种角色：
loopnull.com 作为网站域名
loopnull.com 作为邮箱域名
loopnull.com 作为身份认证域名这也是 DNS 的核心作用之一： 它不是只负责“把域名解析到网站”，而是负责把同一个域名下的不同服务，分发到对应的基础设施上。
四、配置 MX：让邮件知道该送到哪里
配置域名邮箱的第一步，是添加 MX 记录。
在 Cloudflare 的 DNS 面板里，我为 loopnull.com 添加了三条 MX 记录：
MX loopnull.com mx1.larksuite.com priority 1
MX loopnull.com mx2.larksuite.com priority 5
MX loopnull.com mx3.larksuite.com priority 10这三条记录的作用是告诉外部邮件服务器：
loopnull.com 的邮件由 Lark Mail 接收。其中 priority 表示优先级。 数字越小，优先级越高。
所以在这组配置中：
mx1.larksuite.com 优先级最高
mx2.larksuite.com 次级备用
mx3.larksuite.com 再次级备用正常情况下，邮件会优先投递到 mx1.larksuite.com。 如果它不可用，发送方再尝试后面的 MX 服务器。
这就是为什么邮箱服务商通常会提供多条 MX 记录。它不是重复配置，而是为了提高邮件接收的稳定性。
这里还需要注意一个 Cloudflare 相关的问题： 邮件相关记录必须保持 仅 DNS，不能走 Cloudflare 代理。
Cloudflare 的代理主要面向 HTTP / HTTPS 流量，也就是网站访问流量。 而 MX 记录负责的是邮件投递，不适合也不能通过橙云代理。
所以在 DNS 面板里，MX 相关记录应该是：
仅 DNS而不是：
已代理这一步完成后，外部邮件服务器就已经知道： 如果要给 loopnull.com 发邮件，就应该把邮件交给 Lark Mail。
但这还不代表整个邮箱配置已经完整。 MX 解决的是“邮件送到哪里”的问题，后面还要继续解决“谁可以代表这个域名发信”“邮件是否可信”“认证失败时怎么办”等问题。
五、配置 TXT：不只是验证域名所有权
在配置 Lark Mail 的过程中，除了 MX 记录，还需要添加多条 TXT 记录。
TXT 记录本质上是一种 DNS 文本记录。 它的作用很宽泛：可以在 DNS 中存放一段文本，让外部服务通过查询 DNS 来读取这段信息。
在域名邮箱场景里，TXT 记录通常承担几类任务：
验证域名所有权
配置 SPF
配置 DKIM
配置 DMARC例如，Lark Mail 可能会要求添加一条验证记录，用来证明我确实拥有 loopnull.com 这个域名。 原理很简单：只有域名所有者，或者有 DNS 管理权限的人，才能往这个域名下添加指定 TXT 记录。
所以，当我在 Cloudflare 中添加类似下面的验证记录后：
verification-code-site-...Lark Mail 就可以通过 DNS 查询确认：
这个人确实能控制 loopnull.com 的 DNS这一步解决的是“域名归属验证”。
但 TXT 的作用不止于此。 现代邮件系统大量依赖 TXT 记录来完成身份认证。例如：
SPF 声明哪些服务器可以代表这个域名发信
DKIM 提供邮件签名所需的公钥
DMARC 定义 SPF / DKIM 失败时的处理策略所以在域名邮箱配置里，TXT 记录并不是可有可无的附加项，而是邮件可信体系的核心组成部分。
可以这样理解：
MX 负责邮件投递位置
TXT 负责邮件身份认证如果只有 MX，没有 SPF / DKIM / DMARC，那么邮箱可能可以收信，也可能可以发信，但可信度是不完整的。 在 Gmail、Outlook 等大厂邮箱面前，这种不完整配置很容易导致邮件被判定为可疑，甚至直接进入垃圾箱或被拒收。
所以，域名邮箱真正完整的配置，不只是添加 MX，还要把 TXT 里的认证记录补齐。
六、SPF：告诉别人哪些服务器可以代表我发信
SPF 是 Sender Policy Framework 的缩写。 它的作用是声明：
哪些邮件服务器被允许代表这个域名发信。假设我用 [email protected] 给别人发送邮件。 收件方邮件服务器收到邮件后，会检查这封邮件是不是真的有资格代表 loopnull.com 发出。
检查方式之一，就是查询 loopnull.com 的 SPF 记录。
在我的配置里，SPF 记录是通过 TXT 记录添加的，形式大致如下：
v=spf1 include:spf.onlarksuite.com ~all这条记录可以拆开理解：
v=spf1表示这是一条 SPF 记录。
include:spf.onlarksuite.com表示允许 Lark Mail 指定的一组服务器代表 loopnull.com 发信。
~all表示如果发信服务器不在允许范围内，则软失败。
整个 SPF 验证流程可以简化成这样：
收件方收到一封来自 [email protected] 的邮件
↓
收件方查询 loopnull.com 的 SPF 记录
↓
发现 SPF 记录包含 include:spf.onlarksuite.com
↓
继续检查实际发信服务器是否属于 Lark Mail 允许范围
↓
如果匹配，则 SPF 通过SPF 主要解决的是发信来源问题。
没有 SPF 时，收件方很难判断： 这封自称来自 [email protected] 的邮件，到底是不是由授权服务器发出的。
有了 SPF 之后，域名所有者就公开声明：
只有这些邮件服务器可以代表我发信。这里有几个配置时需要注意的点。
第一，一个域名通常只应该有一条 SPF 记录。 如果同时添加多条 v=spf1，可能会导致 SPF 解析失败。
错误示例：
v=spf1 include:spf.onlarksuite.com ~all
v=spf1 include:example.com ~all如果以后同时接入多个发信服务，应该把它们合并到同一条 SPF 记录里：
v=spf1 include:spf.onlarksuite.com include:example.com ~all第二，~all 和 -all 不一样。
~all 软失败
-all 硬失败对于刚开始使用的新域名来说，~all 通常更保守。 因为新域名还在磨合期，过早使用过于严格的策略，可能会导致某些边缘情况下的邮件被直接拒收。
第三，SPF 不是万能的。 它只能证明发信服务器是否被授权，不能证明邮件内容是否被篡改，也不能单独决定邮件一定会进收件箱。
所以 SPF 需要和后面的 DKIM、DMARC 一起使用，才能构成比较完整的邮件认证体系。
到这一步，loopnull.com 已经完成了一个关键声明：
Lark Mail 可以代表 loopnull.com 发信。这也是域名邮箱从“能发邮件”走向“可信发邮件”的第一步。
七、DKIM：让邮件带上可验证的签名
配置完 SPF 之后，还需要配置 DKIM。
SPF 解决的是“发信服务器是否被允许”的问题，而 DKIM 解决的是另一个问题：
这封邮件是否真的由可信系统签名，并且在传输过程中没有被篡改？DKIM 是 DomainKeys Identified Mail 的缩写。它的核心机制是“数字签名”。
简单来说，Lark Mail 在代表 loopnull.com 发信时，会用一把私钥给邮件生成签名。收件方收到邮件后，会去 DNS 中查询对应的 DKIM 公钥，然后用这个公钥验证签名。
如果签名可以验证通过，就说明两件事：
这封邮件确实经过授权邮件系统签名
邮件关键内容在传输过程中没有被篡改在我的 DNS 配置里，DKIM 也是通过 TXT 记录完成的。记录名称大致类似：
lark**********._domainkey记录内容则类似：
v=DKIM1; k=rsa; p=...这里可以拆开理解：
v=DKIM1表示这是一条 DKIM 记录。
k=rsa表示使用 RSA 密钥算法。
p=...表示公开的 DKIM 公钥。
整个 DKIM 验证流程可以简化成这样：
Lark Mail 使用私钥给邮件签名
↓
邮件被发送到收件方邮箱服务器
↓
收件方根据邮件头中的 DKIM 信息查询 DNS
↓
DNS 返回 loopnull.com 对应的 DKIM 公钥
↓
收件方用公钥验证邮件签名
↓
验证通过后，说明邮件可信度更高这里有一个容易误解的地方： DKIM 不是用来“加密邮件内容”的。
它的重点不是让别人看不到邮件内容，而是让收件方可以验证：
这封邮件是不是经过授权系统签名
这封邮件在传输过程中有没有被改动所以，SPF 和 DKIM 的侧重点不同：
SPF 验证发信服务器是否被授权
DKIM 验证邮件是否带有有效签名如果只有 SPF，没有 DKIM，收件方只能知道发信服务器是否在授权范围内。 如果同时配置 DKIM，邮件本身也会带上可验证的身份标记。
这一步完成后，[email protected] 发出的邮件就不再只是“从某个服务器发出去”，而是带上了和 loopnull.com 绑定的签名信息。
八、DMARC：告诉收件方认证失败时怎么办
SPF 和 DKIM 配置完成后，还需要配置 DMARC。
DMARC 是 Domain-based Message Authentication, Reporting and Conformance 的缩写。 它建立在 SPF 和 DKIM 之上，用来告诉收件方：
如果一封自称来自 loopnull.com 的邮件没有通过认证，应该怎么处理？也就是说，SPF 和 DKIM 负责“验证”，DMARC 负责“处置策略”。
在我的 DNS 配置中，DMARC 记录位于：
_dmarc.loopnull.com记录内容大致类似：
v=DMARC1; p=none; rua=...这里可以拆开理解：
v=DMARC1表示这是一条 DMARC 记录。
p=none表示当前策略是只观察，不要求收件方强制拦截。
rua=...表示接收聚合报告的地址，用来观察邮件认证情况。
DMARC 常见策略主要有三种：
p=none 只观察，不强制处理
p=quarantine 认证失败时建议隔离，通常表现为进垃圾箱
p=reject 认证失败时建议直接拒收对于一个刚开始使用的个人域名来说，我没有一开始就设置成 reject，而是先使用更保守的：
p=none原因很简单：新域名、新邮箱系统、新 DNS 配置都需要一段观察期。 如果一开始就把策略设置得过于严格，一旦 SPF、DKIM、转发规则或第三方服务配置存在边缘问题，可能会导致合法邮件也被拦截。
所以当前阶段更合理的做法是：
先让 SPF 和 DKIM 正常工作
再用 DMARC 观察认证结果
确认稳定后，再考虑提高策略强度DMARC 的实际意义并不只是“多加一条记录”。 它让域名所有者可以明确告诉收件方：
如果有人伪造 loopnull.com 发信，请按我的策略处理。这对于防止域名被冒用有直接价值。
到这一步，邮件认证体系大致形成：
SPF 声明哪些服务器可以发
DKIM 给邮件加上可验证签名
DMARC 告诉收件方认证失败时怎么办这三者结合起来，才算是比较完整的域名邮箱认证结构。
九、测试收发：Gmail 正常，Outlook 被拒
完成 MX、SPF、DKIM、DMARC 配置之后，下一步就是测试收发。
我首先测试了 Gmail。 结果比较正常：[email protected] 发出的邮件可以被 Gmail 接收，这说明基础配置大概率已经生效。
至少可以确认几件事：
MX 记录可以正常解析
Lark Mail 可以正常承接域名邮箱
SPF / DKIM / DMARC 没有明显阻断 Gmail 收信
[email protected] 已经具备基本可用性但在测试 Outlook 时，我遇到了拒收问题。 退信信息里出现了类似这样的提示：
550 5.7.1 Unfortunately, messages from [某个 IP] weren't sent.
Please contact your Internet service provider since part of their network is on our block list.这里一开始容易产生误判：看到退信里出现 IP，就会以为是自己的服务器 IP 被封了。
但实际上，我使用的是 Lark Mail 作为邮件服务商，发信出口并不是我自己的 VPS。 所以退信里显示的 IP，更可能是 Lark Mail 或其上游邮件基础设施的出口 IP，而不是我运行博客的服务器 IP。
这说明一个问题：
邮件投递是否成功，不只取决于我自己的 DNS 是否配置正确。收件方还会综合判断很多因素：
发信出口 IP 信誉
域名年龄
历史投递行为
邮件内容特征
SPF / DKIM / DMARC 认证结果
是否命中黑名单
用户是否曾经与该域名互动
收件平台自己的风控策略所以，Gmail 正常接收，而 Outlook 拒收，并不一定说明 DNS 配置错误。 更准确的判断应该是：
基础邮件配置已经可用，但不同收件平台的风控策略不同。尤其是 Outlook / Hotmail 这一类邮箱，对新域名、新发信源、共享出口 IP 的策略往往更严格。 即使 SPF、DKIM、DMARC 都配置完整，也不能保证刚开始就拥有稳定投递能力。
这一步让我明确了一件事：
邮件系统不是“配置正确 = 全平台稳定投递”。DNS 认证解决的是身份可信问题，但邮件能否进入对方收件箱，还受到邮件生态中的信誉系统影响。
十、为什么暂时不把 Outlook 当主要目标
在 Gmail 可以正常收信，而 Outlook 出现拒收之后，我没有继续把 Outlook 作为当前阶段的主要目标。
原因不是 Outlook 不重要，而是它不适合作为新域名邮箱早期阶段的唯一判断标准。
对于刚配置好的个人域名邮箱来说，最优先的目标应该是：
保证基础收发正常
保证 DNS 认证完整
保证低频、真实、稳定地使用
逐渐建立域名邮件信誉而不是一开始就追求所有邮箱平台都无条件稳定投递。
尤其是 Outlook 的拒收信息里提到的是某个出口 IP 所在网络被限制，而不是直接指出 loopnull.com 的 SPF、DKIM 或 DMARC 配置错误。 这意味着问题很可能和共享发信基础设施的信誉有关，而不是我这个域名本身的某一条 DNS 记录明显配置错了。
所以，当前阶段我更适合这样使用 [email protected]：
作为网站联系邮箱
作为个人基础设施相关服务的注册邮箱
作为 Cloudflare、GitHub、Lark 等服务的绑定邮箱
用于低频真实通信
用于接收系统通知和验证码同时暂时避免这些行为：
大量外发邮件
群发通知
营销邮件
短时间高频注册
频繁给陌生 Outlook 地址发信这就是所谓“养域名”的实际含义。
它不是玄学，而是邮件信誉系统中的长期行为积累。 一个新域名如果长期保持低频、真实、稳定、认证完整的邮件行为，后续投递表现通常会比一开始就高频外发更稳。
所以我对当前阶段的判断是：
Gmail 正常接收，说明配置基本可用。
Outlook 拒收，说明投递信誉还需要时间和观察。因此，暂时不把 Outlook 当主要目标，而是先把域名邮箱作为个人网站和基础设施体系的一部分稳定使用。
十一、最终 DNS 结构：网站、邮箱、认证各司其职
配置完成后，loopnull.com 的 DNS 不再只服务于网站访问，而是同时承担了网站、邮箱和身份认证的功能。
从截图中可以看到，和域名邮箱相关的记录主要包括几类：
MX 指定邮件接收服务器
TXT 验证域名所有权
TXT 配置 SPF
TXT 配置 DKIM
TXT 配置 DMARC其中，MX 记录负责告诉外部邮件服务器：
loopnull.com 的邮件应该交给 Lark Mail。对应配置大致是：
MX loopnull.com mx1.larksuite.com priority 1
MX loopnull.com mx2.larksuite.com priority 5
MX loopnull.com mx3.larksuite.com priority 10TXT 验证记录负责告诉 Lark Mail：
我确实拥有 loopnull.com 的 DNS 控制权。SPF 记录负责声明：
Lark Mail 被允许代表 loopnull.com 发信。DKIM 记录负责提供：
用于验证邮件签名的公钥。DMARC 记录负责定义：
当 SPF / DKIM 认证失败时，收件方应该如何处理。可以把这套结构整理成下面这样：
| 记录类型 | 作用 | 解决的问题 |
|---|---|---|
| A / CNAME | 网站访问解析 | 浏览器访问域名时应该去哪里 |
| MX | 邮件接收服务器 | 别人给这个域名发邮件时应该投递到哪里 |
| TXT verification | 域名所有权验证 | 邮箱服务商如何确认我拥有这个域名 |
| TXT SPF | 发信服务器授权 | 哪些服务器可以代表这个域名发信 |
| TXT DKIM | 邮件签名验证 | 邮件是否由可信系统签名 |
| TXT DMARC | 认证失败处理策略 | SPF / DKIM 失败时收件方应该怎么处理 |
到这里，DNS 的角色就变得更清楚了。
它不是简单地“把域名指向服务器”，而是一个面向不同互联网服务的分发和声明系统：
网站访问 依赖 A / CNAME
邮件接收 依赖 MX
邮件认证 依赖 TXT
服务验证 也依赖 TXT也就是说，同一个 loopnull.com，可以同时承担多个层面的基础设施身份。
它既可以是：
博客入口也可以是：
邮箱后缀还可以是：
服务认证主体这一步之后，loopnull.com 的意义已经从“一个能访问网站的域名”，扩展成了一个更完整的个人互联网命名空间。
十二、总结：域名邮箱是个人基础设施的身份层
这次配置域名邮箱之后，我对个人基础设施的理解又往前推进了一步。
之前搭建服务器，解决的是：
服务运行在哪里购买域名，解决的是：
别人如何访问这些服务配置 DNS，解决的是：
域名如何找到对应的服务而域名邮箱解决的是：
这个站点如何对外建立一个稳定的身份入口所以，[email protected] 不是单纯换了一个更好看的邮箱地址。 它代表的是 loopnull.com 这个域名开始承担对外通信和身份识别的功能。
在这个过程中，MX、SPF、DKIM、DMARC 分别承担不同角色：
MX 负责收信路径
SPF 负责发信来源授权
DKIM 负责邮件签名验证
DMARC 负责认证失败后的处理策略它们共同构成了域名邮箱的基础可信体系。
当然，这并不意味着配置完成后就可以立刻获得完美投递能力。 Gmail 正常接收、Outlook 拒收的测试结果也说明：邮件系统不仅是协议问题，也是信誉问题。
DNS 记录可以快速配置完成，但域名信誉和发信信誉需要时间积累。
所以我对这一步的定位很明确：
先完成基础配置
再保持低频真实使用
逐步观察投递表现
后续再根据情况调整 DMARC 策略和发信习惯到这里，LoopNull 的基础设施结构变得更完整了：
服务器负责运行
域名负责命名
DNS 负责定位
HTTPS 负责安全访问
邮箱负责对外身份
SPF / DKIM / DMARC 负责邮件可信度从这个角度看，域名邮箱不是一个孤立功能，而是个人基础设施中的身份层。
它让 loopnull.com 不只是一个网站地址，而开始成为一个可以访问、可以联系、可以认证、可以长期扩展的互联网身份。