If you would like to read the other parts in this article series please go to:
What is DMARC?
Spammers often forge the “From” address on mail messages so the spam appears to come from a user in your domain. Domain-based Message Authentication, Reporting & Conformance (DMARC) is a technical specification, published in 2012, created by a group of organizations with the purpose of helping reduce phishing.
A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes, such as quarantine or reject the message. DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages.
The way DMARC works is to help email receivers determine if the purported message aligns with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. DMARC does not directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC requires that messages not only pass DKIM and/or SPF validation, but that they also pass alignment. For SPF, the message must PASS the SPF check and the domain in the From: header must match the domain used to validate SPF. For DKIM, the message must be authentically signed and the domain of the valid signature must align with the domain in the From: header. Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.
Another great feature of DMARC is that it also provides a way for the email receiver to report back to the sender about messages that pass or fail DMARC evaluation. To ensure the sender trusts this process and knows the impact of publishing a policy different than p=none (monitor mode as we shall see), the receiver sends daily aggregate reports indicating to the sender how many emails have been received and if these emails passed SPF and/or DKIM and if they were aligned. This greatly helps organizations deploying SPF and DKIM as they can slowly deploy these features and monitor them without first blocking or rejecting any emails.
DMARC policies are published using DNS TXT resource records and announce what an email receiver should do with non-aligned mail it receives. Because the specification is available with no licensing or similar restriction, any interested party is free to implement it.
Consider an example DMARC TXT for the domain nunomota.pt that reads:
“v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]”
In this example, the sender requests that the receiver rejects (p=reject) all (pct=100) non-aligned messages and sends a report about the rejections to a specified address (rua=mailto:[email protected]). If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they should not necessarily reject the message, but consider quarantining it.
As you can see, DMARC records follow the “tag-value” syntax. The following table illustrates some of the available tags:
|pct||Percentage of messages subjected to filtering||pct=20|
|ruf||Reporting URI for forensic reports||ruf=mailto:[email protected]|
|rua||Reporting URI of aggregate reports||rua=mailto:[email protected]|
|p||Policy for organizational domain||p=quarantine|
|sp||Policy for subdomains of the organizational domain||sp=reject|
|adkim||Alignment mode for DKIM||adkim=s|
|aspf||Alignment mode for SPF||aspf=r|
Only the v (version) and p (policy) tags are required. Three possible policy settings are available for the policy:
- none - take no action (known as monitor mode);
- quarantine - mark affected messages as spam;
- reject - cancel the message at the SMTP layer.
Alignment mode refers to the precision with which sender records are compared to SPF and DKIM signatures, with the two possible values being relaxed or strict, represented by “r” and “s” respectively. In short, relaxed allows partial matches, such as subdomains of a given domain, while strict requires an exact match.
In the following example, if a message claims to be from the domain nunomota.pt and fails the DMARC check, no action is taken. Instead all of these messages appear on the daily aggregate report sent to [email protected]:
“v=DMARC1; p=none; rua=mailto:[email protected]”
In the next example, if messages claim to be from the domain nunomota.pt and fail the DMARC check, quarantine 20% of the messages. Then email daily aggregate reports to [email protected]:
“v=DMARC1; p=quarantine; pct=20; rua=mailto:[email protected]”
DMARC has been designed based on real-world experience by some of the world’s largest email senders and receivers deploying SPF and DKIM. The specification takes into account the fact that in most cases it is very hard for an organization to flip a switch to production. There are a number of methods for “throttling” the DMARC processing so that all parties can ease into full deployment over time.
- Start by deploying DKIM and/or SPF;
- Ensure that your mail servers are correctly aligning the appropriate identifiers;
- Publish a DMARC record with an action of “none”;
- Analyze the data reported by other recipients and modify your email infrastructure as appropriate;
- Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you become more confident in the overall configuration.
DMARC use should be ramped up slowly by employing these policies in this order. First, monitor your traffic and look for anomalies in the reports, such as messages that are not yet being signed or are perhaps being spoofed. Then, when you are comfortable with the results, change the policy setting from “none” to “quarantine”. Once again, review the results. Finally, once you are absolutely sure all of your messages are signed, change the policy setting to “reject” to make full use of DMARC. Revisit reports to ensure your results are acceptable and as expected.
Similarly, the optional pct tag can be used to stage and sample your DMARC deployment. Since 100% is the default, using “pct=25” in your DMARC TXT record results in one-fourth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is useful once you choose to quarantine and reject mail. Start with a lower percent to begin with and increase it every few days. A conservative deployment cycle would be something like this:
- Monitor all;
- Quarantine 5%;
- Quarantine 10%;
- Quarantine 25%;
- Quarantine 50%;
- Quarantine all;
- Reject 5%;
- Reject 10%;
- Reject 25%;
- Reject 50%;
- Reject all.
Microsoft is currently rolling out DMARC to Office 365. Once it is finished, you will not need to do anything to enable DMARC validation for inbound mail. To check if it has already been deployed to your tenant, check the Authentication-Results header. If DMARC is already in place, EOP will add the following DMARC verification information:
The dmarc=<result> indicates whether the message passed or failed DMARC (pass, fail or none). The action=<action> indicates what the recipient’s action should be based on the DMARC result (none, quarantine, or reject). In this case, this was a message sent from my Gmail account to a mailbox in my Office 365 tenant.
As I have mentioned, Office 365 already fully supports inbound validation of DKIM with outbound DKIM signing coming really soon. As such, and at the time of writing this article, all we can do for now is set up DMARC records. And this is what we will be doing in the next part of this article series.
In this article we started to look at DMARC, how it works and what its purpose is. In the next part of this article series we will implement our DMARC record and see it in action.
If you would like to read the other parts in this article series please go to: