DMARC is the last step in securing your Office 365 mail. Where SPF only checks against the 5321.MailFrom address does DMARC also check the 5322.From address. It also tells the receiving mail systems what to do with mail send from your domain that didn’t pass the SPF and DKIM check.
Before we can start with configuring DMARC, you first need to configure SPF and DKIM for Office 365. These protocols are used to determine who is allowed to send mail on behalf of your domain.
In this article, we are going to take a look at how to set up DMARC and I will explain the different options you have when it comes to configuring DMARC.
How does DMARC work?
Before we configure DMARC, it’s good to understand how it exactly works. Because DMARC does not only tell the receiving mail server what to do with unauthorized (spoofed) emails, it also adds an extra security check.
The problem is that email can have multiple From headers. We have the Mail From address (5321.MailFrom), which identifies the sender of the mail. And we have the From address (5322.From), which is displayed in the mail client.
SPF only checks the Mail From address, which can be a problem. Take the following SMTP transcript example:
S: Helo stonegrovebank.com S: Mail from: fake@phishingdomain.com S: Rcpt to: info@lazyadmin.nl S: data S: To: "LazyAdmin" <info@lazyadmin.nl> S: From: "Finance Stonegrove bank" <finance@stonegrovebank.com> S: Subject: Stonegrove bank - Important!
SPF only checks the Mail From the address. So in this case is the sending IP address allowed to send mail for the domain phishingdomain.com. If the attackers created an SPF record for the domain phishingdomain.com and listed the sending IP address, then the SPF check will pass.
The problem is that SPF doesn’t check the From address, it will completely ignore the fact the From address doesn’t match the Mail From address.
When you have enabled DMARC for your domain (stonegrovebank.com in this example), then the receiving server will also check the From address. This check will fail because the sending IP Address isn’t listed in your SPF record.
Monitoring, Quarantine and Rejecting Email
Another important function of DMARC is that it tells the receiving mail server what it should do with unauthorized emails. Before we can start with moving unauthorized mail to the spam folder, or rejecting mail completely, we first need to know for sure that all legitimate systems are authorized.
| Option | Policy | Description |
|---|---|---|
| Monitoring | p=none | Just deliver the mail (used for testing) |
| Quarantine | p=quarantine | Move the mail to the spam folder |
| Reject | p=reject | Drop the email |
The last thing that you want is that your legitimate emails are dropped by the receiving server because you forget to add an IP Address to the SPF record. So what we can do is first monitor the DMARC results, using the monitoring policy setting.
Only when we are certain that everything is working as expected, can we move to quarantine or rejecting mails.
DMARC Reporting
The monitoring policy is always used in combination with an email address to send the report to. These reports are generated in XML format and give you insight into the DMARC results. Now I have to say, they are a bit hard to read:
To help you analyze these reports you can use a third-party service, like dmarcly (they offer a 14-day trial to get started).
You can specify the email address to send the reports to with the following tag in the TXTrecord:
rua=mailto:dmarc@lazyadmin.nl; ruf=mailto:dmarc@lazyadmin.nl;
As you can see we have two different tags here that we need to supply, RUA is used for the aggregate reports and RUF for the forensic reports. Most third-party DMARC analyzers will have a different email address for each.
After you have monitored the DMARC reports for a couple of weeks you can start with moving the mail to the spam folder. This way emails won’t be lost when you forgot to add that new mail system (or web application) to the SPF record.
In the end, you might want to reject emails completely, but keep in mind that if you are not using a DMARC analyzer you won’t know when emails are dropped after a failed SPF and DMARC check. So be careful with the reject policy.
Setup DMARC for Office 365
So now you have an idea of how DMARC works, let’s take a look at how to set up DMARC for Office 365. The steps below are not specific to Office 365 but will work for any domain. To set up DMARC we need to create a DNS record, just like with SPF. So make sure you have access to the DNS records.
The first step is to log in to your DNS provider. I am using Cloudflare, if you don’t know how to create DNS records then contact your hosting provider.
We are going to create a new TXT DNS record:
- Add a new record
- Select TXT as type
- Set the name to _dmarc
- Set the content to:
v=DMARC1; p=none; rua=mailto:dmarc@stonegrovebank.com; ruf=mailto:dmarc@stonegrovebank.com; sp=none; fo=1;
What this record does is monitor p=none all DMARC events, and send a report when SPF or DKIM fails fo=1. It also monitors all subdomains sp=none. The reports are sent to the mail address dmarc@stonegrovebank.com.
When you are ready to move the unauthorized mail to the spam folders, you can change the record to the following:
v=DMARC1; p=quarantine; rua=mailto:dmarc@stonegrovebank.com; ruf=mailto:dmarc@stonegrovebank.com; sp=quarantine; fo=1;
DMARC Tags
Besides the policies and reporting mail address, you have also a couple of other options that you can use in your DMARC record.
| Tag | Options | Description |
|---|---|---|
| sp | none, quarantine, reject | Used to apply the DMARC record to all subdomains. You can set a custom policy for the subdomains. |
| fo | 0, 1, d or s | Determine when to generate a forensic report: 0 – When both SPF and DKIM fail 1 – When SPF or DKIM fails d – Only when DKIM fails s – Only when SPF fails |
| pct | 1 – 99 | Percentage of failed emails that should be quarantined or rejected. Allows you to slowly test the quarantine or reject policy. Does not work with p=none |
Third-party options for DMARC analyses
DMARC reports are sent on a daily basis to the given mail address. The reports are formatted in XML, so they are not easy to read or analyze. There are different DMARC monitoring solutions on the market, like DMARCLY for example.
These monitoring solutions are not free, but they can really help you with analyzing the DMARC reports and speed up the overall implementation.
After you have signed up you can customize and generate the DMARC record after which the reports will be sent to the monitoring tool.
After a couple of days, you will see the first results in the aggregate reports. Keep monitoring the reports for a couple of weeks until you are certain that all your systems are configured correctly in the SPF record.
Wrapping Up
SPF and DKIM are important steps when it comes to protecting your email. But don’t forget DMARC. Most people don’t implement DMARC, because they are afraid that legitimate mail won’t arrive. But by starting with monitoring and using DMARC monitoring tools to analyze the reports you can safely implement DMARC for your Office 365 tenant.
If you have any questions, just drop a comment below.
Thanks for this post.
It was clear and concise.
For adding a Dmarc DNS Record. Added Dmarc with the DNS provide. Not sure if I should add the content we need into admin center as well. Do not know if there are any consequences.
Thanks for your plain English explanation!
Thank you for demystifying this for us. I’m an IT consultant with several clients that need to implement DKIM and DMARC, and you’ve really helped me to understand the steps needed.
could you let us know to turn off spf, dkim, dmarc check for specific senders?
Create a new transport rule in Exchange Online, bypass spam filtering, and apply the rule if the sender > domain is.