This is an issue we're seeing with Exchange Online but it would be an issue with most hosted email I suspect. When Office 365 / Exchange Online sends an automatic reply (Out of Office for example) it adheres to RFC 2298 and the RFC5321.MailFrom is null:
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.
When the RFC5321.MailFrom is null SPF uses the "HELO/EHLO" identity of the sending server instead:
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).
The issues start when you're using DMARC because an OOF or NDR will look like this:
- RFC5321.MailFrom: <>
- RFC5322.From: "[email protected]"
- HELO/EHLO identity: "mail-.outbound.protection.outlook.com"
When the receiving mail server does its spam checks they'll go something like this:
- SPF against "[email protected]" -> PASS
- DKIM against "c=relaxed/relaxed; d=company365.onmicrosoft.com; s=selector1-company-com" -> PASS
- DMARC alignment between RFC5321.MailFrom and RFC5322.From -> FAIL because @*.outlook.com != @*.company.com
Actual header snippet (anonymized):
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
In that example p is equal to 'none' so the message arrives anyway but with reject or quarantine the message will never arrive and because the return-path is null no NDR is delivered to the user who sent the auto-reply (that's the point and why it's null.) So, the external contact doesn't get an auto-reply and doesn't know they were supposed to and the internal user doesn't know the external contact didn't get it. Lose-Lose.
Only through messages traces will you find the problem:
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
With internal mail servers where the HELO/EHLO identity of the mail servers is whatever.mail.company.com this isn't an issue as aspf=r in the DMARC record will allow the subdomain to pass alignment; However, since the HELO/EHLO identity is a *.Microsoft domain and not *.company.com alignment will always fail.
Is there a way to overcome this limitation? Some sort of exception or policy flag? Using a rule to send automatic replies or using a transport rule are not in my mind solutions; They're workarounds and users will inevitably forget/ignore messaging and set auto-replies anyway.
