DKIM 规范化 定义如何为散列和签名验证准备消息字节。它允许特定的标准化；它不会使任意消息编辑变得无害。在更改发送者的配置之前诊断实际签名的设置和原始内容。
分别读取两个设置
签名的 c= 标签名称标头和主体按该顺序规范化。例如， 轻松/简单 对标头使用宽松的处理，对正文使用简单的处理。 RFC 6376 §3.5 当标签不存在时，将 simple/simple 定义为默认值；如果只说明头部算法，则主体算法默认为简单。
记录 c=, 签名头列表 h=， 这 正文哈希 bh= 以及任何身体长度限制 l= 旁边 d= 和 s=。主体哈希不匹配、标头签名不匹配和丢失的公钥需要进行不同的调查。不要从邮件客户端显示的内容推断规范化设置。
了解允许的标准化
简单的标头规范化保留了呈现给算法的标头字段。宽松的标头处理会小写字段名称、展开连续行并标准化指定的空白。它不会小写字段值或授权更改主题的单词。
简单的正文规范化会删除末尾的空行并确保最终所需的 CRLF，同时保留其他正文内容。宽松的正文处理还可以减少行内的空格和制表符运行，并在处理尾随空行之前删除行尾的空格。它不会组合任意行、重写 URL、删除MIME边界或忽略添加的文本。 RFC 6376 §3.4 指定确切的顺序和边缘情况，包括空体的不同处理。
使用一致的实现来进行精确测试。在验证之前更改行结尾的手工编辑近似值可能会导致其应该调查的故障。
应用受控示例
考虑合成车身线条 立即付款<SP><SP><SP><CRLF>，其中括号中的标签表示字节而不是文字文本。放松的身体规范化产生 立即付款<SP><CRLF> 对于那条线。简单的正文处理保留了内部和尾部空格。因此，这种仅包含空白的更改在两种主体算法下可能会产生不同的结果。
现在在签名消息后添加一个新句子。宽松的处理不会放弃实质性的添加。假设全身覆盖并且测试中没有其他变化，则规范化的主体会有所不同，其预期的主体散列也会有所不同。不能仅仅因为发件人使用relaxed/relaxed 就将页脚规则声明为安全。
该示例解释了预期的标准化，而不是捕获的事件或执行的测试。在生产中，考虑MIME编码、签名标头和签名的实际长度处理。两条消息可以呈现相同，但它们的签名字节不同。
在改变策略之前找到转型
保留原始的原始消息，然后获取可疑修饰符之前和之后的授权比较样本。使用副本进行分析。比较具有和不具有可疑页脚、链接重写或重新编码功能的其他等效测试，保持传输路线相同。
如果支持的体系结构允许，请在适当的最终签名阶段之前执行所需的内容更改。如果中间人重新签约，评估其新身份并 结盟。不要仅仅为了使一项诊断测试绿色而禁用保护网关处理或削弱域策略。
作为 RFC 6376 §8.2 警告，身体长度 l= limit 改变了规范化主体的覆盖范围。它不是签名后修改的通用解决方法，并且可能会将附加内容保留在签名部分之外。检查安全影响和提供商支持，而不是添加它来抑制故障。
证明字节和路由级别的修复
保留原始故障、规范化设置、受控比较以及从纠正的路线收到的结果。如果更改规范化是选择支持的补救措施，请确认实际的修改操作落在其允许的转换范围内。新的宽松签名可以容忍一些空白更改，同时仍然容易受到原始实质性重写的影响。仅当观察到的更改与验证结果一致时才关闭问题。
检查空体边缘情况
在下面 RFC 6376 §3.4.3，在简单的主体规范化中，一个完全空的或缺失的主体变成一个 CRLF 或两个八位字节。在下面 RFC 6376 §3.4.4，宽松的主体规范化为空主体生成零个八位字节。在这两种情况下对 CRLF 进行哈希处理的工具将不符合标准，即使这两条消息都显示为空白。这是一个规范示例，而不是完整的DKIM验证或执行的邮件测试。
相关阅读
DKIM公钥语法：识别截断或格式错误的DNS值 · 多个DKIM签名：找到对齐的传递签名.