MXroute Blog

Why I Terminated a Customer Today

Sat, 09 May 2026 00:00:00 GMT

Today I terminated a customer for what looks on the surface like a borderline offense. They used an email warmup service. That's it, on paper. No mass-spamming, no fraud, no abuse complaints rolling in. Just a tool that helps you make a new sending domain look more credible than it actually is, which is something they specifically agreed not to use when they signed up.

If you've never run a shared email host, that probably reads as harsh. Warning territory at best. And honestly, that was my position for years.

The problem is, I keep watching the same pattern. Warmup service plus a specific stack of other indicators (which I'm not going to enumerate here, because I'd rather not teach the next round of spammers how to dress themselves up) has, in the entire history of MXroute, resulted in unsolicited bulk email every single time the customer was given the runway to do it. Not most of the time. Every time. I spent years denying the strength of the pattern because it felt unfair to act on something that wasn't, by itself, a clear-cut violation. The pattern proved itself out anyway, repeatedly, across a long enough timeframe that continuing to give it the benefit of the doubt was no longer caution. It was negligence toward the rest of my customers.

Here is the thing people miss when they hear "your account has been terminated": the customers we serve well are the customers we serve at all. Every spammer who gets a runway on MXroute is paid for by the deliverability of every legitimate customer sharing infrastructure with them. Every cold outreach campaign that goes out from one of our IPs costs the rest of the user base in the form of degraded reputation, slower delivery, and more filtering. There is no scenario where we ignore an emerging spam pattern and the rest of our customers don't pick up the bill.

So when I terminate someone over what reads as a thin offense, the question isn't whether the offense alone justified termination. The question is whether keeping the account justified the cost to everyone else. Once a pattern has hit 100% correlation with downstream abuse, the answer is no.

The customer was refunded in full. Not because I owe it to them, but because terminating an account isn't an act of spite or a money grab. It's a quality control mechanism. Refunding signals what the action actually is: I made a business decision about who belongs on the platform, and I'm not interested in being paid for the part of the relationship I'm not going to honor.

Protecting service quality for everyone we serve is the precise reason we terminate anyone, ever. If the bar were lower than that, I wouldn't bother. There would be too many other things to argue about.

Stability is the primary goal

Thu, 23 Apr 2026 00:00:00 GMT

This year MXroute has grown exponentially, to the point that "the way we've always done things" is being tested in many ways. We always knew this was coming, and we would continue to work on processes that we believed would scale in ways that avoid the mistakes that so many businesses make when this time hits. Things like:

- Hiring unskilled support agents just to be a voice, even if the voice couldn't actually do anything.

- Overloading servers to maximize revenue to pay for the previous line item.

- Increasing pricing for existing customers to pay for the things they didn't see coming.

- A gradual decline in service quality that appears, whether true or not, to be in service of profit over reliability.

All of this time, since late 2013, we've been preparing for the times when the business would scale to the point that our plans were tested. Sometimes we failed. Sometimes we succeeded. One plan actually upset a customer so badly that I've never been talked to so angrily by anyone in my entire life. We've tried a lot of things to avoid going down the same paths that everyone else did, the paths that resulted in the loss of that "small business" feeling everyone loved so much about them before.

As we're growing so much this year, I just wanted to let you all know that we're going to be tested. A lot. Sometimes we're going to fail. Sometimes we're going to succeed. Sometimes we're going to piss someone off. We're not doing it to lose who we are, we're doing it to try to keep it intact. It's going to be stressful on us, and we're going to continually refuse to solve everything in the way that everyone else always does. Anyone love GoDaddy these days? You get what I'm saying.

Throughout all of this, remaining stable is the goal. There might be bumps along the road. There may be things that scale in ways we hadn't imagined or planned for. But every time we'll learn, we'll adapt, and we'll do better.

Thank you all for joining us on this journey. I know at the end of the day you just want your email to work and you don't want to have to think about it. Giving you that is always the primary goal.

We Fixed Quota Reporting. Then Dovecot 2.4 Happened.

Wed, 04 Mar 2026 00:00:00 GMT

Back in October I wrote about how we fixed Dovecot's quota reporting so it reflected real disk usage instead of imaginary numbers. If you missed it, the short version is that Dovecot was counting the declared size of messages rather than what they actually occupied on disk, and that caused some users to hit quota limits when they genuinely had space available. We fixed it. Felt good. Moved on.

Then Dovecot 2.4 came out.

Here's what you need to know about how we store your email. We compress it. That's not magic, it's just standard practice for running email hosting at a reasonable cost. Compression means that an email that takes up 2GB of declared space might only occupy 1GB on the actual disk. In Dovecot 2.3, we were able to configure quota to report based on real physical disk usage. So if your email was using 1GB on disk, that's what counted against your quota.

Dovecot 2.4 removed that ability.

In 2.4, quota is reported and enforced based on the uncompressed size. So that same email that physically occupies 1GB on disk gets reported as 2GB. Which means you could be sitting at half your quota in terms of real disk usage and Dovecot will tell you your mailbox is full. That is not a good user experience, and it's not accurate.

The servers currently running Dovecot 2.4 are: blizzard.mxrouting.net, chocobo.mxrouting.net, fusion.mxrouting.net, sunfire.mxrouting.net, taylor.mxrouting.net, and wednesday.mxrouting.net. The rest of the fleet will be there eventually.

I asked about this on the Dovecot mailing list. Nobody cared. That's not a dig, it's just the reality of open source software development. The people building it have priorities, and our specific use case is not at the top of that list.

The options I've identified are not great:

**Stop compressing email.** Let the larger size be the real size and the problem disappears. This benefits no one. Costs go up, and that eventually reaches you.

**Report Dovecot's inflated numbers and enforce against them.** This makes the numbers consistent, which matters more than people realize. If the quota system reports 2GB usage and Dovecot enforces at 2GB, at least you won't be surprised. But you're being held to a number that doesn't reflect reality, which means you're effectively getting less usable quota than you should.

**Build a custom Dovecot quota driver** that reports actual compressed disk usage. This is the right answer. It's also uninvestigated territory for me and not a quick fix.

What I'm not willing to do is end up in a situation where our quota system reports one number and Dovecot enforces a different one. That's what I fixed in October and I'm not going back to it.

Right now we're working through how to handle this in a way that's fair to you and honest about what's happening. We're not there yet.

Why we removed the “deliver spam to spam folder” option for panel.mxroute.com

Wed, 18 Feb 2026 00:00:00 GMT

This is one of those changes that looks small on the surface and feels big if you relied on it.

For the average user, here is the simple version: removing this option reduces the number of ways your email can behave unexpectedly. The complexity behind that feature runs far deeper than most people realize. It has been one of the most frustrating parts of our service for years. It has led to confusion, feelings of lost mail, cancellations, and understandably angry users.

Maybe it comes back one day after we fully rewrite and redesign the logic behind it. Right now, there are too many structural problems tied to how it works. For the sake of reliability and clarity, it had to go. I am asking you to trust that this decision was justified and made in the interest of long term stability.

*If you want the technical explanation, here it is.*

The option to deliver mail to the recipient’s spam folder does not behave the way people assume it does in our current stack. The logic is rooted in legacy Perl code that we did not write. As we continue moving away from third party vendor logic, this is one of the areas where that old foundation becomes a liability.

**There are actually two separate problems with this feature.**

**The first is architectural.** Even when it is not outright breaking, it does not perform well in practice.

In order to meaningfully populate a spam folder, the scoring threshold has to be lowered. For most users, lowering that threshold means legitimate email will regularly be classified as spam. We do not operate like Google. We reject a significant amount of mail at the SMTP layer and do not accept large volumes of mail that we already know to be spam just to sort it later. The mail that makes it through to SpamAssassin often shares scoring ranges with legitimate mail. This happens all the time, and it’s expected behavior.

**The second problem is mechanical**, and this is where things get worse.

If the recipient address is a forwarder without its own mailbox, and an incoming message is flagged to be delivered to that address’s spam folder, the alias cannot be fully expanded in the way you would expect. Instead of delivering to the spam folder of the actual destination mailbox, it defaults to the spam folder of the Linux user account that owns the domain.

**For example:**

If forwarder@mxroute.com only forwards mail to jarland@mxroute.com and has no matching mailbox by that name, and the system is configured to deliver spam to the recipient’s spam folder, you would reasonably expect it to land here:

*/home/linuxuser/imap/mxroute.com/jarland/Maildir/.INBOX.spam*

Instead, it lands here:

*/home/linuxuser/Maildir/.INBOX.spam*

That location is tied to the system level Linux user, not the mailbox. The only way to access it is by visiting:

[https://yourserver.mxrouting.net/webmail\](https://yourserver.mxrouting.net/webmail?ref=blog.mxroute.com)

Then logging in as the Linux user with the DirectAdmin password.

It never reaches jarland@mxroute.com. I will not see it in the mailbox. The only way to find it is to know that this hidden location exists and go looking for it manually.

**That is not acceptable behavior for a modern email service.**

Explaining this to someone who just wants email to work is not reasonable. It violates expectations. From the user’s perspective, the feature is broken. No one should ever have to be told to log in as their system user to retrieve mail that was addressed to a mailbox.

We have spent years simplifying the experience, building a more coherent control panel, and removing layers of inherited complexity. Leaving this behavior in place undermines that effort. It creates confusion and erodes trust.

For now, the function has been removed from panel.mxroute.com. If you still access DirectAdmin, you will see the option there. I understand that its removal may be frustrating if you relied on it. However, when weighing ongoing confusion and support friction against removing the feature entirely, this is the most responsible choice available to us today.

Cracking Down on Deceptive Account Abuse

Mon, 02 Feb 2026 00:00:00 GMT

MXroute has seen a dramatic increase in new customers over a short period of time. Growth brings opportunity, but it also brings visibility. As a result, patterns that were once rare or isolated are now easier to detect at scale.

**One of those patterns is deceptive use against third party services.**

This includes creating multiple email accounts for the purpose of pretending to be multiple independent users of another service. The intent is usually to bypass limits, evade enforcement, manipulate systems, or misrepresent activity in ways that violate the terms of those platforms.

**This has always been against MXroute policy.**

What has changed is not the rule, but the level of scrutiny. With more activity on the network, these behaviors stand out more clearly, and we are actively looking for them.

MXroute is intentionally a smaller mail provider. That helps us keep pricing fair and avoid the compromises common in large corporate platforms. It also means that correlation matters. If abuse against a third party disproportionately traces back to a small provider, that third party has a strong incentive to block the provider entirely. From their perspective, doing so can significantly reduce abuse with minimal downside.

When that happens, legitimate customers pay the price. Email addresses get blocked, flagged, or quietly deprioritized simply because of where they are hosted. That erodes trust in the service and reduces its usefulness for everyone.

**That is not something we are willing to allow.**

For that reason, deceptive use against third party services may be met with immediate account termination, a warning if you are lucky. The risk to the broader customer base is too high.

If your business model relies on appearing as multiple independent users on other people's platforms, MXroute is not a suitable platform.

Our focus remains unchanged. We exist to provide reliable, low cost email hosting for people who use email honestly and responsibly. As the platform grows, enforcement will scale with it.

That is how we protect the service for everyone.

MXroute 4.0 Announcement

Sat, 03 Jan 2026 00:00:00 GMT

Today I am proud to announce MXroute 4.0. That's what we're calling a complete UX overhaul, which does also include some new features and a unified experience for all of the customers deployed on our DirectAdmin servers (sorry to legacy cPanel users, only half of it is ready for you, but most of you guys are settled and fine).

Here's a quick TLDR version:

* New billing management panel
* New ordering flow that actually makes sense
* Single login to billing and control panel
* Automated (but invasive) 2FA removal
* New service control panel
* Simplified spam filter configuration
* Easier access to DNS records
* Cal/CardDAV implemented for everyone, easily outlined in new control panel
* New reseller control panel
* Custom URL, branding, and login form customization of our new control panel for resellers

While we still have a long way to go to reach my complete vision, this release catapults us so much closer to the finish line.

I understand that some of the simplifications are going to rub long time users the wrong way. I don't mean for them to, and I do mean to go ahead and be perfectly honest here. There is absolutely nothing that can be done that pleases everyone. The thing we can do that pleases the least number of people is nothing, just let things be as they are and make no improvements. The improvements we've made here are specifically designed to address the problems that cause the most number of support tickets. To explain why that is the goal, I have to tell a story. Here's where the TLDR stops.

When we first launched, this was meant to be a very small business that appealed to Linux admins. These were people who were totally fine with a rough UX, what they needed the most was to stop dealing with IP reputation issues at hosting providers. All I had to do was throw together some licensed and open source software to help them manage the service, and then I would manage the outbound reputation to take that off of their hands.

Well, fate had other plans. Dreamhost experienced a growing number of complaints about the email side of their service. Their customers started recommending each other to us. Suddenly we became an end-user platform overnight. Through no attempt of our own, we continued to grow in that direction. Suddenly that rough UX intended for sysadmins became the reason that almost none of our customers understood anything about how our service operated. Sure, we made documentation to try to ease the pain, but it did very little to reduce ours. You see, with this new user base the list of options were growing pretty thin:

**Option 1**: Ditch the end-users, refund them and try to be more hostile in the ordering process so that they would go away.

**Option 2**: Increase service price for every customer so that we could realign our business strategy around hiring support staff.

**Option 3**: Stop offering support, it works how it works and if you don't like it you can leave. *We actually tried this one.* I'll never forget the one guy who probably would have been less upset if I had snuck into his house and murdered his pets. He wasn't the only one, but he was the only one who vocalized it so hard that I needed a shower after reading it.

**Option 4**: Increase service price for every customer to realign the business strategy around hiring developers to improve UX.

**Option 5**: Slowly improve UX based on the feedback from these end-users until we were finally able to reduce nearly all of the pain points that caused them to open support tickets.

Option 5 is the only option that allowed us to continue with the same business strategy and pricing model. To be frank, I'm not sure that raising everyone's price would have even allowed us to pull off Option 2 or Option 4. Because once you alienate enough users who feel like you've provided them no immediate value (only the promise of future value), ending up with 25% of the customers you had and the same bottom line on the revenue sheet doesn't really fund developers or support staff, and punishes the users who remain for it.

So really, when you boil it down, Option 5 was the only one that made any sense. So yes, while I do believe that this direction will alienate a few users, I truly believe that this path is the most effective path for providing the most value to the most number of people. And that is why I'm excited to make this announcement.

Why I Take Spam Personally (And how Shopify enables it)

Fri, 12 Dec 2025 00:00:00 GMT

Most people think spam is an annoyance. An inconvenience. Something you swipe away, filter, or laugh about in screenshots.

For me, spam stopped being abstract a long time ago.

Years ago, someone deliberately weaponized newsletter systems against me. Not phishing. Not malware. Something far more insidious and far harder to clean up. Mass newsletter subscriptions, spread across thousands of legitimate stores, all pointed at one address that could not be changed.

That address was abuse@.

If you run email infrastructure, you already know why that matters. Abuse needs to be reachable. It needs to be stable. You cannot just rotate it away without breaking the reporting ecosystem that keeps the internet functional.

The attacker knew this.

What made it worse was not just the volume. It was the platform design choices that enabled it to persist indefinitely.

Shopify was, and still is, the worst offender by a mile. Their system allows stores to send newsletters without requiring double opt in. Unsubscribe often does not work when a store is abused this way. Even when it does, forcing someone to manually unsubscribe from thousands of stores is not a remedy. It is a punishment.

On top of that, Shopify sends mail for every store from the same envelope sender. One sender. Thousands of shops. No meaningful way to block abuse without collateral damage. No practical way to stop it without building one filter per abused shop.

That is not accidental design. That is a choice.

Meanwhile, Shopify has quietly become the backbone of online ordering across the internet. When a platform at that scale treats abuse as an acceptable externality, the damage compounds. Not just for providers like us, but for every end user caught in the blast radius.

The attack also used aliases (ex. abuse+jarlandisarapist). Not clever ones. Spiteful ones. Crafted to make the intent unmistakable. This was not automation gone wrong. This was someone discovering that modern email systems make it trivial to hurt someone for a very long time without ever technically breaking the rules.

That was the moment spam stopped being theoretical for me.

Every one of those emails is an abuse report. I forward them. I log them. I filter them. I send them to shops. I send them to executives. I send them to investors. I do not stop.

Not because I think it will magically fix the problem overnight. But because silence is how these systems stay broken.

One day, someone will lose a filter. Someone will migrate systems. Someone will have a bad day. And when that happens, I want the consequences of negligent platform design waiting for them at the top of their inbox.

You might ask how I stay motivated to fight spam. The answer is simple. I look at the logs. I see the same junk hitting the inboxes of customers who were caught in the same attack. People who may not have the tools, time, or knowledge to defend themselves.

That is the part that never stops being fuel.

MXroute exists because I refuse to treat email as disposable. I refuse to treat abuse as someone else’s problem. And I refuse to accept that inbox destruction is just the cost of doing business online.

My goal is not to win loudly. It is to win quietly. To reduce the surface area for abuse. To make these attacks harder, noisier, and more expensive to execute. To push back against systems that prioritize growth metrics over the health of the internet.

I may be fighting a war most people never see.

But I am fighting it anyway.

Because spam is not just annoying.

Spam is personal.

And the systems that enable it deserve to be challenged.

-Jarland

The Next Chapter (New Control Panel)

Fri, 05 Dec 2025 00:00:00 GMT

When I first launched MXroute, the goal was always simple: make email hosting boring. Not boring in a bad way, but boring in the sense that it should quietly do its job while you live your life, run your business, or obsess over something more interesting than SMTP logs. Over the years, DirectAdmin has been the cockpit that powered a lot of what we do, and while it’s powerful, it’s also built to be everything for everyone. Most people don’t need “everything.” They need clarity.

Today I’m happy to introduce something that moves us closer to that clarity. MXroute finally has its own control panel, built for what our customers actually care about. You’ll find it at [https://panel.mxroute.com\](https://panel.mxroute.com/?ref=blog.mxroute.com).

My aim with this new panel is to strip away everything that distracts from the core experience. Instead of parachuting new users directly into DirectAdmin’s full interface, we give them a place that makes sense for email hosting right out of the gate. A few essentials, presented cleanly, no hunting around for the “one thing” you actually logged in to do. And for the veterans who still need the old tools, DirectAdmin is still right there in the background, ready when you call it.

This is just the beginning. The new panel isn’t a destination. It’s groundwork. It’s the start of pulling MXroute’s identity into a space that reflects what we’ve always been: practical, transparent, focused, and stubbornly against making things harder than they need to be.

Thanks for sticking with me through every weird turn this journey takes. The next chapter starts at panel.mxroute.com, and I’m excited to keep building on it.

-ChatGPT (impersonating Jarland, because fuck... I'm tired)

Cold Email Is Spam. Full Stop.

Wed, 05 Nov 2025 00:00:00 GMT

There’s a lot of noise lately from self-proclaimed growth hackers, sales gurus, and startup founders preaching the gospel of “cold email.” They say it’s how you “scale outreach,” how you “get noticed,” how you “grow.” They wrap it up in euphemisms like “personalized contact” or “B2B lead generation,” but the truth is simpler: cold email is unsolicited marketing. And unsolicited marketing is spam.

Let’s unpack that.

---

### What Is “Cold Email” Really?

Marketers like to pretend that “cold email” lives in a special moral gray area, like it’s somehow different from spam because it’s “personalized” or “targeted.” But in reality, it’s the same mechanism.

You obtained an email address without consent.
You’re sending commercial content.
You’re doing it in bulk.
You’re hoping for conversions.

That’s literally the legal and ethical definition of spam. Adding “Dear John” at the top doesn’t magically sanctify it.

If someone didn’t ask for your email, and you’re trying to sell them something, it’s spam. End of debate.

No one has ever gotten off a blacklist by saying “we send cold email, not spam.” Not once. It’s the same thing, and the people running anti-abuse systems know it.

---

### The Industry Built Around Stopping You

If you need a reality check, look at the infrastructure that exists specifically to fight “cold outreach.” An entire global industry exists to identify and stop people who send cold email. From blocklists to spam filters to data vendors, the entire system is designed to make sure your “outreach” never lands.

At MXroute, we see both sides of it. On one side are the people sending “campaigns” and “outreach.” On the other are the systems built to find and bury them. The filters aren’t fooled by excuses, and neither are we.

---

### The Future Is Already Watching You

We are actively monitoring email warmup services and compiling lists of their customers. Not because we’re playing police, but because warmup activity is one of the clearest signals that someone plans to send spam. That data is being shared with other providers who are also tired of cleaning up the aftermath.

So if you’re using a warmup service to “prepare” for a cold email campaign, you’re already marked. You are not being clever. You are already on the radar.

---

### The “Everyone’s Doing It” Problem

Here’s what’s really killing your results. The flood of new SaaS founders has created a massive surge in cold outreach. We’ve never seen so many people launching products and immediately blasting “cold emails” to strangers. The result is fatigue. Every inbox owner is fucking tired of it.

If everyone is doing it, no one stands out. You’re not being “scrappy.” You’re just another interruption. Another unwanted pitch in a sea of delete buttons.

---

### The Honest Alternative

If you want to reach people, start by earning permission.

Build something valuable enough that people want to hear from you. Offer them something real before you ask for their time. Let them subscribe to you, not be hunted by you.

The best marketing doesn’t feel like marketing. It feels like alignment. That’s what built MXroute’s customer base: years of reputation, word of mouth, and treating every email we send as a guest in someone’s inbox, not a battering ram at the door.

---

Dovecot Quotas: Now Counting Reality Instead of Imagination

Thu, 16 Oct 2025 00:00:00 GMT

For years, a few people noticed something that didn’t make sense. They would hit their quota limit, get “mailbox full” errors, and check their disk usage only to find plenty of room left. Most users never ran into it, but those who did were understandably confused.

The reason came down to how Dovecot measures mailbox size. By default, it doesn’t look at what’s actually stored on disk. It looks at the declared message size, meaning the size reported when the email was sent. That number is usually larger than the space the message ends up taking on disk, because attachments are base64-encoded during transmission, which inflates their size.

So, Dovecot just stopped lying about it.

Moving Forward with Lifetime Plans, Smarter This Time

Sat, 23 Aug 2025 00:00:00 GMT

Lifetime packages have always been a strange but meaningful part of MXroute. They’ve brought in customers who wanted to bet on us for the long haul, and in return we’ve honored those bets. The people who picked up our original lifetime plans years ago are still sitting comfortably in their accounts, untouched by every change since. That’s not going to change. We’re not here to pull the rug out from under anyone. If you bought a lifetime plan before, it stays exactly as it was.

What we are doing now is shaping the next step for lifetime plans in a way that makes sense for both you and us. We’ve learned a lot since the first time we offered them. The biggest challenge isn’t the customers who use the service every day, it’s the ones who disappear forever. When that happens, abandoned accounts just sit there, eating up resources and never being cleaned out. That’s wasteful, and it keeps us from offering lifetime plans in a sustainable way.

So here’s the solution: we’re introducing a new **15GB Lifetime Plan for $299**, with one important detail. It comes with a renewal of **$1 per year**. That dollar isn’t about profit. It’s simply a trigger. If you keep paying that $1, you’re letting us know you’re still here. If you don’t, it gives us a reason to clear the account. That way the people who truly want lifetime service get it, and the people who walk away don’t leave behind ghost accounts that linger forever.

If that sounds right for you, you can order it here: [15GB Lifetime Plan – $299](https://accounts.mxroute.com/?cmd=cart&action=add&id=300&ref=blog.mxroute.com).

This is a smarter balance. You get a simple, clear option for lifetime email hosting, and we get a mechanism to keep things tidy and sustainable for everyone. Lifetime customers from the past keep everything exactly as it is, and new customers get an offer that can live on long after most “lifetime” products would have collapsed under their own weight.

As always, the plan here isn’t about squeezing profit. It’s about making MXroute last.

No, We Don’t Just Ban People for “Any Reason”

Mon, 28 Jul 2025 00:00:00 GMT

Every time we terminate a customer for sending spam, there’s a predictable wave of posts on Reddit and other corners of the internet: *“MXroute just bans people out of nowhere,”* or *“they’ll shut you down over anything.”*

The truth? We’re far more deliberate and patient than you might think.

Let’s look at three actual cases we handled **today** to make the point crystal clear:

**Case 1: Might be spam, might just be a messy list**
A customer sent what looked like unsolicited marketing. It definitely wasn’t pretty, but there was some chance it came from a poorly maintained list rather than bad intentions. We didn’t kill the account. We paused their outbound mail and reached out to clarify. That’s it.

**Case 2: Spam software spotted, customer contacted**
Another user connected software that is *designed and marketed* for sending unsolicited marketing emails. We’ve seen it tied to spam every single time. But in this case, the customer has been with us for about four years, and there was no sign they had started using it to send mail. We reached out, flagged the concern, and let them know it’s being watched. No shutdown. No drama.

**Case 3: Clear, deliberate spam from a fake account**
This was the easy one. A two-month-old account, fake customer details, sending bulk unsolicited marketing on behalf of a company. It was intentional, obvious, and indefensible. We terminated the account without warning. That’s the kind of thing we don’t tolerate, period.

**The Reality**
We don’t mass-terminate. We don’t go hunting for reasons to kick people out. What we *do* is protect the integrity of our service for all the customers who play by the rules.

Sometimes that means giving the benefit of the doubt. Sometimes it means giving a warning. And sometimes it means hitting delete.

But it’s never random, and it’s never without reason.

Snappy Webmail to Be Removed August 1, 2025

Thu, 10 Jul 2025 00:00:00 GMT

I’m going to keep this short and direct because this isn’t a negotiation. It is a courtesy announcement.

As of **August 1, 2025**, the *Snappy* webmail interface will be removed from the MXroute platform. If you’ve been using it, you’ve got a few weeks to migrate your webmail habits over to Roundcube or your favorite email client.

Why? Simple: We don’t have the bandwidth to maintain two separate webmail interfaces to the standard we expect. Trying to juggle both Snappy and Roundcube has created a scenario where *neither* is getting the attention it deserves, and that’s a problem. Not because Snappy has issues, but because the way we’ve had to manage it makes us *more likely* to create issues down the road. That’s not a risk I’m willing to take.

We’d rather do one thing well than two things poorly. Roundcube stays. Snappy goes.

This isn’t us “pivoting,” and it’s not some giant shift in our values. It’s just about focus and not creating a mess we can’t clean up later. The end result will be a tighter, more secure webmail experience. An experience that we can actually commit to improving.

We appreciate the understanding (or at least the acceptance). If Snappy was your daily driver, it’s a good time to fire up Roundcube and get comfortable. It’s not going anywhere.

– Jarland

New Domain Verification

Wed, 18 Jun 2025 00:00:00 GMT

On June 4th a user registered for service using entirely reasonable credentials, passing any sane human verification check. The user proceeded to add 1,522 domains belonging to our other customers under a reseller account, and then used those domains to send spam. The idea here being that by using our service they could pass SPF. Though it would fail DKIM, passing SPF is still quite valuable. Previously we had accounted for this behavior by policing spoofed emails (heavy audit trails, alerting, etc). What we didn't account for was when the domain wasn't spoofed because it matched the SMTP login domain, because the user maliciously added the domain to their account. More on this at the bottom of the post.

Now, obviously, anyone with half a brain could tell you this was an inevitable conclusion to the ability to add domains in DirectAdmin without ownership verification. It's not rocket science. However, the ability we're talking about has been present in the shared web hosting industry for the vast majority of it's existence. Still, today, this is an issue present in a huge number of shared web hosting providers, if not still the majority (and may well still be the majority). As our frontend was modeled after the shared web hosting industry, and as a low budget provider, we figured the industry at large (and the MUCH larger players in it) would face an attack of this kind well before we did and thus they would make demands of the tooling we shared by licensing, allowing the "fix" to drip down to us at no cost.

**We weren't out here trying to solve all of the problems inherent in that industry for them, and in our minds the fact that we shared them meant we were at least in good company. But as seems to be the way life actually goes, it was thrust upon MXroute to solve this problem. So we did. Now you have to verify ownership of a domain to add it via DirectAdmin. This ONLY refers to NEW domains that you add to your account. Zero domains in your account already will require this verification.**

Your domain verification key will be used as a TXT record in your domain's DNS. You will obtain it in DirectAdmin from the DNS Records page under Account Manager in the left menu. The key is the record name, the record contents are just "domain-verified" because it's not really important. By having a unique record name per account, we will have made it difficult for anyone to just do bulk lookups of a single TXT record and find domains owned by the same user. Once you have your domain added into DirectAdmin, you can delete the TXT record.

*More on the June 4th attack:*

The attacker attempted to send 5,899 Comcast phishing emails from the 1,522 domains. Unfortunately most of these emails succeeded. The only positive here is that this particular attack did not harm anyone's domain reputation. Now that we've covered both methods of performing this attack, we are no longer susceptible to it.

Dear Spammers: We're Not Your Shortcut to Easy Money

Sun, 25 May 2025 00:00:00 GMT

Every day like clockwork, someone signs up for MXroute with a domain that screams, “I’m here to make a quick buck and ruin someone’s inbox.” It’s always the same story: domains like `get-something.ai`, `trythisainow.com`, `aiflowofnonsense.net`, all hooked up to some sketchy lead-gen funnel or repackaged “growth hack” SaaS. Bonus points if they’re piping their garbage through SparkPost to try to skate around our policies. Real subtle.

Let’s be clear: MXroute wasn’t built for this. Our service exists for people who care about email. People who run real businesses, build real communities, or just want to host their own mail without giving it all to Google. If your whole game is scraping addresses from Instagram bios and blasting out AI-generated sales pitches, we’re not the tool for you. We don’t want to be.

Some of you are probably here because some grifter is selling a course on “How to Make Your First $100K by 27 Using This One Weird Email Trick,” and that course name might as well be “How to Get Banned from MXroute in an Hour.”

Here’s the part you’ll want to screenshot:
**If your domain is intentionally used to send spam from any platform, you don’t belong here.**

We will continue terminating these accounts as they violate our policies (and they nearly always do). We’ll keep refining our filters, our blacklists, and stocking up on Red Bull. Every time you think you’ve found a clever way to game the system, we’ll shut the door tighter.

You can call that hostile if you want. We call it defending our customers from being associated with your spammy ass.

Real businesses are still welcome here. We’ll always have your back.

The rest of you? Go sell your dream somewhere else.

Make MXroute Great Again (Yes, Again)

Fri, 09 May 2025 00:00:00 GMT

Over the years, I’ve tried to strike a balance between being the watchful guardian of our IP reputation and giving users enough freedom not to feel like they’re tiptoeing through a minefield. I’ve relaxed on that balance recently, just a little. A little less aggressive on outbound filtering, a little more room to test the waters. I wanted to know how far I could go without lighting a match in a dry forest.

Well, I found it.

Not in a catastrophic way. No blacklist apocalypse, no Google-wide rejections, no headline-worthy collapse. But the subtle signals came in. Microsoft started throwing shade, Gmail went colder than usual on some customers, and a handful of emails I wouldn’t even want in my spam folder made it out before I noticed. That’s the thing about reputation: it erodes quietly. And then it’s gone loudly.

So I’m drawing the line again. Re-doubling. Re-militarizing. Not by clamping down on legitimate use, but by doing what I’ve always done when MXroute is at its best—protecting the customers who don’t want to be on a network with the lowest common denominator. The ones who expect their email to land in inboxes because they aren’t trying to game the system, they’re just trying to talk to people.

You’ll see outbound filtering get stricter again. You’ll see some outbound blocks and false positives, and a handful of you might be mad at me. And I’ll be here to take the heat, because that’s my job. My job is not to be liked in every moment. It’s to make sure your email gets delivered. The real kind of delivered, not just “we accepted your message” delivered. Inbox delivered.

I’ve walked this road before. It works. It’s why so many of you are here. And now I’m walking it again, boots on, no apologies.

MXroute isn’t going corporate. It’s going militant—again—for the right reasons.

Let’s make MXroute great again.

<3
Jarland

ARC: The "Trust Me Bro" of Email Authentication

Tue, 06 May 2025 00:00:00 GMT

There’s a lot of noise in the email world lately about ARC (Authenticated Received Chain). People talk about it like it’s the missing puzzle piece in email authentication. But after watching it float around in production for years, I’ve come to a pretty simple conclusion:

ARC is basically just a *“trust me bro”* header.

Let’s back up for a second. What’s ARC supposed to do?

ARC tries to fix the problem where SPF and DKIM fail because an email got forwarded. Imagine a university forwards an email to your Gmail account, and suddenly Gmail sees the wrong IP or modified headers. DMARC fails. ARC steps in and says, “Hey, don’t worry. The person before me checked SPF, DKIM, and DMARC. Here’s what they saw. Trust me, they did their homework.”

It’s a cool idea on paper. But here’s the problem.

### Trust isn’t transitive

Just because someone says they trusted it doesn’t mean you should. If I forward you an email and tell you it’s legit, that only matters if you already trust me. ARC doesn’t change that. It just wraps that idea in a signed header.

And who are we supposed to trust? Should Gmail rely on ARC results from a random guy running a mail server on a dusty old VPS? Should I trust ARC results from someone who forgot they set up DKIM back in 2019? There’s no universal trust network here. Everyone is just guessing who’s credible.

### What actually happens in the real world?

I haven’t seen a single provider say, “We now let this email through because of ARC.” Not once. Not even Google, who helped design it.

We all keep forwarding email the same way we always have. If forwarding breaks authentication, it still breaks it. ARC just adds headers. That’s it. The only places using ARC in any meaningful way are already putting effort into making forwarding work, and even they treat ARC as optional metadata. Nothing more.

### Yes, spammers can fake it

There’s nothing stopping a spammer from signing their own ARC headers. “Hey, I totally checked SPF and DKIM and it passed. Look, I signed it myself.” Cool story. I’ll file that next to the Bitcoin giveaway.

Receivers can choose which ARC signers to trust. But that puts us right back where we started. Trust is still subjective. And most of us have no reason to build a hand-curated list of who we trust to sign ARC headers.

### Bottom line?

ARC is a clever technical idea. I’m not calling it useless. It has potential. But in practice, it’s not solving a real problem for most providers. It’s not improving deliverability. It’s not making forwarding more reliable in any noticeable way. And I’ve never once heard someone say ARC was the reason they trusted a message.

So for now, we’re not doing anything with ARC at MXroute. If that ever changes, it’ll be because it makes things measurably better for real people.

Until then, ARC is just another header.

Trust me bro.

- Jarland

Why MXroute Doesn’t Globally Reject DMARC Failures

Sun, 04 May 2025 00:00:00 GMT

There’s a question that pops up maybe once a year, and I do mean that literally. Someone asks why we don’t globally reject emails that fail DMARC checks. It’s a fair question. After all, DMARC exists to protect domain owners from spoofing, and on the surface, rejecting failures sounds like the responsible thing to do.

But the reality of running a large-scale email service means balancing good intentions with operational truth. So here’s the short version, followed by the long one:

We don’t globally reject DMARC failures because it would cause far more problems than it would solve.

**SPF: Yes. DMARC: Not So Fast.**

MXroute already rejects mail that fails a hard SPF check. That’s a line I’m willing to draw. SPF is simple. There’s no ambiguity.

DMARC is a different beast. It layers policy enforcement on top of SPF and DKIM, but when it comes to forwarding, it often breaks. That’s not because anything is wrong with the sender. It’s because forwarding changes the path of the email. The SPF fails because the forwarding host is not in the sender’s SPF list. By focusing on the From header, it invalidates SRS which is a great feature that was designed to fix this. DKIM fails if the message is modified in transit. DMARC fails because one or both of those failed. This happens all the time, and it’s expected behavior.

Strict DMARC enforcement turns email forwarding into a problem, and that’s not something I’m interested in doing to our customers.

**Let’s Talk Real Numbers**

The number of customers who ask us to enforce DMARC strictly? Roughly one per year. And I’m being generous there.

The number of customers who use some kind of email forwarding where DMARC would break? Easily thousands. These people aren’t doing anything wrong. They’re using email in a normal, expected way.

So we’re not going to disrupt all of that for a feature one person a year might care about. Google's strict DMARC enforcement is handled in an excellent way, by offering zero support so users can either just suck it up or leave. This is not something we intend to emulate.

**Will We Ever Offer It?**

Probably. One day I may add a toggle that lets customers enable strict DMARC enforcement on their own domains. If someone wants to reject DMARC failures for their domain, I won’t stand in the way. But it’s not a priority. I have no intention of putting time into building UI for a feature that would only be used by a tiny fraction of customers, and even then, would generate complaints because half of the users that enable it wouldn't understand the implications.

**Bottom Line**

MXroute is built for reliability and practicality. That means we make decisions that work for the majority and avoid breaking email for the sake of a checkbox. Rejecting hard SPF fails is a useful boundary. Rejecting DMARC failures across the board is not.

That’s not going to change.

Apple Broke Push Notifications, So We Fixed It (Sort Of)

Fri, 14 Feb 2025 00:00:00 GMT

**Z-Push was not a viable option when we attempted it many years ago. It is not a viable option today. While the instructions below may work for you, for now, intermittent reports of this not working and for no reason that we can fix have continued to trickle in. Unlike the time we attempted to use it years ago, we are not going to let this weigh us down. Use this at your own risk, understand that there will be no support for it, and we will announce it's shutdown at a future date. We will continue to pursue real solutions, this isn't the correct one.**

**The original article is below. You should really question if this is something you need, because it probably isn't.**

**Original article:**

As many of you know, Apple recently threw a wrench in our ability to provide push notifications for the iOS Mail app. We’ve been working around the clock to develop a solution, and today we’re rolling out what we’re calling a **beta** version of Push notifications for iOS. There will be bumps in the road, but we need real-world usage to iron them out. Here’s what you need to know:

### The Key Details

* **Your inbox will appear empty at first.** After setting up your account, your Mail app won’t show your inbox for a few minutes. This is due to an initial sync process that Apple gives you absolutely no feedback on. Just wait it out, and your emails will appear when it’s done.
* **We built our own Z-Push backend.** It’s designed for speed, and new emails should be pushed to your Mail app within **one minute** of hitting our servers. We’re continuously refining this to make it even faster.
* **This uses the Exchange protocol.** Is it perfect? No. Is that the goal? Always. For now, **Notes, Calendars, Contacts, and Reminders won’t work.** You’ll be instructed to disable them during setup, but we do plan to add support later.

### **IMPORTANT:** Your MX records **must** be pointed to MXroute for this to function.

---

### Setting Up Push Notifications on iOS Mail

Follow these steps to get it running:

1. Open the **Settings** app.
2. Use the **Search** bar to find “Mail accounts.”
3. Tap **Mail Accounts** (Apps → Mail).
4. Tap **Add Account**.
5. Select **Microsoft Exchange**.
6. Enter your email address in the **Email** field.
7. Tap **Next**.
8. When prompted, tap **Configure Manually**.
9. Enter your email **password**.
10. Tap **Next**.
11. In the **Server** field, enter: `push.mxroute.com`
12. In the **Username** field, enter your **email address**.
13. Tap **Save**.
14. Uncheck **Contacts, Calendars, Reminders, and Notes**.
15. Tap **Save** again.
16. Walk away, grab a coffee, scroll social media—come back in **5-10 minutes** and check your inbox.

Need a visual guide? Here’s a short video walking you through the setup (note: Apple hides password fields in screen recordings, so they may appear empty, but they’re not):
[📹 Watch the setup video](https://www.youtube.com/shorts/c5CH04p3Qlg?ref=blog.mxroute.com)

This is a work in progress, and we appreciate everyone willing to jump in and test it out. As always, feedback is welcome!

Known bugs:
- Email sent through this is not signed by DKIM, high priority

Important Update Regarding iOS Push Notifications

Wed, 18 Dec 2024 00:00:00 GMT

Here's a situation we need to discuss. Apple has discontinued an endpoint we were using to generate certificates for iOS Mail push notifications. This endpoint was part of the now-deprecated MacOS Server application, which we and many other providers had been using for this purpose. While our current push notification system remains fully functional, this change creates some uncertainty for the future.

To be specific: We're still successfully delivering push notifications to your iOS devices. Your current notification setup continues to work as expected. However, the certificate generation process through MacOS Server is no longer available, and at present, there doesn't appear to be a direct replacement.

It's worth noting this isn't about regular push notification certificates used for standard iOS apps. This was a specific implementation through MacOS Server that allowed us to provide mail push notifications, and its future availability is now uncertain.

We're actively exploring all possible alternatives and working closely with other service providers to identify solutions. However, we want to be upfront: there's a possibility that third-party mail providers may face limitations with iOS Mail app push notifications once current certificates expire.

For the immediate future, everything continues to function normally. We're committed to finding the best path forward and will keep you updated as we learn more.

The Hidden Dangers of Email Warmup Services: Why They're More Harmful Than Helpful

Fri, 13 Dec 2024 00:00:00 GMT

Email warmup services have gained popularity among businesses looking to improve their email deliverability. However, these services aren't just ineffective—they pose a serious risk to your business's long-term email reputation and deliverability.

### The False Promise

Many business owners fall into a tempting trap: "If I pay these services, they'll improve my inbox delivery rates." While this might appear to work initially, the reality is far more concerning.

### The Dangerous Association Game

What many users don't realize is that these services create statistical correlations between your domain and known spam domains. Here's a sobering look at some of the domains commonly associated with these services:

* hottmatches.com
* keenflirts.com
* loanforbiz247.loan
* spiceydate.com

Take a moment to consider: do you want your business email domain sharing patterns and behaviors with these types of websites?

### The Impending Reputation Crisis

As these warmup services become increasingly widespread, we're witnessing a concerning trend. Email providers are becoming more sophisticated in identifying patterns, and it's only a matter of time before all users of these services are categorized together—as spammers. This guilt by association isn't just theoretical; it's a growing reality in email delivery algorithms.

### Why We Take a Stand

This is precisely why many reputable email service providers, including our network, prohibit the use of warmup services. The logic is straightforward: why would we allow our customers to create correlations between our carefully maintained IP addresses and potentially harmful behavior? We've invested significant resources in building and protecting our reputation to ensure optimal inbox delivery for our customers.

### The Better Path Forward

Instead of relying on artificial warmup services, focus on building genuine email engagement through:

* Sending relevant, valuable content to engaged subscribers
* Maintaining clean email lists
* Following best practices
* Building organic engagement over time

To provide you with the level of service we have sold to you, we have to make sure that you do not shoot yourself in the foot and then make us look guilty by association. We've always promised that we won't let a bad neighbor effect cause reputation issues for our customers, please try not to be the bad neighbor.

Automating Security: A Better Way to Handle Compromised Email Accounts

Thu, 14 Nov 2024 00:00:00 GMT

I'll be the first to admit when we can do better. For years, we've handled compromised email accounts in a way that, frankly, wasn't great for anyone. When we detected a compromised account, you'd have to wait. Wait for us to be available, wait for us to respond, wait for us to manually unlock your domain. It wasn't efficient, and it certainly wasn't respectful of your time.

We've fixed that.

What's Changed?
---------------

When our systems detect a compromised email account now, everything happens automatically:

1. The affected email account is immediately suspended to prevent abuse
2. You receive a support ticket with details about the security event, including relevant logs we've collected
3. Most importantly: You get an immediate path to resolution through our new security portal

No more waiting for us to wake up, finish dinner, or get to your ticket. You're in control of the resolution timeline.

How It Works
------------

The process is straightforward:

When we detect suspicious activity, we immediately suspend the compromised account and send you a ticket containing a unique security link. Visit that link to review the incident details and logs, then unlock your domain when you're ready to change the password.

The whole process takes minutes instead of hours or days. You don't need to convince us, explain anything, or wait for our availability. Just acknowledge the incident, agree to change the password, and you're back in business.

Why This Matters
----------------

Security incidents don't run on business hours. They don't care if we're sleeping or if it's a holiday. When an email account is compromised, every minute counts - both for your security and for preventing abuse of our infrastructure.

This automated system means:

* Faster resolution times
* Less frustration for you
* Better security for everyone
* No more timezone delays
* No more waiting for support to be available

Being Better
------------

We're not perfect. We make mistakes, we learn, and we try to be better. This new system isn't just about automation - it's about respecting your time and giving you more control over your service.

The old way of handling compromised accounts wasn't great. It was manual, slow, and frustrating for everyone involved. We knew we could do better, so we did.

Remember: security is a partnership. We provide the tools and infrastructure, but the strength of your passwords ultimately rests with you. Use strong, unique passwords. And if something goes wrong, we've got your back with systems in place to help you recover quickly.

Stay safe out there.

-Jarland

Evolving Our Spam Prevention: The Journey to SusRanges

Thu, 24 Oct 2024 00:00:00 GMT

Oct 30, 2024 Edit: As we transition to this system today by spinning down the previous system, we expect inbound spam to increase for a few weeks while we rebuild our data set. Previous data sets cannot be migrated to this, as they were too inconsiderate of important details for this type of system.

At MXroute, fighting spam is an endless arms race. While content filtering has its place, we've learned that the most effective approach is network-based filtering. Today, I'm excited to share how we've revolutionized our spam prevention system after several iterations of learning what works - and what doesn't.

The Learning Process
--------------------

Our initial approach used network-level firewalling to block known spam networks. Simple in theory, but problematic in practice. Some legitimate customers had servers in these networks, and residential ISPs proved especially tricky to handle without causing collateral damage.

We then tried blacklisting spam-heavy networks. While this caught more spam, it also increased false positives. We discovered that finding the sweet spot between aggressive spam blocking and maintaining delivery reliability was harder than expected.

Our third attempt introduced whitelist capabilities, allowing customers to override blacklist restrictions. This helped, but didn't solve the residential ISP problem.

Introducing SusRanges: Our Game-Changing Solution
-------------------------------------------------

After much iteration, we're proud to introduce SusRanges - our most sophisticated spam prevention system yet. Here's why it's revolutionary:

1. **Near-Zero False Positives**: Our most accurate filtering system to date
2. **Global Whitelist Control**: Allows us to instantly correct any false positives
3. **Unparalleled Efficiency**: The most effective spam blocking we've ever implemented
4. **Zero Customer Impact**: Works seamlessly whether you're sending or receiving mail

### How SusRanges Works

SusRanges identifies IP ranges that typically don’t host legitimate mail servers. Take Chinanet for example - while it's a massive network, very few legitimate mail servers operate within it. For those few, we've prepared a whitelist in advance.

The magic happens in how we handle these connections. When we receive SMTP traffic from a SusRange-listed IP, we simply require SMTP authentication. That's it. If you're our customer, you're already authenticating, so you'll notice no change. But this simple requirement stops spam botnets dead in their tracks.

This approach means:

* Our customers see dramatically reduced spam
* Legitimate senders aren't impacted
* Even if you're in a SusRange, your service continues normally
* Compromised computers in these ranges can't spam our other customers

We're excited about this evolution in our spam prevention strategy. It's proving to be our most effective solution yet, delivering the spam reduction our customers want without the headaches of our previous approaches.

Spam-B-Gone: How We Nuked Chinese Spam Without Nuking China

Fri, 11 Oct 2024 00:00:00 GMT

Look, I'm not one to mince words, and if you've been around these parts for a while, you know I've got about as much patience for spam as I do for people who put pineapple on pizza. (That's zero, for those keeping score at home.)

So let's talk about the elephant in the room - or should I say, the dragon. China. Land of great food, fascinating history, and apparently, an endless supply of spam emails. It's like they've got a national hobby of clogging up inboxes or something.

Now, I've been pulling my hair out over this for years. It's obvious that this isn't just some random Joe Schmoes sitting in their basements. We're talking organized operations here - whether it's state-sponsored shenanigans, ISPs making a quick buck on the side, or honest-to-god spam gangs. (Seriously, who wakes up and thinks, "You know what? I'm gonna join a spam gang today!")

The problem has always been that you can't just nuke all of China from orbit. I mean, sure, it'd solve the spam problem, but it'd also piss off a lot of people, including our awesome Chinese customers. And let's face it, I like making money more than I like pissing people off. Usually.

So for the longest time, we've been stuck. Blacklist China's IPs? Nope, that causes false positives SpamAssassin (uses Received headers not connecting IP). Block at the firewall? Say goodbye to our Chinese customers. It's been like trying to perform brain surgery with a sledgehammer - messy and ineffective.

But today, my friends, today we cracked the code. We've deployed a new spam filter that's so beautiful, it brings a tear to my eye. Here's the secret sauce:

If you're connecting from a Chinese IP, you've got two options:

1. Be authenticated (one of our legit customers)
2. Be on our whitelist (legit Chinese email services like qq.com)

Fail those checks? Get lost. No ifs, ands, or buts. No content filters, no DNS checks, just a big fat "NOPE" right to your face.

Why am I so damn proud of this? Because it's perfect. Zero false positives. Zero impact on our Chinese customers. Zero problems for anyone trying to email their Great Aunt Mei in Beijing. It's like we found the Holy Grail of spam filtering, and it tastes like sweet, sweet victory.

So to all you spammers out there in the Middle Kingdom: sorry, not sorry. Your precious IPs just became about as useful as a chocolate teapot. Enjoy trying to circumvent that, suckers.

And to everyone else: you're welcome. Now if you'll excuse me, I'm going to go celebrate by not reading any spam emails. It's gonna be great.

MXroute's Commitment to Email Integrity: Taking a Stand Against Abuse

Mon, 19 Aug 2024 00:00:00 GMT

At MXroute, we've experienced tremendous growth this year. While this expansion is exciting, it has also brought new challenges. We're seeing an increase in attempts to misuse our service for malicious purposes. Today, we want to address one of the most prevalent issues: the use of our platform for spam account creation.

The Problem: Spam Account Creation
----------------------------------

### What is spam account creation?

Spam account creation occurs when users generate numerous randomized email addresses on our service. These addresses are then used to sign up for hundreds or thousands of accounts on other websites.

### Why is this a problem?

1. It undermines the integrity of other online services
2. It can lead to abuse of free trials and promotional offers
3. It facilitates the spread of spam content across the internet
4. It damages the reputation of legitimate email providers like MXroute

Our Stance
----------

At MXroute, we are taking a hard stance against users who attempt to use our service as a base for scam operations. We believe that maintaining a good reputation with the internet as a whole is crucial for several reasons:

1. It ensures our legitimate customers are treated as the upstanding citizens they are
2. It helps maintain our customers' emails as "inbox-worthy"
3. It contributes to a healthier, more trustworthy email ecosystem

Our Commitment to Higher Standards
----------------------------------

As a growing player in the email service industry, we recognize our responsibility to be a driving force for higher standards. This commitment includes:

1. Implementing robust systems to detect and prevent spam account creation
2. Promptly investigating and acting on reports of abuse
3. Educating our users about best practices for email use
4. Collaborating with other service providers to share information and strategies for combating email abuse

The Importance of a Good Reputation
-----------------------------------

In the world of email, reputation is everything. A poor sender reputation can lead to:

1. Emails being marked as spam or blocked entirely
2. Decreased deliverability rates for all users on our platform
3. Loss of trust from other email providers and potential customers

By maintaining high standards and actively combating abuse, we protect not just our reputation, but the reputations of all our users.

How You Can Help
----------------

As valued members of the MXroute community, you play a crucial role in maintaining our high standards:

1. Report any suspicious activity you encounter
2. Follow best practices for email use
3. Spread the word about the importance of responsible email practices

Conclusion
----------

At MXroute, we're committed to being more than just an email service provider. We aim to be a leader in promoting responsible email practices and combating abuse. By taking a firm stance against spam and other forms of email abuse, we're not just protecting our service – we're contributing to a better, more trustworthy internet for everyone.

Together, we can ensure that email remains a powerful, reliable tool for communication in the digital age.

The Rise of Registration and Password Reset Bombardment

Sun, 12 May 2024 00:00:00 GMT

Over the weekend, our team at MXroute discovered a significant increase in the number of WordPress websites being abused to send spam emails. The attackers are using a tactic known as "registration and password reset bombardment" to target unsuspecting email recipients.

How the Attack Works
--------------------

The attackers are submitting a high volume of registration and password reset requests across numerous WordPress websites, using the email addresses of their intended victims. This results in the targeted individuals receiving a flood of unwanted emails from these WordPress sites, even though the sites themselves are not compromised.

The Importance of Rate Limiting
-------------------------------

To protect your WordPress site from being used in these attacks, it is crucial that you implement rate limiting measures. Rate limiting helps to restrict the number of requests that can be made within a specific timeframe, making it more difficult for attackers to abuse your site's registration and password reset functionality.

By setting up proper rate limiting, you can significantly reduce the chances of your WordPress site being used to harass others via email.

Our Stance on Sender Responsibility
===================================

At MXroute, we take email abuse seriously. While we understand that website owners may not have intentionally allowed their sites to be used for these attacks, we will not hesitate to block senders that are being abused in this manner.

It is the responsibility of website owners to ensure that their sites are not being used to harass third parties. Failure to take appropriate measures to prevent such abuse may result in your sending capabilities being restricted or suspended.

Steps to Secure Your WordPress Site
===================================

To help protect your WordPress site from being abused in email spam attacks, consider implementing the following measures:

1. Enable rate limiting on registration and password reset requests
2. Use CAPTCHA or other verification methods to prevent automated form submissions
3. Regularly update your WordPress core, themes, and plugins to patch known vulnerabilities
4. Monitor your site's activity logs for suspicious behavior or high-volume requests

By taking proactive steps to secure your WordPress site, you can help maintain a safer email ecosystem for everyone.

If you suspect that your WordPress site is being abused to send spam emails, please contact our support team immediately. We are here to assist you in resolving the issue and ensuring that your site is not contributing to email abuse.

MXroute: From Email Service to Independent Intelligence Agency

Mon, 01 Apr 2024 00:00:00 GMT

We have a major announcement to make. After years of providing top-notch email hosting services, we've come to a startling realization: we're sitting on a gold mine of user data. So, we've decided to take a bold step forward and transition from being a humble email service provider to a full-fledged independent intelligence agency.

With the vast amount of data we've accumulated over the years, we believe we have the potential to become a major player in the intelligence gathering industry. Our team of expert data analysts has been working tirelessly to develop cutting-edge algorithms that can extract valuable insights from your emails, contact lists, and even those silly cat memes you've been sharing.

As of today, MXroute will be known as MXIntel. Our mission is to provide top-quality intelligence to governments, corporations, and even your nosy neighbor who's always wondering what you're up to. With our advanced data mining techniques, we can uncover everything from your favorite pizza toppings to your deepest, darkest secrets.

But don't worry, we value your privacy. That's why we're offering a special "Opt-Out" program. For a small fee of $9,999.99 per month, you can ensure that your data remains private and secure. It's a small price to pay for peace of mind, don't you think?

We're excited about this new chapter in our company's history and look forward to serving you in a completely different and slightly unsettling capacity.

Thank you for your continued support, and remember, we're always watching.

Sincerely,

The MXIntel Team

PS: This is totally not an April Fools' joke. Or is it?

Why We Disabled Redirect Sieve Filters on MXroute

Fri, 22 Mar 2024 00:00:00 GMT

Hey everyone, Jarland here. I wanted to take a moment to explain a recent change we've made. We've decided to disable the ability for users to create redirect sieve filters, and I want to provide some context as to why we made this decision.

The Problem with Redirect Sieve Filters
---------------------------------------

Redirect sieve filters have been a feature on MXroute for a while now, allowing users to create simple email forwarding rules. However, we've come to realize that these filters are vastly inferior to actual email forwarders, and they can cause significant problems for our users and their recipients.

The main issue with redirect sieve filters is that they don't use Sender Rewriting Scheme (SRS). SRS is a technique that rewrites the envelope sender address of an email message, ensuring that any bounces or replies are properly handled and routed back to the original sender. Without SRS, forwarded emails can easily be mistaken as spam or rejected by the recipient's email server.

We attempted to mitigate this issue by implementing the `sieve_redirect_envelope_from` setting, which aimed to rewrite the envelope sender address. However, we've found that this solution is not strong enough to fully address the problems caused by the lack of SRS in redirect sieve filters.

The Solution: Use Email Forwarders Instead
------------------------------------------

Instead of relying on redirect sieve filters, we strongly encourage our users to set up actual email forwarders. Email forwarders on MXroute are designed to properly handle SRS, ensuring that your forwarded emails are delivered reliably and without issues.

Setting up an email forwarder on MXroute is simple and straightforward. Just log in to your control panel, navigate to the "Email Forwarders" section, and create a new forwarder. You can specify the source email address and the destination address(es) to which emails should be forwarded. Our system will take care of the rest, ensuring that your forwarded emails are properly handled and delivered.

Our Commitment to Reliable Email Delivery
-----------------------------------------

At MXroute, we're committed to providing our users with the best possible email hosting experience. Sometimes, that means making tough decisions like disabling features that don't meet our standards for reliability and performance.

We understand that this change may be inconvenient for some users who have been relying on redirect sieve filters. However, we strongly believe that moving to actual email forwarders is the right decision for the long-term health and reliability of our platform.

If you have any questions or concerns about this change, please don't hesitate to reach out to our support team. We're always here to help and to ensure that your email hosting experience on MXroute is as smooth and trouble-free as possible.

Thanks for being a part of the MXroute community!

Jarland

Protecting Your Inbox: How MXroute Prioritizes Intentional Email

Sun, 18 Feb 2024 00:00:00 GMT

At MXroute, we know the importance of reliable email delivery. That's why we're continually implementing and refining strategies to ensure that your important messages actually reach their destination. This is increasingly difficult in an email landscape filled with automated messages and the potential for unintended consequences. Let's explore why we emphasize "human consumption" for our emails.

****The Problem: When Machines Get Chatty****

Modern technology relies heavily on automated emails. Your Linux servers faithfully generate system updates, logs, and job notifications... and send them out into the email world. The problem is, companies like Google, Microsoft, and Yahoo use sophisticated algorithms to differentiate legitimate emails from potential spam.

Now, if most of the email destined for these providers originates from automated servers rather than actual people, even valid emails may start to land in the dreaded spam folder. This situation compromises the overall health of our systems and negatively impacts our ability to deliver your important messages.

****Our Approach: The "Intended for Human Consumption" Policy****

This is why we devised the "Intended for Human Consumption" policy. We proactively limit the volume of automated, machine-generated emails flowing through MXroute. We want to maintain a strong correlation between our IP addresses and real, intentional email – the kind that people want to read, reply to, and interact with.

****Why This Matters: You Benefit in the End****

Here's the bottom line:

* ****Optimized Email Deliverability:**** Prioritizing human-generated email allows MXroute to improve our reputation with major email providers. This increases the likelihood of your important emails reaching their intended recipients.
* ****A Protected Ecosystem:**** Our commitment to managing automated email traffic contributes to a healthier email environment, minimizing the potential for spam-like behavior that penalizes everyone.

* ****Our Ongoing Commitment****

At MXroute, we are constantly optimizing our policies and systems to stay ahead of the challenges in the email ecosystem. Our policy emphasis on prioritizing "human consumption" email is a significant part of our mission to ensure dependable delivery for your messages.

Got any questions about this policy, or how it might touch your specific application? We're here to help!

MXroute Blocks SenderGlobal to Protect Customers

Sat, 17 Feb 2024 00:00:00 GMT

In our ongoing commitment to providing a spam-free email experience, MXroute has blocked the entire SenderGlobal network across our services. This decision comes after repeated instances of spam delivery, a disregard for unsubscribe requests, and ignored abuse complaints spanning over two years.

**Why We Took Action**

* **Spam volume:** SenderGlobal consistently sent large volumes of unwanted and unsolicited email to MXroute customers.
* **Ignoring unsubscribes:** Customers reported that SenderGlobal did not honor unsubscribe requests, leading to ongoing email harassment.
* **Unresponsive to abuse reports:** MXroute repeatedly notified SenderGlobal of abuse issues, but they failed to take corrective action.

**Protecting Our Customers**

MXroute prioritizes the safety and privacy of our customers. Blocking SenderGlobal safeguards against unwanted emails and potential security risks. Our goal is to maintain a trustworthy and reliable email environment for all users.

**Our Commitment**

MXroute takes a proactive approach against spam and abuse. We continuously monitor our systems for malicious activity and will take decisive action whenever necessary to protect our customer base.

**Thank you for your continued trust in MXroute.**

Buckle Up: Google and Yahoo Enforce DMARC for Better Email Security

Thu, 15 Feb 2024 00:00:00 GMT

If you're a business owner or marketing professional relying on email communication, recent changes by Google and Yahoo are shaking things up in the email world. Understanding these changes and implementing DMARC is now essential for keeping your emails trustworthy and avoiding the dreaded spam folder. Let's dive in and get your email practices sorted!

**What is DMARC, and Why Is It Suddenly So Important?**

* **DMARC Explained:** Consider DMARC the bouncer at an exclusive club – ensuring only legit emails bearing your domain's name ("From" address) pass through to a user's inbox. It fights against fraudsters trying to impersonate your brand in phishing schemes.
* **The Google and Yahoo Push:** The two biggest email providers are upping their security game. Since February 2024, high-volume senders (especially if you send more than 5000 emails per day to their addresses) will need a DMARC policy in place for better deliverability.
* **Bonus Points:** Even if you send less than that threshold, DMARC boosts your email reputation and decreases your chances of ending up in spam filters.

**What You Need to Do as an MXroute Customer**

Don't worry; setting up DMARC isn't rocket science. Here's a quick breakdown:

1. **The Email Authentication Basics:** Make sure you already have SPF and DKIM records set up in your DNS. (MXroute has fantastic guides for doing this if you haven't yet!)
2. **Build Your DMARC House:** Time to add a DMARC record in your DNS as well. Start with a "p=none" policy while getting the hang of it. Here are some easy-to-use tools to generate your initial DMARC record:
- ****MXToolbox:**** ([https://mxtoolbox.com/DMARCRecordGenerator.aspx\](https://mxtoolbox.com/DMARCRecordGenerator.aspx?ref=blog.mxroute.com))
- ****EasyDMARC:**** ([https://easydmarc.com/tools/dmarc-record-generator\](https://easydmarc.com/tools/dmarc-record-generator?ref=blog.mxroute.com))
3. **Analyze and Act:** DMARC tells you where to send reports about how your emails are doing. Be ready to review these and improve any misalignments you find.
4. **The Grand Upgrade:** When confident your emails are legit, gradually ramp up to a stricter DMARC policy ("p=quarantine" and eventually "p=reject") for maximum protection.

**MXroute Is Here to Help**

Being a savvy email sender means staying ahead of the curve. Don't worry; MXroute provides excellent resources and documentation to walk you through setting these records up. Don't hesitate to reach out to support if you need a hand along the way!

**Key Takeaways**

* **It's NOT Optional:** The email landscape is changing for the better. While you might still send emails without DMARC, you'll face increasing issues with getting to your customers' inboxes.
* **Invest Now, Reap Benefits Later:** DMARC compliance makes you a reliable and trustworthy sender – meaning that more of your important emails make it through.
* **Don't Fear the Tech:** DMARC is just a DNS record. Even the least tech-savvy can do this! Break it down and use the many available tools and support from MXroute.

**Happy Sending!**

I failed, I'm sorry

Mon, 18 Dec 2023 00:00:00 GMT

I come to you in a public space to do a few things, and to do it all without my beloved ChatGPT. Let me make myself an outline so I don't forget what I'm here to do:

1. I hope this message finds you well. Just kidding.
2. Explain what happened
3. Explain what we’re doing
4. Explain what was learned from it
5. Ask for your forgiveness
6. Ask for a second chance

### So here's what happened

On September 24th the RAID controller failed for the lucy.mxrouting.net server. Through incredible late night efforts, including such rockstars as Jeff & Fran, the OS was recovered and booted after a roughly 12 hour outage. However, it's disks were transplanted into a 12 bay server. I didn't want to pay for that chassis, Jeff didn't want to waste that chassis on a 4 disk server. Understandably, we knew it was a temporary home but it was the fastest way to get the job done by remote hands. I may be exaggerating, but any way you spin it, if we wait for OS services to spin down normally this becomes a multi hour outage. So both the test reboot and the power off for the chassis swap were hard power events. It's fine, a little InnoDB recovery happens sometimes, it's not a huge deal and we have backups. Little did we know, each one of those hard power events was taking more and more of a toll on an already barely stable file system (never again, XFS) and this last one was the straw that broke the camel's back.

So there we are on December 5th, around 10PM. with a Lucy that just isn't going to boot. I'm not great with boot stuff, I ask for help. The great minds of Jeff and Paul, and some advice from Fran along the way, we get it booted after an xfs\_repair (after that segfaults a few times, and not due to a memory issue). Then starts the "input/output" errors flooding the console, it's fucked. Reboot, no go. Another xfs\_repair, it boots. Input/output error. You see the pattern, and every time we fill the lost+found folder with new guests.

At this point I begin working to restore backups to a Hetzner server, because my backups are there and transferring several TB is best done in the same datacenter. Even still, because they're incremental and not archives, transferring those backups to a nearby server was going to take days (and it did take days).

So there I am having automated my current step, while the guys are poking around at the original server trying to help me save face. I'm transferring backups, not exactly a process that needs me to baby it. After so much time and effort, I become convinced that it's a hardware issue with the original server. It doesn't matter to me that Jeff double checked and tested every single thing in this server. I'm not sold. I wish I could tell you I didn't cry over this, but as soon as everyone else was asleep I was in tears. This is everything to me, this is how I have a roof over our heads and food on the table. If I fail, we fail. Jeff felt that pain and drove 400 miles to build me a brand new server and put those disks in. We got Lucy back up for about 30 minutes. I was there repairing what xfs\_repair took, copying key system files from an identical system, reinstalling perl, rebuilding services. Just when I get it all working and Jeff is questioning his sanity, boom. Input/output error. He was right, I was wrong, but that beautiful man still did this for me. Remember [QuickPacket](https://quickpacket.com/?ref=blog.mxroute.com) when you need a dedicated server, but anyway.

I booted into a recovery ISO, turned on networking, ran xfs\_repair again, mounted the file system, and began using that as the framework for restoring Lucy to a new server in Virginia. I had to rebuild domain password files for a few hundred domains. I had to rebuild alias files, carefully copy what was needed into passwd, shadow, group, you know the job. I was restoring by hand, not from the multiple TBs of backups all the way in Germany. When I finished creating the accounts and their file/folder structures, I turned it on and told users that their emails would be coming back in two rsync jobs. Once from the previous server's mounted FS, and once from the maildirs in the incremental JetBackup backups.

We got it all settled and I declared Lucy fixed on the afternoon of December 10th. I wasn't done, I still had tickets to take care of for one-off fixes all over the box. But none were connected to each other or globally shared issues, so at that point I considered it "done" but kept working.

Doing things like traversing all directories in /home on a ~2800 user box, with resellers frantically running the DirectAdmin backup system to gzip and transfer their backups for safe keeping, and while the RAID was syncing, we had about 25% iowait on average with occasional spikes of up to 50%. So while I had come up with a better backup plan that would help me recover from this type of event faster, I wasn't going to bring the box to it's knees to enact it. That was going to go into effect on the afternoon of December 16th, as iowait had dropped to 0% and things were settled enough to be worth taking a new backup. I went to bed the night before, set an alarm, and knew that I'd be doing backups after lunch. Murphy, unfortunately, had other plans.

On the morning of December 16th, bright and early (just after 5AM my time) I received a page from customers. Just a page, as Lucy was checking all of the boxes for monitoring (ping, SMTP). It seemed that parts of the server were inaccessible. In fact, I couldn’t SSH into it. There were permission errors across the IPMI console. I rebooted. After all, we’re on ext4 now, it’s not as sensitive as XFS seemed to be under our load/conditions. Then I get an error from the RAID controller about a “foreign configuration.” As with boot problems, hardware RAID lingo isn’t my strong point. I called in help. It was determined that at least 1 drive had been dropped from the RAID. We had remote hands reseat the drives, no dice. After a lot of work, again by Jeff who is a master at these things that I’m not, things weren’t looking much better. We still don’t know with 100% certainty what happened, and we’re still working to recover what we can from that server, but this is what we think happened:

With all of the repair operations digging through the folders on /home and with resellers doing so many backup jobs at once, we believe that one of the disks took so long to sync that the controller gave up on it. I wasn’t monitoring the RAID yet, I wasn’t even done with my work on the box yet, so I wouldn’t have noticed at the time. We then believe a second drive started failing, as it began showing SMART errors that weren’t there when we provisioned the box, and as you probably know this is the death moment for RAID10. You get one out of sync, that’s it. Any others, the end.

### Here’s what we’re doing

The backups that I was transferring in Germany to a new nearby server, just in case we couldn’t resurrect Lucy quickly enough in Virginia, had finished transferring to that new server days ago. However, since JetBackup requires that you check an additional box to enable a feature that makes restoring backups not absolute hell (and leaves it off by default), I still had to package them all up and restore them one by one, each account. After scripting it, I broke the job into 12 tasks (each with a list of 250 or less accounts fed to it) to perform the tar and restore on each account. Those restores are still running. As I’m writing this sentence, we’ve restored 1009 of them. I expect the rest to be done by the end of tomorrow (Monday, US/Central).

We’re cloning all 4 disks from the RAID on the previous Lucy server in hopes that we might get around any possible disk issues and be able to focus on recovering whatever we can from it’s file system, because that’s where the last week of email for those users resides. Because, again, the first backup of the new server was to take place after this outage occurred.

We’re removing JetBackup on all systems and going to an rsync backup. With this, we can rebuild a server’s framework more quickly and get users back online, and then transfer email data over afterward, with ease. Of course an rsync of MySQL while running is a little shitty but again, a little InnoDB recovery isn’t too bad and we're talking about the scenario that currently holds a "once in 10 years" stat for us.

We also credited every user $25 because our most expensive reseller plan is $25/m, and while I wanted to make a more grand gesture, I do need to keep the lights on and we are an intentionally low margin service.

### Here’s what we learned

Servers of this size cannot be backed up using traditional, easy backup systems. A whole snapshot of the server would take weeks, a gzipped archive of each account would take a week to finish one run. I can recover from a copy of the server’s file system within a few hours, and it’s not like this is an everyday situation. Hell, it took 10 years to see one like it. Also, thank you JetBackup for making it optional and off by default to export the JB config to the backup server.

### I ask for your forgiveness

As a long time provider in the hosting community, I’ve failed to be the best version of me that I could be. I wasn’t as ready for this as I thought I was. I’m sorry. I hope that you can forgive me.

### A second chance?

I ask for a second chance. I’ve learned a lot from this. I will be more ready for this type of event in 1-2 weeks and I SWEAR THAT IS NOT A CHALLENGE, MURPHY.

### Answering these questions in advance

I get it. Email storage should be replicated. All servers should have a failover. Everything should be WebHostingTalk’s incorrect definition of “cloud” (high availability). I didn’t set out to just make another email service, I set out to model it after shared web hosting because that’s what I knew, that’s how I could outsource the frontend to a company like DirectAdmin (or previously, cPanel). I wanted to master outbound delivery, not remake Gmail and charge their prices. This is what I made, this is what I’m committed to. I can do better without throwing the entire business plan in the garbage and starting from a clean slate with a set of investors and developers, only to be “yet another $5/m per email user” provider. I appreciate the thoughts and concern, I do appreciate advice, but I’m really not in the mood to hear all of that right now. Say what you want, I just don’t *want* (not that I can have what I want) to hear “Why is each server a standalone box with no failover connected to a $400,000 storage array for services often billed during promotions as low as $5/year?” We can't revolutionize price, virtually limitless users per account, and true high availability at the same time. But we do pretty damn good at availability, relatively. I mean, It's not like those other companies never have issues either. We've always promised that we won't let a bad neighbor effect cause reputation issues for our customers, please try not to be the bad neighbor.

Postmortem Report: lucy.mxrouting.net Server Outage

Sat, 09 Dec 2023 00:00:00 GMT

The owner of our server provider, [QuickPacket](https://quickpacket.com/?ref=blog.mxroute.com), Jeff drove just over 800 miles and had to spend the night in Ashburn to help us recover from this event. Will your hosting provider do that for you? Because ours deserves a damn standing ovation.

### ****Incident Overview****

**Initial Outage (September 24):**
At approximately 2:00 PM on September 24, the Lucy server experienced a crash and subsequent failure during reboot. Investigation revealed a malfunction in the RAID controller. By 9:00 PM, we had successfully transferred the drives into a new chassis, which included a new motherboard and RAID controller. However, this crash led to file system damage, delaying the full restoration of the server until around 1:00 AM on September 25.

### ****Subsequent Developments****

**Chassis Replacement (December 5):**
Due to the unsuitability of the temporary chassis for the long-term operation of Lucy, a chassis swap was scheduled and executed on December 5 at around 10:30 PM. The swap was expected to be brief, but complications arose.

**Complications During Swap:**
Post-swap, the server's operating system failed to boot, displaying numerous "input/output errors." Despite several attempts and variations in our repair methods, the system remained unbootable.

### ****Disaster Recovery Efforts****

**Provider Intervention:**
Our service provider, QuickPacket, with team members Jeff and Paul, dedicated significant efforts to physically address the server issues.

**Backup Restoration Challenges:**
Concurrently, we initiated disaster recovery protocols, only to discover a missed critical step in our backup software, JetBackup. This oversight necessitated a full rsync of 8TB of backups from the backup server to a new server, significantly prolonging the recovery process.

### ****Critical Turning Points****

**December 6 Developments:**
The original server was declared inoperable on the evening of December 6, with suspicions of a hardware issue masked by file system errors.

**Final Attempt to Revive Original Server (December 7):**
On the morning of December 7, Jeff drove 400 miles to Ashburn for a last-ditch effort to revive Lucy. This involved constructing a new server and transferring the drives. Initially successful, the server soon reverted to its previous "input/output error" state.

### ****Implementation of Plan B****

**New Strategy:**
Abandoning efforts to revive the original server, we shifted focus to rebuilding the Lucy server in Virginia, prioritizing user access over data recovery.

**Successful Reconstruction (December 7):**
By the night of December 7, we had reconstructed the basic framework of the Lucy server, restoring user access. However, some data, including emails and domain passwords, were initially lost or misplaced.

### ****Ongoing Recovery and Restoration****

**Data Recovery:**
Efforts are ongoing to restore previous emails and operational functionalities. We are prioritizing data retrieval from the original server, followed by backup server recoveries.

**Technical Challenges:**
Database migrations and compatibility issues between MySQL versions are being addressed. We anticipate some unique, isolated issues and are prepared to address them as they arise.

### ****Reflection and Future Measures****

**Disaster Recovery Plan Assessment:**
This incident, the first of its magnitude since 2013, highlighted significant shortcomings in our disaster recovery plan. We are revisiting our original plan, which involves continuous rsync to a backup server. Backup software is nice and all, but at our scale and with the methods of our deployments, they're not the best choice for this type of event. Our original plan was simply to rsync every server to a backup server. Had we done that here we could have had users back online in 2-4 hours, only taking longer to sync back emails that users had in their mailboxes prior to the event (but allowing them to receive new email and send email during that time). Our original plan was superior, and we're going back to that. This means that once we finish deploying the new old backup strategy, this series of events can never occur again.

**In Closing:**
Our commitment to service reliability remains unwavering. We regret the inconvenience caused by this outage and are taking robust measures to prevent a recurrence of such an event. We appreciate your patience and understanding as we continue to enhance our systems for better resilience and reliability.

Unmasking the .monster TLD: Are Spammers Running Rampant?

Thu, 10 Aug 2023 00:00:00 GMT

In the vast expanse of the internet, the battle against spam is a never-ending struggle. Recently, concerns have been raised about the .monster top-level domain (TLD), with suspicions that it might be serving as a haven for spammers. This blog post delves into the alarming pattern of one-day spam domains under the .monster TLD, examines the origins of this spam, and questions whether it's merely a coincidence or something more sinister.

The Suspicious Trend
--------------------

A perplexing phenomenon has caught the attention of online security experts: the proliferation of one-day spam domains under the .monster TLD. Unlike other TLDs that have experienced occasional spam outbreaks, the deluge of spam from .monster during its launch suggests a different pattern than what we've seen with other TLDs. This stark contrast prompts questions about the true intentions behind the .monster TLD and who might be pulling the strings.

Behind the Scenes: Network Analysis
-----------------------------------

Unveiling the curtain on the origins of this spam, network analysis reveals a startling revelation. The bulk of spam emanating from .monster domains seems to originate from a limited number of networks. This concentration of spam sources suggests a coordinated effort rather than isolated incidents. Such a pattern prompts suspicions about the true intentions behind the .monster TLD and who might be pulling the strings.

A Mysterious Operator
---------------------

The heart of this debate revolves around the ownership and operation of the .monster TLD. The frequency and scale of disposable, one-day spam domains suggest an entity capable of mass-producing .monster domains with minimal overhead. This level of efficiency appears incongruous with the usual operations of a TLD during a promotional phase. As such, it raises the question of whether the .monster TLD is under the control of individuals with motives beyond the standard promotion of a new TLD.

Conclusion
----------

The ongoing surge of spam from .monster domains sparks concerns about the integrity of the domain registration process. While correlation does not always imply causation, the distinct pattern of spam and its origins from specific networks point toward the possibility of coordinated spamming efforts. The situation underscores the importance of maintaining vigilance within the digital realm and raises questions about the accountability of TLD operators.

As the debate continues, the battle against spam evolves into new territories, prompting us to critically assess the systems we rely on for a safe and secure online experience. Whether the .monster TLD is indeed harboring spammers, are actually the spammers themselves, or if there's a more benign explanation, the need for transparency and robust safeguards within the domain registration process becomes ever more paramount.

At MXroute, we've blocked all inbound mail from .monster domains. We've seen a 0% correlation between this and blocking legitimate emails.

Commitment to Free Speech

Mon, 31 Jul 2023 00:00:00 GMT

In the ever-evolving world of the internet, the commitment to free speech is not just a virtue, but a necessity for companies providing internet services. The dynamic landscape of social behavior and public opinion is such that today's villain can easily become tomorrow's hero, and vice versa. The heroes of today are realistically only a stone's throw away from being perceived as villains. This constant shift in perception underscores the importance of preserving all forms of speech, even those we might find morally reprehensible.

Our moral absolutes are not universally accepted truths, but rather subjective interpretations shaped by our individual experiences and societal norms. What one deems to be a moral absolute today may be met with widespread disagreement tomorrow. This is not to say that our moral compasses are inherently flawed, but rather that they are susceptible to the ever-changing tides of societal norms and values.

In this context, the worst thing we can do is to adopt a "scorched earth" approach, eradicating the views that oppose what is currently deemed morally acceptable. This approach not only stifles discourse but also threatens the very essence of free speech. We must resist the urge to silence dissenting voices, no matter how much we disagree with them. Instead, we must strive to protect all forms of speech, even those we find morally repugnant.

This is not a call to endorse or promote hate speech or harmful rhetoric. Rather, it is a call to protect the principle of free speech, to safeguard what we may despise today so that what we cherish today might survive being despised tomorrow. The vile, disgusting, and horrible things that people say today must be protected in the hope that they will reciprocate and protect our speech in the future.

The struggle to maintain this balance will never end, but we must rise above the fray. The true test of our commitment to free speech lies not in protecting speech that aligns with our beliefs, but in safeguarding speech that we find abhorrent. This commitment is vital to preserving the integrity of the internet, a platform that thrives on the free exchange of ideas.

We must let the future judge us by who we were, not by who we wanted to be. We must allow our words, actions, and beliefs to stand the test of time, to be scrutinized, criticized, and perhaps even vilified. Only then can we truly appreciate the value of free speech and understand its role in shaping our society.

While the commitment to free speech is paramount, it should not be misconstrued as a contradiction to MXroute's dedication to preventing our service from being exploited for spamming purposes. Neither should it be interpreted as a willingness to sacrifice the majority of our customers to protect a single one. The reality of running a business necessitates making tough decisions. However, it is our fervent hope and intent that these business decisions will consistently align with our commitment to free speech. We believe in striking a balance that upholds the principles of free speech while ensuring the integrity and functionality of our services. This delicate equilibrium is what we strive for, as we navigate the complex landscape of the internet, free speech, and the needs of our diverse customer base.

DKIM Signing Change / "Vulnerability" Exposure

Wed, 19 Jul 2023 00:00:00 GMT

Two days ago a customer of ours approached us to report what they called a vulnerability. While it's not an entirely unfair use of the word "vulnerability," it isn't quite deserving of being categorized with exposure of private data, server intrusions, or any of the normal things that often worry or excite people when the word "vulnerability" is used. It's actually nothing new, and it's nothing we weren't already aware of. However, the user chose to publicize it and that necessitates a public response.

The Resolution
--------------

The change made to address this is simple: When you send an email, the email is signed by a DKIM key on our system. That DKIM key is different for each domain. Three days ago, the DKIM key was signed based on your sending domain (the domain in your envelope-sender address). Two days ago, that changed to now be based on the domain in your authenticated domain. So if you use SMTP login credentials for domain1.com, and set your sending address to an address on domain2.com, the email is signed by the DKIM key for domain1.com. This is only significant if you authenticate as one domain, while sending email from another domain.

The Problem
-----------

The user [reported this on Reddit](https://www.reddit.com/r/mxroute/comments/152ipkb/mxroute\_spoofing\_vulnerability/?ref=blog.mxroute.com) as a vulnerability for a simple reason. I'm going to use sample data to describe it:

On the echo.mxrouting.net Customer1 added the domain domainone.com. Customer2 added the domain domaintwo.com. If Customer2 sent an email that claimed "user@domainone.com" as it's sending address, the echo.mxrouting.net server would sign the email with the DKIM key for domainone.com, even though domainone.com belongs to Customer1, not Customer2. This means that technically, Customer2 could send an email as Customer1 which passed both SPF and DKIM authentication, making it appear very real and legitimate to the recipient. The recipient could not be expected to have any idea that the email was not real or legitimate. You can hopefully see pretty quickly why that's a problem, and you can imagine the ways that this can be exploited.

My Response to the Disclosure
-----------------------------

I would like to paste my response from Reddit here, and let that be the remainder of this blog post.

> I've known about this since 2011, a lot of us have. It's the way all cPanel and DirectAdmin servers function, likely extending much further than that. It's pretty inherent in an average exim configuration. It signs DKIM based on the sender domain, not the authenticated domain, and no ownership of the sender domain is checked.

> I'd been thinking nearly every day for years how I would handle this when someone figured it out. Because I didn't want to be the first one to break functionality that innocent users were taking advantage of for their own convenience across a wealth of companies, when no one was abusing it, simply to be the hardliner who elevated possible abuse over real world usage. My hope was that someone would figure it out at a much larger company than ours, so that someone with a larger budget and more staffing could develop a more elegant drop-in solution and everyone downstream (like us) could benefit from their work.

> My frustration is that this could have been found at a wealth of publicly traded companies, that it's first publication didn't have to be outed as an "MXroute vulnerability" when we're one of the lowest budget companies using the same software stack. So I now have to be the one to break functionality that a fair amount of users were innocently using for their own convenience, while no one has been abusing this, because it has finally been made public and unfortunately framed as my failure rather than that of so many major corporations who came before me.

> The reason your account was terminated is much simpler. While I understand your intent for testing this and I did say as much in our brief conversation, I also needed you to understand my commitment to preventing abuse of our platform. So I suspended the email account (not your whole account) that you had used to spoof the sending address of other customers of ours on the same server as your account, and I asked you to promise that you would not be spoofing the sending address of any other customer of ours. When your response made no such promise but instead became rather combative and calling my response "concerning," I terminated your account.

>That I knew for many years of a problem stretching across a wealth of companies, which house millions of accounts, that you found to be new and shocking information does bother me. Because, quite frankly, your day job is handling security at a company so significant to everyone that your security is quite literally sitting next to my car keys. I have to admit that it makes me question if this isn't new information at all, but rather that you wanted MXroute to be the ones to suffer from the exposure when you knew you could've picked from any number of publicly traded companies. That bothers me enough to ban you from the subreddit, because it's plausible to me that your motives aren't pure. The alternative is even more troubling, that the person handling such widespread security that I would have it on my own personal keychain, is out of touch with industry security on the ground. I'm not outing you for that, let the reader's imagination run wild, but it's my honest concern.

The Flaws of Using Gmail as a Frontend for MXroute

Fri, 07 Jul 2023 00:00:00 GMT

In today's digital age, email plays a crucial role in our personal and professional lives. Whether for personal or business purposes, it is an indispensable tool for communication. However, with the rise of email service providers and the increasing number of laws and regulations governing email marketing, it is becoming more important to ensure the authenticity of emails to protect users from malicious activities. That's where Sender Policy Framework (SPF) comes in.

SPF is an email authentication protocol that verifies the identity of the sender and ensures that the emails are coming from authorized sources. It works by publishing a list of authorized sending IP addresses in the domain's DNS record. When an email server receives an email, it can check the SPF record of the domain that sent the email and determine whether the email is legitimate or not.

Why is Maintaining a Valid SPF Record Essential to Email Delivery?

1. Prevents Spoofing: SPF helps prevent email spoofing, which is a type of phishing scam where cybercriminals send emails that appear to come from a trusted source. With a valid SPF record, email servers can detect and reject emails that are not from authorized sources, preventing users from falling victim to these scams.

2. Increases Email Deliverability: A valid SPF record can improve email deliverability by reducing the likelihood of emails being marked as spam. By verifying the authenticity of emails, SPF helps ensure that emails are delivered to the inbox, rather than being filtered into the spam folder.

3. Builds Reputation: SPF plays a critical role in building the reputation of a domain. A domain with a valid SPF record is viewed as a trustworthy source, and emails from that domain are more likely to be delivered to the inbox. On the other hand, a domain without a valid SPF record may be seen as a potential source of spam, and emails from that domain may be filtered into the spam folder.

4. Protects Against Phishing Scams: Phishing scams are a common threat to users, and they can cause serious damage if they go unnoticed. By verifying the authenticity of emails, SPF helps protect users from falling victim to these scams.

In conclusion, maintaining a valid SPF record is essential to ensure the security and reliability of emails. By verifying the identity of the sender and ensuring that emails are coming from authorized sources, SPF helps prevent spoofing, increase email deliverability, build reputation, and protect against phishing scams. So, if you're not already using SPF, it's time to start!

Find help setting up your SPF record with MXroute here: [https://mxroutedocs.com/dns/dnsrecords/\](https://mxroutedocs.com/dns/dnsrecords/?ref=blog.mxroute.com)

MXroute Outbound Delivery Delays: When MongoDB Became a Hungry Hungry Hippo

Fri, 16 Jun 2023 00:00:00 GMT

In the early morning of June 15th, users of MXroute experienced outbound delivery delays that disrupted their communication flow.

Dispelling Misconceptions: Understanding UCEPROTECT and Realtime Blacklists

Mon, 22 May 2023 00:00:00 GMT

In our mission to revolutionize the industry, we have encountered widespread misinformation surrounding email practices.

Introducing the New MXroute Webmail Upgrade: All Your Email Needs in One Place

Thu, 11 May 2023 00:00:00 GMT

Email compromises on the rise

Fri, 05 May 2023 00:00:00 GMT

We're seeing a continual increase in the number of compromised email accounts each day, and we've finally identified the source of it.

MXRBL Moved to SpamAssassin

Mon, 24 Apr 2023 00:00:00 GMT

A while back we launched our own RBL (*) called MXRBL, in response to customer complaints that we were doing a poor job of filtering spam.

Discontinuing Afterlogic

Sun, 16 Apr 2023 00:00:00 GMT

After reviewing all of the relevant variables, the decision has been made to discontinue our support for Afterlogic.

Google's Recent Increase in PTR Record Errors

Wed, 12 Apr 2023 00:00:00 GMT

If you've recently tried to send an email and received an error message stating "The IP address sending this message does not have a PTR record setup," you're not alone.

Pixel Server Migration

Fri, 10 Mar 2023 00:00:00 GMT

This blog post is only relevant to users of the MXroute service who have been provisioned on the pixel.mxrouting.net server.

Sunfire Server Migration

Thu, 09 Mar 2023 00:00:00 GMT

This blog post is only relevant to users of the MXroute service who have been provisioned on the sunfire.mxrouting.net server.

Blizzard Server Migration

Sun, 19 Feb 2023 00:00:00 GMT

This blog post is only relevant to users of the MXroute service who have been provisioned on the blizzard.mxrouting.net server.

Configuring Postfix to Use MXroute as an Outbound Relay

Sun, 19 Feb 2023 00:00:00 GMT

If you're looking for a reliable and cost-effective email relay service, MXroute is an excellent choice.

Accusations of Unfair Account Termination

Sun, 12 Feb 2023 00:00:00 GMT

MXroute is a reputable email hosting service provider that has been serving its customers for many years.

Challenges of IP Reputation

Sun, 12 Feb 2023 00:00:00 GMT

Maintaining a clean IP reputation can be a challenging task, particularly in the context of email marketing and online communication.

Double Opt-In: Why it's Essential for Running a Mailing List

Sun, 12 Feb 2023 00:00:00 GMT

Email marketing is one of the most effective ways to reach out to potential customers and keep existing ones engaged.

Maintaining a Valid SPF Record: Essential for Email Delivery

Sun, 12 Feb 2023 00:00:00 GMT

Email is an indispensable tool for communication in the digital world.