DMARCy MARC and the funky bunch
Otherwise known as the benefits of DMARC in your environment
Microsoft published their May 2023 Cyber Signals report this week. They shared information about the surge in Business Email Compromise (BEC). If you can believe it, cybercriminals have created CaaS – cybercrime as a service – to make BEC attacks easier than ever. I’m not going to rehash the report. You can check it out here.
But I thought it would be good to talk about one way to help mitigate these kinds of attacks. Implementing DMARC in your email environment is a fairly simple method to verify the person sending you the email is who they say they are.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication policy that protects against bad actors attempting to use fake email addresses that are disguised to look like legitimate emails from trusted sources.
Emails contain a 5321.MailFrom and a 5322.From address (what the user sees). DMARC simply determines if there’s a match between the two, so that someone impersonating a legitimate 5322.From user would fail because of a mismatch with the 5321.MailFrom value (the true sender, who may be malicious). But to put that more simply, DMARC makes it easier for email senders and receivers to determine whether or not an email actually originated from the person you think it did.
If you use Microsoft 365 as your email solution, you don’t have to do anything to set up DMARC for incoming mail. It’s already taken care of. If you use Microsoft 365 but you aren't using a custom domain (you use onmicrosoft.com), SPF is already set up for you and Microsoft 365 automatically generates a DKIM signature for your outgoing mail. If you have a custom domain or are using on-premises Exchange servers along with Microsoft 365, you need to manually set up DMARC for your outbound mail. Setting up DMARC for your custom domain includes these steps:
"If you use Microsoft 365 as your email solution, you don’t have to do anything to set up DMARC for incoming mail."
This isn't entirely true. Microsoft will not honor a DMARC reject policy for incoming mails. So malicious mails that fail DMARC might just end up in your inbox, junk or in quarantine. Also see https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure?view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc
Improvements are on the way: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-phishing-policies-about?view=o365-worldwide#spoof-protection-and-sender-dmarc-policies
But didn't see it yet in my tenant. It's a good idea to reject mails failing DMARC coming from a domain with a reject policy - by using the option in preview, or by enabling a custom mail flow rule.
Need help setting up DMARC for your custom domain so you can utilize Microsoft 365's built-in DMARC protection? Visit the Microsoft Intelligent Security Association (MISA) catalog to view third-party vendors offering DMARC reporting for Microsoft 365: https://www.microsoft.com/misapartnercatalog?IntegratedProducts=DMARCReportingforOffice365