DNS表单的长度错误可能涉及多种不同的限制。长TXT值、单个名称标签和整个DNS名称的测量方式不同。缩短一个 DKIM 钥匙或拆分一把 SPF 将策略分成单独的记录可能会将输入问题转变为身份验证失败。
识别哪个物体太长
参考： RFC 1035 §2.3.4, RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 2181 §11.
RFC 1035将DNS标签限制为 63 个八位字节，将完整有线格式名称限制为 255 个八位字节，包括其长度字段和终止根标签。表示标点符号和 Unicode 输入可能会掩盖这些测量结果。计算编码的DNS形式，而不仅仅是浏览器文本框显示的内容。不要盲目地将主机名字符规则应用于包含下划线的服务标签。
TXT RDATA 由一个或多个字符串组成，每个字符串的长度为 1 个八位位组，因此最多为 255 个八位位组。这并不是整个 255 个字符的总括限制。 TXT记录。提供商可以通过在其中存储多个字符串来支持更长的记录，但须遵守DNS消息和服务限制。
拆分字符串而不拆分策略
参考： RFC 7208 §3.3, RFC 7208 §4.5, RFC 6376 §3.6.2.1, RFC 6376 §3.6.2.2.
对于SPF ，一条TXT记录中的字符串会连接在一起，不带额外的空格。在分割边界处保留所需的空间。夹具 "v=spf1 ip4:192.0.2.10" " -all" 重建一项政策。两个单独的TXT资源记录，每个记录均以开头 v=spf1 不是受支持的扩展方式； SPF选择多个策略并返回永久错误。
DKIM密钥数据还需要保留其预期值。使用提供商记录的长 TXT 输入方法，而不是手动截断。请勿分割较长的 选择器 通过插入点来添加标签：这会更改验证程序查询的DNS名称，除非实际的选择器配置一致更改。
运行以边界为中心的装置
参考： RFC 1035 §2.3.4, RFC 1035 §3.3.
创建正好 255 ASCII 的字符串 a 八位位组和 256 ASCII a 八位位组。单个DNS字符串可以对第一个字符串进行编码，但不能对第二个字符串进行编码。 一个记录 包含两个 128 个八位位组的字符串，每个字符串都是不同的有效字符串结构，总共 256 个数据八位位组。这些标记不是身份验证策略。
对于名称，将 63 八位字节 ASCII 标签与 64 八位字节标签进行比较，然后独立测试完整的线路名称长度。保留每个被拒绝案例的验证错误。在一个单独的测试区，发布一个 SPF记录 带有两个字符串，然后是故意无效的双策略记录变体。在更正的单记录发布之前和之后捕获权威 RR 边界。预期的应用结果是单策略处理与多策略处理 permerror.
这些装置指定边界行为。本地编码测试可以演示长度，但无法证明DNS提供商接受表单、活动区域发布预期的 RRset 或接收器验证消息。这些执行结果必须单独捕获。
验证生成的线路数据
参考： RFC 7208 §3.3, RFC 6376 §3.6.2.2.
查询所有活动权限的确切所有者和类型。使用保留每个资源记录及其字符串列表的DNS解析器。根据使用协议重建值，而不是连接每个输出行。然后比较相关的递归答案并测试邮件流。
如果表单仍然拒绝有效数据，请捕获确切的错误并查阅其当前特定于提供商的限制。请勿添加广泛的SPF授权、削弱密钥或创建其他策略作为权宜之计。正确的修复会保留预期的字节和DNS结构。
执行的解析器和 RRset 证据
2026 年 11 月 7 日保留的历史捕获（已检查但未重新运行本次审查）记录 dnspython 解析器接受 63 八位字节标签和 255 八位字节线路名称，并拒绝相应的 64 和 256 八位字节情况（长度例外）。实际的 UDP 权限捕获将之前的状态显示为两个单独的SPF TXT记录，然后将更正后的状态显示为包含两个有序字符串的一个TXT记录。环回转发器返回相同的边界。这是本地控制的出版物，而不是提供商面板的更改。两种策略情况下的SPF permerror仍然是源定义的预期结果，因为没有执行SPF评估器。边界和记录捕获证据不应被误认为是现场交付证据。
保持证据范围明确
存档的解析器和DNS捕获保持不变。这次审查检查他们记录的结果并单独计算本地字节边界；它不会重复 UDP 发布、运行SPF评估程序或测试提供程序表单。两条记录的SPF结果是规范预期，而不是捕获的身份验证执行。