It is a rare thing to be given the opportunity to right a historic wrong. The root of essentially every Internet security issue in history is the same—architects try to build fundamentally sound concepts, engineers try to strip out complexity, and developers just try to get their code to compile. Security is and always will be a secondary concern to primary functionality. This is not an editorial about how security should be “baked in”. There is only so much time in the day, so much room in the specification, so much code you can write before you have to ship.
The early IETF groups that defined core Internet standards around SMTP undoubtedly pondered the integration of authentication into the core spec, but were more worried about building a sufficiently simple, scalable solution that developers would implement and people would use. Email security is really, really hard, which is why we are still talking about it 20 years after SMTP was standardized.
The DMARC specification has emerged in the last couple years to pull together all the threads of email authentication technology under one roof—to standardize the method in which email is authenticated, and the manner in which reporting and policy enforcement is implemented. The last two pieces are critical. Prior to DMARC there was no real way to determine how policies were implemented upon email receipt, and no way to determine who was doing what with those emails.
Just like with other successful pre-standard technologies (802.11 wireless comes to mind), the email hosting industry eagerly jumped on the bandwagon and widely implemented DMARC on the email receiver side. Yahoo, Microsoft, Google, LinkedIn, Facebook and others, which make up 80% of the mailboxes in the US, already request and honor DMARC policies. This means that if you as an email sender advertise a DMARC policy, it will be listened to. The cost to do this is exactly $0.
2015 will be the turning point for DMARC implementation by the guys on the other side of the desk — the world’s largest brands and email senders. The IETF working group is currently putting together the draft specification, DMARC policy deployment is increasing, and early adopter feedback is promising. Many large enterprises will be able to realize huge benefits from converting their domain’s email from a source of mistrust, spoofing, phishing and fraud to a bastion of trust by deploying a DMARC policy – at no cost to the enterprise. The OTA’s 2014 Online Trust Audit & Honor Roll, shows that across all verticals, there are huge gaps in DMARC deployment, which continues to erode consumers’ trust in brand’s email communications.
There is zero risk to any large email sender/enterprise in deploying a DMARC policy in “monitor” mode. By doing so, an organization receives, at no cost, incredibly valuable data from all the world’s biggest email providers about who is sending legitimate and illegitimate email from their domain. Organizations can manually parse these reports themselves, using them to remediate unauthenticated email senders, or leverage one of the commercial solutions available to make sense of hundreds or thousands of aggregate reports per day. We have a dog in that hunt with our DMARC Compass product, which is designed to wrangle all the data, track good/bad senders and help illuminate a path to deploying a “reject” policy—the holy grail of email authentication. With a “reject” policy, you have the power to force the automatic deletion of potentially billions of fraudulent or spoofed emails immediately upon receipt.
As adoption grows, those that leverage DMARC will be able to fine-tune their policies to create and foster a more positive customer relationship, while those who ignore this valuable tool will be left behind to face a slow but sure erosion of customer trust. Deploying DMARC will help restore your customer’s confidence in your domain, reclaiming it from decades of abuse, and help contribute to a more secure Internet as a whole. What do you have to lose?