如何通过Microsoft Graph API查询Send As权限下共享邮箱实际发件人
问题场景
我持有地址为SHAREDBOX1@mycompany.com的共享邮箱,少量用户拥有该邮箱的邮件发送权限,需要确认能否通过Microsoft Graph API查询到通过该共享邮箱地址发出的外发邮件的实际发送用户。
我已查阅Message资源的官方文档中邮件属性相关说明,尝试定位共享邮箱代发用户的字段。以下为脱敏后的MS Graph API返回示例,对应用户通过共享邮箱代发至3名收件人的邮件数据:
{ "@odata.etag": "W/\"CQSJDKJGKJGROwCC\"", "id": "AASDGSDGSDFMP4-RK_VSDFA1-bSDFSDFjB-JHUffy=", "createdDateTime": "2022-07-06T16:50:55Z", "lastModifiedDateTime": "2022-07-06T16:51:03Z", "changeKey": "CSDFSDFSDGSFDSDFSFCC", "categories": [], "receivedDateTime": "2022-07-06T16:50:00Z", "sentDateTime": "2022-07-06T16:50:45Z", "hasAttachments": false, "internetMessageId": "<PDSVSSVSVFGNFGHJ.something.prod.outlook.com>", "subject": "RE: Work Stuff", "importance": "normal", "parentFolderId": "SDFFGAGSDFHSDFHDFNIUERGHSJHDNVUIAGNOIGAIU", "conversationId": "JHFBVJHSBVJBVJHZVJ=", "conversationIndex": "ETHYTJTJDGNRYJD", "isDeliveryReceiptRequested": false, "isReadReceiptRequested": false, "isRead": true, "isDraft": false, "webLink": "https://outlook.office365.com/owa/?ItemID=SFBHWIUEwfADtegVAJBVSHFBVYUS&exvsurl=1&viewmodel=ReadMessageItem", "inferenceClassification": "focused", "sender": { "emailAddress": { "name": "SHAREDBOX1", "address": "SHAREDBOX1@mycompany.com" } }, "from": { "emailAddress": { "name": "SHAREDBOX1", "address": "SHAREDBOX1@mycompany.com" } }, "toRecipients": [ { "emailAddress": { "name": "Thad", "address": "thad@mycompany.com" } } ], "ccRecipients": [ { "emailAddress": { "name": "Chad", "address": "chad@mycustomer.com" } }, { "emailAddress": { "name": "Vlad", "address": "vlad@mycustomer.com" } } ], "bccRecipients": [], "replyTo": [], "flag": { "flagStatus": "notFlagged" } }
该邮件显示发件人为SHAREDBOX1@mycompany.com,收件人为Chad、Vlad和Thad,实际代发该邮件的用户为brad@mycompany.com。
按照官方文档中Send on Behalf(代表发送)场景的说明,我原本预期sender字段会填充实际发件人brad@mycompany.com,但实际返回中sender与from字段均填充为共享邮箱地址,确认用户持有的是共享邮箱的Send As(完全代理发送)权限,而非Send on Behalf权限。
回答
核心结论
Send As权限场景下,无法通过Message资源的公开字段直接查询到实际发件人身份。
原因说明
- 这是Exchange Online的原生设计逻辑:Send As权限的设计目标就是完全模拟目标邮箱身份发送邮件,邮件存储属性、对外暴露的邮件头中都不会主动留存代发用户的身份信息,和Send on Behalf场景会在
sender字段标注代发人、客户端显示「XXX代表XXX发送」的逻辑有本质区别。你拿到的返回结果就是这个设计的直接体现。 - Message资源公开的所有属性都不会存储Send As场景下的实际发件人信息,不存在未被注意到的隐藏字段可以直接提取该身份,解析邮件头也无法拿到相关信息——邮件经过Exchange传输链路时,会剥离所有和内部代发操作人相关的头字段,不管是租户内用户还是外部收件人拿到的邮件内容里都不会留存这类信息。
可行的审计方案
如果需要追溯Send As邮件的实际操作人,只能通过Office 365审计日志做关联查询,没有其他路径:
- 提前确认租户已开启Exchange邮箱审计,针对共享邮箱的
SendAs操作开启审计记录,否则历史操作不会留存。
注意:未开启审计的时间段内的Send As操作没有任何记录可以追溯,无法事后补查。
- 调用Microsoft Graph的审计日志接口,查询对应时间范围内、针对该共享邮箱的Send As发送操作记录:这类记录会留存操作人(实际发件人)的账号信息、操作时间、邮件的internetMessageId、主题等字段。
- 用你已拿到的邮件
internetMessageId、sentDateTime、subject三个维度和审计记录做匹配,就能定位到实际发送邮件的用户。 - 审计日志的留存周期和租户配置绑定,默认留存90天,超过留存周期的记录无法查询。
内容的提问来源于stack exchange,提问作者aaron
相关产品推荐
相关产品推荐

