这是我们在Exchange Online上看到的一个问题，但对于我怀疑的大多数托pipe电子邮件来说，这是一个问题。 当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 (ie, 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将如下所示：
当接收邮件服务器进行垃圾邮件检查时，他们会这样做：
实际标题片段（匿名）：
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'，所以消息到达但是拒绝或隔离消息将永远不会到达，因为返回path为空，所以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身份是any.mail.company.com这不是问题，因为DMARClogging中的aspf = r将允许子域通过alignment; 但是，由于HELO / EHLO身份是* .Microsoft域，而不是* .company.comalignment将始终失败。
有没有办法克服这个限制？ 某种exception或政策标志？ 使用规则发送自动答复或使用传输规则不在我的脑海里的解决scheme; 他们是解决方法，用户将不可避免地忘记/忽略消息，并设置自动回复。