Microsoft’s Office 365 (O365) email exchange server is undoubtedly one of the largest industry players and acclaimed email exchange service providers out there. However, from a security perspective, just like any other email service, there are a few loopholes that attackers and impersonators can easily exploit.

Email security is extremely essential in the current scenario with companies switching from office environments to remote working infrastructures, which has exponentially increased digital communication and thereby email fraud. Let’s first explore O365’s existing security protocols and why we need to implement email authentication protocols like DMARC, SPF, and DKIM to build on them for better protection.

Email Security Weaknesses in Office 365

• MX Records impact the functionalities of O365’s integrated security gateways

An MX record is a type of DNS record that allows you to point your domain to different email servers, which makes it quite an adaptable mechanism. For added security, Office 365 recommends that you point your MX record to Office 365 for your organization’s domain. By doing so, Office 365 can authenticate messages and IP addresses to validate incoming email messages on your behalf. If you don’t direct your email MX records to Office 365, some of the functionality and protections available to Office 365 users won’t be available for you.

As you may know, for an email to be delivered, messages need to flow through your mail server. By pointing your MX record to Office 365, you ensure that the email sent in your domain is securely and reliably delivered. Therefore, when you use a verified domain as your Office 365 SMTP address, the service sends all emails from your organization through Office 365 mailboxes. This lets you use the spam filtering and antispam features that are built into Office 365.

• Built-in Spam Filters for O365 aren’t effective against sophisticated Social Engineering Attacks

As much as we like to rely on our email system providers to protect us, enterprise security is still the responsibility of everyone in the organization. For instance, you cannot depend entirely on your Office 365’s anti-spam protection, since it just deals with spam content and not with phishing sources that are coming from your own domain, such as in the case of more sophisticated email-based attacks like domain spoofing. This is where implementing DMARC for O365 becomes mandatory for that extra layer of all-around protection.

• Lack of Visibility on your Email Channels

Office 365 also fails to provide you with visibility on your email flow and authentication results. When your emails fail authentication, as a domain owner you would like to know what caused the authentication failure. This will help you resolve deliverability issues and respond to impersonation attempts faster. DMARC report analyzer does exactly that. With the help of these comprehensive XML reports, you are presented with a wealth of information regarding sending sources and underlying IP addresses for all emails sent on behalf of your domain.

Setting Up SPF, DKIM and DMARC for Microsoft Office 365

Before you implement Office 365 DMARC, you need to configure SPF and DKIM.

Step 1: Create a TXT SPF Record

First off, you would need to create an SPF record for O365, which would be something like this:

v=spf1 include:spf.protection.outlook.com –all (for a new record )

v=spf1 include:spf.zoho.com include:spf.protection.outlook.com -all (in case you are adding O365 to an existing SPF record)

We recommend you generate an SPF record with our free SPF record generator, which would help you evade syntactical errors.

Step 2: Publish the SPF record in your DNS

Simply log in to your DNS management console and publish the record in the DNS records section for your domain, using TXT as your resource type and @ in the Name/Host field.

Step 3: Create DKIM CNAME Records

For DKIM setup for O365 you would need to create 2 CNAME records like the following:

Host: s1._domainkey.yourdomain.com

Pointing to: s1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Host: s2._domainkey.yourdomain.com

Pointing to: s2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Note: replace yourdomain.com with your domain name, and s1 and s2 with the DKIM selectors for your domain.

Step 4: Publish the DKIM CNAME records in your DNS

Simply login to your DNS management console and publish the record in the DNS records section for your domain, using CNAME as your resource type.

Note: In order to start signing your emails with DKIM while using O365 as your email vendor, you need to activate it for your domain. To do so, log in to your O365 Cpanel and navigate to DKIM. Enable DKIM signing for the domain for which you have published the CNAME records.

Implementing DMARC Email Authentication and Reporting for Microsoft Office 365

The final step to ensure well-rounded email security and protection against domain spoofing, BEC, and domain name impersonation, is to implement DMARC in your organization with PowerDMARC! DMARC makes use of domain alignment to verify sending sources making use of both SPF and DKIM authentication standards. It provides a way for domain owners to specify to receiving MTAs how to respond to emails failing authentication checks, so you are always in control.

Our DMARC analyzer helps you gain maximum protection against fraud while improving your email deliverability rates over time. With a user-friendly dashboard to view your DMARC Aggregate (RUA) reports in organized and human-readable formats, we make integrating DMARC for O356 users extremely simple and automated.