邮件通信领域的权威标准、可自由发布的官方指南，以及配套在线小工具——把"标准"变成"随手可用"。
仅收录美国政府公共领域（NIST/CISA/FBI）、IETF 自由再分发标准、CC/GPL 等开放协议释放的权威资料；商业版权书籍不在本专栏转载。当前共收录 171 份资料。
IETF 公共领域标准原文，覆盖传输、报文格式、MIME、客户端访问、身份认证与传输加密六大体系；每份英文全文均配套非官方中文译本。
IETF 邮件核心 RFC（26 份公共领域规范）全文汇编与阅读路线，覆盖传输、格式、访问、安全、认证、国际化与运维。
RFC 5321 Simple Mail Transfer Protocol 完整全文：定义邮件如何在互联网上从发送方传输到接收方，是现代电子邮件的传输基石。（IETF 公共领域）。
IETF RFC 5321《Simple Mail Transfer Protocol (SMTP)》非官方中文译本：定义邮件在 Internet 上的路由、传输与投递的核心协议（权威性以英文原文为准）。
RFC 5322 Internet Message Format 完整全文：定义电子邮件消息的语法与格式（信头、信体、地址规范），取代 RFC 2822。（IETF 公共领域）。
IETF RFC 5322《Internet Message Format》非官方中文译本：定义电子邮件报文头与主体的语法、地址与日期格式（权威性以英文原文为准）。
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies 完整全文：定义邮件信体如何携带非 ASCII 文本、附件与多媒体，是电子邮件超越纯文本、承载富媒体的基石。（IETF 公共领域）。
IETF RFC 2045《MIME Part One: Format of Internet Message Bodies》非官方中文译本：定义 Internet 报文主体的格式、Content-Type 与内容传输编码（权威性以英文原文为准）。
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 完整全文：定义 MIME 媒体类型（text/image/audio/application 等）与 multipart 结构，规范附件与复合信体的承载方式。（IETF 公共领域）。
IETF RFC 2046《MIME Part Two: Media Types》非官方中文译本：定义 multipart 等媒体类型结构，是 MIME 报文复合体的基础（权威性以英文原文为准）。
RFC 2047 MIME Part Three: Message Header Extensions for Non-ASCII Text 完整全文：规定信头中如何编码非 ASCII（如中文）的主题、姓名与注释（=?UTF-8?B?...?= 等形式），是解决中文邮件头乱码的根本规范。（IETF 公共领域）。
IETF RFC 2047《MIME Part Three: Message Header Extensions for Non-ASCII Text》非官方中文译本：定义报文头中非 ASCII 文本的 encoded-word 编码扩展（权威性以英文原文为准）。
RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations 完整全文：扩展 MIME 参数值的非 ASCII 编码、语言标注与多段续行，与 RFC 2045/2047 互补，支撑国际化附件文件名。（IETF 公共领域）。
IETF RFC 2231《MIME Parameter Value and Encoded Word Extensions》非官方中文译本：定义 MIME 参数值的字符集、语言与续行扩展（权威性以英文原文为准）。
RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 完整全文：定义 MIME 实现必须满足的一致性标准，并给出完整的复合报文示例与常见实现陷阱，是 MIME 五部曲的收官规范。（IETF 公共领域）。
IETF RFC 2049《MIME Part Five: Conformance Criteria and Examples》非官方中文译本：定义 MIME 实现的一致性标准与示例（权威性以英文原文为准）。
RFC 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 完整全文：定义客户端如何从服务器读取、检索、管理邮件（文件夹、搜索、状态、离线同步），是现代邮件客户端的核心访问协议。（IETF 公共领域）。
IETF RFC 3501《INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (IMAP4rev1)》非官方中文译本：定义远程邮箱的访问、检索与状态管理协议（权威性以英文原文为准）。
RFC 1939 Post Office Protocol - Version 3 完整全文：定义客户端如何最简单地下载服务器上的邮件，协议轻量，适合单设备取信后删除服务端副本。（IETF 公共领域）。
IETF RFC 1939《Post Office Protocol - Version 3 (POP3)》非官方中文译本：定义邮件服务器上邮箱的检索、下载与删除机制，是经典的邮件收取协议（权威性以英文原文为准）。
RFC 8620 The JSON Meta Application Protocol (JMAP) 完整全文：现代邮件访问协议，基于 HTTP/JSON，统一替代 IMAP/POP3 的复杂状态机，使客户端同步更简单、更高效、更易调试。（IETF 公共领域）。
IETF RFC 8620《The JSON Meta Application Protocol (JMAP)》非官方中文译本：定义邮件等数据的现代 JSON 同步访问协议（权威性以英文原文为准）。
RFC 8621 The JSON Meta Application Protocol (JMAP) for Mail 完整全文：JMAP 的邮件扩展，定义邮件/邮箱/搜索/提交的对象模型与操作方法，被视为 IMAP 的现代继任者。（IETF 公共领域）。
IETF RFC 8621《The JSON Meta Application Protocol (JMAP) Mail》非官方中文译本：定义 JMAP 的邮件数据模型与操作（权威性以英文原文为准）。
RFC 6186 Use of DNS SRV Records for Locating Email Submission/Access Services 完整全文：规定通过 _submission._tcp / _imap._tcp / _pop3._tcp 等 SRV 记录自动发现邮件提交与访问端点，简化客户端配置。（IETF 公共领域）。
IETF RFC 6186《Use of SRV Records for Locating Email Submission/Access Services》非官方中文译本：定义用 DNS SRV 记录定位邮件提交/访问服务（权威性以英文原文为准）。
RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email 完整全文：通过 DNS TXT 记录声明某域名授权哪些 IP 可代其发送邮件，防伪造。（IETF 公共领域）。
IETF RFC 7208《Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1》非官方中文译本：定义 ADMD 如何授权主机在「MAIL FROM」/「HELO」身份标识中使用其域名，以及接收方如何检查此类授权（权威性以英文原文为准）。
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures 完整全文：以数字签名验证邮件未被篡改且确由声明域名发出，是信任链核心。（IETF 公共领域）。
IETF RFC 6376《DomainKeys Identified Mail (DKIM) Signatures》非官方中文译本：定义基于域的邮件签名与验证机制，配套 DKIM 在线工具（权威性以英文原文为准）。
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 完整全文：在 SPF/DKIM 之上定义策略与反馈机制，指导接收方对未认证邮件的处理。（IETF 公共领域）。
IETF RFC 7489《Domain-based Message Authentication, Reporting, and Conformance (DMARC)》非官方中文译本：在 SPF/DKIM 之上定义策略、报告与一致性机制，指导接收方处置未认证邮件（权威性以英文原文为准）。
RFC 8617 Authenticated Received Chain (ARC) 完整全文：解决邮件经中转/转发后 DKIM/SPF 认证链断裂问题，保留认证的可追溯性。（IETF 公共领域）。
IETF RFC 8617《The Authenticated Received Chain (ARC)》非官方中文译本：在邮件转发场景下保护既有 SPF/DKIM/DMARC 认证结果（权威性以英文原文为准）。
RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling 完整全文：定义基于 X.509 证书的端到端邮件加密与签名，保障邮件机密性、完整性与不可否认性。（IETF 公共领域）。
IETF RFC 8551《Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4 Certificate Handling》非官方中文译本：定义 S/MIME v4 证书处理（权威性以英文原文为准）。
RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) 完整全文：以 DNSSEC + TLSA 记录锚定 SMTP 服务器的证书，抵御 STARTTLS 拦截与证书伪造，是 MTA-STS 的强安全补充。（IETF 公共领域）。
IETF RFC 7672《SMTP Security via Transport Layer Security (TLS)》非官方中文译本：定义基于 DNS 的 DANE 证书关联，保障 SMTP 传输层 TLS（权威性以英文原文为准）。
RFC 4422 Simple Authentication and Security Layer (SASL) 完整全文：定义通用的客户端-服务器认证与安全保障框架，是 SMTP/IMAP/POP3 接入认证的机制容器，承载 PLAIN/SCRAM 等具体机制。（IETF 公共领域）。
IETF RFC 4422《Simple Authentication and Security Layer (SASL)》非官方中文译本：定义面向连接协议的通用认证与安全层框架（权威性以英文原文为准）。
RFC 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism 完整全文：定义 SASL PLAIN 机制：以用户名+口令明文传输，须始终在 TLS 之上使用；与 SCRAM 互补，生产环境应避免无加密明文。（IETF 公共领域）。
IETF RFC 4616《The PLAIN Simple Authentication and Security Layer (SASL) Mechanism》非官方中文译本：定义以明文口令（经通道保护）进行认证的 SASL 机制（权威性以英文原文为准）。
RFC 5802 Salted Challenge Response Authentication Mechanism (SCRAM) 完整全文：现代 SASL 认证机制，提供口令加盐质询响应、防止明文口令泄露与重放攻击，优于 PLAIN/LOGIN。（IETF 公共领域）。
IETF RFC 5802《Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms》非官方中文译本：定义抗窃听的加盐质询响应认证机制（权威性以英文原文为准）。
RFC 6409 Message Submission for Mail 完整全文：定义邮件提交代理（MSA）如何通过 587 端口接收用户邮件并投递，是 SMTP 的配套标准。（IETF 公共领域）。
IETF RFC 6409《Message Submission for Mail》非官方中文译本：定义邮件客户端向邮件提交代理（MSA）提交信件的协议（权威性以英文原文为准）。
RFC 8461 SMTP MTA Strict Transport Security (MTA-STS) 完整全文：通过策略机制抵御 STARTTLS 剥离攻击，强制 SMTP 之间使用 TLS 加密传输。（IETF 公共领域）。
IETF RFC 8461《SMTP MTA Strict Transport Security (MTA-STS)》非官方中文译本：定义基于策略的 SMTP 强制 TLS 机制（权威性以英文原文为准）。
RFC 8460 SMTP TLS Reporting (TLS-RPT) 完整全文：提供 SMTP TLS 连接失败的可观测性与报告机制，与 MTA-STS 配套部署。（IETF 公共领域）。
IETF RFC 8460《SMTP TLS Reporting》非官方中文译本：定义接收方对 MTA 间 TLS 连接失败的标准化报告机制（权威性以英文原文为准）。
RFC 8314 Use of Transport Layer Security (TLS) for Email Submission and Access 完整全文：规定邮件提交（587/465）与访问（IMAP/POP3）应优先采用隐式 TLS（465/993/995）。（IETF 公共领域）。
IETF RFC 8314《Use of Transport Layer Security (TLS) for Email Submission and Access》非官方中文译本：建议邮件提交与访问（IMAP/POP3/Submission）使用隐式 TLS（权威性以英文原文为准）。
RFC 6531 SMTP Extension for Internationalized Email 完整全文：定义 SMTPUTF8 扩展，使邮件地址与信头支持 UTF-8 非 ASCII（如中文邮箱名），是邮件国际化（EAI）的传输基石。（IETF 公共领域）。
IETF RFC 6531《SMTP Extension for Internationalized Email》非官方中文译本：定义 SMTP 支持 UTF-8 邮箱地址与国际化报文（权威性以英文原文为准）。
RFC 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) 完整全文：更新 DKIM 对签名/密钥算法的强制与推荐要求，淘汰 SHA-1 等弱算法，规定 ed25519-sha256 等现代算法的使用约束。（IETF 公共领域）。
RFC 8301 更新 RFC 6376 的 DKIM 密码要求：签名方必须使用 rsa-sha256，验证方必须能验证 rsa-sha256，rsa-sha1 不得再用于签名或验证并被 IANA 标记为 historic；签名密钥必须至少 1024 位、应当至少 2048 位，验证方必须能处理 1024 至 4096 位密钥，且不得把小于 1024 位的 RSA 签名视为有效。使用历史算法或密钥过短的签名按 RFC 6376 第 3.9 节视为永久失败。
RFC 7817 Opportunistic Security: Some Protection Always 完整全文：提出「机会型安全」原则：在无法强制加密时，只要对端支持就主动协商 TLS，为邮件传输等场景的渐进式加密加固提供框架。（IETF 公共领域）。
RFC 7817 规定 SMTP 提交、IMAP、POP、ManageSieve 客户端如何校验 TLS 服务器身份：在证书路径验证通过后，按 RFC 6125 规则用用户邮件地址的域名部分或连接所用主机名作为参考标识进行匹配。客户端实现必须支持 DNS-ID，支持 RFC 6186 服务发现的还必须支持 SRV-ID；不得使用 URI-ID，CN-ID 仅为向后兼容而可选；通配符只能出现在最左侧名字组件且不匹配裸域。
RFC 4954 SMTP Service Extension for Authentication 完整全文：定义 SMTP 的 AUTH 扩展，支持 PLAIN/LOGIN/CRAM-MD5 等机制，是 587 提交端口身份认证的基础规范。（IETF 公共领域）。
RFC 4954 定义 SMTP AUTH 扩展，是 SASL 在 SMTP 上的剖面：AUTH 命令携带机制名与可选初始响应，服务端用 334 发挑战、客户端用 base64 回应、单个星号取消；成功回 235 2.7.0，凭据无效回 535 5.7.8，机制过弱回 534 5.7.9，需要认证回 530 5.7.0。会话内只允许成功认证一次，事务进行中不得发 AUTH，MAIL FROM 的 AUTH 参数用于跨跳传递已认证身份。
RFC 4409 Message Submission for Mail 完整全文：定义邮件提交协议（Submission，端口 587）与 SMTP 传输（端口 25）的职责分离，是 MSA 与 MTA 分界、提交认证的前提标准。（IETF 公共领域）。
RFC 6532 Internationalized Email Headers 完整全文：规定 UTF-8 国际化地址与信头在邮件报文中的编码与处理规则，与 RFC 6530/6531 共同构成 EAI 国际标准体系。（IETF 公共领域）。
RFC 6532 扩展 RFC 5322 与 MIME，允许在邮件地址和大多数头字段内容中直接使用 UTF-8，而无需 encoded-word 构造。它把 VCHAR、ctext、atext、qtext、text、dtext 扩展为可含非 ASCII UTF-8，使非结构化文本、原子、引用字符串与域名均可用 UTF-8；头字段名仍限 ASCII。行长上限由 998 字符改为 998 字节，规范化应当用 NFC 而不应当用 NFKC，并定义 message/global 媒体类型。此类邮件经 SMTP 传输需要 SMTPUTF8 扩展。
RFC 8601 Message Header Field for Indicating Message Authentication Status 完整全文：定义 Authentication-Results 信头，承载 SPF/DKIM/DMARC 等认证的判定结果与属性，是接收端传递与审计认证状态的事实标准；取代 RFC 7601。（IETF 公共领域）。
RFC 8601 定义 Authentication-Results 头字段，把 SPF、DKIM、DMARC、SMTP AUTH、iprev 等认证方法的结果以结构化形式记录在邮件中，供下游过滤器与用户代理使用。字段以认证服务标识（authserv-id）开头，随后是若干 method=result 与 ptype.property=value 三元组；DKIM 结果集为 none/pass/fail/policy/neutral/temperror/permerror。它废止 RFC 7601，并强调信任边界内必须删除外来的同名头字段以防伪造。
RFC 5598 Internet Mail Architecture 完整全文：以组件图形式刻画邮件系统的完整拓扑：MUA/MSA/MTA/MDA/邮箱与 DNS，界定各角色的协议边界与信任关系，是理解全部邮件标准的导航地图（Informational）。（IETF 公共领域）。
RFC 5598 为互联网邮件建立统一的架构术语与参考模型，把参与者分为用户、消息处理服务（MHS）与管理域（ADMD）三类。用户角色包括作者、收件人、退回处理者与中介；MHS 组件包括 MUA、MSA、MTA、MDA 与 MS；ADMD 用于界定运营与信任边界。文档还区分了信封与信头两套标识、说明了各标识的用途，并系统讨论邮件列表等中介的重投递行为，是理解 SPF/DKIM/DMARC 对齐关系的共同语言基础。
RFC 9051 Internet Message Access Protocol (IMAP) - Version 4rev2 完整全文：现代 IMAP 客户端访问协议标准，整合此前分散的扩展并取代 RFC 3501，统一了邮箱访问、搜索、推送与元数据操作（Standards Track，取代 3501）。（IETF 公共领域）。
RFC 9208 IMAP QUOTA Extension 完整全文：为 IMAP 定义 QUOTA 扩展（RFC 2087 修订），使客户端可查询与设置邮箱/邮箱存储的配额上限与使用量，是邮箱容量治理的标准机制（Standards Track，取代 2087）。（IETF 公共领域）。
RFC 2595 Using TLS with IMAP, POP3 and ACAP 完整全文：规定 IMAP/POP3/ACAP 在明文端口上通过 STARTTLS 命令协商 TLS 加密的标准流程，是现代邮箱客户端安全连接的基石（Standards Track，被 8314 扩展）。（IETF 公共领域）。
RFC 2449 POP3 Extension Mechanism 完整全文：定义 POP3 的标准扩展框架（能力声明 CAPA、扩展注册流程），统一了 POP3 服务器能力协商的机制，是 POP3 生态扩展的基础（Standards Track）。（IETF 公共领域）。
RFC 5034 The POP3 SASL Authentication Mechanism 完整全文：为 POP3 增加 SASL 认证扩展（AUTH 命令），使 POP3 客户端可使用 PLAIN/CRAM-MD5/DIGEST-MD5 等 SASL 机制完成安全认证，取代过时的 APOP（Standards Track，取代 1734）。（IETF 公共领域）。
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security 完整全文：定义 SMTP 的 STARTTLS 扩展，允许在明文端口 25 上协商升级到 TLS 加密通道，是邮件传输层防窃听与中间人攻击的基石（Standards Track）。（IETF 公共领域）。
RFC 3207 定义 SMTP 的 STARTTLS 扩展：客户端发出 STARTTLS 后服务端回 220 就绪、501 语法错误或 454 暂时不可用；握手成功后双方必须丢弃此前协商状态并重新发送 EHLO。公开引用的 MX 服务器不得强制要求 STARTTLS 才收本域邮件；使用流水线时 STARTTLS 必须是分组内最后一条命令；剥离 250 STARTTLS 通告的降级攻击需靠强制策略配置防御。
RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field 完整全文：定义 Content-Disposition 信头，指示接收方如何呈现邮件附件（inline 内联 / attachment 附件、文件名提示），是 MIME 报文结构的关键组成（Standards Track）。（IETF 公共领域）。
RFC 2183 定义 MIME 的 Content-Disposition 头字段，用于向接收方表达“这个 MIME 体应当如何呈现/处置”（内联显示或作为附件保存），而不是 MIME 既有头字段所表达的“这是什么类型”。处置类型有 inline、attachment 与扩展类型；参数含 filename、creation-date、modification-date、read-date、size。未识别的处置类型按 attachment 处理，filename 存在跨平台安全陷阱。
RFC 3156 MIME Security with OpenPGP 完整全文：规定如何在 MIME 报文中封装 OpenPGP 加密与签名数据，使邮件端到端加密可与标准邮件客户端无缝集成，是 S/MIME 之外另一条端到端加密报文路线（Standards Track，取代 2015）。（IETF 公共领域）。
RFC 1870 定义 SMTP 的 SIZE 服务扩展：服务端在 EHLO 响应中以 SIZE 关键字通告自身可接受的最大消息字节数（可选），客户端在 MAIL FROM 后用 SIZE= 参数预先告知本封邮件的总八位组数。服务端据此可在接收内容之前就判断是否超限，超限以 552（永久失败）拒绝、本地存储不足以 452（临时失败）拒绝。SIZE 值是 octets（含 CR-LF 不含终止点），为零表示未约定上限。
RFC 2920 定义 SMTP 的 PIPELINING 服务扩展：客户端在收到服务端对前一条命令的应答之前，即可连续发出多条命令组成“命令流水线”，从而减少往返时延。可成组批送的是 RSET 和 MAIL/SEND/SOML/SAML FROM 与 RCPT TO；EHLO/DATA/VRFY/EXPN/TURN/QUIT/NOOP 只能作为流水线中的最后一条。服务端必须按接收顺序逐条应答，且不得冲刷（flush）TCP 输入缓冲，以防拒绝服务。
RFC 8689 定义 SMTP 的 REQUIRETLS 服务扩展：服务端在 EHLO 中通告 REQUIRETLS，发件方在 MAIL FROM 上使用 REQUIRETLS 参数，要求本封邮件全程必须经 TLS 保护、且对端证书须通过 DNSSEC/DANE 或 MTA-STS 校验。相关状态码为 X.7.30（因策略要求 TLS 而失败）与 5.7.10（因缺少 TLS 被拒）；退信（DSN/MDN）若源自 REQUIRETLS 邮件也须带 REQUIRETLS。信件中可加 TLS-Required: No 头字段表达“本域允许降级”。
RFC 7435 提出“机会性安全（Opportunistic Security，OS）”的设计哲学：以明文（未认证、未加密）作为基线，在连接双方都具备能力时协商加密与身份认证，从而把“完全无保护”提升为“大多数时候有保护”。它区分已认证加密与未认证加密，并强调机会性安全不排斥显式安全策略，而是填补策略未覆盖处的保护空白。以 SMTP 机会性 TLS 为典型示例。
核心协议之外、真实运维中高频遭遇却中文资料稀缺的标准：Authentication-Results 认证结果头、ARF 滥用反馈、一键退订、DSN 退信与增强状态码、Null MX、灰名单与角色邮箱约定。
RFC 7601 Message Header Field for Indicating Message Authentication Status 完整全文：定义 Authentication-Results 信头字段，用于记录 SPF/DKIM/DMARC 等认证的执行结果，是接收端认证信息传递与排障的事实标准。（IETF 公共领域）。
IETF RFC 7601《Message Header Field for Indicating Message Authentication Status》非官方中文译本：定义 Authentication-Results 信头，承载 SPF/DKIM/DMARC 等认证结果的传递（权威性以英文原文为准）。
RFC 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows 完整全文：系统梳理邮件列表、转发、自动回复等间接投递场景下 DMARC 失效的成因与缓解方案，是部署 p=reject 前必读的风险清单。（IETF 公共领域）。
IETF RFC 7960《Interoperability Advice for DOMAIN-Based Message Authentication》非官方中文译本：面向 DMARC 部署的发送方/接收方互操作建议与故障排查（权威性以英文原文为准）。
RFC 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists 完整全文：说明邮件列表管理器如何在改写主题、追加页脚时避免破坏 DKIM 签名，给出列表运营方与签名方的双向最佳实践（BCP 167）。（IETF 公共领域）。
IETF RFC 6377《DomainKeys Identified Mail (DKIM) and Mailing Lists》非官方中文译本：分析 DKIM 签名在邮件列表转发场景下的挑战与缓解方案（权威性以英文原文为准）。
RFC 5965 An Extensible Format for Email Feedback Reports 完整全文：定义 ARF（Abuse Reporting Format）滥用报告格式，是 ISP 向发送方回传「用户举报为垃圾邮件」的标准载体，反馈回路（FBL）的基础。（IETF 公共领域）。
IETF RFC 5965《An Extensible Format for Email Feedback Reports》非官方中文译本：定义滥用报告格式（ARF）的反馈报告容器，是退信/回执/反滥用报告的基础（权威性以英文原文为准）。
RFC 6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) 完整全文：规定 ARF 报告在真实运营中的生成、传输与消费方式，界定报告方与接收方的责任边界，避免反馈回路被滥用或造成隐私泄露。（IETF 公共领域）。
IETF RFC 6650《Creation and Use of Email Feedback Reports: An Application of the Abuse Reporting Format (ARF)》非官方中文译本：规范 abuse / fraud / other 等反馈报告类型的创建与使用（权威性以英文原文为准）。
RFC 6591 Authentication Failure Reporting Using the Abuse Reporting Format 完整全文：定义 auth-failure 类型的 ARF 报告，用于回传 SPF/DKIM/DMARC 认证失败详情，是 DMARC 失败报告（ruf）的格式依据。（IETF 公共领域）。
IETF RFC 6591《Authentication Failure Reporting Using the Abuse Reporting Format (ARF)》非官方中文译本：定义 ARF 的 auth-failure 报告类型，用于上报 SPF/DKIM/DMARC 等认证失败（权威性以英文原文为准）。
RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields 完整全文：定义 List-Help、List-Unsubscribe、List-Subscribe 等信头字段，让邮件客户端可直接呈现订阅管理入口，是群发合规的基础规范。（IETF 公共领域）。
IETF RFC 2369《The Use of URLs as Meta-Syntax for Core Mail List Commands》非官方中文译本：定义 List-Help、List-Unsubscribe、List-Post 等信头，是群发邮件合规与订阅管理的基础规范（权威性以英文原文为准）。
RFC 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists 完整全文：定义 List-Id 信头，为每个邮件列表提供稳定唯一的标识符，便于客户端过滤归档与服务端识别列表流量。（IETF 公共领域）。
IETF RFC 2919《List-Id: A Structured Field and Namespace for the Identification of Mailing Lists》非官方中文译本：定义邮件列表的稳定唯一标识符与命名空间（权威性以英文原文为准）。
RFC 8058 Signaling One-Click Functionality for List Email Headers 完整全文：定义 List-Unsubscribe-Post 信头实现「一键退订」，是 Gmail、Yahoo 自 2024 年起对批量发件人的强制合规要求，直接影响送达率。（IETF 公共领域）。
IETF RFC 8058《Signaling One-Click Functionality for List Email Headers》非官方中文译本：定义 List-Unsubscribe-Post 信头实现一键退订，是 Gmail、Yahoo 对批量发件人的强制合规要求（权威性以英文原文为准）。
RFC 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) 完整全文：定义 SMTP 的 DSN 扩展，允许发送方请求投递成功/失败/延迟通知并控制通知内容，是退信机制的协议起点。（IETF 公共领域）。
IETF RFC 3461《SMTP Service Extension for Delivery Status Notifications (DSNs)》非官方中文译本：定义让 SMTP 能生成投递状态通知（DSN）的服务扩展（权威性以英文原文为准）。
RFC 3463 Enhanced Mail System Status Codes 完整全文：定义 X.Y.Z 三段式增强状态码（如 5.7.1 拒绝、4.2.2 邮箱满），比三位数 SMTP 回复码更精确，是退信原因诊断的核心字典。（IETF 公共领域）。
IETF RFC 3463《Enhanced Mail System Status Codes》非官方中文译本：定义 X.Y.Z 三段式增强状态码（如 5.7.1、4.2.2），是退信原因精确诊断的核心字典（权威性以英文原文为准）。
RFC 3464 An Extensible Message Format for Delivery Status Notifications 完整全文：定义 message/delivery-status 媒体类型与退信报文结构，规范退信中原始收件人、动作、状态码与诊断信息的机器可读表达。（IETF 公共领域）。
IETF RFC 3464《An Extensible Message Format for Delivery Status Notifications (DSNs)》非官方中文译本：定义 DSN 报文的可扩展格式，是退信诊断的权威依据（权威性以英文原文为准）。
RFC 6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages 完整全文：定义 multipart/report 容器格式，是退信（DSN）、已读回执（MDN）、滥用报告（ARF）等所有邮件系统管理类报文的统一外壳。（IETF 公共领域）。
IETF RFC 6522《The Multipart/Report Media Type》非官方中文译本：定义退信（DSN）、已读回执（MDN）与滥用报告（ARF）共用的报告容器格式（权威性以英文原文为准）。
RFC 8098 Message Disposition Notification 完整全文：定义已读回执机制与 message/disposition-notification 格式，规范 Disposition-Notification-To 请求与隐私保护要求。（IETF 公共领域）。
IETF RFC 8098《Message Disposition Notification》非官方中文译本：定义已读/处置回执（MDN）的格式与生成规则（权威性以英文原文为准）。
RFC 2142 Mailbox Names for Common Services, Roles and Functions 完整全文：规定 postmaster、abuse、security、hostmaster 等角色邮箱的强制与推荐约定，是域名可联系性与滥用处置能力的基本要求。（IETF 公共领域）。
IETF RFC 2142《Mailbox Names for Common Services, Roles and Functions》非官方中文译本：规定 postmaster、abuse、security 等角色邮箱约定，是域名可联系性与滥用处置的基本要求（权威性以英文原文为准）。
RFC 7505 A
IETF RFC 7505《A
RFC 6647 Email Greylisting: An Applicability Statement for SMTP 完整全文：系统说明灰名单（Greylisting）反垃圾技术的原理、副作用与部署建议，权衡拦截效果与合法邮件延迟的取舍。（IETF 公共领域）。
IETF RFC 6647《Email Greylisting: An Applicability Statement for SMTP》非官方中文译本：将灰名单机制作为反垃圾邮件手段的应用指引与运维建议（权威性以英文原文为准）。
RFC 5068 Email Submission Operations: Access and Accountability Requirements 完整全文：面向 ISP 与企业给出邮件提交环节的接入控制与可问责性要求（BCP 134），包括 587 端口认证提交、25 端口出站管控等反滥用实践。（IETF 公共领域）。
IETF RFC 5068（BCP 134）《Email Submission Operations: Access and Accountability Requirements》非官方中文译本：587 端口认证提交、25 端口出站管控等反滥用运营要求（权威性以英文原文为准）。
RFC 6530 Overview and Framework for Internationalized Email 完整全文：给出国际化邮件（EAI）的整体架构与术语框架，说明 UTF-8 邮箱地址与信头如何贯通传输、投递与访问各环节。（IETF 公共领域）。
IETF RFC 6530《Overview and Framework for Internationalized Email》非官方中文译本：定义国际化电子邮件（EAI）的综述、框架与术语，支持 UTF-8 邮箱地址（权威性以英文原文为准）。
RFC 8616 Email Authentication for Internationalized Mail 完整全文：规定 SPF、DKIM、DMARC、ARC 在处理 UTF-8 国际化域名与地址时的规范化与比较规则，避免国际化场景下认证误判。（IETF 公共领域）。
IETF RFC 8616《Email Authentication for Internationalized Mail》非官方中文译本：规定 SPF、DKIM、DMARC、ARC 处理 UTF-8 国际化地址与域名时的规范化与比较规则（权威性以英文原文为准）。
RFC 6533 Internationalized Delivery Status and Disposition Notifications 完整全文：将投递状态通知（DSN）与已读回执（MDN）扩展到 UTF-8 国际化地址场景，与 RFC 6530/6531/6532 共同补全 EAI 国际化的状态回报闭环（Standards Track，取代 5337）。（IETF 公共领域）。
RFC 7258 Pervasive Monitoring Is an Attack 完整全文：确立 IETF 工程立场：大规模的被动监控本身就是对互联网的攻击，协议设计应默认提供抗监控能力；是邮件传输加密（STARTTLS/DANE/MTA-STS）的根本动因（Best Current Practice）。（IETF 公共领域）。
RFC 7372 Email Authentication Status Codes 完整全文：定义 X.7.20–X.7.26 等 SMTP 增强状态码，精确表达 SPF/DKIM/DMARC 认证失败原因，是认证失败退信与排障的机器可读字典（Standards Track，与 8601/7489 配套）。（IETF 公共领域）。
RFC 7372 注册了一组用于精确表达“因邮件认证失败而拒收或延迟”的增强状态码：X.7.20 无通过的 DKIM 签名、X.7.21 无可接受的 DKIM 签名、X.7.22 无与作者地址匹配的 DKIM 签名、X.7.23 SPF 校验失败、X.7.24 SPF 校验出错、X.7.25 反向 DNS 校验失败、X.7.26 多项认证同时失败。它更新 RFC 7208，取代其原先推荐的 5.7.1、4.4.3、5.5.2 用法。
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages 完整全文：定义 multipart/report 容器格式，是退信（DSN）、滥用报告（ARF）、已读回执（MDN）等所有邮件系统管理类报文的统一外壳（Standards Track）。（IETF 公共领域）。
RFC 8996 Deprecating TLS 1.0 and TLS 1.1 完整全文：建议所有应用（含 SMTP/IMAP/POP3 的 TLS 加密）停用不安全的 TLS 1.0/1.1，强制 TLS 1.2+，是邮件传输加密合规升级的官方指引（Best Current Practice）。（IETF 公共领域）。
RFC 8996 正式废止 TLS 1.0 与 TLS 1.1 并将其转为历史状态，同时废止 DTLS 1.0（DTLS 1.2 不受影响）。这两个版本缺乏对当前推荐密码算法与机制的支持，且强依赖 SHA-1 与 MD5：TLS 1.0/1.1 的 PRF 和数字签名结构无法与对端协商更强的哈希。规范要求实现不再协商这两个版本，客户端不得发送、服务端不得选择低于 TLS 1.2 的版本，并相应更新 RFC 7525。
RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages 完整全文：定义 CHUNKING 与 BINARYMIME 扩展，使 SMTP 能可靠传输 8 位二进制与超长 MIME 报文而无须 Base64 转码损耗（Standards Track）。（IETF 公共领域）。
RFC 3030 定义 SMTP 的两个服务扩展：CHUNKING 引入 BDAT 动词以二进制分块方式上传邮件，避开 DATA 阶段对“单独一行的点”转义的需求；BINARYMIME 在配合 CHUNKING 时允许邮件正文包含任意二进制（超长行、NUL 等）而无需编码。BDAT 后跟块大小与可选的 LAST 标记，DATA 与 BDAT 不可在同一事务中混用。CHUNKING 被 MIME 头 BINARY 与消息体结构引用。
RFC 6152 SMTP Service Extension for 8bit-MIMEtransport 完整全文：定义 8BITMIME 扩展，允许 SMTP 直接传输 8 位 MIME 内容（如含非 ASCII 字节的报文）而无需 7 位编码，是国际化邮件传输的前置能力（Standards Track）。（IETF 公共领域）。
RFC 6152 定义 SMTP 的 8BITMIME 服务扩展：服务端在 EHLO 中通告 8BITMIME 后，客户端可用 MAIL FROM 的 BODY=8BITMIME 参数表示正文含有 8 位字节（高位不清除）。服务端必须保留每个字节的全部 8 位，但在 8BITMIME 模式下行长仍受 1000 octet 限制，且不提供任意二进制传输能力。BODY 取值为 7BIT 或 8BITMIME，缺省为 7BIT。
RFC 5228 Sieve: An Email Filtering Language 完整全文：定义 Sieve 过滤语言——用于在邮件投递阶段按规则自动筛选、分发、拒绝与自动回复邮件的声明式脚本语言，是服务器端邮件过滤的事实标准（Standards Track）。（IETF 公共领域）。
RFC 5228 定义 Sieve，一种运行在邮件服务器端的邮件过滤脚本语言。它是非图灵完备的（无循环、无变量），以“测试（test）+ 动作（action）”的方式描述规则，控制结构为 if/elsif/else、require、stop。内置测试涵盖 address、allof、anyof、exists、false、header、not、size、true、envelope；匹配关键字 :is/:contains/:matches 与比较器 i;octet/i;ascii-casemap。未命中任何动作时执行隐式 keep。
RFC 3834 给出自动邮件响应（如外出回复、阅后回执）的规范化建议。它区分服务类（Service）、个人类（Personal）与群组类（Group）响应者三类，要求响应者不得盲目回复每一封来信，而应通过 Auto-Submitted 头字段识别机器生成的邮件以避免回环；运输层级的响应（退信/已读回执）应使用 DSN/MDN 机制而非普通邮件回复。还规定了响应应当指向原发件人、附带原始信头、并对主题与频率加以约束。
RFC 6068 规定 mailto: URI 的语法与语义，用于在网页/文档中以统一方式表达“发邮件给谁、附带什么”。其 ABNF 为 mailtoURI =
RFC 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates 完整全文：规定 TLS 证书中「域名身份」的表示与校验规则，是邮件服务器校验对端证书、抵御伪造证书中间人攻击的 PKIX 地基（Standards Track）。（IETF 公共领域）。
RFC 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance 完整全文：对 DANE/TLSA 的更新与运维指导，澄清证书绑定、信誉与降级处理，使邮件系统可稳健部署 DANE 以加固传输加密（Standards Track，Updates 6698）。（IETF 公共领域）。
RFC 7671 基于实现经验澄清并更新 RFC 6698 的 DANE TLSA 规范：要求客户端至少支持 TLS 1.0 与 SNI；不推荐应用同时支持全部四种证书用法，建议只支持 DANE-EE(3) 与 DANE-TA(2)；DANE-EE(3) 的身份匹配与有效期判定仅依据 TLSA 记录本身；发布 DANE-TA(2) 摘要记录的服务器必须在证书链中带上该 TA 证书。文档还给出密钥轮换、CNAME 展开与摘要算法敏捷性的操作规程。
RFC 4314 IMAP4 Access Control List (ACL) Extension 完整全文：定义 IMAP 的 ACL 扩展，使服务器可精细控制用户对邮箱的访问权限（读/写/删除/管理），是多租户邮箱与共享文件夹的权限基础（Standards Track）。（IETF 公共领域）。
RFC 4315 Internet Message Access Protocol (IMAP) - UIDPLUS Extension 完整全文：定义 UIDPLUS 扩展（APPENDUID/COPYUID/UID EXPUNGE），使客户端在 APPEND/COPY 后获知服务端分配的 UID，避免重复同步，是离线客户端可靠同步的基础（Standards Track）。（IETF 公共领域）。
RFC 4551 The IMAP CONDSTORE Extension 完整全文：定义 CONDSTORE 扩展，使客户端可仅获取自某修改序列号以来的变更，是 QRESYNC 快速重同步的前置标准（Standards Track）。（IETF 公共领域）。
RFC 4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned 完整全文：定义 ESEARCH 扩展，使 SEARCH 命令可返回 UID 集合或节省带宽的计数/最小最大结果，是大规模邮箱高效搜索的基础（Standards Track）。（IETF 公共领域）。
RFC 5256 Internet Message Access Protocol - SORT and THREAD Extensions 完整全文：定义 SORT 与 THREAD 扩展，使服务器可代为按日期/发件人/主题等排序或按会话线索分组，减轻客户端计算负担，是邮件列表与搜索体验的关键（Standards Track）。（IETF 公共领域）。
邮件安全与投递的地基：域名系统（DNS）的查询与记录规范、DNSSEC 为解析提供完整性保护、DANE 把 TLS 证书绑定到域名、DoT/DoH 为解析链路提供加密传输。缺了它们，SPF/DKIM/DMARC 无从谈起。
RFC 1034 Domain Names - Concepts and Facilities 完整全文：定义 DNS 的域名空间、资源记录、解析器与缓存等核心概念，是理解 MX/SPF/TXT 等邮件相关记录的前提性基础规范。（IETF 公共领域）。
IETF RFC 1034《DOMAIN NAMES - CONCEPTS AND FACILITIES》非官方中文译本：DNS 体系的总纲性文档（STD 13 第一部分），定义域名空间、解析器/名称服务器模型与委派机制，是理解邮件路由与 SPF/DKIM/DMARC 所依赖 DNS 的根基（权威性以英文原文为准）。
RFC 1035 Domain Names - Implementation and Specification 完整全文：规定 DNS 报文格式、区域文件语法与各类资源记录（A/MX/TXT/NS 等）的 wire 编码，是域名解析实现的权威规范。（IETF 公共领域）。
IETF RFC 1035《DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION》非官方中文译本：DNS 协议与实现的权威规范（STD 13 第二部分），定义报文格式、资源记录、区域文件语法与解析算法，是邮件基础设施（MX 记录解析、发件方认证查询）的底层依据（权威性以英文原文为准）。
RFC 4033 DNS Security Introduction and Requirements 完整全文：给出 DNSSEC 的威胁模型、安全目标与部署要求，说明公钥密码如何为 DNS 应答提供来源真实性与完整性保护。（IETF 公共领域）。
IETF RFC 4033《DNS Security Introduction and Requirements》非官方中文译本：DNSSEC 系列三篇之首，说明 DNS 安全扩展能/不能提供什么、威胁模型与设计需求，是邮件安全（SPF/DKIM/DMARC 之外的信道完整性）的基础（权威性以英文原文为准）。
RFC 4034 Resource Records for the DNS Security Extensions 完整全文：定义 DNSSEC 引入的 RRSIG、DNSKEY、DS、NSEC、NSEC3 等资源记录的类型、字段与语义，是签名验证的数据结构基础。（IETF 公共领域）。
IETF RFC 4034《Resource Records for the DNS Security Extensions》非官方中文译本：定义 DNSSEC 新增的 DNSKEY/RRSIG/NSEC/DS 资源记录格式与用途，是 DNS 数据签名验证的标准依据（权威性以英文原文为准）。
RFC 4035 Protocol Modifications for the DNS Security Extensions 完整全文：规定验证解析器如何处理 DNSSEC 签名、信任锚配置与 SERVFAIL 处理，描述从根到叶的信任链验证流程。（IETF 公共领域）。
IETF RFC 4035《Protocol Modifications for the DNS Security Extensions》非官方中文译本：DNSSEC 三部曲之三，规定 DNSSEC 对 DNS 协议的具体修改（签名验证、区签名、缓存与解析算法、安全服务），与 4033/4034 共同构成 DNSSEC 完整规范（权威性以英文原文为准）。
RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA 完整全文：定义 TLSA 资源记录，将 TLS 证书/公钥绑定到域名，使邮件服务器可在无 CA 信任的情况下验证对端证书，是 MTA-STS/DANE 加固传输加密的关键。（IETF 公共领域）。
IETF RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》非官方中文译本：定义 TLSA 资源记录，将 TLS 证书/公钥绑定到域名，是邮件传输加密加固（DANE for SMTP）的基础（权威性以英文原文为准）。
RFC 7858 Specification for DNS over TLS (DoT) 完整全文：规定 DNS 查询经 TLS 加密传输的协议，防止 DNS 查询被窃听与篡改，是解析链路隐私保护的基础标准。（IETF 公共领域）。
IETF RFC 7858《Specification for DNS over TLS (DoT)》非官方中文译本：规定 DNS 查询经 TLS 加密传输的协议，防止 DNS 查询被窃听与篡改，是解析链路隐私保护的基础标准（权威性以英文原文为准）。
RFC 8484 DNS Queries over HTTPS (DoH) 完整全文：定义通过 HTTPS 承载 DNS 查询的协议，将解析流量伪装为普通 Web 流量以规避封锁与中间人，对解析隐私与可达性影响深远。（IETF 公共领域）。
IETF RFC 8484《DNS Queries over HTTPS (DoH)》非官方中文译本：定义通过 HTTPS 承载 DNS 查询的协议，将解析流量伪装为普通 Web 流量以规避封锁与中间人（权威性以英文原文为准）。
美国联邦政府作品，属公共领域可自由转载：NIST 可信邮件与认证指南、CISA 邮件与 Web 安全强化行动、反钓鱼联合指南，以及 FBI IC3 的 BEC 损失情报。
NIST SP 800-177 Rev.1 Trustworthy Email 完整全文：SPF/DKIM/DMARC/TLS/DANE/S-MIME 企业邮件信任体系（美国政府公共领域）。
NIST SP 800-45 Rev.2 Guidelines on Electronic Mail Security 完整全文：邮件系统设计与运维、加固、隔离与应急响应（美国政府公共领域）。
NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management 完整全文：口令、多因子认证（MFA）、防钓鱼与认证器生命周期管理（美国政府公共领域）。
CISA Insights: Enhance Email & Web Security 完整全文：SPF/DKIM/DMARC 与 HTTPS/HSTS 的近期落地动作，源自 BOD 18-01（美国政府公共领域）。
美国网络安全和基础设施安全局（CISA）《CISA Insights: Enhance Email & Web Security》非官方中文译本：以 DMARC、STARTTLS、HTTPS、HSTS 为核心的邮件与 Web 安全强化行动指引（权威性以英文原文为准）。
CISA Domain-Based Message Authentication, Reporting and Conformance (DMARC) for Healthcare Organizations 完整全文：医疗行业 DMARC 落地（美国政府公共领域）。
美国网络安全和基础设施安全局（CISA）《Enhance Email & Web Security: DMARC for Healthcare Delivery Organizations》非官方中文译本：面向医疗行业的 DMARC 部署路径、常见障碍与分阶段推进建议（权威性以英文原文为准）。
美国 CISA、NSA、FBI、MS-ISAC 联合发布的反钓鱼权威指南全文：凭据钓鱼与恶意软件钓鱼的缓解措施、事件响应与报告（美国政府公共领域）。
CISA 联合 NSA、FBI、MS-ISAC 发布的《Phishing Guidance: Stopping the Attack Cycle at Phase One》非官方中文译本：钓鱼获取凭据与投递恶意软件两类攻击路径的成因、缓解措施与中小组织落地建议（权威性以英文原文为准）。
美国 FBI 互联网犯罪投诉中心（IC3）关于商业邮件欺诈（BEC）的权威公告全文：定义、统计（2013–2023 全球暴露损失 554 亿美元）、防护与报告建议（美国政府公共领域）。
美国联邦调查局互联网犯罪投诉中心（IC3）公共服务公告《Business Email Compromise: The $55 Billion Scam》非官方中文译本：BEC 攻击手法演变、损失统计与企业防护建议（权威性以英文原文为准）。
以 CC BY-SA、GFDL 等自由协议发布、允许再分发的社区权威资料。
工具全部在浏览器端运行，输入的域名/邮件头不会上传到我们服务器；DNS 查询经 Cloudflare / Google 公共 DoH 完成。