1

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.

1 Answer 1

0

If you set the DKIM for your custom domain "company.com" (d=company.com) it would be aligned with the RFC5322.From header and that would pass DMARC.

DMARC will pass if ANY of the two (SPF or DKIM) pass aligned with the RFC5322.From.

You can set the DKIM for your custom domain in the Exchange admin center -> Protection -> DKIM

2
  • Won't work unfortunately. When the from address is null such as with MDNs the RFC5322.From is interpreted as postmaster@<EHLO/HELO sending server> which for us is a Microsoft Office 365 server so there is no alignment. It's explained in detail in the post.
    – omniomi
    Commented Feb 1, 2018 at 14:48
  • No, only Envelope From (RFC5321) is null. Header From (RFC5322) is '[email protected]'. DKIM checks this against d= tag and if it passes, thats enough for DMARC to pass.
    – Tomcat
    Commented Feb 7, 2018 at 10:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .