Don't Make It Easy For The Phishers

A few years ago, a smart product manager showed me a way to visualize the evolution of features in a legacy product. It looked like kind of like a set of stairs. At the bottom were the basic features that the product had when it launched; those had become standard, every competing product had them also, but they were still required. Above that, the 2.0 features — also now standard, also still required. Above that, the 3.0 features which weren’t quite standard, but were now expected by users. And at the top, the features we planned to release soon — unique to our product, certain to excite our users, but built on the foundation of everything which came before. Viewed that way, it was clear that neither the old nor the new, the de rigeur or the shiny, could be ignored.

This model works for security features, too — especially when addressing spam and phishing, where relatively simple prevention methods like IP-based blacklists are still extremely effective. The old methods can never catch all of the newest attacks, which causes some analysts to declare them useless — but ancient spamming techniques are still used by a surprisingly large percentage of miscreants, and their messages can be just as destructive as the tricky new stuff. Neither the old nor the new, the easy or the difficult, can be ignored.

There’s no such thing as a Final Ultimate Solution to the Spam Problem, or a Final Ultimate Solution to the Phish Problem. What works is security in layers — and more layers, and more layers, and more layers. Yet in the search for that FUSSP or FUSPP, some of the simpler, lower layers have been skipped over.

One of these, believe it or not, is email authentication. Despite early predictions from wild-eyed, ill-informed enthusiasts, neither SPF nor DKIM will stop spam. They also won’t stop all phishing. But they’re extremely effective in catching specific types of phishing, especially when applied to mail inbound to your own system.

As you’ll recall from my series on DKIM a couple years ago (parts 1, 2, 3, 4, 5), checking DKIM on inbound messages tells us two basic things:

1. does the message have a valid signature? (yes or no)
2. which domain signed the message?

When a message has a valid signature, and that signature was applied by your domain name, then you know the message is from a mail server under your control. In most cases, that’s enough to know you can trust the message, let it bypass spam filters, et cetera.

The converse is also true: when a message does not have a valid signature, yet it claims to be From: your domain, you know you shouldn’t trust it.

So here it is, the simplest anti-phishing method to date:

1. start signing all your outbound mail with DKIM
2. use Return Path’s Domain Assurance tool to audit your mailstreams, and make absolutely sure that you’re signing everything correctly (there are other ways to do this, but ours is easier)
3. configure your mail server to reject all non-authenticated mail which purports to be From: your domains

Similarly, if the message is signed by any other domain you trust, you know you can trust the message — at least as far as you trust the domain which signed it. Perhaps that domain belongs to a corporate partner, or an employee’s home system; you can add those trusted domains to your DKIM whitelist, and be protected from forgeries of those domains too. (Assuming, again, that your partner/employee/etc signs all of their legitimate outbound mail.) And they can do the same for your domains, creating a small but effective web of trust.

Doing the same thing with SPF is a bit trickier. SPF tells you which IP addresses are authorized to send mail on behalf of a particular domain, so in effect you’d be configuring your mail server to only accept mail which purports to be from your domain (in the SMTP MAIL FROM or HELO; SPF ignores the visible From: header) if it’s from an IP address you control. You could do the same thing without SPF, since you know what those IP addresses are.

Problem is, there are often legitimate reasons for mail to leave your system from one IP address, and return from another. Forwarding services and mailing lists are the standard examples; there are probably more. As such we’d recommend being very cautious with the SPF method and focusing instead on DKIM.

Obviously, neither of these would catch messages which don’t forge your domain. You’ll need additional tools for those. But why not implement the simplest protections first? Don’t make it easy for the criminals to get to you or your users. Neither the easy nor the difficult can be ignored.

minute read

Popular stories



BriteVerify email verification ensures that an email address actually exists in real-time


The #1 global data quality tool used by thousands of Salesforce admins


Insights and deliverability guidance from the only all-in-one email marketing solution

GridBuddy Cloud

Transform how you interact with your data through the versatility of grids.

Return Path

World-class deliverability applications to optimize email marketing programs

Trust Assessments

A revolutionary new solution for assessing Salesforce data quality


Validity for Email

Increase inbox placement and maximize subscriber reach with clean and actionable data

Validity for Data Management

Simplify data management with solutions that improve data quality and increase CRM adoption

Validity for Sales Productivity

Give your sales team back hours per day with tools designed to increase productivity and mitigate pipeline risks in real-time