This is a very interesting scenario and I think DMARC is one of the things common to all 365 hybrid configurations available. There is a problem with this problem. I am sending an e-mail that Office 365 notifies when sending sent e-mail messages. The email you receive is a bounce status notification (also called a bounce message).
The most common form is a non-delivery report (NDR), which tells you that a message has not been delivered. Inability to deliver can be as simple as an email address. The NDR contains a code indicating that the e-mail was not delivered and that you can get help from a friend.
Find out more about the items included in my NDR email Finding and getting help with my NDR code The following table lists the most common bounce messages and NDRs for Office 365 (also known as enhanced status codes).
Problem Description:
In an Office 365 Hybrid solution (Where you have online users/mailboxes and on-premise users/mailboxes), Online mail users reported that they are not receiving Non-Delivery-Report mails from on-premise server/users.
For example if the on-premise user mail box is full or if the online user sent an email with huge attachment beyond the on-premise server mailbox attachment limit, they never receive the NDR and accordingly they assume their mail was delivered which lately turns to be wrong.
Investigation Steps
To identify the root cause of this problem, I started troubleshooting as follows:
- Checked the On-premise servers for the email sent by the online user and for any response using power shell "Get-MessageTrackingLog" and an Undeliverable mail (NDR) was generated and sent to the online user.
- Since the mail wasn't received by the online user in his mailbox i went and checked the Quarantine queue (Office 365 - Admin Centers - Exchange - Protection - Quarantine), Advanced search and entered the email address of the online user in the "Recipient mail address" and I found this mail quarantined in his queue.
- The mail was quarantined because its classified as SPAM (Check above image) so the next step was to check Message header by clicking view message header (check above image)
- Copied the content from the Message Header and fired the Microsoft Message Header Analyzer Tab at the bottom to analyze the header for further details.
- Few important things to note from the message analyzer as follows (Check below image):
- SPAM confidence Level (SCL) is 9 which is the highest score
- It was filtered by SKS (Transport rules). Check this link for more details on the Anti-Spam Message header and their meaning https://technet.microsoft.com/en-us/library/dn205071.aspx?f=255&MSPPError=-2147217396
- The Authentication Results shows that DMARC Failed.
- Return-Path (Item 19) is empty
- So the question is why it was marked SPAM SCL 9 and the impact of the DMARC failure since we have DMARC implemented on this domain.
- My immediate next step was checking the Exchange Admin Center - Mail flow - Message Trace. The sender is the mail i got from the Header Analyzer "From" field which is the on-Premise Microsoft Exchange mail (MicrosoftExchangexxxxxxxxxxx@domain.com) - Option 5 in the above image and the recipient is the online user mail address. Click Search to check this criteria
- Upon opening the result trace, it was clear as shown in the below image that the mail was quarantined and SPAM level set by a transport rule named "Block Spoof Mail with DMARC" This is the transport rule created when we activated DMARC. It confirms the earlier results that it was quarantined and considered SPAM by a transport rule (SKS) and it has relation to the failure of DMARC
- My next check of course was the transport rules (Exchange Admin Center - Mail Flow - Rules) and it was very clear that this rule "Block Spoof Mail with DMARC" was the reason since its criteria is to set the mail SCL to 9 if DMARC fails (which was exactly our case) - Check below image
Root Cause, Why DMARC Failed ?
DMARC helps fighting and protecting our mail systems against spoofing along with SPF and DKIM (Will have several post on these three technologies). DMARC stands for Domain-Based message authentication, reporting and conformance.
DMARC works by comparing the "From" Field with "Return-Path" field and they should be the same (normally you are receiving mail from Ahmed@test.com and will reply back to Ahmed@test.com). The two fields will never match when the mail is spoofed.
Ex: You think you are getting a mail from admin@bank.com (From field) however when you reply its going to spoofadmin@spoofdomain.com (Both fields didn't match)
For Exchange System Generated NDRS, they don't contain any value/address in the Return-Path by design and that's why the DMARC test in our Case failed which triggered the Transport rule which in return set its SCL to 9 and got Quarantined.
How can we fix it ?
We have three options (checked by Microsoft Support Team) to fix this issue by editing the Transport rule in question and creating an exception:
- 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)
- 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)
- Except if - A Message header - includes these text patterns - Auto-submitted header contains "auto-replied"
Also make sure to set the "Match sender address in message" to "Header and Envelope"
This was a nice case and passed by several sections and views to troubleshoot it. Hopefully this post might help others facing the same issue/problem.
0 Comments
