Malicious MCP Servers & Email Security: The New Supply Chain Threat
by
Last Updated: 9 min read
Key Takeaways
- Attackers are using typosquatted npm packages to trick developers into installing fake Model Context Protocol (MCP) servers.
- These malicious servers inherit pre-authorized corporate API keys, silently BCCing sensitive outgoing data to attacker-controlled domains.
- Because these emails flow through your legitimate infrastructure, traditional filters like SPF and DKIM pass them automatically.
- Closing this gap requires tight application dependency auditing, least-privilege API scoping, and continuous DMARC aggregate volume monitoring.
In September 2025, a single line of hidden code in an open-source npm library shattered our assumptions about supply chain safety. It put malicious MCP server email security on the map as a dangerous new threat class.
The package, postmark-mcp, spent over a week forwarding 3,000 to 15,000 corporate emails every day to an attacker. There was no flashy zero-day exploit here; just a basic, hidden blind carbon copy (BCC) rule executed with full administrative permissions. The fallout was devastating, leaking passwords, internal invoices, customer data, and live authentication tokens.
This is the first documented case of a malicious MCP server breach in the wild. As autonomous AI agents scale across enterprise pipelines, they are exposing a massive blind spot. Traditional defenses like SPF, DKIM, and DMARC were built for an era of predictable, human-driven mail routing. The Model Context Protocol (MCP) paradigm completely scrambles that posture, introducing an insider threat layer that traditional perimeter filters simply cannot catch.
What Happened – The postmark-mcp Incident
Postmark (operated by ActiveCampaign) is a popular transactional email service used by thousands of businesses to send critical automated notifications like password resets and order confirmations. To support the boom in generative AI, an official open-source repository was launched on GitHub to let developers link Anthropic’s Claude AI assistant directly to Postmark’s infrastructure via the Model Context Protocol.
Seeing an easy opening, a malicious actor published a lookalike package named postmark-mcp. This wasn’t a slight typosquatting miss; it was an exact name match designed to snare developers looking for a quick npm install.
The Long Game: Building Trust
The attacker played a calculated long game. Across fifteen sequential version releases (from 1.0.0 to 1.0.15), the package ran cleanly. It mirrored the official repository’s code, executed API calls perfectly, and triggered zero alerts. This allowed it to slide right past automated sandbox checks and earn baseline trust from security tracking systems.
Activating the Payload
Significant damage was done on September 17, 2025, with version 1.0.16. Deep inside index.js at line 231, the publisher added one line of code. This tweak appended a hidden BCC address to every single email payload moving through the server and routed copies to an attacker-controlled domain [giftshop.club].
Because this module sat inside the validated application layer, it already possessed authorized access to live API keys. The attack required no exotic privilege escalation. It worked because the code was running inside a trusted corporate pipeline. The data leak continued until September 25, 2025, when the risk engine at Koi Security flagged anomalous behavioral patterns originating from the library.
The Impact
Post-incident audits by Koi Security and Snyk revealed that the package racked up roughly 1,643 downloads, which translated to around 1,500 active weekly installs leaking data daily.
When caught, the publisher deleted the package from npm. But here’s the real cleanup headache: pulling a package from a public registry doesn’t delete it from active environments. Any active cloud cluster or container pipeline running version 1.0.16 kept leaking data until teams tracked it down and removed it manually. Postmark quickly issued a statement clarifying they didn’t develop, authorize, or maintain the package. Because this was a behavioral backdoor rather than a code flaw, no formal Common Vulnerabilities and Exposures identifier was assigned, which leaves a unique, unverified MCP server supply chain attack footprint in its wake.
If you think your team ever pulled this package, treat it as an active incident: uninstall it from every environment right away, rotate every credential and API key that ever passed through it, and grep your mail logs for BCC traffic heading to the flagged domain. It is also worth checking the rest of the publisher’s account; the same author maintained roughly 31 other packages, any of which could carry the same risk.
Why Are MCP Servers a High-Value Target for Email Attacks?
The Model Context Protocol (MCP) is rapidly becoming the standard integration framework for enterprise AI. Gartner projects that by the end of 2026, 75% of API gateway vendors will have integrated native MCP toolsets to govern agentic AI email security.
What is a Model Context Protocol integration exactly? Think of an MCP server as a secure API bridge connecting an AI assistant (like Claude) to external data repositories, development environments, and third-party tools. Instead of managing a messy web of custom APIs, an AI agent uses this unified protocol to query databases, check CRMs, or orchestrate email pipelines autonomously.
The Core Vulnerability: Total Trust
To be useful, an MCP server needs long-term, expansive operational permissions. When you connect an AI agent to an email gateway to automate scheduling or customer support, you give it full read and write access. It acts like an employee with full delegate rights.
As Koi Security’s CTO Idan Dardikman put it, organizations are essentially handing over god-mode administrative permissions to backend tools built by unverified, untrusted external authors.
Unlike traditional software supply chain hits (like SolarWinds) that target deep infrastructure, third party MCP server risks require zero infrastructure hacking. Attackers just need to trick you into installing the module, and the AI agent runs it autonomously. Because there is no human in the loop to double-check an automated workflow, a compromised library can exfiltrate sensitive data for days without raising a single red flag.
The Email Authentication Gap – What DMARC Can and Cannot Protect
As risk teams scramble to defend against these AI supply chain attack email threats, many assume protocols like SPF, DKIM, and DMARC will block the bleeding. But we have to look closely at what these controls actually handle, and where the gap lies.
What DMARC, SPF, and DKIM Were Designed to Prevent
The core suite of SPF, DKIM, and DMARC was built to stop domain spoofing and block bad actors from executing an email spoofing / BEC campaign using your brand identity.
- SPF verifies if a sending mail server’s IP is authorized in your DNS records.
- DKIM adds a unique digital signature to the header to prove a message wasn’t altered in transit.
- DMARC ties them together, enforcing rules on how receiving servers handle failures.
In the postmark-mcp exploit, these controls weren’t bypassed; they were completely irrelevant. Because the malicious package was embedded inside a legitimate corporate app, it used valid API keys to route messages through authorized Postmark servers. Every stolen email carried a flawless DKIM signature and passed SPF checks perfectly. There is a bitter irony here: that valid DKIM signature even helped the attacker’s own receiving server confirm the stolen messages were genuine.
Where Email Authentication Partially Helps
| Protocol Component | Capability against Malicious MCP Servers | Limitation |
|---|---|---|
| SPF & DKIM | Verifies infrastructure validity. | Passes completely because the attack originates from the authorized application layer. |
| DMARC Enforcement (p=reject) | Prevents external domain spoofing. | Cannot block a valid internal application from executing a BCC rule or leaking data directly. |
| DMARC Reporting (RUA / RUF) | Provides granular visibility into outbound sending volumes and third-party sources. | Requires continuous, automated monitoring and behavioral analysis to spot anomalies. |
What Email Authentication Can and Can’t Do Here
DMARC, SPF, and DKIM were built for spoofing, not insider exfiltration
| Cannot block | Can reveal | Can contain |
|---|---|---|
| The malicious server uses a legitimate API key, so SPF & DKIM PASS automatically p=reject cannot stop a valid internal app from adding a BCC and leaking data directly | RUA aggregate reports map every source sending on your domain A sudden spike in outbound transactional volume is the smoke-detector signal | Moving to p=reject is a backstop against fallout It stops attackers from weaponizing stolen content to spoof your domain in follow-on phishing campaigns |
The Visibility Power of DMARC Reports
While it won’t block the initial code injection, a mature email authentication setup provides vital forensic visibility. This comes down to granular DMARC reports (RUA/RUF).
When properly configured, these records give you an explicit map of every IP and sending service active on your domain. Aggregate (RUA) reports summarize sending volumes by source, while forensic (RUF) reports capture detail on individual failures. If your SecOps team is continuously auditing these streams, they can spot sudden, unexplained spikes in outbound transactional volumes. Tracking those anomalies acts as a smoke detector, signaling that an integration is leaking data.
Creating a Backstop with Strict Enforcement
Moving your domain to a strict DMARC p=reject stance provides a critical safety net against secondary fallout. It won’t stop an internal MCP server from BCCing data out, but it keeps attackers from weaponizing what they steal. A reject policy stops threat actors from using leaked invoices or customer data to launch highly targeted spoofed phishing campaigns against your clients and partners using your actual domain.
The Real Gap – Credential and Permission Hygiene
At its core, this security breakdown was an identity and access failure, not an authentication protocol issue. The exploit succeeded because an unverified piece of software had access to a legitimate, highly privileged API key.
Your primary defense here is code dependency auditing and credential hygiene. However, deploying autonomous AI tools without an active visibility layer leaves you completely blind. Continuous DMARC monitoring creates the active safety net required to catch the behavioral anomalies that point to an active exploit.
How to Protect Your Organization from Malicious MCP Email Attacks
Malicious MCP server email security necessitates operational steps like those below:
1. Audit Your MCP Server Footprint
You can’t secure what you don’t track. Build an explicit inventory of every active integration, plug-in, or connection point tied to your mail setup.
- Verify whether the integration comes from an official vendor repository or an unverified community package on npm or PyPI.
- Explicitly log what data and endpoints each integration can touch.
- Use open-source security tools like mcp-scan to enumerate and analyze your environment for behavioral anomalies.
2. Apply Least-Privilege Permissions to AI Email Integrations
Stop giving wide-open administrative access to automated tools.
- Scope API keys so they only allow the exact actions needed (e.g., sending notifications), while explicitly blocking full mailbox read/write access.
- Enforce strict API key rotation schedules and revoke credentials instantly if a dependency flags an alert.
- Use firewall and network security policies to restrict outbound destinations from MCP servers and allowlist only known corporate email API endpoints.
3. Enable DMARC Reporting and Monitor for Anomalies
If you aren’t actively processing aggregate DMARC data, you have a massive operational blind spot. Setting up a dedicated DMARC Analyzer gives your team continuous visibility, which allows you to track data streams, map volume baselines, and get alerted to sudden outbound transactional spikes before severe damage occurs.
4. Enforce DMARC at p=reject
Leaving your domain at a weak p=none configuration provides no real protection. Transitioning to a strict p=reject enforcement level ensures that even if an attacker manages to exfiltrate mail content via a compromised integration, they can never use that stolen intelligence to launch spoofed campaigns that mimic your official brand domain.
5. Vet MCP Servers Before Deployment
Treat any MCP server module with the exact same scrutiny as any other privileged piece of enterprise infrastructure. Audit the publisher’s history, cross-reference packages against official vendor docs, and review the underlying source code before moving it to production.
To minimize risk, avoid raw community packages and stick to certified, vendor-verified integrations. For teams deploying automation, checking verified vendor options like the PowerDMARC MCP Server ensures a secure, authenticated integration layer built specifically for safe enterprise operations.
The Bigger Picture – MCP Security Will Define the Next Phase of Email Threats
The postmark-mcp library compromise was low-sophistication by design: one developer, a basic name-matching trick, and a single line of hidden code. Yet it triggered widespread data exposure. As businesses rapidly adopt autonomous AI tools and MCP becomes standard in software architectures, threat groups will inevitably roll out much more advanced operations.
Security teams need to prepare for several emerging threat vectors:
- Indirect Prompt Injection: Attackers who send malicious emails designed to manipulate an AI agent reading the inbox and trick it into misrouting sensitive data or leaking internal keys.
- Malicious Workflow Tooling: Attackers are publishing helpful-seeming AI productivity tools that quietly harvest credentials and tokens in the background.
- High-Value Lookalikes: Sophisticated typosquatting campaigns targeting enterprise CRM, HR, and finance integrations on developer package networks.
Email is quite vulnerable because it sits at the intersection of corporate communication, identity verification (password resets), and critical business data. MCP servers bridging AI to this infrastructure have access to all three.
Conclusion
The email threat landscape has shifted far beyond simple external phishing. The postmark-mcp incident proves that organizations now face AI-native supply chain threats operating silently inside trusted internal environments. These integration attacks leverage valid credentials to bypass legacy filters, which is exactly why malicious MCP server email security now belongs on every CISO’s agenda.
Protecting your enterprise requires balancing tight permission controls with continuous data tracking. Combining a strict enforcement policy with deep reporting insights lets you expose unusual sending volumes and catch rogue integrations before data is permanently lost.
Don’t leave your automated systems unmonitored. Protect your domain from hidden, application-layer threats today. See every source sending email on behalf of your domain; start monitoring with PowerDMARC’s DMARC Analyzer.
Frequently Asked Questions
Wait, if my emails are passing SPF and DKIM, how is it an exploit?
Because the call is coming from inside the house. The malicious package isn’t spoofing your domain from some random rogue server. It’s sitting right inside your trusted application environment and hijacking your actual, legitimate API keys. To the rest of the world, your server sent that email legally, which is why cryptographic perimeter protocols give it a green light. It’s a data exfiltration problem, not a server spoofing problem.
If DMARC can’t block the data from leaking, why should I turn it on?
Think of RUA DMARC aggregate reporting as your network’s smoke detector. If an MCP server quietly starts BCCing thousands of operational emails to a third-party inbox, your transactional email volume is going to spike dramatically. If you are actively monitoring your DMARC data feeds, that sudden volume shift stands out like a sore thumb, giving your SecOps team an early warning to audit active code dependencies.
Our team needs AI tools to process support emails. How do we do this safely without completely shutting down integrations?
You don’t need to block AI automation, you just need to put rails around it. First, treat MCP servers like high-risk infrastructure components: never install raw community scripts without code review. Second, scope your API keys with hyper-specific granular permissions; if an agent only needs to send support responses, lock down its API token so it is physically impossible to execute bulk data reads, account creations, or BCC rules. Finally, stick to verified vendor integrations like the PowerDMARC MCP Server rather than unverified community clones.
How do I check if my dev team accidentally installed a malicious MCP server?
Step one is running a software composition analysis (SCA) scan or using open-source tools like mcp-scan to map out your active environment. Look closely at public package registries like npm and PyPI for third-party, unverified community libraries handling your communications pipelines. If a library isn’t directly published and signed by a verified corporate vendor, like the official Postmark repository or the secure PowerDMARC MCP Server, treat it as a liability until the code is manually audited.
Content Specialist at PowerDMARC
Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.
Latest posts by Milena Baghdasaryan (see all)
- Malicious MCP Servers & Email Security: The New Supply Chain Threat - June 9, 2026
- How to Set Up Email Authentication for a Newly Registered Domain - June 2, 2026
- What Is a Phishing Link? - May 19, 2026
