Gartner has included DMARC, or Domain-based Message Authentication, Reporting, and Conformance, in its list of the top ten security initiatives for 2021. With rare exceptions, integrating DMARC into Office 365-based email ecosystems is the best option for enterprises to avoid being impersonated in email assaults.
To understand why, explore the advantages of installing DMARC inside Office 365 settings, as well as success suggestions for deploying DMARC for your firm.
DMARC and its Benefits
Every month, fraudulent emails purporting to be from a legal, trusted source cause over $7.5 billion in corporate losses globally. According to the Ponemon Institute, the cost to U.S. firms, brought about by these scams, currently averages $3.86 million per event.
DMARC's main purpose is to avoid this. DMARC is an email authentication standard that serves as a policy layer for Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to assist email receiving systems in determining when an email has not been approved by the firm whose From header domain it bears. DMARC instructs email receiving systems on how to properly delete these unlawful communications.
Its most zealous enforcement policy is rejected (p=reject), which indicates that email communications that do not pass DMARC authentication will be prevented from reaching their intended recipients. Less stringent policy options include quarantine (p=quarantine), which places such emails in the spam folder, and monitor only (p=none), which assists companies in monitoring how their domain is being spoofed but does not safeguard the receivers of those emails.
Because DMARC is already embedded into O365's comprehensive security safeguards, you are well protected against most inbound phishing and spam attempts. In truth, you don't need to do anything to enable DMARC for emails received through Office 365. Furthermore, if you do not utilize a custom domain for outgoing email and instead use the standard onmicrosoft.com subdomain, you will not need to configure or deploy DMARC on your Office 365 tenancy.
However, if you have set your Office 365 tenant to use a custom domain (for example, yourcompany.com), or if you use third-party email services like SendGrid, MailChimp, Salesforce, Marketo, or others, you will need to deploy DMARC yourself.
But where do you begin with DMARC in your Office 365 environment?
Set-Up DMARC for OFFICE365
We advocate a staggered DMARC rollout. This is especially true for big organizations that are adopting DMARC across a significant number of domains that span divisions, departments, and third-party senders. This ensures that you don't disrupt the remainder of your email flow.
EmailAuth suggests a multi-step approach to DMARC deployment. Before going on to the following phase, each step's execution should begin with a single subdomain, then progress to additional subdomains, and eventually complete with the organization's top-level domain.
Best practices for DMARC implementation include:
- First, assess the impact. For big businesses implementing DMARC across several domains, we recommend starting with a basic monitoring-mode record. A monitoring-mode record is a DMARC TXT record with the policy ‘p=none’ set. Many businesses publish a DMARC TXT record with ‘p=none’ because they are unclear how many emails they would lose if they implement a more stringent DMARC policy, and this allows them to monitor the impact before making changes.
- Incorporate SPF and DKIM into your strategies. Remember that you won't be able to safely quarantine or reject email using DMARC until you use SPF and DKIM on all valid email sources. All of the servers sending emails for your domain will be shown in your DMARC reports. Once you've successfully deployed SPF and DKIM on genuine mail sources, fraudulent emails will be easy to spot since they'll fail DMARC and come from servers that don't belong to you or any of your approved senders.
- Request that email that fails DMARC is quarantined by external mail systems. When you think that the majority of your valid traffic is protected by SPF and DKIM, and you understand the implications of deploying DMARC, you may put in place a quarantine policy. By doing so, you instruct DMARC receivers to route communications from your domain that fail DMARC to the local equivalent of a spam folder rather than your customers' inboxes.
- Request that email that fails DMARC not be accepted by external mail systems. This final step is to set a reject policy after you are satisfied that your valid emails have been completely verified. This instructs DMARC receivers not to accept messages that fail the DMARC tests. This is the last and most effective method of securing your domain since it stops unauthorized emails from reaching your end-users.
When installing DMARC across many domains, keep in mind that DMARC records are hierarchical. This can be advantageous since you may be able to provide fewer high-level DMARC entries for broader coverage.
However, if you do not want the subdomains to inherit the top-level domain's DMARC record, you must establish explicit subdomain DMARC records.
To learn more about DMARC records and to verify your pre-existing record head to EmailAuth.