邮件能不能作为证据？电子签名法对数据电文的原件与完整性要求，怎么落到邮件系统上？

实务中常见的误解是「电子邮件不算数，得有纸质盖章件」。电子签名法在这一点上给出的原则很明确：不得仅因为某一文件采用了电子签名或数据电文的形式，就否定其法律效力。数据电文本身被定义为以电子、光学、磁或者类似手段生成、发送、接收或者储存的信息，电子邮件完整地落在这个定义之内。

所以真正的问题不是「邮件算不算证据」，而是「这封邮件能不能被证明是真的、完整的、来自它声称的那个人」。法律没有为电子形式设置额外的效力门槛，但它为「可采信」设置了可验证性的条件。这些条件全部是技术条件，也正是邮件系统需要回答的部分。

同时要注意，该法也划出了不适用的范围，例如涉及婚姻、收养、继承等人身关系的文书，涉及土地、房屋等不动产权益转让的文书，以及停止供水、供热、供气等公用事业服务的文书。这类事项不能靠邮件流程替代。

很多合规场景要求提交「原件」。电子签名法规定，数据电文满足两项条件即视为符合法律法规规定的原件形式要求：其一，能够有效地表现所载内容并可供随时调取查用；其二，能够可靠地保证自最终形成时起内容保持完整、未被更改。

该法同时给出了一个非常重要的技术豁免：在数据电文上增加背书，以及数据交换、储存和显示过程中发生的形式变化，不影响数据电文的完整性。这一句直接决定了邮件系统的设计空间——

• 邮件在中继过程中每一跳追加 Received 信头，这属于形式上的增加，不破坏完整性；
• 网关追加认证结果信头、附加免责声明，同属此列；
• 但改写正文、剥离附件、重编码字符集、把 HTML 部分改写成纯文本，就已经越过了「形式变化」的边界，需要谨慎对待。

落到系统上：归档必须在报文被任何加工之前完成，且归档的应当是完整的 RFC 5322 原始报文（含全部信头与 MIME 结构），而不是数据库里被拆解成字段的「邮件对象」。后者在需要证明完整性时是无法还原的。

对于「保存文件」的法定要求，该法给出的条件比原件要求多一条。除了内容可有效表现并可供随时调取查用之外，还要求数据电文的格式与其生成、发送或者接收时的格式相同，或者格式不相同但能够准确表现原来所生成、发送或者接收的内容；并且能够识别数据电文的发件人、收件人以及发送、接收的时间。

最后半句是邮件归档最容易出问题的地方。「发件人」在邮件里至少有三个不同的东西：

1. 信封发件人（SMTP MAIL FROM），用于退信，不显示给用户；
2. 信头 From，用户看到的那个，也是最容易被伪造的那个；
3. 认证通过的标识，如 DKIM 签名域、SPF 校验通过的域。

只归档信头 From 是不够的——它恰恰是攻击者最容易控制的字段。要满足「能够识别发件人」，归档必须同时保留信封层信息与认证结果，并保留支持这些结论的原始数据（DKIM-Signature 信头本身、SPF 判定所依据的连接源地址）。同理，「发送、接收的时间」应当同时保留报文 Date 信头与本系统实际接收的时间戳，二者不一致本身就是一条有价值的线索。

该法规定，电子签名同时符合下列条件的，视为可靠的电子签名：电子签名制作数据用于电子签名时属于电子签名人专有；签署时电子签名制作数据仅由电子签名人控制；签署后对电子签名的任何改动能够被发现；签署后对数据电文内容和形式的任何改动能够被发现。当事人也可以选择使用符合约定可靠条件的电子签名。

把这四条对照 DKIM（RFC 6376），结论是清晰的：

• 「签署后对内容的改动能够被发现」——DKIM 对被签名的信头与正文哈希做验签，这一条能够满足；
• 「制作数据属于签名人专有、仅由签名人控制」——DKIM 做不到。DKIM 的私钥由发送域的邮件系统持有，代表的是「这封邮件由该域的基础设施发出」，而不是「由某个自然人签署」。DKIM 是域级别的责任标识，不是个人级别的签署意思表示。

因此，若业务需要的是「某个具体的人对这份内容作出了确认」，正确的技术选型是由签署人个人持有密钥的端到端签名（如 S/MIME 报文签名，见 RFC 8551），而不是依赖服务端的 DKIM。二者不能互相替代，也不冲突——DKIM 解决域的责任归属，个人签名解决意思表示的归属。

该法在审查数据电文作为证据的真实性时，要求考虑几个因素：生成、储存或者传递数据电文方法的可靠性；保持内容完整性方法的可靠性；用以鉴别发件人方法的可靠性；以及其他相关因素。注意这几条问的都是「方法的可靠性」，而不是「这一封邮件本身」。这意味着单封邮件是证明不了自己的，能被证明的是整套机制。

据此可以列出邮件系统的动作清单：

1. 原始报文级归档。在任何改写之前落盘完整原始报文，保留全部信头。归档存储应采用写入后不可修改的方式。
2. 归档完整性自证。对归档对象计算并单独保存摘要值，形成可独立校验的完整性证据；必要时引入符合 RFC 3161 的时间戳服务，为「自最终形成时起未被更改」提供独立于本系统的时间锚点。
3. 认证链路证据同步归档。DKIM 验签结果与 DKIM-Signature 原文、SPF 判定与连接源地址、TLS 握手信息一并存档。公钥会轮换，若干年后 DNS 里已查不到当年的选择器——当年的验签结论与公钥必须在当时就固化下来。
4. 访问与操作留痕。谁在什么时候导出过哪封归档邮件，本身也要被记录。归档系统若能被无痕修改，其证明力就被削弱。
5. 取证流程按规范执行。RFC 3227 给出了证据收集与归档的通行做法，其核心要求包括按易失性顺序收集、避免污染现场、记录每一步操作与时间、以及保管链的连续性。技术上正确但流程上断链的证据，仍然可能不被采信。
6. 定期做一次恢复演练。随机抽取一个历史时间点，验证能否在合理时间内取出完整原始报文并通过完整性校验。没演练过的归档，等于没有归档。