Microsoft’s Office 365 platform supports DMARC (Domain-based Message Authentication, Reporting, and Conformance). This protocol prevents spammers from illegitimately using your 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.
SPF Record
The starting point is to review the SPF and DKIM settings as an initial activity. We would also recommend Microsoft’s guide – Set up SPF in Office 365 to help prevent spoofing. How your SPF record is formatted depends on if whether Office 365 is the only service:
If you’re using only Office 365:
v=spf1 mx include:spf.protection.outlook.com ?all
If you’re using other services as well, add include:spf.protection.outlook.com to your existing SPF so it looks similar to:
v=spf1 include:spf.serviceA.com include:spf.protection.outlook.com ?all
Once you gain confidence that the SPF record is implemented correctly, change ?all to -all .
Inbound vs Outbound
In the above 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 it’s 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 third-party vendor management.
Third-Party Secure Email Gateways
Office 365 subscribers seem to have a third-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 route email to their infrastructure. Although Office 365 sits behind these third-party gateways, it will still validate SPF, DKIM and DMARC records. This introduces a number of issues for both inbound and outbound that need to be addressed. Take inbound for example, Office 365 SPF validation will fail as the source will show up as the third-party email gateway – typically solved with a white-list rule. For outbound, DKIM signature will need to be configured on the third-party email gateway, as Office 365 based DKIM signatures will fail if the third-party email gateway adds any disclaimers to all outbound emails.
Step 1
Create your 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 for creating the record :
- Use dmarcian’s DMARC Record Wizard to generate the record – basic technical expertise required and all email is sent to your designated inbox.
- Register for a trial on dmarcian – very little technical expertise is required – a DMARC record is created, and guidance is given on how to place it in your domain’s DNS. Reports will be sent to the dmarcian dashboard for easier interpretation.
Step 2
Use a DMARC dashboard to interpret the XML reports. Once you are confident that all of your email resources are accounted for, you can move forward with restricting your DMARC policy so that only legitimate senders are using your domain.
If you registered with dmarcian you’re already on your way. Reports should be appearing within a few days of creating the DMARC record in your domain’s DNS.
