2012/02/16 by Jérôme Gays.
DMARC: A new standard for domain protection
SMTP protocol is old and easy to use. It was invented before 1980 to enable email sending to private networks. Thanks to the native SMTP protocol, it is possible to send an email using the desired sender address, but this option has also created electronic communication reliability issues as , in particular, the development of phishing campaigns. To address this problem, the operators have implemented a new concept allowing senders to authentify their messages.
Email authentication should ensure that senders are truly who they pretend they are.
In practice, it resulted in 4 standards:
SPF and SenderID, place a TXT record in the domain DNS to specify which ISPs are authorised to send emails from this domain. SPF being the common standard based on SMTP dialog MAIL FROM and the in the Reverse DNS domain of sending IPs. SenderID is the Microsoft version based on the “PRA” address domain for which Microsoft has patented the algorithm restricting its use.
DomainKeys andDKIM, which principle is based on a public/private key encryption system applied to some fields of the mail header. DomainKeys was invented by Yahoo and DKIM by the internet community, as for the previous case, DKIM is gradually becoming the most popular .
But these schemes were missing something that would allow senders who correctly authentify their emails to inform receivers, so they can, on their side, filtrate more strictly the unauthenticated messages that often happen to be phishing. A group of important players like Google, Facebook, Microsoft, Yahoo and AOL joined together to develop a new scheme that would fill this gap, creating the DMARC standard which they tried to get approved from IETF.
DMARC (Domain-based Message Authentication, Reporting & Conformance) allow the advertisers to protect their brand et their domain, stating explicitly to the ISP how they want to process unauthenticated messages.
DMARC allows the advertisers to protect their domains by clearly indicating to the ISP the policy they want to adopt regarding mails whose SPF and or/DKIM signatures have failed. Which, in case of a perfect implementation, will stop any phishing attempt on the advertiser’s domain for good. In my opinion, this represents a significant step forwards in terms of domain protection and anti-phishing fight. Another DMARC interesting option for an advertiser is the possibility to receive reports from ISP that show the proportion of authenticated and unauthenticated messages sent to his domain. Which can give him an idea of the phishing volume on his domain.
As sender, in order to implement DMARC, you have to ensure that the correct SPF and DKIM implementation has been performed, then you have to publish a DMARC record in DNS as a TXT record for the zone _dmarc.mondomain.com.
Practical example with delivernow.eu domain:
Domain Type Record
_dmarc.delivernow.eu TXT « v=DMARC1; p=none; sp=none; pct=100; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com; »
p= Processing policy based on the domain to be applied to emails for which authentication has failed. possible value: none, quarantine or rejected
sp= Processing policy based on subdomains to be applied to emails for which authentication has failed. possible value: none, quarantine or rejected
pct= percentage of mails to filter
rua= address where aggregated reports from ISP are received
ruf= address where authentication error reports will be received each time such an error occurs(AFRF)
There are additional attributes for DMARC registration, available in detailed specifications.
At this stage, only Gmail uses DMARC to protect its incoming messages, but you can expect more implementations this year, with , probably Yahoo, AOL and Microsoft.