You’re doing everything right – or so you think. You’ve got SPF and DKIM email authentication in place for every mail stream. You’ve got DMARC in place (with a p=reject policy) and you’re telling the world: I authenticate every piece of email I send, and if it purports to be from me, don’t accept it if it doesn’t authenticate. Nobody’s going to successfully send email using my email domain – nobody except me, that is.
But then you see it, hear it, or even worse, read about it. People are receiving spoofed email messages FROM your email domain, even though you didn’t authorize it. Even worse, that bad mail, whether it be phishing, spoofing, or just plain old unwanted spam, is passing email authentication and DMARC checks. You locked the door, but somehow, the attackers still found a key and were able to get access to send mail as you.
This is called reputation hijacking and it’s not only scary, but damaging to your own domain reputation and likely to negatively impact the reputational view of your email domains and your company, as well as damaging your ability to get your (good) email messages delivered to the inbox reliably.
Here are four scenarios that can cause reputation hijacking:
1. Dangling DNS and domains
The scenario:
You’ve added a CNAME or NS record in DNS, or added a new “include” entry to your SPF record, to point toward a new email sending service as part of the setup process to enable proper email authentication for sends from the new service. You successfully use the service for a period of time, but then switch services or email platforms later. The SPF “include” never gets removed, or the CNAME or NS record remains, when it is no longer needed. Or the sending platform changes their name or brand, switching out their own domain name.
What gets left behind?
That old domain reference to a platform whose name has changed that you’ve stopped using. Companies change names or shut down service, and domain names expire. Attackers look for these expired domain names, register them speculatively, watching to see what DNS queries come flying in. They’re looking for exactly this scenario. Dead provider domain, resurrected, allowing them to now send email as your email domain, while passing authentication checks. No true hacking involved; your infrastructure was never compromised. You put a link out there with an open end and phishers were able to find and connect to it.
The fix:
Monitor for no longer used sending services, and revoke their authorization. Periodically review to look for email sending services your organization no longer being utilized. For those no-longer-active services: Delete their SPF “include” references. Discard DKIM keys. Disable CNAME and NS entries.
This way, you’ll close the door to future exploits using forgotten partner vendor domains.
2. Typos in service links
The scenario:
You’re in the process of adding a CNAME or NS record in DNS, or adding a new “include” entry to your SPF record, to point toward a new email sending service as part of the setup process to enable proper email authentication for sends from the new service.
But, you’ve typo’d one of those domains. A record might make reference to “vendormaii.com” instead of “vendormail.com” (mis-spelling “mail” with two i’s instead of an i followed by an L).
Now you’re offering up a link to … who knows where. And you’re not the only one. Typos in DNS are very common, and criminals can scan DNS looking for references to typo’d domains. Are any of those typo’d domains registerable? Are they exploitable for email authentication mis-use? Potential scammers are watching for domain references published by big brands, or published many times
The fix:
Don’t type DNS records; copy and paste is your friend. Don’t trust fingers on the keyboard. Double check entries after they are created. Perform a Google search for that exact string, text or domain you’ve added, and make sure it links back to the right help pages or setup documentation for that email platform.
3. Zombie service resurrection
The scenario:
Your company uses a particular email send platform for a period of time, maybe one of those very popular transactional email API services. They’re quite popular, and there are a number of them out there. Maybe you even switch services at one point. You abandon the account – but on your way out the door, did you lock that account down? If a cyber crook were to attempt to access this email service today, would they be able to get into, and send from, your account on the platform, using your credentials?
If those unsavory adversaries are able to get access, they’ll be able to send email messages from that platform, using your credentials, and your email domain. Passing every email authentication and DMARC check that you had previously enabled. Mailbox providers will think the mail came from you, because the send process and platform used are commonly used to send millions of emails every day.
The fix:
In addition to revoking email authentication authorization in DNS (see above), be sure to have a structured shutdown process when a send platform (or any external vendor) will no longer need to be accessed. Review settings in the platform’s configuration to look for things to delete, disable, or otherwise lock down. This includes deleting API keys, resetting credentials (passwords and 2FA) to ensure they’re as secure as possible, and auditing user access to look for user accounts that should be deleted, so that you don’t later find that they weren’t as secure as they should have been.
4. Unauthorized account access
The scenario:
You’ve memorized everything above and are following all the best practices you’re aware of when it comes to DNS typos, service authorization, dangling domains, and abandoned platforms and vendor partnerships. But, still, somebody, somehow, is sending email using your domain, and it’s passing authentication checks.
In this case, you have perhaps locked all the doors to access your email domain directly. But what about the windows?
Every employee in your company can send email using your email domain. It’s a necessary part of their job. But how secure are those users’ accounts? What requirements, and controls, do you have in place when it comes to limiting access and preventing email account takeover (ATO)?
If a malicious abuser can gain full control of an employee’s laptop, or of their email account, they’ll be able to send email as that employee, impersonating their way to a costly data breach or security incident.
The fix:
Follow best practices when it comes to securing employee access to hardware and software, local and remote accounts, and vendor partner logins. Requiring phishing-resistant MFA (multi-factor authentication), prohibiting weak passwords, securing hardware with recent patches and updated software, implementing conditional access and risk-based authentication, these are just a few of the important steps that will help you keep your overall environment, and not just your email domain, safe and secure.
When authentication alone isn’t enough
For years, the industry’s answer to email fraud has been: “Authenticate your mail.” This is still true, and still very important. But as DMARC adoption grows, attackers are realizing they can no longer easily spoof protected domains. Instead of trying to bypass DMARC, they are now trying to ride on top of it.
By using authenticated paths, hijacked emails can bypass traditional spam filters and secure email gateways (SEGs). After all, the email looks perfect to a machine. It has the right keys, the right records, and the right reputation. It just has the wrong person behind the keyboard.
This “Reputation hijacking” is the next frontier of the email battleground. It is less about the strength of your “locks” and more about the management of your “keys.” At Valimail, we believe that the only way to truly secure a brand is to ensure that no one, not even a “trusted” third party, can use your reputation without your explicit, real-time consent.
It’s time to close the doors (and windows) that you didn’t know were open.
