外贸邮件与域名基础：MX、SPF与发信可信度的常见配置

报价发出去第三天，客户回了一句「没收到你的邮件，方便再发一次吗」，发件箱里明明标着已发送。昆山做外贸的团队遇到这种情形，下意识先重发一遍，重发之后对方还是没看见——信其实到了对方邮件网关，只是被丢进了垃圾箱，发件这头不会收到任何提示。比退信更麻烦的就是这种静默丢失：没有报错，没有回执，只有一段被拖长的来回。问题往往不在正文写了什么，而在域名那几条 TXT 记录没配齐。

本文要点

• MX 只管收信不管发信，发信可信度靠 SPF、DKIM、DMARC 三项配合
• SPF 有 10 次 DNS 查询上限，include 叠太多会直接判为 PermError
• DMARC 从 p=none 起步看聚合报告，再逐步收紧到 quarantine 或 reject
• 退信先看 SMTP 状态码是 5xx 硬退还是 4xx 软退，再查三项对齐结果

为什么发信可信度影响外贸

跨时区、跨运营商、跨邮件服务商，是外贸往来的常态。国内互发很顺的一封信，发给海外企业网关时可能多过几道检查：发信 IP 有没有反向解析、发信域名有没有声明哪些服务器可以代发、邮件头有没有可用签名、From 域名和签名域名对不对得上。这些检查不看你报价写得多细，也看不出你是不是老供应商，只看域名与 IP 的几项技术凭据。

凭据不齐的后果分两种。一种是硬退信，550 之类的状态码会把原因写回来，还算好查；另一种是进了垃圾箱或隔离区，发件方看到的只是「已发送」，客户那边不翻垃圾箱就永远看不到。常见情形是：一次性群发几十封开发信、正文塞了多个链接、附件接近网关上限，几件事叠在一起，同一域名后续发出的正常报价也跟着受影响。发信可信度管的是「能不能进收件箱」这一层，和内容质量是两回事。

还有个容易被忽略的时点：新域名或新发信 IP 短时间内发信量陡增，接收方没有历史记录可参照，处理会偏保守。所以配置之外还有节奏问题，这属于运维习惯，不是改一条记录就能解决的。

MX记录的作用

MX 是 DNS 里回答「别人往这个域送信，该送到哪台机器」的记录。它只作用于收信方向，和往外发信用哪台服务器没有关系。这点分清了，很多误判就能避开：官网上不了、发不出信，去查 MX 通常查不出原因。域名MX记录决定的是收信去向，不是发信权限。

一条 MX 由优先级数值和目标主机名组成，数值小的先试，数值相同则分摊。目标必须是能解析到 A / AAAA 的主机名，不能写成 IP，也不能指向 CNAME。TTL 决定别处缓存这条记录多久，改之前先调低，切换时回滚才快。

example.com.   3600  IN  MX  10  mx1.mailhost.example.
example.com.   3600  IN  MX  20  mx2.mailhost.example.

用 dig mx example.com 或 nslookup -type=mx 就能看到当前值。外贸邮箱设置里常出的几类错：把两条 MX 的优先级填成一样却指望主备、目标主机名少写一个点被拼成子域、旧邮局的 MX 没删干净导致一部分信去了旧系统、改 A 记录时顺手把 MX 覆盖掉。多条 MX 做冗余是好事，但前提是每一条都真的能收。

SPF与DKIM

SPF 是一条 TXT 记录，声明「哪些服务器被允许用这个域名发信」。收件方拿到信，取出信封里的发信域名，查它的 SPF，再比对这次连接的 IP 在不在允许列表里。

v=spf1 include:_spf.mailhost.example ip4:203.0.113.0/24 ~all

include 引用别家的 SPF 记录，ip4 / ip6 直接写网段，a、mx 按域名的 A 或 MX 反查，结尾 ~all 是软失败、-all 是硬失败。刚配时先用 ~all，确认所有合法发信源都覆盖到了再考虑收紧。有个硬限制要记住：一次 SPF 验证的 DNS 查询上限是 10 次，include 层层嵌套很容易超，超了直接判 PermError，前面写得多认真都会失效。另外同一个域只能有一条 SPF 记录，两条 TXT 各写一份 v=spf1 同样报错，要合并成一条。

SPF 还有个结构性短板：邮件经第三方转发后，转发服务器的 IP 通常不在原域名允许列表里，SPF 就会 fail。这正是需要 DKIM 的原因。

DKIM 换了个思路。发件服务器用私钥对邮件头与正文算出签名，写进 DKIM-Signature 头；收件方按头里的 selector 去查 <selector>._domainkey.example.com 的 TXT 公钥，验签是否成立。签名里带 d= 标明签名域名，只要头和正文没被中间环节改动，转发之后仍能验。selector 让一个域名可以同时挂多套密钥，轮换时不用一刀切。

一句话概括：SPF 管「谁可以发」，DKIM 管「信是不是原样、算不算这个域签的」。昆山做外贸的域名，两项都该有，别只配一项就以为齐了。

DMARC策略

DMARC 把前两项串起来，加一条对齐要求：From 头里显示的域名，要和通过 SPF 或 DKIM 验证的域名对得上。对不上，即使 SPF 单独 pass，DMARC 也可能判失败。策略写在 _dmarc.example.com 的 TXT 里：

v=DMARC1; p=none; rua=mailto:dmarc-report@example.com; pct=100; adkim=s; aspf=r

p 有三档：none 只观察不拦截，quarantine 让接收方倾向丢进垃圾箱，reject 直接拒收。rua 用来接收聚合报告，一般每天一封 XML，能看出「谁在替你这个域发信、各来源通过率多少」；ruf 是逐条取证报告，含邮件样本，不少服务商不提供，启用前要考虑隐私。adkim / aspf 控制严格（s）还是宽松（r）对齐，子域策略用 sp= 单独给。

落地顺序别跳步：

1. 先上 p=none，收一两周聚合报告，把报告里出现的发信源逐个认领
2. 把官网表单通知、系统告警、财务单据、营销工具这些「也在替你发信」的通道补齐 SPF 或 DKIM
3. 确认没有漏网来源后，用 pct 小比例试 quarantine，观察退信与客户反馈
4. 稳定一段时间再考虑 reject，并保留报告接收，方便日后追查

一上来就写 reject 是常见事故，往往把自家表单通知一起挡掉，而这类邮件没有人工发件人，没人会立刻发现。把 SPF DKIM DMARC 三项一起配齐、跑过观察期，才谈得上发信域名有了基本凭据。

域名与账号统一

发信域名和官网域名用同一个主域（比如都是 example.com），客户看到的 From 地址和网址对得上，域名声誉也集中在一处累积，DMARC 对齐更容易满足。反过来，用免费邮箱域名发 PI、合同或提单确认，接收方很难把来信和官网主体关联起来，信任成本就落在业务员一遍遍解释上。

但也不是所有邮件都挤在主域上。营销群发、系统通知这类量级大、投诉概率高的通道，建议放到子域（news.example.com、mail.example.com），把风险与主域的商务往来隔开。子域要单独配 SPF 与 DKIM，DMARC 的组织域对齐规则也要算清楚，别以为父域配了就自动覆盖。另一个细节是 From 域与 Return-Path（信封发件人）域：两者不一致时，SPF 验证的是后者，对齐就可能失败，使用第三方发信服务时尤其要核。

账号侧同样要提前定规矩。销售离职后账号是停用保留还是直接删、期间来信转给谁，info@ / sales@ 这类共用账号由谁看、多久清一次，对外显示名用「名.姓」还是中文名加公司，统一一种写法。昆山做外贸的团队人员流动时，共用账号往往比个人账号更该先交接。这些和密码策略一起写进管理台账，比出事后再翻记录省事。

退信排查清单

退信原文末尾的 status= 与 Diagnostic-Code 是起点。5xx 是硬退（地址不存在、被策略拒绝），4xx 是软退（稍后重试、对方忙、容量不足），处理方式完全不同：硬退要停下来查地址与策略，软退可以观察重试队列。

按下面这份清单走一遍，多数退信能定位到具体一层：

1. 读完整退信，抄下 status=、Diagnostic-Code、时间戳与 Message-ID，别只看主题行
2. 核收件地址与域名拼写，硬退里这类占比不低
3. dig mx 对方域名 确认对方 MX 存在且可解析
4. dig txt 己方域名 检查 SPF 是否只有一条、引号与分段有没有被控制台拆坏、include 层数是否逼近 10 次上限
5. 用发信测试工具收一封测试信，看 spf=、dkim=、dmarc= 三项是 pass 还是 fail，以及对齐结果
6. 查发信 IP 是否落在常见黑名单，PTR 反解是否与 HELO 名称一致
7. 看内容侧：附件是否超过 20–25MB、正文外链是否过多、是否一次性群发量陡增
8. 新域名或新 IP 是否有逐步预热的过程，短期内发信量有没有跳变
9. 若属对方企业网关白名单问题，请对方管理员按时间戳加白，并提供 Message-ID 便于对方查日志

排查时按「地址 → 对方 → 己方记录 → 验证结果 → IP 声誉 → 内容」的顺序收窄，比一上来就改正文有效。海外往来的时差会拉长每一轮验证，把每次改动和对应时间戳记下来，隔天回看才分得清是哪一步起了作用。

小结

发信可信度不是一封邮件写得好不好，而是域名那几条记录有没有互相配合。明天就能做的一件事：用 dig 查一遍自己域名的 MX 与 TXT，确认只有一条 SPF、DKIM 的 selector 能查到公钥、_dmarc 记录存在且处于观察档。需要把记录和现有发信通道对一遍，可以看 服务与解决方案 的交付范围，或走 免费咨询；同类技术拆解收在 行业动态栏目。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。