DMARC validation in Office 365

DMARC is together with SPF and DKIM another technology protecting you against phishing and spoofing. Implementing DMARC with SPF and DKIM provides additional layer of protection. This validation uses DNS records where are specified mail servers authorized for sending emails from your domain.

Differences between SPF and DMARC

The difference between SPF (Sender Policy Framework) and DMARC (Domain-based Messaging and Reporting Compliance) is that SPF can catch only spoofing of MailFrom address, specifically 5321.MailFrom. But DMARC is much more sophisticated. First let me explain the difference between FROM addresses.

• 5321.MailFrom identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. This appears in the envelope portion of an email message and is not usually displayed by your email application.
• 5322.From is address displayed as the From address by your mail application. This address identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. This address is not checked by SPF technology.

From the above mentioned it’s clear that user can receive an email which successfully passes SPF protection, but 5322.From address, which is displayed in an email client, is spoofed. Let’s have a look on the following example:

In this example, user can see as the sender’s address, which can be real address of his/her bank, but it’s phishing email, which successfully passed SPF check, because SPF checked 5321.MailFrom address which belongs to existing domain and existing email address with defined SPF record. In this example everything looks correct and user is not able to check whether the email is valid or not, because the header of the email contains:

In case of implementing DMARC on both sides (DMARC DNS record in the sender’s domain and DMARC validation on the recipients mail server), this email would by marked as phishing (sent to junk or rejected directly by the mail server), because DMARC checks DMARC DNS record as well as DKIM and SPF. And email header would be:

Now let’s have a look how to implement DMARC in Office 365.

Implementing DMARC in Office 365

In Office 365 is DMARC for inbound emails enabled by default, therefore your users are protected by default and now it’s responsibility of domain owners to implement DMARC records. But let’s assume and hope that all important institutions (banks, insurance companies, authorities, …) have their domains protected.

To have also our domain protected, we need to add one DNS record to our domain. General DMARC record format is:

Where v is the version, p is the policy, sp is the subdomain policy, pct is the percent of “bad” emails on which to apply the policy, and rua is the URI to send aggregate reports to.

DMARC is set using TXT domain record. I recommend using the following configuration which says to reject messages with failed DMARC check in 100% of emails in the main domain and all subdomains.

In my example it looks like:

And because I have set SPF, DKIM and DMARC, email header looks like: