无空格TXT(SPF)记录经dig/host查询出现异常空格 排查问题来源

该异常显示既不是DNS服务商配置错误导致的记录损坏，也不是本地终端环境的问题，本质是DNS协议规范与客户端工具输出逻辑共同造成的显示假象

核心规则说明 #

依据DNS协议基础规范，TXT记录的文本内容并非存储为一整个连续长字符串，而是由多个单段最长255字节的独立文本片段拼接组成，每个文本片段在协议报文中有独立的长度标识与内容结构，片段本身不存在默认的分隔符语义。

• 当你在DNS服务商控制台配置的整条SPF记录长度超过单段255字节上限时，权威DNS服务器会按照协议规则，自动在255字节边界位置把整条记录拆分为多个独立文本片段存储，这个拆分过程不会修改原记录的语义，是全行业通用的合规处理逻辑。这种显示逻辑经常造成运维人员的误判，大家会误以为DNS服务商篡改了自己的配置内容。
• 你通过dig txt domain.com +short等命令看到的带双引号拆分内容、片段衔接位置的多余空格，只是客户端工具的显示效果：工具会把每个独立的协议层文本片段单独用双引号包裹，在两个相邻片段的显示位置自动补一个间隔用来区分块，并非记录内容本身被插入了空格、语义被拆分。
• 当拆分边界刚好落在域名（如spf.protection.outlook.com）、IP地址（如1.2.3.4）的字符串中间时，就会出现你观察到的类似“域名被插入空格、IP被拆成两段”的显示效果，和实际记录内容无关。

跨端复现的原因 #

所有操作系统下的DNS查询工具（Linux的dig/host、Windows的nslookup、macOS的dig）的输出逻辑都是严格遵循协议规范实现的，不存在某一系统工具单独出故障的情况，因此跨CentOS、Ubuntu、Windows、macOS全平台复现该显示效果是完全符合规则预期的，不是本地环境的问题。

正确的记录核验方式 #

• 不要直接以+short模式的输出作为记录正确性的判断依据，该模式默认不会自动拼接多个独立的TXT文本片段。
• 可使用无short参数的dig命令查看原始返回：dig txt domain.com，返回结果中所有被双引号包裹的字符串块就是协议层的独立文本片段，将这些块的内容直接顺序拼接即可得到完整的原始SPF记录内容。
• 你之前使用sed命令处理输出消除空格与拆分标记的操作，本质是移除工具的格式化显示内容、还原真实记录字符串，该方法可正常生效的结果，恰恰反向证明了你配置的TXT记录本身没有损坏。

内容的提问来源于stack exchange，提问作者Guruchandran