Email 协议与客户端

概述

电子邮件的发送、投递和读取是几件不同的事。SMTP 负责提交和转运邮件，IMAP 与 POP3 负责访问已经存入邮箱的邮件。因此，第三方客户端通常要分别配置“收信服务器”和“发信服务器”：收信正常，发信仍可能失败。

邮箱服务商保存邮件、执行投递与风控；Apple Mail、Thunderbird、Outlook 等客户端负责呈现和操作邮箱。换客户端不会换掉邮箱地址，也不会绕过服务商的权限、配额与反垃圾规则。

投递流程

以 alice@example.com 给 bob@example.net 发信为例，常见链路如下：

Alice 的客户端
  │ SMTP 提交，通常使用 465 或 587
  ▼
example.com 的发信服务
  │ 查询 example.net 的 DNS MX 记录
  │ SMTP 转运，通常使用 25
  ▼
example.net 的收信服务
  │ 检查收件人、反垃圾规则与容量，存入 Bob 的邮箱
  ▼
Bob 的客户端
  └─ 通过 IMAP 或 POP3 读取邮件

邮件系统里常见几个缩写：

• MUA：邮件用户代理，也就是客户端。
• MSA：邮件提交代理，接收用户提交的待发送邮件。
• MTA：邮件传输代理，在服务器之间转运邮件。
• MDA：邮件投递代理，把邮件交给最终的邮箱存储。

这些是角色划分，不要求分别运行在四台机器上。服务商可以把多个角色放在同一套系统中。

MX 记录用于寻找域名的收信服务器，不能据此推导客户端的 IMAP 或 SMTP 地址。 企业邮箱地址可能使用公司的域名，客户端连接的却是邮件服务商提供的主机名。SMTP 的路由与投递规则见 RFC 5321。

邮件使用存储转发机制。下一跳暂时不可用时，服务器可以排队重试；最终无法投递时，可能生成退信。发信服务接受邮件、收件服务器接受邮件、进入收件箱、被收件人阅读，是四种不同结果。

邮件结构

一封邮件通常由邮件头、空行和正文组成。邮件头记录发件人、收件人、主题、日期等信息；HTML、图片、附件和多语言文本则依靠 MIME 描述和编码。SMTP 管传输，MIME 管内容如何组织。格式分别由 RFC 5322 和 RFC 2045 等规范定义。

还有一个容易混淆的区别：邮件有“信封地址”和“邮件头地址”。

信息	所在位置	用途
MAIL FROM	SMTP 信封	指定信封发件人，通常用于接收退信
RCPT TO	SMTP 信封	指定本次实际投递的收件人
From	邮件头	客户端显示的发件人
To、Cc	邮件头	客户端显示的收件人与抄送人
Reply-To	邮件头	指定回复地址

信封地址和显示地址可以不同，例如邮件列表、代发服务和退信处理系统。密送 Bcc 的收件人也要出现在投递信封中，但通常不会出现在其他收件人收到的邮件头里。

因此，只看到 From 写着某个地址，并不能证明邮件真的来自那个账号。发件人身份还需要结合认证结果判断。

协议分工

SMTP：提交与转运

SMTP 的全称是 Simple Mail Transfer Protocol。客户端用它提交邮件，邮件服务器也用它把邮件交给下一跳。客户端提交通常需要认证，服务器间转运通常不会要求登录收件人的账号。

客户端的 SMTP 会话通常包含这些操作：

• EHLO：询问服务器支持哪些扩展，例如 TLS、认证和消息大小声明。
• STARTTLS：在支持这种连接方式时升级到 TLS。
• AUTH：在服务商要求时完成身份认证。
• MAIL FROM、RCPT TO：指定投递信封。
• DATA：传输邮件头与正文。

ESMTP 是支持扩展机制的 SMTP。客户端配置里通常仍写“SMTP”，不需要另找一套 ESMTP 服务器。

收到 DATA 结束后的成功响应，表示当前服务器接受了邮件并承担后续处理责任，不代表对方已经读到。SMTP 也不负责同步收件箱、已读状态或文件夹。RFC 5321 定义了 SMTP 的命令与响应语义。

POP3：下载邮件

POP3 是 Post Office Protocol Version 3，主要用于把服务器邮箱中的邮件取到本地。它适合单设备下载、旧设备接入，或某些明确需要本地保存的场景。

典型操作包括列出邮件、下载邮件，以及按配置删除服务器上的副本。客户端通常会记录 UIDL 返回的标识，避免下次连接重复下载。

POP3 不等于“收完必删”。 下载使用 RETR，删除需要另外发出 DELE；正常通过 QUIT 进入更新阶段后，服务器才执行已标记的删除。是否删除、保留多少天，还取决于客户端设置和服务商实现。RFC 1939 说明了这一过程。

POP3 不提供 IMAP 那样的文件夹和已读标记同步。电脑上读过一封邮件，手机不一定知道；电脑上删除了本地副本，也不一定改变其他设备的状态。即使开启“在服务器上保留副本”，这些同步能力也不会凭空出现。

IMAP：管理邮箱

IMAP 的全称是 Internet Message Access Protocol。服务器通常保存邮箱的主状态，客户端同步文件夹、邮件与已读、星标等标记，并可按需获取正文和附件。

手机把一封邮件标成已读，电脑随后同步到这个变化；客户端移动或删除邮件，操作通常也会传播到服务器与其他设备。IMAP 客户端同样可以保存本地缓存、支持离线阅读，具体下载范围由客户端决定。

同步时，客户端可使用邮箱名、UIDVALIDITY 和邮件 UID 识别邮件，而不是假设列表中的“第 3 封”永远指向同一封。支持 IDLE 时，服务器能在现有连接上通知客户端邮箱变化，减少反复轮询。RFC 9051 描述了这些机制。

IMAP 同步不是备份。删除操作也会同步；需要独立备份时，应导出到不再随服务器变化的归档位置。IMAP 也不负责把新邮件投递给外部收件人，发信仍通常交给 SMTP。

如何选择

需求	常见选择	边界
手机、电脑、网页共同使用邮箱	IMAP + SMTP	删除与状态修改通常跨设备同步
单设备下载邮件	POP3 + SMTP	明确检查服务器副本保留策略
完整保存历史邮件	独立导出或备份	仅有同步缓存不等于完整备份
企业邮件、联系人和日历一起接入	服务商支持的 Exchange 接入方式或 API	普通 IMAP 不覆盖完整协作功能

网页邮箱通常通过 HTTPS 与服务商后台交互，浏览器不直接连接 IMAP 或 SMTP 端口。某些客户端也会使用 Gmail API、Microsoft Graph 或 JMAP 等接口，不能把所有邮件应用都归结为 POP3、IMAP 和 SMTP 三件套。

常用端口

下表是传统邮件协议常用的 TCP 端口。客户端设置需要同时匹配协议、主机名、端口、加密方式和认证方式，端口相同不代表其余设置都正确。

协议与用途	端口	连接方式
SMTP，服务器间转运	25	可通过 STARTTLS 升级加密，实际策略由双方决定
SMTP，客户端提交	587	通常配置 STARTTLS，并要求升级成功
SMTP，客户端提交	465	隐式 TLS，连接后立即进行 TLS 握手
IMAP，传统入口	143	可通过 STARTTLS 升级加密，不应明文登录
IMAP，加密入口	993	隐式 TLS
POP3，传统入口	110	可通过 STLS 升级加密，不应明文登录
POP3，加密入口	995	隐式 TLS

隐式 TLS 的邮件提交与访问端口见 RFC 8314。POP3 的升级命令叫 STLS，有些客户端界面仍统一把选项标成 STARTTLS。

25 主要是服务器之间的入口，个人客户端一般按服务商文档使用 465 或 587。部分云平台还会封禁向外连接 25，例如腾讯云的相关说明。应用改用服务商的提交端口可解决这类提交问题，但自建 MTA 向外投递仍需要考虑 25 的可达性。

连接加密

隐式 TLS 和 STARTTLS 的区别是开始加密的时机：

• 隐式 TLS：建立 TCP 连接后先做 TLS 握手，再交换邮件协议数据。
• STARTTLS：先建立协议会话、协商升级，再做 TLS 握手；认证和邮件内容应在加密成功后发送。

客户端里写着“SSL/TLS”，通常指隐式 TLS 连接方式，不意味着应启用已经过时的 SSL。465 + SSL/TLS 与 587 + STARTTLS 都是常见配置；不能只改端口而保留错误的加密模式。

STARTTLS 应配置为必须成功，不应在升级失败后悄悄继续明文登录。两种方式都需要校验证书的主机名、有效期与信任链。RFC 8314 指出，在正确实现且强制 TLS 的前提下，这两种提交方式的安全属性没有显著差别。

TLS 保护的是某一段连接。客户端到服务商加密，不保证所有服务器转运环节都按相同策略加密，也不阻止服务商读取普通邮件正文。S/MIME、OpenPGP 等内容加密方案才涉及端到端内容保护；Base64 只是编码，与加密无关。

客户端原理

账号接入

添加邮箱时，客户端先根据服务商预设、自动发现机制或手动输入，获得收发信服务器参数。随后建立连接、校验证书，并通过服务商支持的方式认证。

“自动配置成功”只表示发现了一组参数，认证和权限检查仍可能失败。MX 记录也不能代替这一步。

同步与缓存

以常见的 IMAP 客户端为例，工作过程通常包括：

1. 获取文件夹列表与邮件标识。
2. 同步邮件头、摘要、标记等信息。
3. 按设置下载正文和附件，写入本地数据库或文件。
4. 把已读、移动、删除等操作提交给服务器。
5. 通过 IDLE 通知或定时轮询继续检查变化。

本地搜索可能依赖已下载的内容，也可能请求服务器搜索。离线时能看到主题，不代表附件已经下载；缓存范围过小，也可能让客户端搜索结果少于网页端。

发信时，客户端把正文与附件组装成 MIME 邮件，再通过 SMTP 提交。发出后“已发送”副本可能由服务商自动保存，也可能由客户端通过 IMAP 上传。配置不匹配时，会出现重复副本，或者只在当前设备看得到已发送邮件。

直连与云端代理

第三方客户端有不同的数据路径：

本地直连：设备上的客户端 → 邮箱服务商

云端代理：设备上的客户端 → 客户端厂商云服务 → 邮箱服务商

本地直连模式由设备保存缓存与凭据，并直接同步邮箱。云端代理模式可能由客户端厂商的服务器持续连接邮箱、处理通知与搜索，再把结果同步给设备。

例如，Microsoft 官方说明中，部分 Outlook 场景会把外部账号的邮件、日历和联系人副本同步到 Microsoft 云端。是否采用这种路径，需要按具体产品、版本和账号类型判断。Outlook 云端同步说明

OAuth 授权不代表应用无法读取正文；它能读取什么，由授权范围和产品实现决定。移除设备上的账号也不等于厂商云端数据已经删除，停用时还需要检查服务商授权与客户端厂商的数据保留规则。

移动系统的后台限制也会影响通知。IMAP 的 IDLE 是已有连接上的通知机制，不等于应用退出后仍能独立收到系统推送。

登录认证

加密回答“连接是否安全”，认证回答“谁有权访问邮箱”，两者不能互相替代。

方式	客户端使用的凭据	主要边界
账号密码	邮箱账号的登录密码	部分服务商已不允许用于传统协议登录
授权码、应用专用密码	服务商生成的独立密码	可单独撤销，但通常仍具备较广的邮箱权限
OAuth 2.0	访问令牌，通常还包含刷新令牌	权限受授权范围约束，应用仍可在授权范围内访问邮件

授权码

授权码通常填写在客户端的“密码”字段，用于代替网页登录密码。它往往是长期凭据，不是手机验证码，也不是 OAuth 授权流程中的一次性授权码。

泄露授权码可能让他人读取或发送邮件。停用客户端后，应撤销对应凭据；服务商允许时，可以为不同应用分别生成，便于定位和撤销。

Google 的应用专用密码需要开启两步验证，但组织策略、高级保护等条件可能让这个选项不可用。Google 优先推荐“使用 Google 登录”，不能假设每个账号都能生成应用专用密码。Google 应用专用密码说明

OAuth 2.0

OAuth 接入通常会打开服务商的登录与授权页面。用户完成登录、多因素验证和授权后，客户端获得令牌，再把令牌用于 API 或邮件协议认证。访问令牌到期时，客户端可按授权条件用刷新令牌换取新令牌。

因此，OAuth 2.0 是授权机制，IMAP、POP3 和 SMTP 是邮件协议。使用 OAuth 登录后，底层仍可能在使用这些协议；Google 与 Microsoft 都提供相应支持。Google 邮件协议认证、Microsoft 邮件协议认证

令牌同样是敏感凭据。撤销授权会影响后续访问，但已经下载到本地或同步到第三方云端的副本，不会因此自动消失。

服务商差异

下面列的是常见接入方式，依据 2026 年 10 月查阅的官方文档整理。账号套餐、企业管理员设置、地区与后续策略调整都可能影响实际可用性。

服务商或账号	IMAP 收信	POP3 收信	SMTP 发信	接入要求
Gmail	imap.gmail.com:993，隐式 TLS	pop.gmail.com:995，隐式 TLS	smtp.gmail.com:465，隐式 TLS；或 587，STARTTLS	优先 OAuth；符合条件时使用应用专用密码，POP 需按设置启用
Outlook.com 个人邮箱	outlook.office365.com:993，隐式 TLS	outlook.office365.com:995，隐式 TLS	smtp-mail.outlook.com:587，STARTTLS	官方要求 OAuth2／现代认证；按账号设置启用 POP 或 IMAP
QQ 邮箱	imap.qq.com:993，隐式 TLS	pop.qq.com:995，隐式 TLS	smtp.qq.com:465，隐式 TLS	开启相应协议服务，使用授权码
Proton Mail	通过本机 Bridge 提供 IMAP	不提供 POP3	通常通过本机 Bridge 提供 SMTP	Bridge 需包含 Proton Mail 的付费套餐，端口与凭据以 Bridge 显示为准

服务器参数来源：Gmail 协议文档、Outlook.com 设置、腾讯云 Email 连接器文档，第 32—33 页、Proton 协议接入说明。

Gmail 个人账号自 2025 年 1 月起不再提供 IMAP 开关，IMAP 始终开启；旧教程里的“先启用 IMAP”步骤未必适用。Google Workspace 账号还受组织策略影响。Gmail 第三方客户端说明

Outlook.com 个人账号与 Microsoft 365 企业邮箱不能混用配置。Exchange Online 的 SMTP AUTH 可以在组织级或单个邮箱级被关闭，网页能发信不代表程序有 SMTP 提交权限。Exchange Online SMTP AUTH 设置

Proton Bridge 在本机提供 IMAP、SMTP 接口，并负责本地解密与发信加密。客户端连接的是本机 Bridge，不是直接填写一个公网 Proton IMAP 地址。它目前面向 macOS、Windows 和 Linux，不是手机端的通用接入方式；部分商业套餐另有 SMTP Submission 功能。Proton Bridge 工作原理、支持范围

常见限制

服务商的限制通常分为协议权限、发送额度、消息大小、存储容量、连接与流量，以及风控规则。第三方客户端和脚本使用的仍是同一个邮箱账号，并不会获得额外配额。

发送额度

“每天可发多少封”只描述一个维度，还要区分单封收件人数、总收件人数、外部收件人数和独立收件人数。To、Cc、Bcc 都可能计入配额，别名也不一定拥有独立额度。

• Gmail 个人账号官方帮助指出：单封超过 500 个收件人，或一天发送超过 500 封邮件，可能触发发送限制。这不能当成任何渠道、任何账号都能保证用满的额度。Gmail 发送限制
• Google Workspace 官方表格列出一般用户每天最多 2,000 封、试用账号 500 封；通过 SMTP 提交的单封收件人上限为 100。限制按滚动 24 小时计算，SMTP relay 等渠道另有规则。Workspace 发送限制

达到配额后不断重试，通常不能恢复发送，反而可能增加风控压力。程序应区分配额耗尽、临时错误和永久拒绝，按服务商规则等待恢复或处理失败。

消息与附件

附件原始大小和最终邮件大小不同。Base64 每 3 字节编码成 4 个字符，体积约增加三分之一，还要加上换行、邮件头和 MIME 边界。一个原始大小为 20 MB 的文件，编码后就可能超过 26 MB。MIME 编码规范

服务商有的限制编码前附件大小，有的限制整封消息大小，不能只比较界面上显示的“25 MB”。发信端允许，也不意味着收件端允许。

Gmail 个人账号的附件上限是 25 MB，网页端超出时会转为 Google Drive 链接。这种产品行为不会因为使用 SMTP 就自动复制到所有客户端，第三方客户端需要自行实现云附件功能。Gmail 附件说明

邮箱空间耗尽可能导致收信或其他操作受限。本地下载邮件不等于腾出服务器空间；删除 IMAP 缓存也通常只是在清理本机。服务器上的垃圾箱等文件夹是否占用空间，应以服务商的容量规则为准。

连接与风控

多个设备、多个文件夹长连接和备份工具会增加连接与流量消耗。首次同步大量历史邮件也可能触发限流，应通过缩小同步范围、减少并发或分批下载控制负载。

Gmail 的客户端帮助文档列出每个账号最多同时添加 15 个邮件客户端，并提醒并发连接过多会报错；不能把它简单理解为“每台设备只占一个连接”。Gmail 客户端限制

异常登录、大量退信、短时间集中发送、垃圾邮件举报和账号历史等都可能影响风控结果。公开额度不是投递承诺，更不是群发白名单。验证码、订单通知等应用邮件通常需要专门的投递服务，同时处理退信、投诉与退订，而不只是循环调用个人邮箱 SMTP。

发件人验证

自有域名配置了 MX，只解决“邮件送到哪里”。提高发件人可信度还要配置 SPF、DKIM 和 DMARC。

机制	检查对象	作用
SPF	发送 IP 与 SMTP 信封域名，或 HELO 域名	声明哪些服务器有权代表这个域名发信
DKIM	邮件中被签名的头字段和正文	用 DNS 中的公钥验证域名签名及签名内容的完整性
DMARC	可见 From 域名与 SPF／DKIM 认证域名的对齐	声明认证失败时的处理策略，并提供报告机制

DMARC 通常只需 SPF 或 DKIM 至少一项验证通过，且对应域名与可见 From 域名满足对齐条件。它不要求两项都通过，但部署时往往都会配置。SPF、DKIM、DMARC

这些机制不负责加密邮件，也不保证内容安全或一定进入收件箱。转发可能影响 SPF；邮件列表修改正文可能影响 DKIM。自建发信服务还要考虑 PTR 反向解析、IP 与域名信誉以及接收方的独立反垃圾策略。

配置与排错

配置清单

接入普通 IMAP 邮箱时，分别确认这些项目：

• 邮箱地址与登录用户名：用户名可能需要完整邮箱地址，以服务商要求为准。
• 收信：IMAP 主机名、端口、TLS 模式和认证方式。
• 发信：SMTP 主机名、端口、TLS 模式和认证方式，不应默认免认证。
• 凭据：OAuth 授权，或服务商允许的授权码、应用专用密码。
• 权限：账号是否启用了协议，企业管理员是否允许第三方应用和 SMTP AUTH。
• 同步：文件夹映射、已发送副本、附件下载范围，以及删除行为。

IMAP 与 SMTP 可能使用相同身份，但连接和认证是独立的。能收不能发时，应先检查 SMTP 配置，而不是反复修改收信密码。

连接诊断

有 OpenSSL 的环境中，可以只检查连接、TLS 握手与证书，不发送登录凭据。例如检查 Gmail 的 SMTP 提交入口：

# 465：连接后立即进行 TLS 握手
openssl s_client -connect smtp.gmail.com:465 \
  -servername smtp.gmail.com \
  -verify_hostname smtp.gmail.com -verify_return_error

# 587：先通过 SMTP STARTTLS 升级连接
openssl s_client -starttls smtp -connect smtp.gmail.com:587 \
  -servername smtp.gmail.com \
  -verify_hostname smtp.gmail.com -verify_return_error

不同系统的 OpenSSL 版本和 CA 配置可能不同。成功握手只说明网络和 TLS 这一层可用，不证明账号认证、SMTP 权限和投递都成功。不要为消除报错而关闭客户端的证书校验，也不要把密码、授权码或令牌粘贴进公开日志。

常见现象

现象	优先检查
连接超时	DNS、网络、防火墙、服务主机名与端口是否可达
TLS 握手失败	隐式 TLS 与 STARTTLS 是否混用，协议版本是否兼容
证书不可信	主机名、系统时间、CA 信任配置，是否存在代理拦截
网页能登录，客户端认证失败	是否误用网页登录密码，是否要求 OAuth 或授权码，协议是否开放
能收不能发	SMTP 参数、独立认证配置、发送权限、配额和发件人地址权限
手机与电脑状态不同	是否使用 POP3、是否暂停同步、是否映射到了不同文件夹
网页端邮件突然消失	POP3 删除服务器副本、IMAP 同步删除、服务端过滤规则
已发送邮件重复	客户端上传副本与服务端自动保存是否同时启用
提交成功，对方没看到	垃圾箱、隔离区、退信、投递队列及域名认证结果

SMTP 响应首位数字表示大类：2xx 为成功，3xx 表示需要继续提供信息，4xx 通常是临时失败，5xx 通常是永久失败。SMTP 响应规范

具体原因应结合发生阶段、完整响应文本和增强状态码判断。同一个 550 可能涉及地址不存在、策略拒绝或其他问题；只有把原始服务端响应保留下来，才能避免让所有错误都变成一句“发送失败”。

参考

• RFC 5321：SMTP
• RFC 1939：POP3
• RFC 9051：IMAP4rev2
• RFC 8314：邮件提交与访问的 TLS 规范
• RFC 5322：邮件格式、RFC 2045：MIME
• RFC 7208：SPF、RFC 6376：DKIM、RFC 7489：DMARC
• Gmail 第三方客户端接入、邮件协议参数
• Gmail 发送限制、Google Workspace 发送限制
• Outlook.com 协议与认证设置
• Microsoft 邮件协议的 OAuth 接入
• 腾讯云 Email 连接器文档：QQ 邮箱配置示例
• Proton Mail 的 IMAP、SMTP 与 POP3 支持范围