企业用自有域名收发邮件，地址更规范，员工账号也方便统一开通和交接。阿里云邮箱支持绑定自有域名，但实际操作要处理三类事：确认域名归属、修改解析记录、补齐发信认证。顺序不对，最常见的结果是邮件收不到，或者发出去直接进垃圾箱。下面按操作顺序说明，并附上迁移时容易踩的坑。
先确认解析权限
域名归公司持有，但解析权限不一定在你手里。有些企业注册域名时用的是代理商账号，或者是已离职同事的个人账号，等到要添加 TXT 和 MX 记录时才发现登不进去。开始前先确认三件事：能登录域名的 DNS 管理页面，能修改记录，并且能查到当前已有的 MX 和 TXT 记录。这一步很快，却能省掉后面大量等待。
添加域名并完成归属验证
在阿里云邮箱后台添加域名后，系统会要求证明你对该域名有控制权。常见做法是添加一条 TXT 记录，记录值由后台生成。操作时注意以下几点：
- 主机记录按后台提示填写，根域名通常写 @，不要自行添加前缀。
- 记录值整段复制，不要手敲，也不要留空格或换行，否则验证会一直失败。
- 解析生效需要一段时间。验证不通过时，先用 nslookup 或在线 DNS 查询工具确认记录已经对外可见，再回后台重新验证，不要反复删改。
把 MX 记录指向阿里云邮箱
验证通过后，发给这个域名的邮件仍会走原来的邮件服务器，直到 MX 记录改到阿里云。MX 的主机名和优先级以后台显示为准，照填即可，不要凭经验修改。
如果域名之前接过其他邮箱服务，旧的 MX 记录要删除或替换。同一个域名下留着两套邮件服务器，邮件可能一部分进了新邮箱，一部分还在旧系统里排队，表现就是有人说收到了，有人说没收到。切换前把旧记录截图或导出保存，万一需要回退，可以直接恢复。
SPF、DKIM、DMARC 怎么一起配
很多企业发信进垃圾箱，问题常出在认证记录缺失或不完整。三项各管一块：
- SPF 是一条 TXT 记录，声明哪些服务器可以代表本域名发信。一个域名只能有一条 SPF 记录。如果同时用了阿里云邮箱和营销系统，要把各家的发信来源合并到同一条里，分开写成两条，接收方可能直接判定失败。
- DKIM 给邮件签名，接收方用公钥校验内容在传输中有没有被改动。密钥在后台生成，添加到 DNS 后要在后台检测一次，确认已经生效。
- DMARC 告诉接收方，SPF 或 DKIM 校验失败时怎么处理，并可以接收汇总报告，方便你看到都有哪些服务在用这个域名发信。
比较稳妥的顺序是：先开启 DKIM，把 SPF 合并完整，然后以 p=none 启动 DMARC，只观察不拦截。等报告里所有合法发信来源都已通过认证，再逐步改为 quarantine，视情况再收紧到 reject。直接上严格策略，最容易误伤的是财务通知、客服系统这类通过第三方发出的正常邮件。
一个迁移案例：从个人邮箱切到自有域名
某跨境电商团队原先用多个个人邮箱对接海外客户。客户时不时反馈邮件进了垃圾箱，内部交接也乱，离职员工的往来邮件常要靠人工转。团队决定迁到自有域名的阿里云邮箱。
技术负责人先做准备：确认了域名解析权限，并把旧邮件系统的 MX 和 TXT 记录整理成清单。接着在阿里云邮箱后台完成归属验证，替换 MX 记录，并为每位员工开通企业邮箱账号。认证配置放在最后，SPF 和 DKIM 配好后，DMARC 以观察模式运行两周。报告显示，一套内部营销系统也在用这个域名发信，却没有纳入 SPF。补上之后，相关邮件的认证结果恢复正常。
两个月后，团队反馈客户那边的投递情况有所改善，离职员工的邮箱也能顺利转给接任者。这个案例里最花力气的是提前梳理现有记录，并让认证覆盖所有发信来源，开账号反倒是最简单的一步。
收发不通时先查什么
- MX 记录是否已经指向阿里云，优先级是否与后台一致。
- 旧的 MX 记录是否还残留，导致邮件分流到其他服务器。
- 归属验证用的 TXT 记录是否被误删，删了之后后台可能显示异常。
- 发出去的邮件进垃圾箱时，先看 SPF 是否包含了所有发信服务，再看 DKIM 是否已在后台检测通过。
- 域名是否快到期，员工账号是否已启用。
日常维护中容易忽略的几件事
- 域名到期前提前续费。域名过期后邮箱收发会中断，恢复时要处理的事情往往比想象中多。
- 改过解析记录后，旧配置先别急着删。确认新记录稳定生效、收发正常，再做清理。
- 管理员账号开启两步验证。管理员账号一旦被盗，影响通常比单个员工邮箱大得多。
- 定期清理已不再使用的邮箱账号，避免离职人员的邮箱长期无人管理。
- 迁移前导出重要邮件做备份，合同和客户往来记录尤其要留存。
阿里云邮箱域名的配置本身不算难，容易出问题的是操作顺序和认证细节。先确认权限，再验证归属，然后切换 MX，再补齐 SPF、DKIM 和 DMARC。每一步确认生效后再进行下一步，收发出了问题，也能快速定位到底该查哪里。
