邮件头分析器
展开 RFC 5322 续行，提取 From/To/Subject/Date/Message-ID，解析每条 Received 行（按时间反序）并计算相邻跳之间的实际延迟，从 Authentication-Results 中提取 spf/dkim/dmarc 的结果。适用于诊断邮件为何被归入垃圾箱、发现伪造的 Received 链、定位是哪个 MTA 引入了延迟。
—
- 发件人"Alice Sender" <alice@example.com>
- 收件人user@recipient.com
- 主题Hello there
- 日期Mon, 02 Jun 2026 09:15:38 +0000
- Message-ID<abc123@example.com>
认证
SPFpassDKIMpassDMARCpass
跳数（最旧 → 最新）
- #1from sender-host.example.com → by mail.example.comMon, 02 Jun 2026 09:15:40 +0000 (UTC)
- #2+2sfrom mail.example.com → by mx.recipient.comMon, 02 Jun 2026 09:15:42 +0000 (UTC)
全部在本地处理 — 邮件头不会离开你的浏览器。
使用方法
- 粘贴完整的原始邮件头（在分隔头与正文的空行之前的所有内容）。
- 查看元数据块、认证徽章与跳列表。
常见问题
- 原始邮件头从哪里获取？
- Gmail：消息的 ⋮ 菜单 →「显示原始邮件」。Outlook：文件 → 属性 → Internet 邮件头。大多数其他客户端也有「查看源代码」或「显示原始」选项。
- 为什么跳数有时显示负延迟？
- 服务器时钟之间常有几秒差异，且部分 MTA 会回填 Received 行。轻微负值正常；大幅负值（或缺失跳）可能暗示头部被伪造。
- Received 链条能信到什么程度?
- 只能信由你自己掌控的设施添加的那部分。每台服务器在收下邮件时会把自己的一行加在最前面，因此位于你第一个可信跳点之上的内容，都是你并不运维的机器写的，完全可以被伪造。请从自己这一端往外读，把最早的那些跳点当作说法，而不是证据。
- 邮件通过了 SPF，却明显是垃圾邮件，怎么会这样?
- SPF 校验的是信封发件人的域名与发送服务器地址是否匹配，而这个域名不必是读者看到的那个。发送方完全可以用自己拥有的域名通过 SPF，同时在界面上显示一个冒充他人的 From 地址。DMARC 的存在正是为了要求可见的 From 与 SPF 或 DKIM 真正认证过的东西保持一致。
相关工具
SPF 记录构建器
由机制、IP 和 include 构建 Sender Policy Framework TXT 记录 —— 带实时 DNS 查询计数和警告。
网络 0 0
TXT 记录拆分器（255 字节块）
把长 SPF、DKIM 或 DMARC TXT 记录拆分为 DNS 协议要求的 255 字节块 —— 输出 BIND、通用 zone 文件、Cloudflare 或 Route 53 语法。
网络 0 0
DKIM 记录构建器 & 解析器
构建或解析 DKIM（DomainKeys Identified Mail）DNS TXT 记录 —— 粘贴公钥、选择 selector / 密钥类型（RSA/Ed25519）/ 哈希 / 标志，即可得到完整记录、`selector._domainkey` 主机名，以及超过 255 字符时的 DNS 分段版本。
网络 0 0
DMARC 记录构建器
构建 `_dmarc` TXT 记录 —— 策略、子域策略、百分比逐步推出、对齐、rua/ruf 报告 —— 带安全警告。
网络 0 0
mailto: 链接构建器
构建包含收件人、抄送、密送、主题和正文的 mailto: URL — 按 RFC 6068 进行百分号编码,可直接放入 <a> 标签。
网络 0 0
Cache-Control 头构建器
通过可视化清单构建 HTTP Cache-Control 头 — 新鲜度、再验证、不可变性以及常用预设。
网络 0 0