This article will provide a brief explanation of the consequences when an email fails DMARC authentication tests, indicating non-compliance. Such emails may have failed SPF and/or DKIM authentication or have headers misaligned with the sending domain.
To put it simply, the article will also discuss how O365 handles emails in which the sending email address has been forged by a hacker or used by an unauthorized sending system on behalf of the sending domain.
The sending domain is not yet protected by DMARC :
When an email's "header from" domain lacks a DMARC policy or has a policy set to "p=none," the Exchange Online Protection DMARC filter does not block the email. In other words, the absence or lack of a DMARC policy or a "p=none" policy in the "header from" domain allows the email to pass through the DMARC filter.
The sending domain is protected by a DMARC policy :
When an email's "header from" domain is secured by a DMARC policy with a "p=quarantine" or "p=reject" setting, the "detected as spoof" rule implemented in the anti-phishing filtering policy is triggered. In other words, if the "header from" domain has a DMARC policy set to "p=quarantine" or "p=reject," the anti-phishing filtering policy's "detected as spoof" rule is enforced.
O365 treats emails sent on behalf of domains secured by a DMARC policy set to "quarantine" or "reject" and that fail the DMARC check in the same manner.
Nevertheless, if you want to reject emails failing DMARC because their domain has a DMARC policy set to "p=reject," you need to configure the following transport rule to accomplish this.
This transport rule will not discard emails that either pass DMARC (dmarc=pass action=none) or fail DMARC with a DMARC policy set to "p=quarantine" (dmarc=fail action=quarantine). It will solely reject emails that fail DMARC with a DMARC policy set to "p=reject" (dmarc=fail action=oreject). In other words, the transport rule will only discard emails that do not meet the DMARC policy set to "p=reject" and fail the DMARC check.