The Ultimate Betrayal: How One Trusted Team Member Brought Mailvio’s Email Infrastructure to Its Knees

Four days. Almost no sleep. An entire email infrastructure to rebuild. And one painful lesson about what happens when the trust holding a small company together is shattered.

Building a bootstrapped SaaS company is not for the faint of heart.

At Mailvio, we’re a small team competing against giants. Companies with massive budgets, dedicated security departments, entire DevOps teams, and resources we can only dream of.

We don’t have those luxuries.

What we do have is determination, technical ingenuity, a team willing to go the extra mile, and something absolutely essential to making a small operation work:

Trust.

When you’re a small team, you can’t personally oversee every server, every line of code, or every technical decision. You hire people for their expertise, give them the tools and access they need, and trust them to do their jobs.

Sometimes that trust is misplaced.

And sometimes, the consequences are far worse than you could ever have imagined.

On Thursday, October 1st, 2026, we experienced what our forensic investigation indicates was a deliberate act of sabotage against Mailvio’s email infrastructure.

Not by a competitor. Not by an anonymous hacker.

By the very person we had hired to maintain and protect it.

This is our account of what happened, how we recovered, what we learned, and what we’re changing to make sure something like this can never cripple our infrastructure again.

It Started 18 Months Ago With a Promise

About a year and a half ago, I hired Hemant Kumar, an email infrastructure specialist based in Rajasthan, India, to join the Mailvio team.

His responsibility was straightforward but critical: manage and improve the servers responsible for delivering our customers’ emails.

His first major assignment was migrating our infrastructure from Postfix to KumoMTA, a modern, high-performance mail transfer agent.

It was a significant undertaking.

The project took substantially longer than promised, and it became apparent that his practical experience wasn’t quite at the level he had represented during hiring.

But here’s the thing: the results were there in the end.

Once completed, the migration made a meaningful difference. Our sending infrastructure became considerably better, and despite the delays, I was happy that we’d made the move.

I gave him the benefit of the doubt.

Unfortunately, what followed was a long, frustrating pattern of missed responsibilities, overlooked problems, and promises that never translated into progress.

The Warning Signs We Shouldn’t Have Ignored

Over time, I began discovering problems that shouldn’t have existed.

Servers weren’t receiving important security updates. Software upgrades were being neglected. Infrastructure issues that should have been caught proactively went unnoticed until I discovered them myself.

And let me make something clear.

I’m not an email DevOps expert.

I know enough about our infrastructure to understand how the pieces fit together and to identify problems, but that’s precisely why we hired a specialist in the first place.

When the person responsible for maintaining your servers repeatedly fails to identify issues that you discover yourself, something is fundamentally wrong.

During the final four to five months, the situation deteriorated further.

Important tasks remained unfinished. Deadlines slipped. Progress became virtually nonexistent.

We had multiple conversations. I explained the problems, gave him opportunities to improve, and made my expectations clear.

Each time, I received assurances that things would change.

Each time, the same problems continued.

Eventually, I had reached my limit.

I had already decided that we needed to replace him. The only reason I hadn’t acted sooner was that running a small business means constantly juggling competing priorities, and I hadn’t yet found the time to recruit a suitable replacement.

In hindsight, waiting was an expensive mistake.

The Disagreement That Triggered Everything

The final disagreement wasn’t even about server infrastructure.

It was about working hours and compensation.

Like the rest of our team, Hemant had agreed to contractual terms defining his compensation against an expected number of working hours.

If fewer hours were worked, compensation would be adjusted accordingly.

These weren’t new rules. They were part of the agreement he had signed approximately 18 months earlier.

For the previous month’s payroll, I applied those terms.

He disagreed.

There was also an ongoing issue with how his working time was being recorded.

Our company uses time-tracking software. Normally, I’m not particularly concerned about activity metrics. If someone produces excellent work efficiently, that’s what matters.

But when important work isn’t getting done for months, naturally, you start examining what’s happening.

The records repeatedly showed isolated ten-minute tracking intervals containing only one to three minutes of recorded computer activity, often separated by hours.

Low computer activity isn’t automatically a problem. Engineers need time to think, investigate, and plan.

But combined with months of missed deliverables and virtually no progress, this pattern raised serious concerns.

Two months earlier, I had already discussed this with him and established clear expectations: work should be performed in meaningful blocks of at least 30 minutes, rather than scattered fragments throughout the day.

I also explained that isolated ten-minute intervals with less than three minutes of recorded activity would not be counted under our time-tracking rules.

He acknowledged the concerns and promised to improve.

When those previously discussed rules were enforced, he complained that I hadn’t discussed them with him beforehand.

After another frustrating exchange, I told him:

“You are free to leave.”

He confirmed that he would.

At that point, I thought the disagreement was over.

I was wrong.

One Minute Later, Our Servers Started Breaking

What happened next is something I still find difficult to comprehend.

According to our investigation, approximately one minute after our conversation ended, Hemant accessed our email servers.

But he wasn’t logging in to perform maintenance.

Critical configuration files began disappearing.

These were the main configuration files used by our email-sending infrastructure.

Without them, affected servers could no longer function properly.

One by one, parts of our sending infrastructure began failing.

This wasn’t an abstract technical problem.

Mailvio is an email marketing platform. Our customers depend on us to deliver their campaigns.

When our sending infrastructure goes down, their businesses are affected.

Campaigns get delayed. Emails fail. Revenue opportunities can be lost.

And suddenly, we were facing exactly that situation.

What the forensic evidence showed

We immediately began investigating.

Our analysis of the server logs, access records, and originating IP addresses linked the destructive activity to access associated with Hemant.

He was also the only other person besides me who had been granted that level of access to the affected email servers.

The timing, the recorded access, and the deletion activity led us to conclude that this was deliberate sabotage rather than an accidental configuration error.

We are preserving the evidence and evaluating legal action.

I had already begun revoking his access as part of the offboarding process, but by the time we could stop further access, the damage had been done.

The person entrusted with maintaining our email infrastructure had, according to the evidence we recovered, used that privileged access to damage it.

There is no pleasant way to describe that feeling.

Anger. Disbelief. Frustration.

And then the realization that none of those emotions would bring the servers back online.

We had customers depending on us.

There was work to do.

Four Days to Undo the Damage — and Four Months of Neglect

The incident began on Thursday, October 1st.

What followed was four days of intensive recovery work, continuing throughout the weekend.

Our small team dropped everything.

We investigated the damage, recovered configurations, repaired affected systems, restored sending functionality, and checked that the infrastructure was operating correctly.

But I made another decision along the way.

We weren’t simply going to restore the servers to their previous state. We were going to make them better.

Remember those neglected security updates?

The outstanding software upgrades?

The technical improvements that had been sitting unfinished for months?

We tackled those too.

In four days, while repairing the damage, we also completed upgrades and infrastructure improvements that had been outstanding for approximately four months.

Four months of stalled progress.

Four days of recovery, upgrades, and improvements.

I’m not suggesting that every technical task is equally complicated, or that emergency work is a sustainable way to run a company.

But the contrast was impossible to ignore.

And while I would never have chosen to spend a weekend like this, I’m immensely proud of how our remaining team responded.

Nobody asked whose responsibility the problem was.

Nobody disappeared when things became difficult.

We focused on getting our customers’ email flowing again.

And we did.

The Good News: Customer Data Was Not Exposed

One critically important detail deserves its own section.

Hemant’s privileged access was limited to our email-sending servers.

He did not have access to our application servers or the systems hosting our customers’ email queues and account data.

Based on our investigation, we found no indication that customer data was accessed or compromised during this incident.

The damage was to the sending infrastructure and its configurations, not our customer database.

That separation proved extremely valuable.

As painful as the operational disruption was, it could have been considerably worse if the same access had extended across our entire platform.

We Didn’t Just Recover. We Rebuilt How Recovery Works.

One of the biggest lessons from this incident is that backups and access controls aren’t enough on their own.

You also need the ability to rebuild critical infrastructure quickly, reliably, and without depending on any single person.

During the recovery, we created a new deployment and configuration management system for our email servers.

Instead of relying on manually maintained configurations spread across individual machines, we now have a much more controlled way to deploy and restore the infrastructure.

If critical server configurations were deleted again, our goal is to recover in hours rather than days.

We’ve also:

• Applied outstanding security and software updates.
• Hardened the security of our sending servers.
• Completed pending technical improvements.
• Improved our configuration deployment and recovery procedures.
• Begun tightening how privileged access is granted, reviewed, and revoked.

There is an unavoidable reality here.

People responsible for infrastructure need enough access to perform their jobs.

You cannot hire someone to administer email servers and then deny them every permission required to administer those servers.

But you can design your infrastructure so that one person’s access cannot become one company’s single point of failure.

That is the standard we’re moving toward.

To Our Customers: We Owe You an Apology

Some of our customers experienced delayed campaigns, and a smaller number experienced failed campaigns during the disruption.

For that, I’m genuinely sorry.

You trusted us to deliver your emails, and during this incident, we fell short of that expectation.

Regardless of the circumstances behind the outage, responsibility for Mailvio’s service ultimately rests with us.

I won’t hide behind the actions of a former team member to avoid that responsibility.

What I can promise is that we’ve taken this incident seriously, worked relentlessly to restore operations, and made meaningful changes to reduce the chance and impact of anything similar happening again.

Thank you to everyone who showed patience and understanding while we worked through it.

A Warning to Others in the Email Industry

I also believe there is a responsibility to share what happened with others who might find themselves in a similar position.

The individual involved was Hemant Kumar, based in Rajasthan, India.

His professional profile is here:

https://www.linkedin.com/in/hemant-kumar-81b8b454/

During my subsequent research, I also discovered associations with businesses operating under the names DealCareGlobal and MigoMail, which had not been disclosed to me during our working relationship.

Our forensic findings have led us to conclude that he deliberately damaged Mailvio’s infrastructure immediately after a disagreement about compensation and working arrangements.

We are evaluating potential legal action. No court has yet ruled on these allegations.

I’m sharing this information so that other business owners can evaluate the circumstances and conduct their own due diligence before granting privileged infrastructure access.

I would strongly caution anyone considering working with him in a position involving critical systems.

The Next Chapter: Mailvio v3

Despite everything that happened, I’m ending this report with good news.

Our email servers are back online.

The infrastructure is upgraded, hardened, and running with improvements that should have been implemented months ago.

And perhaps most importantly, we’re moving forward with something we’ve been working toward for a very long time.

Mailvio v3.

Our next-generation platform is now deployed in production, where we’re completing configuration and testing before beginning customer migrations.

This release represents an enormous amount of work, and I’m excited about what it means for our customers and the future of Mailvio.

The last week was a brutal reminder of how vulnerable a small company can be when trust is abused.

But it was also a reminder of something else.

A small, determined team can accomplish extraordinary things when everyone is pulling in the same direction.

We lost four days.

We lost a considerable amount of sleep.

And we lost trust in someone we’d worked with for 18 months.

But we didn’t lose Mailvio.

We’re still here. Our infrastructure is stronger. Our next platform is nearly ready.

And we’re moving forward.

Steven Founder, Mailvio