通过Python和Microsoft Graph发送的S/MIME邮件在Gmail正常但Outlook异常

一、Outlook对S/MIME的特殊处理 #

Outlook对S/MIME的校验和格式兼容逻辑比Gmail、iOS Mail严格不少：

• 证书校验：会强制检查证书的**增强密钥用法（EKU）是否包含1.3.6.1.5.5.7.3.4（安全邮件发送），同时要求证书链完整，哪怕其他客户端忽略的链上小问题，Outlook都会触发“内容篡改”提示。另外，发件人邮箱必须出现在证书的主题备用名称（SAN）**里，仅在主题字段里的email可能不被Outlook认可。
• TNEF自动转换：Outlook默认会对不符合它预期的MIME结构生成winmail.dat（TNEF格式），尤其是邮件带富文本、MIME嵌套不规范，或者没明确禁用TNEF时，大概率会触发这个转换。

二、Graph API发送时的核心问题与修复 #

针对你遇到的三个具体问题，逐个拆解：

1. 证书提示内容篡改 #

• 确保签名覆盖完整MIME内容：生成S/MIME签名时，要对包括Subject、From、To在内的所有邮件头部+正文+附件的完整MIME内容签名，Graph API发送时绝对不能修改这些内容，哪怕改个空格，Outlook校验签名时都会判定内容不一致。
• 别在签名后改内容：签名生成后，再添加附件、修改正文或头部，直接破坏签名完整性，必触发篡改提示。
• 用SHA-256及以上算法：Outlook对SHA-1这类旧算法兼容性极差，生成签名时一定要指定SHA-256或更高的哈希算法。

2. 邮件变winmail.dat附件 #

• 强制禁用TNEF：发送邮件时，在Graph API的请求体里加"sendAs": {"disableTnef": true}（创建邮件时设置disableTnef: true也可以），直接阻止Outlook生成TNEF格式。
• 规范MIME结构：邮件根Content-Type必须是multipart/signed，内部的内容部分用text/plain或text/html，别用text/richtext这类Outlook敏感的格式。同时要保证MIME边界完全一致，别让Graph API自动修改边界。
• 检查头部：如果邮件里有X-MS-TNEF-Correlator这个头部，说明TNEF被启用了，必须通过上述参数禁用。

3. DKIM/DMARC校验失败 #

• 启用租户DKIM：如果是用Microsoft 365租户发送，先确认租户的DKIM已经启用，发件人邮箱的域名在DKIM记录里。Graph API只会给租户内验证过的邮箱发送的邮件加DKIM签名，非租户邮箱发送的话，DKIM直接是none。
• 对齐From和Return-Path：Outlook要求DKIM签名的域名和From地址的域名完全匹配，如果Return-Path是第三方域名，也会导致DKIM校验失败。
• 检查DMARC配置：如果域名的DMARC记录是p=none，那结果自然是none；如果是其他值，那大概率是SPF/DKIM没通过，先把这俩搞定，DMARC才会正常评估。

三、快速验证步骤 #

• 用openssl smime -verify -in your-signed-email.eml -inform pem命令本地验证签名完整性，先确保本地能过。
• 在Outlook里查看邮件源：
  • 检查签名部分的Content-Type: application/pkcs7-signature，确认算法是sha256WithRSAEncryption这类SHA-2+的。
  • 找有没有X-MS-TNEF-Correlator头部，有就说明TNEF没禁用成功。
  • 看有没有DKIM-Signature头部，域名是否和From的域名一致。

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