速查在线工具箱邮件协议与送达认证速查
SMTP、POP3、IMAP 谁管发谁管收、SPF / DKIM / DMARC 三条 DNS 记录如何配合、邮件进垃圾箱该从哪里查起。
邮件系统看起来古老，其实是把「谁负责发、谁负责收、如何证明这封信确实是你发的」拆成了几套独立机制。发信靠 SMTP，收信靠 POP3 或 IMAP，而「证明是你发的」靠 DNS 里的三条记录。
做网站时最常遇到的场景是「事务邮件进垃圾箱」——注册验证码、订单通知发出去用户收不到。这类问题九成出在发件人认证没配齐，而不是邮件内容写得不好。
1三种邮件协议的分工
发信与收信由不同协议负责，而且收信有两种风格完全不同的方式。
| 协议 | 负责 | 工作方式 | 适用场景 |
|---|---|---|---|
SMTP | 发送（以及服务器之间中转） | 把邮件推给目标服务器，端口 25 / 587 / 465 | 所有发信场景，包括客户端提交与服务器投递 |
POP3 | 收取 | 把邮件下载到本地，通常下载后从服务器删除 | 单设备收发，不需要多端同步 |
IMAP | 收取 | 邮件保留在服务器，客户端同步状态（已读、文件夹） | 多设备使用，是当前的主流选择 |
| 端口对照 | 加密情况不同 | 110 / 995（POP3），143 / 993（IMAP） | 带 S 后缀的端口为加密版本 |
| 「发送」的两种端口 | 提交与中转不同 | 587 用于客户端提交（推荐），25 用于服务器间中转 | 25 常被机房封禁以防垃圾邮件 |
多数邮箱服务商在网页与客户端里自动处理协议细节，但配置第三方客户端或自己调发信接口时会碰到这些参数。用 `587` 端口做提交、开启加密、用授权码而不是登录密码，是当前的主流实践。
2SPF / DKIM / DMARC 三条记录
这三条记录都写在发信域名的 DNS 里，共同回答「这封邮件真的是这个域名发的吗」。它们层层递进：SPF 管发信服务器，DKIM 管内容未被篡改，DMARC 管失败后怎么办。
| 机制 | 记录类型 | 验证什么 | 示例要点 |
|---|---|---|---|
SPF | TXT | 发信的服务器 IP 是否在授权列表里 | 如 v=spf1 include:_spf.example.com -all，-all 表示未授权一律拒 |
DKIM | TXT（放公钥） | 邮件正文与头部是否被中途修改 | 发信服务器用私钥签名，收信方用 DNS 里的公钥验签 |
DMARC | TXT（放策略） | SPF 或 DKIM 失败时如何处理、报告发到哪里 | 如 v=DMARC1; p=none; rua=mailto:...，p 取值见下 |
MX | MX | 这个域名的邮件该投递到哪台服务器 | 收信必需的记录，与发信认证是两回事 |
| 对齐（Alignment） | DMARC 的判定基础 | 用于认证的域名要与邮件头里的发信域名一致 | 这也是「代发邮件」容易失败的原因 |
DMARC 的 `p` 参数有三档：`none` 只观察并收报告、不拦截；`quarantine` 把可疑邮件丢进垃圾箱；`reject` 直接拒收。正确做法是从 `none` 开始跑一段时间，看清报告、把所有合法发信源都纳入 SPF / DKIM 之后再逐步收紧，直接上 `reject` 很容易把自己正常的邮件也拦掉。
3从发信到收信的链路
理解完整链路有助于定位「邮件到底卡在哪一步」。每一步都有可能出现问题。
- 1. 提交
- 你的应用或客户端把邮件交给发信服务器（用
587），此时需要认证身份 - 2. 查找收件方
- 发信服务器通过
MX记录找到对方负责收信的服务器 - 3. 认证校验
- 收信方检查
SPF（来源 IP 是否被授权）、DKIM（签名是否有效） - 4. 策略判定
- 按对方域名的
DMARC策略与自身反垃圾规则给出结论，决定进收件箱、垃圾箱还是拒收 - 5. 投递
- 存入收件人邮箱，等待用户用
IMAP或POP3收取 - 6. 反馈
- 若配置了 DMARC 报告，收信方会定期把汇总报告发到你指定的邮箱，可用于排查
4邮件被判为垃圾的常见原因
按「先查认证、再查内容、最后查信誉」的顺序排查，比盲目改标题有效得多。
| 层面 | 常见原因 | 排查方向 |
|---|---|---|
| 认证缺失 | 没配 SPF / DKIM / DMARC | 收一封信看原始头部里的认证结果，或看 DMARC 汇总报告 |
| 域名信誉 | 新域名大量发信、被投诉过 | 控制发送频率，从少量真实收发开始积累信誉 |
| 内容特征 | 标题夸张、正文像广告、图片过多而文字过少 | 减少营销化措辞，保证正文有实质文字与明确的退订方式 |
| 链接问题 | 正文里的链接与发信域名不一致 | 尽量使用同域链接，或对链接域名也做好认证 |
| 发送方式 | 用个人邮箱或免费邮箱批量发事务邮件 | 改用专业事务邮件服务，它们处理好了 IP 信誉与退信 |
| 退信与投诉 | 硬退信地址未清理、用户点了「举报垃圾」 | 及时清理无效地址，控制投诉率 |
新域名不要在第一天就发几千封。信誉是累积出来的，突然的量与投诉会让整批邮件被判定为垃圾。稳妥做法是先用低量真实邮件运行一段时间，逐步提升。
5四个高频误区
- 配了 SPF 就不会进垃圾箱
- SPF 只是三件事之一。DKIM 与 DMARC 缺一个，主流免费邮箱都会降权处理
- SPF 记录越长越全越好
- SPF 的 DNS 查询次数有上限（通常为 10 次），每多一个
include就多一次查询，超限会导致整体校验失败。应精简而非堆砌 - DMARC 设 reject 才显得专业
- 在没摸清所有合法发信源之前设
reject，很可能把业务邮件（比如第三方系统代发的通知）也一并拦掉。应当从none起步 - MX 配好了就能发信
MX决定的是「别人发给你时投到哪里」，与「你发出去能不能通过认证」无关。发信认证要看 SPF / DKIM / DMARC
看完就能用的站内工具
全部工具总览 →关于「邮件协议与送达认证速查」的常见问题
SMTP、POP3、IMAP 有什么不同？
SMTP 负责发送邮件，是「推」的角色，你的应用或客户端把邮件交给它，它再转发给对方的收信服务器，端口常见 587（客户端提交）和 25（服务器中转）。POP3 和 IMAP 都负责收取邮件，区别在同步方式：POP3 把邮件下载到本地后通常从服务器删除，因此不适合多设备，每台设备各收各的；IMAP 让邮件留在服务器上，并同步已读状态、文件夹结构，因此手机、电脑、网页端看到的是一致的内容，是当前的主流选择。两者都各有加密端口，POP3S 是 995、IMAPS 是 993。
SPF、DKIM、DMARC 分别做什么？
它们构成发件人认证的三层。SPF 通过一条 TXT 记录声明「哪些服务器有权用这个域名发信」，收信方核对来源 IP 是否在名单里；DKIM 由发信服务器用私钥给邮件签名，收信方用 DNS 里的公钥验签，用来证明内容在传输途中未被篡改；DMARC 则是策略层，规定当 SPF 或 DKIM 校验失败时怎么处理（只观察、丢垃圾箱还是拒收），以及把汇总报告发到哪个邮箱。三者配合才能有效提升送达率，只配其中一个通常不够。
自己的网站发验证码邮件总是进垃圾箱怎么办？
按顺序排查。第一步查认证：确认发信域名配齐了 SPF、DKIM 与 DMARC，可以给自己发一封信，查看原始头部里的认证结果（通常是 Authentication-Results 字段），三项都是 pass 才说明配置到位。第二步看发送方式：不要用个人邮箱或免费邮箱批量发事务邮件，改用专业事务邮件服务，它们的发信 IP 已有信誉积累。第三步查内容与频率：新域名不要突然大量发送，正文要有实质文字、不要堆砌链接、要有明确的用途说明。第四步看反馈：如果配了 DMARC 报告，定期查看哪些来源在代发你的域名，及时把合法的纳入认证。
DMARC 的 p 参数该设成什么？
稳妥的路径是从 p=none 开始，而不是一上来就 reject。p=none 表示「只观察不拦截」，同时会按 rua 参数把报告发给你，你可以从中看到所有以你的域名发信的来源。运行一段时间、确认所有合法发信源（自建服务器、第三方事务邮件服务、办公系统等）都已被 SPF 或 DKIM 覆盖之后，再把策略收紧到 quarantine（丢垃圾箱）观察一段，最后才设为 reject（直接拒收）。直接设 reject 的风险在于会拦掉自己都没意识到的合法发信通道，比如某个系统用你的域名代发通知。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。