DKIM、 S/MIME和OpenPGP都可以涉及数字签名，但它们并没有做出相同的断言。从您需要的保护开始：域责任、签名消息实体的完整性、收件人的机密性或对特定密钥持有者的信心。没有任何标签可以单独证明付款请求已获得授权。
遵循一条消息路径
想象一下，作者撰写消息、应用DKIM发送服务器、添加页脚的网关以及打开结果的收件人。 DKIM将选定的标头和规范化正文连接到签名域。接收器使用 选择器 和域来在DNS中查找公钥。它不加密内容。页脚修改可能会破坏 正文哈希，取决于签署的范围和处理。 RFC 6376.
S/MIME使用基于证书的加密技术对MIME消息实体进行操作。签名和加密是不同的操作：仅签名的消息不是保密的。接收者必须根据其信任策略验证相关证书和身份绑定。加密到接收者证书可以保护相应私钥持有者的加密实体；它不会隐藏每个外部路由字段。 RFC 8551.
OpenPGP 定义密钥、签名和加密数据格式。有效签名证明与密钥的关系，而用户对密钥属于预期通讯方的信心取决于经过验证的绑定和本地信任决策。加密和签名再次分开。电子邮件打包和客户端互操作性需要自己的实施检查。 RFC 9580.
比较威胁而不破坏身份
对于伪造的域级发件人路径， DKIM提供域身份验证并可以提供对齐的 DMARC 小路。对于更改签名内容的中间人，适用的S/MIME或 OpenPGP 签名在正确验证后可以显示修改。对于被动方读取消息内容，适当的加密可以解决机密性问题；单独签名则不然。
这些陈述都不意味着端点是安全的。受损的私钥或授权帐户可以产生加密有效的材料。任何签名也不能使发票正确。密钥生命周期、收件人验证和独立业务批准仍然是必要的。
使用有界控制矩阵
下面的文献比较直接提供了这五个选择。它描述了正确实施时的预期保护，而不是经过验证的互操作性。
- DKIM ：与签名域关联的选定标头和规范化主体；没有保密性。页脚更改覆盖的规范化字节可能会使签名无效。
- 仅签名S/MIME ：与经过验证的证书密钥关联的签名MIME实体；没有保密性。更改的签名实体可能无法通过验证，而外部修改则需要范围检查。
- 加密S/MIME ：为预期接收方密钥持有者提供保护的加密MIME实体；外部路由字段可以保持可见。仅加密并不能验证作者身份。
- 仅签名 OpenPGP：与必须验证对应绑定的密钥关联的签名数据；没有保密性。更改所涵盖的数据可能会使验证无效。
- 加密 OpenPGP：为预期密钥持有者保护加密数据；打包和公开的元数据仍然需要审查。单独的加密并不是发件人授权。
此比较未执行任何加密操作、客户端往返或网关测试。可以将签名和加密结合起来；订购和包装必须在实际路线上进行测试。在加密或签名实体之外添加的网关页脚与更改该实体具有不同的效果。将这些案例分开，而不是分配通用的生存转发结果。
选择并验证组合
将所需的身份和保护范围写入验收标准。验证密钥注册、丢失和撤销处理、算法支持、转发行为和组织外部的收件人。检查验证失败时用户实际看到的内容。 DKIM可以与最终用户签名或加密共存；添加一项并不会使其他项变得多余。保留记录的恢复路径，该路径不会默默地降低预期的保护。