How Microsoft and Valimail Work Together
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 important of those layers is the prevention of unauthorized use of your trusted domain to spoof others, or even your own 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 which protect your domain from being used in spoofing attacks, and Microsoft enforces your policies, stopping abuse of your domain before it occurs. Let’s get into details…
DMARC is an important tool for domain owners to deploy to protect the integrity of their domain and their brand. With DMARC, a domain owner can ensure that all uses of their domain in email are authorized, and they can request that mail receivers either reject or spam folder any email that does not pass authentication checks. This is all done through 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 properly. In this whitepaper, we will describe how Microsoft and Valimail complement each other to assist our mutual customers to make sure they derive all the benefits of a proper DMARC configuration.
How DMARC Works
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 authorizes 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 also sometimes called the bounce domain, or the envelope header domain, and is usually only visible to the servers exchanging messages, not to 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 that are 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, on the other hand, is a protocol that allows a domain to take responsibility for a message in a way that can be verified by the recipient. 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 not just in alignment, but identical in order 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
Within Microsoft’s Technical Documentation knowledge base, Microsoft provides information on a tremendous number of topics related to Microsoft 365 and email security. This post describes what Microsoft does for its customers as well as what it doesn’t do, with regard to DMARC, DKIM, and SPF. The next few paragraphs succinctly summarize and clearly describe how we work together.
Inbound DMARC Validation
While it is important for domain owners to protect their own domains and brands by publishing DMARC policy records in DNS, it is just as important for a domain to perform DMARC validation checks on inbound mail and to 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 their reasoning for doing so (namely that some domain owners publish p=reject policies without first making sure that they are properly authenticating their email) is sound, but administrators of Microsoft 365-hosted domains should be aware of this all the same.
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 have to 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, but it can be overwhelming to someone not comfortable with making DNS changes and each environment is unique. Moreover, there is one key piece of information regarding DMARC that doesn’t get enough attention. Let’s talk about how Valimail can fill in the gaps.
How Valimail Can Help
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 make sure everything is in place before moving on to DMARC Enforcement. Valimail uses DMARC reporting to hasten the process of 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.
The way we do this is with Valimail’s Authenticate 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 fairly simple for a domain that only sends mail from one source or one platform, but that doesn’t describe most domains. For those domains that do send from multiple platforms, it can be a challenge to identify all of them, get the SPF record configured just right to make sure they’re all represented, and also 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.
As an example, this is done in our Enforce product in the domain configuration section, by clicking on “Add an Email Domain”:
DKIM
DKIM is a bit more complex, in that it involves not only publishing a record in DNS (the DKIM public key) but also configuring the mail server to sign each message. Valimail can only help with the publishing of the public key, but it’s a vital step 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 the domain’s DNS for DKIM is hosted by Valimail, 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:
Conclusion
With DMARC, domain owners have an important tool to protect the integrity of their domains and brands. Microsoft 365 users can take advantage of the Microsoft and Valimail partnership to deploy DMARC easily, simplifying the complex setup and ensuring accurate and effective configuration.