DMARC doesn’t fix phishing

Over the last few weeks I’ve had a lot of discussions with folks about DMARC and the very slow adoption. A big upsurge and multiple Facebook discussions were triggered by the ZDNet article DMARCs abysmal adoption explains why email spoofing is still a thing.

There are a lot of reasons DMARC’s adoption has been slow, and I’m working on a more comprehensive discussion. But one of the absolute biggest reasons is that it doesn’t actually fix phishing.

One of the first adopters of DMARC is PayPal. But being an early adopter and publishing a p=reject for years and years has not actually stopped the bad guys from sending PayPal phishes. Here’s an example of one I received recently.

The message clearly shows it’s from PayPal. The sending domain is authenticated with SPF. The SPF domain and the 5322.from domain align. The message is DMARC authenticated.

No, the domain in the From: address isn’t @paypal.com, but that doesn’t matter because a huge number of mail clients, including Gmail, Hotmail, Apple Mail, and Outlook hide the actual email address from the user. All it displays is the so-called friendly from.

The people who think DMARC should be a requirement for email will tell you that this is not the problem space DMARC is supposed to fix. That DMARC is solely intended to fix direct domain spoofing. This is true, DMARC is not intended to fix this type of phishing.

I actually put a lot of blame at the feet of mail client developers. I don’t know who thought it was a good idea to hide the 5322.from address from the user, but they were wrong. To my mind it’s a bad user experience and makes recipients more vulnerable to falling for phishing schemes.

I understand that DMARC isn’t intended to fix this type of phishing. But the fact that it doesn’t fix this type of phishing makes it a whole lot less useful as an anti-phishing product. The tiny scope of DMARC and the expense of implementing it is one of the primary reasons it’s not more widely deployed.

The interesting bit, though, is even without widespread deployment, phishers have changed their attacks. We can declare DMARC a success at stopping direct domain phishing, even though there’s a less than 25% adoption rate. The phishers have moved on. Now, maybe we should look at other ways to address the phishing problem, one that encompasses the majority of attack vectors, rather than a very narrow one.

Related Posts

Fun with opinions

Over the last few weeks I’ve seen a couple people get on mailing lists and make pronouncements about email. It’s great to have opinions and it’s great to share them. But they’re always a little bit right… and a little bit wrong.

Read More

Beware the oversimplification

stencil.linkedin-post-7
Setting up a DMARC record is the easy bit. Anyone can publish a record in DNS that will trigger reports to them. The challenge is what to do with those reports and now to manage them.
DMARC is a complex protocol. It builds on two other protocols, each with their own nuances and implementation issues. I’ve written in the past about what DMARC is, what you need to know to decide if you’re ready for DMARC and walking through whether or not you should publish DMARC. I’ve done talks where it’s taken me 20 minutes and dozens of slides to set up the context for explaining DMARC. Even experienced email folks can have moments where we get confused by some of the nuances.
DMARC is not a passive protocol. DMARC is an active protocol. Even with a p=none record, there is ongoing monitoring and work. Why consume reports if you’re not going to monitor them? The reports are there so that senders can monitor their authentication. If you’re not monitoring, then why waste cycles and bandwidth to receive them? Do you even know if your mail aligns? Can your mail server handle emails with attachments larger than 10MB? Does your mail server block .zip files? All of these things can cause your mail to be rejected and you won’t receive reports.
Postmark has a great post on DMARC and even has some examples of reports.
I know, I know, there’s a lot of fear mongering about how any company not publishing DMARC isn’t going to get to the inbox. We’re not there, yet. We likely won’t be there in the next few years. We may never get there. In any case, it’s much better to actually think about what you’re going to do with DMARC Plus, ISPs are already checking for DMARC style alignment even in the absence of a DMARC record. You don’t have to publish DMARC for this to happen, it already does.
I’ve said it before: publishing a DMARC record is a good idea. But every company needs to take minimal steps to figure out if publishing DMARC, even just to receive aggregate reports, is the right thing for them. It’s not right for every company or domain at the moment.

Read More

You're kidding me

All the authentication and DMARC in the world can’t save you from stupid.
I just got a survey request from my bank. Or, at least, it claimed to be from my bank.

Read More