这是我们在 Exchange Online 中发现的一个问题，但我怀疑大多数托管电子邮件都会出现这个问题。当 Office 365 / Exchange Online 发送自动回复（例如外出）时，它会遵守 RFC 2298，并且 RFC5321.MailFrom 为空：
RFC 2298 – Message Disposition Notifications
https://tools.ietf.org/html/rfc2298
The From field of the message header of the MDN MUST contain the
address of the person for whom the message disposition notification
is being issued.
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
null (<>), specifying that no Delivery Status Notification messages
or other messages indicating successful or unsuccessful delivery are
to be sent in response to an MDN.
当 RFC5321.MailFrom 为空时，SPF 将使用发送服务器的“HELO/EHLO”标识：
RFC 7208 - Sender Policy Framework (SPF)
https://tools.ietf.org/html/rfc7208
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the <sender>.
[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
[RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the
local-part "postmaster" and the "HELO" identity (which might or might
not have been checked separately before).
当您使用 DMARC 时，问题就开始出现了，因为 OOF 或 NDR 看起来是这样的：
- RFC5321.邮件发件人：<>
- RFC5322.发件人：”[电子邮件保护]“
- HELO/EHLO 身份：“mail-.outbound.protection.outlook.com”
当接收邮件服务器进行垃圾邮件检查时，他们会进行如下操作：
- SPF 对抗“[电子邮件保护]“-> 通过
- DKIM 针对“c=relaxed/relaxed；d=company365.onmicrosoft.com；s=selector1-company-com”-> 通过
- RFC5321.MailFrom 和 RFC5322.From 之间的 DMARC 对齐 -> 失败，因为 @*.outlook.com != @*.company.com
实际标题片段（匿名）：
Return-Path: <>
From: John Doe <[email protected]>
Received: from xxx00-xx0-xxx.outbound.protection.outlook.com (mail-xxx00xx0xxx.outbound.protection.outlook.com. [104.47.xx.xxx])
by mx.google.com with ESMTPS id y11si90960plg.98.2017.09.07.10.27.33
authentication-results: spf=none (sender IP is ) smtp.mailfrom=<>;
Received-SPF: pass (google.com: domain of [email protected] designates 104.47.xx.xxx as permitted sender) client-ip=104.47.xx.xxx;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1-company-com header.b=gb5VTzi+;
spf=pass (google.com: domain of [email protected] designates 104.47.xx.xxx as permitted sender) smtp.helo=xxx00-xx0-xxx.outbound.protection.outlook.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=company.com
在该示例中，p 等于“none”，因此邮件无论如何都会到达，但如果拒绝或隔离，邮件将永远不会到达，并且由于返回路径为空，因此不会向发送自动回复的用户发送 NDR（这就是重点，也是它为空的原因）。因此，外部联系人不会收到自动回复，也不知道他们应该收到自动回复，而内部用户不知道外部联系人没有收到自动回复。双输。
只有通过消息跟踪才能发现问题：
Event : Fail
Action :
Detail : Reason: [{LED=550-5.7.1 Unauthenticated email from company.com is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 company.com domain if this was a legitimate mail. Please visit 550-5.7.1
https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initi. OutboundProxyTargetIP: 74.125.xx.xx. OutboundProxyTargetHostName: gmail-smtp-in.l.google.com
对于内部邮件服务器，其 HELO/EHLO 标识是 whatever.mail.company.com，这不是问题，因为 DMARC 记录中的 aspf=r 将允许子域通过对齐；但是，由于 HELO/EHLO 标识是 *.Microsoft 域而不是 *.company.com，因此对齐将始终失败。
有没有办法克服这个限制？某种例外或策略标志？使用规则发送自动回复或使用传输规则并不是我心目中的解决方案；它们只是权宜之计，用户无论如何都会不可避免地忘记/忽略消息并设置自动回复。
答案1
如果您为自定义域“company.com”(d=company.com) 设置 DKIM，它将与 RFC5322.From 标头对齐，并将传递 DMARC。
如果两者（SPF 或 DKIM）中的任何一个与 RFC5322.From 一致，则 DMARC 将通过。
您可以在 Exchange 管理中心 -> 保护 -> DKIM 中为自定义域设置 DKIM