SPF 与 DMARC 记录生成
SPF & DMARC Record Builder
按表单一步步生成合法的 SPF 和 DMARC TXT 记录，并逐条解释生成出来的每个机制。
生成 SPF、DMARC 和 DKIM 记录，把吞掉最多邮件的两个错误从结构上排除：SPF 查询次数是 include 旁边的实时数字，而不是事后的警告；没有报告地址的 DMARC reject 会被拒绝生成，而不是照样输出。每条记录都逐标签解释回来。
你自己的服务器
不花钱 —— 这些完全不消耗 DNS 查询。
替你发信的服务
大约用掉 5次，上限 10次其余所有
软失败把名单外的发信方标成可疑，但不拒收。在你还在摸清谁以你的名义发信时，这就是对的档位。
类型
TXT
名称 / 主机
example.com
值
v=spf1 mx include:_spf.google.com ~all
38个字符
查询都花在哪里
| 机制 | 查询数 |
|---|---|
| mx | 1 |
| include:_spf.google.com | 1 + 内部 3次 |
内部查询数是按这些服务商今天公布的内容估算的，随时可能变。想知道真实总数，只能在发布当时把每个 include 都展开一遍。
记录在这个页面里拼装和校验。不发布、不查询，用这个工具本身也不会把你正在配置的域名透露给任何人。
怎么用
列出每一个以你名义发信的服务
邮件服务商、通讯工具、客服系统、开票系统。最后那个没人记得，而收紧策略时坏掉的也是它。
边添加边看查询计数
SPF 允许十次 DNS 查询，每个 include 至少花一次，展开后往往要几次。超过就是永久错误，大多数收信方把它当作根本没有 SPF——一次无声的、彻底的失败。
DMARC 从 p=none 加报告地址开始
什么都不拦，每天的报告告诉你谁在以你的域名发信。等报告显示没有合法邮件失败了，再转到 quarantine，然后 reject——并用百分比滑块逐步推开。
作为 TXT 记录发布
名称和值按你的 DNS 服务商要的样子给出。DMARC 放在 _dmarc，DKIM 放在选择器下，SPF 放在域名本身——一个域名只能有一条 SPF 记录。
常见问题
会发布或查询什么吗？
都不会。记录在这个页面里拼装和检查。用这个工具不会向任何人透露你在配置的域名，对一个还没上线的域名来说这是有价值的。
能有两条 SPF 记录吗？
不能。两条 SPF 记录是永久错误，表现得和没有一样。把 include 合并进一条记录——合并后再看查询计数，因为合并正是域名越过上限的途径。
嵌套的查询计数准确吗？
不准确，它们是按各家服务商今天公布的内容估算的，服务商可以不通知任何人就改。唯一精确的答案是在你发布的那一刻把每个 include 展开一遍。
该打开严格对齐吗？
通常不该。严格对齐会弄坏一切从子域发信的东西——邮件列表、工单系统、大多数"以某地址发送"的集成。宽松是默认值，有充分的理由。
检查器说没问题，邮件还是失败
它检查的是记录的语法和查询预算。它没法告诉你记录里列出的发信方是不是实际在发你邮件的那些——只有发到你 rua 地址的汇总报告能做到。
可以从这些接进来
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
DNS 记录查询
DNS Lookup
通过 DoH 查询 A、AAAA、CNAME、MX、TXT、NS、SOA、SRV、CAA 和 PTR 记录，显示 TTL 和 DNSSEC 标志，解析器可选 Cloudflare 或 Google。
邮件头分析
Email Header Analyser
把原始邮件头整理成一条投递时间线并标出每一跳的延迟，读出接收服务器给的 SPF、DKIM、DMARC 判定，并点出 From、Reply-To、Return-Path 之间的不一致。
邮件收发配置检测
Mail Deliverability Check
把域名的 MX、SPF、DKIM 和 DMARC 记录放在一起查，并解释邮件会因为哪一条被拒收。
HTTP 请求调试
HTTP Request Builder
构造并发出带自定义请求头和请求体的 GET/POST/PUT/PATCH/DELETE/HEAD 请求，显示状态码、响应头、响应体和耗时，且从不转发 Cookie 和 Authorization。
HTTP 响应头检测
HTTP Header Inspector
请求一个网址，列出完整的响应头、跳转链路、各段耗时和实际用到的压缩方式。
IP 地址信息查询
IP Address Info
查你的公网 IP 或任意地址的反向域名、ASN、宣告网络、前缀和注册国家，数据来自 Team Cymru 的 DNS 服务，不提供城市级定位。