Phishing attacks victimize the email recipient who opens the message AND the company whose domain name has been spoofed in the attack. If enough people get malicious emails that appear to come from legitimate companies, people simply begin to ignore email from them. Now the DMARC email specifications help prevent that kind of brand abuse.
When we think of the victim in a phishing attack, we think of the unfortunate email recipient that has fallen for a ruse and has given away their sensitive information or downloaded malware to their computer. But there's often another victim in a phishing attack: the company whose brand has been usurped for the purpose of delivering a convincing message, albeit an illegitimate one.
Think of the PayPals, the UPSs and the Citibanks of the world -- the companies whose reputations suffer every time some cybercriminal spoofs a message so that it appears to come from them, businesses the recipient knows and trusts. According to the Anti-Phishing Working Group, an average of 418 companies had their good names besmirched as part of a phishing attempt each month in the last quarter of 2012. Perhaps your own company was among them.
Now there is a technical specification that builds on other email standards to help reduce the potential for email-based abuse of a brand. The specification is called DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance. To explain the purpose of DMARC, we have to go back in time before email authentications standards existed.
Suppose you receive an email message that appears to come from your Local Bank, whose domain is LocalBank.com. With the original email standards anyone could say they were sending email from LocalBank.com, so someone who knows you have a relationship with Local Bank could tell you that you need to reset your password and then send you a link to a fraudulent website to capture your password, account information or other sensitive information.
In this context, the fundamental challenge the messaging industry wanted to solve is message authentication. As the recipient of the email, you need to have confidence that a message that purports to be from LocalBank.com really was issued by Local Bank and not by some entity pretending to be the bank.
There are two standards for email authentication. One is SPF, which stands for Sender Policy Framework, and the other is DKIM, or DomainKeys Identified Mail.
SPF is basically an IP-based path-based authentication mechanism. It allows Local Bank to tell receivers such as Comcast, Gmail and Yahoo, "These are the IP addresses or the third parties that are allowed to send mail on my behalf and these are the IP addresses that they are sending from. If you see something that is not coming from any of these IP addresses, then it doesn't pass SPF and the mail can be rejected." The intention is that spoofed email will never get past the ISPs to the targeted recipient.
DKIM is a signature-based authentication. When a message is sent out, certain parts of that message are signed so when the ISP receives it, they can validate to ensure the pieces of the message that were signed did not change during the transmission of the message. This means the person who receives the message can be sure the content of the email is exactly the same as what was sent.
Between these two standards, you can tell a pretty strong story for email authentication. Not only is the message being sent from a legitimate IP address that is allowed to send a message on the sender's behalf, but you also can be sure the message is original.
But, as it turns out, these two standards aren't quite enough from the ISPs' perspective. The ISPs couldn't be sure if LocalBank.com was using this email authentication technology for all of its email. They were reluctant to take any sort of hard stance on rejecting email that looked like it was coming from LocalBank.com but wasn't authenticated because they didn't know whether the legitimate sender was authenticating all of its mail.
What the ISPs needed was some way for the brand to be able to say, "Yes, I am authenticating all of my mail that you, the ISP, receive from me, and if the mail doesn't have the authentication stamp, it isn't from me." This is where the DMARC specification comes in.
DMARC serves two purposes. One is to initiate that policy mechanism for rejecting email messages that don't adhere to SPF and DKIM standards. This resolves the issue of uncertainty that the ISPs had. The other function that DMARC provides is to yield reports that allow a message sender to have visibility into everyone who is sending mail using that company's brand (e.g., LocalBank.com).
Through these reports, the brand owner can see everything that is legitimately being sent on their behalf, such as all of their legitimate corporate mail and affiliate mail. More importantly, they also can see anybody who is sending malicious email using their name, so they can see where a spoofed email is coming from. They get visibility into what the message looks like as well.
Think about what this means to a brand that is prone to phishing, like PayPal. (Actually, every company is vulnerable to phishing.) Using the DMARC standards, PayPal can have confidence that when it sends messages through a service provider that subscribes to DMARC, only messages that are actually from PayPal will up in a recipient's inbox. That is an incredibly powerful statement to make. What's more, the reporting capability of DMARC gives the company the ability to verify that.
One of the business benefits of DMARC is it helps increase consumer trust in the emails that are coming from a brand when it puts that policy statement in place that says, "I am authenticating all of my mail, so help keep all of the bad emails out of recipients' inboxes." A side effect over time: the legitimate company starts to increase its brand loyalty and reduce any brand erosion it may have suffered.
Another benefit from a brand perspective: DMARC provides visibility into who within an organization is applying these email authentication best practices. Reports indicate what is legitimately coming from a company and what is authenticating and what isn't. That's also important from a compliance perspective. For example, the sender can see if there is some marketing group acting on its behalf that is not following the company's messaging authentication policies.
From the standpoint of being able to protect a brand, DMARC is something that every company can and should deploy today because it has those two mechanisms -- policy and reporting. The call to action I'll leave you with is to deploy DMARC and start getting visibility into where all of your legitimate mail is coming from and, if you have a phishing problem, you'll see where all the phishing emails are coming from as well. Once you have that increased visibility, you can work toward deploying a policy so that the ISPs can start blocking mail that is not coming from you.
To get information and resources to help you deploy DMARC today, go to www.dmarc.org. Check out the FAQ and the Resources pages.
Linda Musthaler is a principal analyst with Essential Solutions Corporation. You can write to her at LMusthaler@essential-iws.com.
About Essential Solutions Corp:
Essential Solutions researches the practical value of information technology, and how it can make individual workers and entire organizations more productive. Essential Solutions offers consulting services to computer industry and corporate clients to help define and fulfill the potential of IT.