none
Exchange 2013 On Prem - OOTO / NDR Replies Fail DMARC Authenication Outbound

    คำถาม

  • Overview - 3 On Prem Installations of Exchange 2013 on Server 2012 R2 in a DAG configuration. All exchange boxes are running build 1367.3.

    Issue - Automatic Replies (Out of the Office) and NDR responses from users are failing DMARC checks on the receiving end / being bounced. This is because the Return-Path header value and Mailfrom header values of both NDR and Automatic replies are set to null or <>. This results in the DMARC not having a domain to query against, so the DMARC fails all checks and the recipient domain bounces the email. 

    The reason why the headers are set to null is because of RFC 2298 - this makes sure that the automatic replies / NDRs do not keep going back and forth, creating an email loop that could potentially bring the servers down. However, RFC 2298 forces RFC 5321 MailFrom header as <> or null, which doesn't give a DMARC policy anything to pull its query from, thus the DMARC fails and the email is bounced. To visualize this -

    NDR/OOTO Response:

    MailFrom: <>

    From:Email@domain.com

    HELO/EHLO: mail.outboundsmtp.com

    DMARC Fails

    Normal Email:

    MailFrom: Email@domain.com

    From: Email@domain.com

    HELO/EHLO: mail.outboundsmtp.com

    DMARC - Passes - the policy has a RFC 5321 header to pull its information to query DNS and passes. 

    The reason the DMARC policy is pulling from the 5321 header is to help prevent spoofed emails, where the envelope header may possibly be spoofed, which would then pass the DMARC check, allowing a spoofed email into the domain. 

    My question is for anyone that has a strict reject 100% or quarantine 100% DMARC policy, how did you overcome this? Are you just allowing your NDR/OOTO replies to be bounced / rejected?

    I've tried 2 solutions. Main idea behind my solution was to remove the null value or <> and replace it with a donotreply@domain.com address so that the DMARC has a RFC 5321 header to run against, thus both RFC 5321 and 5322 domains would technically align and pass the DMARC query.

    1. We use mimecast as our email gateway / filter. I've tried to create an address alteration policy going outbound looking for <> as the header value to then input donotreply@domain.com into the header, but mimecast cannot detect the <> value in the header because it is technically null or blank. Using a "null" value doesn't work either. You cannot leave the value blank because some type of syntax is needed for the policy. Opening a ticket with mimecast, L2 engineers confirm that it is working as expected and this is a Microsoft / on prem deployment issue. 

    2. Attempting to use a transport level policy to insert a donotreply@domain.com address into the header doesn't work either. I believe something in exchange is preventing the transport policy from executing. The policy I configured was anything with subject "Automatic Reply" or "Undeliverable" change header property of "Return-Path" to "Donotreply@domain.com" and "MailFrom" to "donotreply@domain.com. Doesn't work and tests to google / gmail do not pass dmarc still and show null values. 

    For reference, I found 2 other issues on technet with the same issue. One solution proposed was to use an outside tool to manipulate the emails going outbound to rewrite the headers so that the DMARC has something to run against. Link here: https://social.technet.microsoft.com/Forums/en-US/9d17cd55-36b0-4d00-8114-d7f1e54fc725/dmarc-test-fails-on-out-of-office-replies-but-not-on-regular-emails?forum=Exch2016MFSM. Another extremely well explained post is here: https://social.technet.microsoft.com/Forums/en-US/51519377-48f5-4833-ac0d-4128eaf9c25e/how-do-you-setup-dmarc-to-allow-null-returnpath-rfc5321mailfrom-messages-out-of-officendr?forum=onlineservicesexchange

    I cannot imagine this being intended nor do I think that a transport policy or using a third party tool to correct this is a real fix, but a work around for the issue. 

    Any help is appreciated. 

    Cheers,

    Jason

    8 มิถุนายน 2561 17:51

ตอบทั้งหมด

  • Hi,

    We could add one of the following exceptions to the transport rule for DMARC:

    1. Edit the Transport rule - Except if - The Sender - IP address is in any of these ranges or Exactly Match - IP (Your on-premise Exchange server Public IP address)
    2. Except If - The Sender - Is this person - add the email address of the NDR mail which is MicrosoftExchangexxxxxxxxxx@domain.com (This is unique per each domain and won't change)
    3. Except if - A Message header - includes these text patterns - Auto-submitted header contains "auto-replied"

    Below is an article which explains the issue, it is also applied to on-premise Exchange.
    Office 365 DMARC rule blocking NDR mails from On-premise servers

    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make sure that you completely understand the risk before retrieving any suggestions from the above link.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    11 มิถุนายน 2561 7:39
    ผู้ดูแล
  • Good Morning Manu,

    Thanks for the reply, however, this does nothing to solve my case. This solution will work on attempting to accept emails with DMARC failures inbound. As in this case, this user has a hybrid environment, consisting of On prem and O365 users. He needed his users on O365 to receive the NDR's on the on prem boxes, so he applied this rule. I am trying to resolve this for all outbound mail from my internal domain. 

    In all, I need a way to insert a donotreply@mydomain.com address into the 5321 RFC header and that should resolve the issue. 

    11 มิถุนายน 2561 13:40
  • Hi,

    Sorry for the delay, we recommend you to open a ticket with Microsoft and make sure if it is possible to realize it.

    Thanks a lot for your understandings.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    15 มิถุนายน 2561 9:58
    ผู้ดูแล