Anyone involved with managing Office 365 or other mail systems should definitely have a look at DMARC. DMARC stands for “Domain-based Message Authentication, Reporting and Conformance” and is built upon protocols DKIM and SPF. In combination, DMARC, DKIM and SPF provides email authentication and reporting services.
Specifically DMARC is used to fight fraudulent email also known as phishing. Email phishing attacks is one of the most widespread and successful attack methods seen on the Internet. It works by sending emails that seem to be originating from a trusted source but really is sent from a cyber criminal. The purpose can be to make companies pay false invoices or to gain credentials to enable launching of a ransomware attack, costing companies literally billions of dollars in 2018. It can even be used politically as seen in the Hillary/Podesta case in the 2016 US election.
Outbound (Sending) vs Inbound (Receiving) DMARC Protection
Sometimes I see admins getting confused about the direction (inbound vs outbound) of DMARC protection. When talking about implementing DMARC it’s usually implied that we’re talking about protecting your outbound email communication (sending side): You’re using DKIM to sign the outbound emails and you’re publishing an SPF record with a list of legit sending mail servers. This allows the receiving part to validate that the mail has not been modified and that it was actually sent from a mail server belonging to your organization. On top of this you use DMARC to inform the recipient how to handle DKIM and SPF validation failures and where to send a report of emails failing validation.
Outbound DMARC protection does not protect your organization from receiving phishing or fraudulent emails. If that is what’s plaguing you, take a closer look at your inbound mail scan and make sure it uses DKIM and SPF checking as part of a larger protection suite. Office 365 mailboxes by default use DMARC analysis and filtering of inbound emails whereas DMARC on outbound emails must be enabled manually.
Today approximately 80 percent of all consumer mailboxes have DMARC implemented on the receiving side. This is largely an effect of the early adoption from Google (Gmail), Microsoft (Office 365), and Yahoo (Yahoo Mail).
Overview of DMARC Processing
The following graph illustrates what’s happening on the receiving side:
When an email is received a check is performed to see if the sender has implemented DMARC. The check is performed by looking up the DNS DMARC record, a TXT record named _dmarc.company.com (if the mail is received from @company.com).
If a valid _dmarc record is found the record will instruct the receiving side how to process the email: Most importantly the record states what to do with the email if it fails the DKIM and SPF check and where to deliver reports on mails that fail validation. This gives two awesome benefits to the sender of the email:
- It is the sender (not the recipient) that decides what the recipient should do with emails failing the DMARC check
- The sender has the option to centrally receive information on all emails with DMARC validation fail that were sent using (or impersonating) the company mail domain
During implementation you should set the DMARC failure option to “None” and carefully review the reports you receive from all partners. From these reports you will learn if you missed any hosts in your SPF record or if any servers fail to do a proper DKIM signature. Both are common issues in case of a complex mail sending infrastructure or use of external hosted mail services.
Once you feel confident that all your sending servers are configuring proper DKIM signatures and are listed in the SPF record then you can move forward and change your DMARC policy to Quarantine or even Reject. Quarantine will mark mails as quarantined but able to be released by the recipients where as Reject will drop the email giving you the best protection (assuming your DKIM and SPF setup is flawless).
Configuring the DMARC DNS Record
The DMARC DNS record is always name _dmarc.domainname.com. It’s a TXT record and it has a number of attributes that inform the mail recipient how to perform DMARC processing of emails received from the domain.
Below you’ll find a description of the most common attributes. For a full description of all attributes please refer to RFC 7489, section 6.3.
DMARC Tags
| Attribute | Description | Mandatory | Default Value | Sample Value |
|---|---|---|---|---|
| v | Version - must be set to "DMARC1" and must be the first tag in the list | Yes | - | v=DMARC1 |
| p | Requested policy that recipient should apply to email. Can be set to "none", "quarantine" or "reject" | Yes | - | p=none |
| rua | RUI (mail address) where to send aggregate reports | No | - | rua=mailto:dmarc@company.com |
| ruf | RUI (mail address) where to send message-specific failure information | No | - | ruf=mailto:forensic@company.com |
| pct | Percentage of messages subject to filtering, i.e. only check 10% of emails | No | 100 | pct=10 |
| sp | Policy to apply to subdomains | No | Same as top domain policy (value of p) | sp=quarantine |
| adkim | Assigns strict or relaxed DKIM identifier alignment, "r" is relaxed, "s" is strict | No | r | adkim=s |
| aspf | Assigns strict or relaxed SPF identifier alignment, "r" is relaxed, "s" is strict | No | r | aspf=s |
| ri | Requested interval between aggregate reports in seconds | No | 86400 | ri=43200 |
Using the above information the following could be a sample DMARC record which will do a strict check of DKIM and SPF identifier alignment, quarantine any email that fails the DKIM and SPF validation and send aggregate reports to dmarc@company.com:
How to Implement DMARC
Implementing DMARC is an iterative and continuous process. The below general steps will ensure a controlled implementation that won’t effect your mail delivery negatively. The specific steps needed depends on the type of mail system you’re using.
How to Manage DMARC
DMARC is not a set and forget type of technology. Once the implementation is completed, hopefully with a reject policy, you need to plan how you will monitor it going forward.
For some environments you may just want to review aggregate DMARC reports once every week or month or simply depend on alerts to notice you of any issues. If your mail system is very large and critical to business operations you may want to give DMARC your daily attention.
There are several online solutions available to help you consume DMARC reports and set up alerts like EasyDMARC, dmarcian, DMARC Analyzer and Return Path.
The following shows some sample actions related to DMARC management:
