Various fraud prevention techniques to prevent almost all email spoofed phishing attempts have been in place for a while. However, twice today I received what has become a very rare complaint: spoofed email. I logged in and expected to find the likely culprit: misspelled domains, similar to the phish target. Normal stuff – some permutation of the domain, I supposed. SPF (Sender Permitted Framework) in the past, with a very restrictive record, would prevent these types of attacks.
Upon analyzing the headers, I quickly realized that this indeed had arrived in the target mailbox with a from address that absolutely matched a known sender. How could a very restrictive ‘-all’ SPF fail in such a manner? My first thought was “Compromised account!!!”. Not so.
SPF records are DNS (Domain Name System) entries that specify to receiving hosts where mail should be coming from. A restrictive entry will cause recipient hosts to reject a message if it doesn’t come from one of these authorized hosts. Where did it fail? SPF=Pass? This was quickly explained when digging a bit deeper.
Due to the popularity of Office 365 and other unified platforms hosting large swaths of the business email, SPF records that need to be in place are now overly broad. Because of the sheer volume of mail domains, as well as the ease of obtaining a ‘free trial’ anyone can send from this service from an address that will cause the SPF record check to pass!
Certainly, there won’t be a technical fix coming forward any time soon to this dilemma. It would be a huge undertaking and really uproot the fundamental architecture of such a service. Second, the impact on end users would be significant as each of them would need to make changes to their own domain hosting account. The sheer support logistics are appalling.
Now what can we do to prevent spoofed phishing attacks?
Certainly, we cannot expect a fix from the vendor and must assume responsibility – it is what it is! Enter DKIM “DomainKeys Identified Mail”. DKIM is a similar scheme to SPF. In addition to authorizing, it also provides cryptographic domain-specific authentication.
Where SPF fails due to its now overly broad authority segment, shared among millions of users, DKIM steps in to provide proof specific to the domain in question. DKIM cryptographically signs messages with domain linked data that can be verified by any recipient. This works in conjunction with SPF, but does not depend on it.
Please, deploy both. I’ll write about DMARC in another post, which ties the two together for the ultimate in phishing protection.
As a Microsoft Cloud Solutions Provider, I am pleased to be able to report that they’ve made it very easy to deploy for Office 365 customers. The only gripe I have is that it is buried within, not advertised, and certainly not called out. This technology sets up so easily that it should be part and parcel of onboarding a new domain. It should be difficult *not* to set it up.
How to implement?
First, create two CNAME records within dns. The host will be elector1._domainkeys and selector2._domainkeys respectively. The value will point to selector1-<domainGUID>._domainkey.<inititalDomain>.
To decipher, <domainGUID> is the customized portion of the MX record for the account. ‘contoso-com’ and <initialDomain> is what you signed up for Office with – contoso.onmicrosoft.com will likely ring a bell.
Second, visit the Exchange Admin Portal, click the protection group, and all the way to the right you’ll find DKIM. Highlight the domain in question, click enable. That’s it. If you have your domain records set up appropriately, it will enable and you’ll be much better protected from phishing attacks – and so will your clients, partners and vendors alike.
Probably, there are considerations beyond just using a ‘-all’ SPF record or implementing DKIM comprehensively in a larger organization. Setting this up hastily is a surefire way to get legitimate mail of your own classified in someone else’s junk mail box or flat-out rejected. It’s important to consider all sources of legitimate mail. This can include services like MailChimp and Constant Contact, devices sending status reports, mailing services from EDI and ERP platforms, scanners and more.
How does your business stack up? Check out this free tool – just enter your domain and it will spell out the defects in your email system that can have catastrophic consequences. There are some DNS related warnings that are common and no problem, but if you see red, look out!
Collett Systems helps businesses implement these technologies carefully with zero guesswork allowing you to know that your mail has the highest deliver-ability and trustworthiness possible while avoiding pitfalls that keep IT staff from implementing these in the first place. Prevent phishing and fraud within your business. Call today or message us to the right and let’s button up your email system!
Check out our managed security services for another layer of defense, and thank you for stopping by!
“No Time for Down Time”