Cyberattacks are on the rise, and phishing (in particular spear phishing) is a leading vector for them. A serious approach to cybersecurity relies on a layered approach, sometimes known as “defense in depth.” One of the most critical layers is preventing unauthorized use of your trusted domain to spoof others or even your employees or customers.
The way to do this is through a protocol known as DMARC (Domain-based Message Authentication, Reporting, and Conformance). At a high level, DMARC sets policies that protect your domain from being used in spoofing attacks, and Microsoft enforces your policies, stopping abuse of your domain before it occurs.
DMARC is an important tool for domain owners to deploy to protect their domain’s and brand’s integrity. With DMARC, a domain owner can ensure that all uses of their domain in email are authorized. They can request that mail receivers either reject or spam folder any email that does not pass authentication checks. This is all done by publishing a DNS TXT record at a defined location for the domain.
While DMARC is simple in concept, it can be challenging to set up correctly. Below, we’ll walk you through how Microsoft and Valimail complement each other to assist our mutual customers in ensuring they derive all the benefits of a proper DMARC configuration.
How DMARC, DKIM, and SPF work
DMARC
DMARC is designed to validate the usage of the domain in the visible From: header in an email. To do so, it relies on two other email authentication technologies: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
SPF
SPF authorizes the use of a domain based on the originating source address of the email message, and its purpose is to validate the usage of the domain in the Return-Path header. This domain is sometimes called the bounce domain or the envelope header domain and is usually only visible to the servers exchanging messages, not the recipient.
To validate the usage of the Return-Path domain, the receiving server will look in DNS for a TXT record for the domain, which contains a list of servers and networks authorized to send email messages using this domain. If the sending server is found in the allowed list in that record, then the message passes SPF validation; otherwise, it fails.
DKIM
DKIM, on the other hand, is a protocol that allows a domain to take responsibility for a message in a way that the recipient can verify. This is done by inserting a specially crafted header, called the DKIM-Signature, into the message.
This header contains two cryptographic hashes, one of the body and one of a subset of the message’s headers, along with enough other information to allow the receiving mail server to validate the message by attempting to calculate the same two hashes.
If the hashes are the same, then the receiving server can be assured that the message was not altered after the DKIM-Signature header was inserted, and the signing domain’s claim of responsibility can be taken to be true. If the hash calculations do not produce the same result as those in the DKIM-Signature header, the signing domain’s claim of responsibility cannot be validated.
With DMARC, a message will generally pass validation if either of the following conditions are true:
- The message passes SPF validation AND the domain used in the SPF check is of the same organization as the domain in the visible From: header. For example, bounces.company.com and marketing.company.com are both of the same organization, company.com, a condition that is referred to as in alignment; OR
- The message passes DKIM validation AND the signing domain is in alignment with the domain in the visible From: header
Under some circumstances, the domains must be aligned and identical for DMARC to pass.
The purpose of requiring a relationship between the authenticated domains is to provide an extra layer of validation for the visible From: domain. Consider the alternative, where only an SPF pass was needed, with no domain alignment necessary. Under these conditions, the following message would “validate” the domain bank.com, and it should be easy to see why this would be undesirable:
Return-Path: <spammer@badguy.com>
From: <customersservice@bank.com>DMARC for Microsoft 365 customers
Learn how Valimail and Microsoft 365 work together to provide DMARC, DKIM, and SPF records for maximum domain protection.
Inbound DMARC validation
While domain owners need to protect their domains and brands by publishing DMARC policy records in DNS, it is just as crucial for a domain to perform DMARC validation checks on inbound mail and honor published policies. Doing so, along with other email defenses, will help guard against employees receiving phishing emails that could be spoofing any domain, not just the local one.
For Microsoft 365 customers that have their inbound mail hosted by Microsoft, DMARC validation checking is turned on, but note that Exchange Online Protection treats p=reject the same as p=quarantine. This means that even if a domain requests that unauthenticated messages be rejected, they will instead only be routed to the spam folder.
Microsoft is not unique in this position, and its reasoning for doing so (namely, that some domain owners publish p=reject policies without first ensuring that they are correctly authenticating their email) is sound. Still, administrators of Microsoft 365-hosted domains should be aware of this.
Those customers with on-premises Exchange servers, in addition to Microsoft 365, will have to configure those on-premises servers to do DMARC validation as appropriate.
DMARC policy for onmicrosoft.com customers
Microsoft’s product documentation states, “If you use Microsoft 365, but you aren’t using a custom domain, that is, you use onmicrosoft.com, you don’t need to do anything else to configure or implement DMARC for your organization.”
DMARC policy for customers with custom domains
Microsoft 365 customers with custom domains must manually configure all aspects of DMARC for their outbound mail. Microsoft provides information for their customers on what to do and the outlines of what information to publish. Still, it can be overwhelming for someone uncomfortable making DNS changes, and each environment is unique.
Moreover, one key piece of information regarding DMARC doesn’t get enough attention. Let’s talk about how Valimail can fill in the gaps.
How Valimail helps
Valimail’s product line is designed to help our customers get to a published DMARC policy of p=reject (what we refer to as DMARC Enforcement) quickly and painlessly, and we can help Microsoft 365 customers get there, too.
DMARC
The “R” in DMARC stands for Reporting, something that Microsoft doesn’t talk about too much in their informational posts. This feature of DMARC, combined with a policy of p=none, allows you to use DMARC to audit your mailstreams and ensure everything is in place before moving on to DMARC Enforcement. Valimail uses DMARC reporting to hasten moving to DMARC Enforcement for our customers.
Each time a customer begins their journey with Valimail, they publish a DMARC record with a policy of p=none and a “rua” tag pointing to an email address hosted by Valimail. This rua tag instructs all domains that do DMARC validation to send daily reports of aggregate data to Valimail, which we consume and parse to present the data to our customers in a format that makes sense to them.
We do this with Valimail’s Monitor product, which provides unmatched visibility into email-sending services. Based on a suite of patented and proprietary technologies for analyzing sender identities, Valimail transforms the raw data of DMARC reports into highly visual, actionable information in the DMARC Monitor dashboard.
SPF
Setting up SPF is relatively simple for a domain that only sends mail from one source or platform, but that doesn’t describe most domains. For those domains that send from multiple platforms, it can be challenging to identify all of them, get the SPF record configured just right to ensure they’re all represented and avoid SPF’s ten DNS query limit. Valimail’s product line makes it easy: our Instant SPF® technology allows you to publish just one record, easily avoiding the ten-query limit.
Furthermore, our UI gives you insight into all your mail flows, where you can approve senders so that they pass SPF checks with just a click of a button.
DKIM
DKIM is a bit more complex in that it involves publishing a record in DNS (the DKIM public key) and configuring the mail server to sign each message. Valimail can only help publish the public key, but it’s vital to getting DKIM pass verdicts because DKIM signatures can’t validate if the public key doesn’t exist in DNS.
How Valimail helps here is similar to how we help with SPF configuration. We identify DKIM public keys that may not exist for a sending domain and present the user with recommendations to publish those keys. If Valimail hosts the domain’s DNS for DKIM, we’ll even present the user with a form to fill out with the necessary information and then publish the key(s) on our DNS servers.
Adding a DKIM key is done in our Enforce product in the domain configuration section, just as with SPF. However, it’s a different action:
Take advantage of the Microsoft 365 and Valimail partnership
With DMARC, domain owners have an essential tool to protect the integrity of their domains and brands. Microsoft 365 users can use the Microsoft and Valimail partnership to deploy DMARC easily, simplifying the complex setup and ensuring accurate and practical configuration.
If you’re interested in benefiting from this partnership, sign up today.
