Microsoft’s O365 platform supports the email authentication protocol called DMARC (Domain-based Message Authentication, Reporting, and Conformance). This protocol prevents spammers from illegitimately using your email domain and sending email with a “From” address that makes email appear to come from someone in your domain. The impact of spammers illegitimately using your domain to send spam or junk email negatively affects your domain quality and domain reputation. The complete Microsoft guide is listed here – Use DMARC to validate to validate email.
SPF record
As with the Gmail guide to DMARC, the starting point is to review the SPF and DKIM settings as an initial activity. See our SPF guide – Starting your SPF journey ? Add DMARC for greater success ! We would also recommend Microsoft’s guide – Set up SPF in Office 365 to help prevent spoofing. You should at least have the following initial tag in your SPF record – “v=spf1 mx include:spf.protection.outlook.com ?all”
Inbound vs Outbound
In the article, Microsoft makes a distinction between inbound and outbound based emails. From the perspective of DMARC, the key aspect for the protocol is to identify legit from fake emails, so its not that concerned about the destination. However, the terms are relevant to DMARC implementation, as the terms reflect the different organizational management and support responsibilities. ie Inbound email managed and supported by IT Operations and outbound email by marketing, customer care and other functional teams. Implementation of DMARC for inbound and outbound email follow the same guidelines of SPF and DKIM record management, however outbound email requires thinking about subdomains, full or cname or manual based delegation and basic 3rd party vendor management.
3rd party Secure Email Gateways – who is the top dog !
O365 subscribers seem to have a 3rd party email cloud filtering service as an added inbound layer, more so than Gmail subscribers. ie ProofPoint, Cisco, Forcepoint(Websense), Symantec, Mimecast etc.
These are classified as traditional email secure gateways that require the MX record to be changed to point to their infrastructure. Although O365 sits behind these 3rd party gateways, it will still perform and validate SPF, DKIM and DMARC records. This introduces a number of issues for both inbound and outbound that need to be addressed. For example, for inbound, O365 SPF validation will fail as the source will show up as the 3rd party email gateway – typically solved with a white-list rule. For outbound, DKIM signature will need to be configured on the 3rd party email gateway, as O365 based DKIM signatures will fail if the 3rd party email gateway adds any disclaimers to all outbound emails.
Microsoft Defender has come a long way since its origins as Exchange Online Protection many years ago. Its efficacy has improved substantially making any additional 3rd party email filtering redundant and costly.
The steps for implementing DMARC are the same for Gmail – Gsuite – Easy guide to add DMARC.
Step 1
Create DMARC record and add it to a subdomain of your domain in the format _dmarc.yourdomain.com (remember the underscore in the front)
There are a number of options to create the record :
- Use Ingressum’s managed DMARC Compliance service, powered by EasyDMARC to generate the record – basic technical expertise required.
- The DMARC record is automatically created, guides advise you how to place it in your domain’s DNS and reports will be sent to the dmarcian dashboard for easier interpretation.
Step 2
You still need a DMARC dashboard to interpret the XML reports.
If you registered with ngressum’s managed DMARC Compliance service, you’re already on your way. Reports should be appearing within afew days of creating the DMARC record in your domain’s DNS.
O365 subscribers have afew more aspects to consider, but overall, DMARC implementation is still just as simple as it is for Gmail subscribers.
by Con Lokos