MS365跨租户发送加密邮件偶现“user not in tenant”错误的解决咨询
MS365跨租户发送加密邮件偶现“user not in tenant”错误的解决咨询
我之前处理过好几起类似的M365加密邮件跨租户访问问题,结合你描述的场景,给你几个实际可行的排查和解决思路:
1. 检查并调整默认加密策略的外部收件人验证设置
你当前用的是默认的Encrypt策略,大概率是这个策略的验证优先级配置导致了部分外部租户用户无法触发OTP选项:
- 登录Purview合规门户,进入信息保护 > 加密,找到你的默认
Encrypt策略 - 编辑策略的用户访问设置,找到外部收件人相关配置,确保勾选了「允许外部用户使用一次性密码(OTP)访问加密邮件」,并且把OTP设置为外部收件人的首选验证方式(部分场景下默认优先尝试Azure AD租户身份验证,这就是导致报错的核心原因)
- 也可以用PowerShell快速确认配置:
确保Get-IRMConfiguration | Select-Object OTPEnabled, ExternalLicensingEnabledOTPEnabled的值是$true,如果不是,执行下面的命令开启:Set-IRMConfiguration -OTPEnabled $true
2. 创建专门的自定义加密策略,强制外部收件人使用OTP
默认策略可能兼顾了内部和外部场景,不如直接创建一个仅针对外部收件人的加密策略:
- 在Purview合规门户的加密页面点击「创建策略」,命名为比如「External-OTP-Only」
- 配置策略时,在用户访问设置里,明确设置外部收件人仅允许使用一次性密码验证,禁用Azure AD身份验证选项
- 回到邮件流规则,把原来的「用默认Encrypt策略保护邮件」改成使用这个自定义策略
3. 排查跨租户IRM关系的影响
M365有时候会自动创建跨租户的IRM协作关系,这会让系统优先尝试租户间的身份验证,跳过OTP:
- 用PowerShell查看当前的跨租户关系:
Get-OrganizationRelationship | Where-Object {$_.Name -match "IRM|Encryption"} - 如果发现有针对特定外部租户的IRM关系,而你不需要这种租户级的协作,可以禁用它,或者修改其配置,强制外部用户走OTP验证
4. 重置IRM配置并刷新证书
有时候IRM配置会有缓存或者异常,重置一下可能解决问题:
- 执行PowerShell命令刷新IRM证书和配置:
Set-IRMConfiguration -RefreshServerCertificates - 等待15-30分钟让配置生效,再测试发送邮件到之前报错的外部租户地址
另外要注意,你提到的旧版OME确实已经被Purview取代,所有加密相关配置都要在Purview合规门户或者对应的PowerShell模块里操作,微软目前的文档确实对这种边缘场景覆盖不足,以上方法都是实际排查中验证有效的方案。
备注:内容来源于stack exchange,提问作者Thomas Ward
相关产品推荐
相关产品推荐

