Dmarc as a Service

The crucial distinction you need to understand before using DMARC with Office 365 and G Suite

Question: I already use Google/Microsoft to run our mail services. Can’t they take care of DMARC or email authentication for me?

Short answer: They support, but they don’t implement. The distinction is important because for email authentication to work, both senders and receivers need to play a part. Fortunately, 100% of U.S.-based email receivers provide support for DMARC authentication on inbound email. But they can only do DMARC authentication for domains that have published (implemented) DMARC records. 

Internet/Mailbox service providers alone cannot remove the implementation burden for email authentication. 

The little bit longer (but still short) answer: Google, Microsoft, and all U.S.-based Internet/Mailbox service providers, as well as 80% of email receivers worldwide, support DMARC by running authentication checks when receiving email. Unlike some SEGs where you must enable DMARC validation, G Suite and O365 do DMARC validation out of the box. 

However, it is up to the owner of the sending domain to publish the correct SPF, DKIM, and DMARC policies in DNS. Without setting those policies, email receivers — including G Suite and Office 365 — will not have the information needed to determine whether an email is authenticated. Nor will they be able to block spoofed messages that appear to come from that domain. 

Receiving mail systems rely on DNS to authenticate messages. When an email is received, they will run validations utilizing the DKIM key, SPF record, and DMARC record published in DNS — if those exist for the sending domain. If a domain owner hasn’t provided this information to the receivers, no action can be taken. 

In other words, they will validate a policy, but only the domain owner can specify that policy. 

That includes your own domain. To protect yourself from spoofing, you need to enable DMARC checks for inbound mail — and configure SPF, DKIM, and DMARC for your domain in order to protect all email sent as you. This is what is meant by “implementing DMARC.”

Another reason Google/Microsoft can’t just take care of this for you: DMARC is global — and it’s not restricted to just incoming mail

What makes DMARC so powerful is that it provides protection for your domain — globally. While secure email gateways and Internet/Mailbox providers provide additional benefits for organizations that use them, only email being sent into your organization is visible by these technologies. 

DMARC extends beyond just your service provider and provides a mechanism for any receiver to get the information they need to make a determination on the authentication status of the email it has received. What’s more, DMARC provides you (the domain owner) with visibility into all email being sent using your domain. 

Once you’ve implemented DMARC and achieved DMARC enforcement on your domain, it will protect you against inbound and outbound impersonation. Inbound impersonations are aimed at fooling employees into thinking they’re receiving an email from an executive or colleague, like an email that appears to come from asking you to wire funds. 

DMARC at enforcement also protects your domain from being abused outside of your walls, or what is sometimes called “outbound” impersonation. This could be fraudulent emails from asking your customers to update their billing info, or an email from to one of your partners telling them that “your company” has a new deposit account. 

Here’s a quick guide for understanding the different roles of your business and those of a service provider when it comes to email authentication:

Supporting vs implementing DMARC

If you’re interested in learning more about how Valimail automates this process, check out the Valimail Platform.  

Related Articles

Subscribe to our newsletter