DMARC is the newest of the mail authentication mechanisms having only started life in 2010 and is still awaiting final ratification. The latest DMARC specification was submitted as an Informational Document to the RFC Independent Submissions Editor (ISE) on April 2, 2014. Despite being a new standard, it is estimated around 2 billion Email addresses are protected by DMARC as at May 2014.
DMARC is designed to complement and bolster SPF and DKIM and uses both as its means of validating Email. What DMARC then adds to SPF and DKIM is:
- Enhanced checks; in effect, SPF+ and DKIM+ checks
- A reporting mechanism so that a domain owner can gain visibility of how recipients are handling mail quoting their domain name
- A formal statement of the action the domain owner would like the recipient to take in the case of a message failing the DMARC checks
So what are these enhanced ‘SPF+ and DKIM+’ checks and what are the implications of these checks?
SPF is designed to check that a server sending a message is a legitimate server for the domain it is sending mail on behalf of, e.g. that if it is sending mail from email@example.com, that it is listed as a legitimate mail server for the domain example.com.
The vulnerability with this check is down to how SMTP messages are assembled as they can include two distinct values; the sender of the message (RFC5321.MailFrom) and the name and Email address that appears as the ‘From’ address at the head of the message displayed to the user (RFC5322.From). The two do not necessarily need to be one-and-the-same. You can sometimes see these two headers in use as some mail clients will show a message as ‘from’ one address, but ‘sent on behalf of’ a different address. How sender information is displayed to the user and whether it identifies different ‘From’ and ‘MailFrom’ addresses is, however, inconsistent across mail programs.
The consequence of these different headers is it is possible for a fraudster to send a message quoting a sending address that will pass an SPF check, but to include a quite different ‘from’ address that will be shown to the user. This can therefore be used to dupe the user into believing the message is truly sent by the ‘from’ address displayed to them on viewing the message. To overcome this vulnerability DMARC enforces ‘domain alignment’. Basically this means that the sender and ‘from’ Email addresses must both belong to the same domain with options for how subdomains are handled.
The consequence of this enhanced SPF check is that a message that passes SPF might fail a DMARC ‘SPF+’ check; you need to ensure that the RFC5321.MailFrom and RFC5322.From headers are in alignment to ensure messages do not fail a DMARC SPF check.
In a similar way DKIM could theoretically be subverted by a misalignment between the signing domain and the displayed ‘from’ address, and so again DMARC looks to close this loophole by ensuring alignment between the two domain names. Again, a message might pass a DKIM check, but fail a DMARC ‘DKIM+’ check, although this is unlikely in a real-world situation.
The most probable cause of a misalignment of domain names with either SPF or DKIM is when third parties are sending Email on behalf of an organisation as they may send quoting a sender address in the domain of the service provider, designed to ensure error reports are returned to the service provider, but quoting an address in the client’s domain as the ‘from’ address as this represents the author or party for whom the message was sent.
DMARC also has one other issue to consider. The DMARC standard states that if a DMARC policy is discovered, the receiver must disregard policies advertised through other means such as SPF or ADSP. The consequence here is that a DMARC policy will override an SPF or ADSP rejection policy if the policies are not aligned, e.g. if you set an SPF record with a ‘hard’ -all mechanism, but use a DMARC ‘reporting only’ policy of p=none, then the DMARC ‘take no action’ policy should override the SPF -all, in effect nullifying the hard SPF mechanism.
A key addition to the fight against fraudulent Email introduced by DMARC is activity reporting. The DMARC policy can include lists of Email URLs (mailto URLs, not Email addresses) to which aggregate statistics and failure (or forensic) reports should be delivered by recipients processing mail claiming to be from the domain.
Aggregate statistics are usually sent daily providing details the number of messages processed claiming to be from the domain and the action the recipient took on this volume; essentially how many rejected and how many delivered.
The failure reports (sometimes referred to as forensic report) are a per-message report and are to provide the domain owner with a copy of suspected fraudulent messages in circulation. The intent is the failure reports can aid in counter-fraud activity including fraudulent site take-down and notification to ISPs being used to transmit the fraudulent mail. However, few ISPs honour the failure reporting mechanism due to concerns over the possible disclosure of personal information included in a message by forwarding a copy of the message to a domain owner.
Both the aggregate and failure reports are sent as XML documents contained within a ZIP archive to compress the XML data.
How then do you implement DMARC?
The recommendation is to deploy both SPF and DKIM before using DMARC, however, this isn’t essential. You can for instance deploy a DMARC ‘reporting only’ policy (p=none) with no impact on Email deliverability, but providing the domain owner an insight into Email in circulation quoting the domain.
The logic DMARC applies to mail checks is that if a message cannot pass a check, then it is deemed to fail. There is no concept of an explicit or implicit fail; if a message doesn’t pass, then it fails – period. Hence by deploying both SPF and DKIM you provide a legitimate Email two chances to pass a DMARC check as a DMARC policy only becomes active if the message records a ‘double-fail’. Consequently if you deploy DMARC with only one of SPF or DKIM in place, your legitimate Email only has one chance to pass the DMARC check. However, this doesn’t significantly deviate from a ‘hard SPF’ policy which on its own defines that if a message fails the SPF check, then it should be rejected. Hence having a DMARC policy based on SPF only and defining a DMARC rejection policy is little different to a ‘hard SPF’ alone, other than an ISP’s propensity to follow the policy.
DMARC is defined by the now familiar DNS text (TXT) record mechanism and an example record would be:
Points of note:
- The record is wrapped only to make reading simpler. It would ordinarily be provided as one unbroken string
- The record shows a ‘reporting only’ policy of p=none, e.g. take no action against messages failing the DMARC SPF+ and DKIM+ checks
- A 100% policy application is also defined (pct=100). This is the default, but this attribute does mean that you can vary the application of a policy from 1 to 100% and is an often recommended approach during the introduction of DMARC to ensure there is limited unintentional damage to legitimate Email
- Both aggregate report (rua=) and failure/forensic (ruf=) reporting addresses are shown
- The Email addresses must be provided as a valid URL starting with ‘mailto:’ as shown
- Multiple addresses can be defined as comma-delimited list, e.g. rua=mailto:firstname.lastname@example.org, mailto:email@example.com;
- It is possible to have DMARC reports from one domain delivered to an Email address in another domain although an additional DNS record is then required in the receiving domain’s zone file
This record would be set in the example.com zone and indicates that the domain is willing to accept DMARC reports on behalf of [domainname]. The actual reporting Email addresses would be set in the DMARC record carried in the [domainname] zone. See Figure 12 above.