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