DMARC doesn't fix Phishing

Not a new thing, but a nice example just popped up in my inbox on my phone.

 
But FedEx solved their entire phishing problem when they published a strict p=reject DMARC record, right?
This didn’t come from fedex.com. It came from another domain that looks vaguely like fedex.com – what that domain is doesn’t matter, as the domain it’s sent from isn’t displayed to the user on my phone mail client. Nor is it displayed to the user by Mail.app on my desktop, unless you turn off Mail → Preferences … → Viewing → Use Smart Addresses.

That lookalike domain could pass SPF, it could be used as d= in DKIM signing, it could even be set up with DMARC p=reject. And the mail is pixel identical to real mail from fedex.com.
On my desktop client I can hover over the link and notice it looks suspicious – but it’s no more suspicious looking than a typical ESP link-tracking URL. And on mobile I don’t even get to do that.
SPF and DKIM and DMARC can temporarily inconvenience phishers to the extent that they have to change the domain they’re sending from, but it’ll have no effect on the vulnerability of most of your audience to being phished using your brand.

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

ARC: Authenticated Received Chain

On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.
What breaks?

DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.
This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)

Read More

Are you (accidentally) supporting phishing

One of the themes in some of my recent talks has been how some marketers teach their customers to become victims of phishing. Typically I’m talking about how companies register domains “just for email” and then use those for bulk messages. If customers get used to mail from company.ESP.com and companyemail.com they’re going to believe that company-email.com is also you.
There are other ways to train your customers to be phishing victims, too. Zeltzer security walks us through a couple emails that look so much like phishing that it fooled company representatives. Go take a read, they give a number of examples of both good and bad emails.
biohazardmail
I was a little frustrated that the examples don’t include headers so we could look at the authentication. But the reality is only a teeny, tiny fraction of folks even know how to check headers. They’re not very useful for the average user.
Security is something we should never forget. As more and more online accounts are tied to our email addresses those of us who market to email addresses need to think about what we’re teaching our recipients about our company. DMARC and other authentication technologies can help secure email, but marketers also need to pay attention to how they are communicating with recipients.

Read More