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.
Facts Only
* SPF and DKIM email authentication are implemented for every mail stream.
* DMARC is in place with a p=reject policy.
* Reputation hijacking allows spoofed emails from a domain to be received.
* One scenario involves leaving old CNAME or NS records from former sending services active after switching platforms.
* Attackers exploit expired or defunct domain names that can be registered speculatively.
* A second scenario involves typos in DNS records, which criminals scan for exploitable domains.
* Zombie service resurrection involves failing to lock down access on abandoned email send platforms.
* Unauthorized account access involves security gaps in employee credential management.
* The fix for dangling references involves deleting SPF includes, discarding DKIM keys, and disabling CNAME/NS entries for unused services.
* The fix for typos involves meticulous checking of DNS entries and cross-referencing with documentation.
* The fix for zombie services requires a structured shutdown process, including deleting API keys and resetting credentials.
* The fix for unauthorized access involves securing employee access through phishing-resistant MFA and strong credential policies.
Executive Summary
Full Take
The narrative pivots on the realization that technical authentication (SPF/DKIM/DMARC) is insufficient defense against modern email impersonation, shifting the focus from locking doors to managing keys. The core pattern uncovered is that security vulnerabilities reside not in the protocol implementation itself, but in the operational hygiene surrounding third-party integrations and human access management. Attackers exploit the latency between infrastructure change (switching services), typographical errors (typos), system abandonment (zombie accounts), and access control failures (user permissions) to achieve reputation hijacking. This suggests a systemic failure where trust is placed too heavily in static technical configurations rather than dynamic operational oversight. The implication is that true security requires continuous, dynamic auditing of all external dependencies—vendor contracts, DNS records, and user entitlements—rather than focusing solely on the protocol layer.
What are the overlooked assumptions about organizational behavior that allow these vulnerabilities to persist? If adherence to best practices is assumed, what mechanism exists to enforce that operational discipline consistently across an organization, especially concerning ephemeral service integrations? Furthermore, if reputation hijacking is the frontier of the battleground, does relying on technical controls alone effectively address the underlying human element required to manage dynamic vendor relationships and employee access?