MXroute changelog
MXroute changelog

Reduction of invalid "Domain not found" errors




In some cases recently we've seen "Domain not found" errors by our outbound filter server, causing temporary rejection (4xx, not 5xx) of outbound emails, that were not warranted and that are difficult to explain. Changing up resolvers doesn't appear to be helping. Perhaps our filter server is simply processing too much traffic. We've added Unbound as a local, recursive resolver on the filter server to try to combat this.

Standardized spam_recipients




To combat a growing problem of users flooding queues with invalid recipients / invalid recipient domains (usually due to things like blog or forum registration sending confirmation emails), we create a list on each server that is populated with invalid recipients or invalid recipient domains that users on that server attempted to send mail to. Why we chose this path is a long story, however the problem doesn't seem to be shrinking much, and so we've standardized the list across all servers:

Large Storage Plans




We've been planning to offer larger storage plans for a long time, and now they're finally ready. You can view them here:

Outbound Delays Resolved




We've been seeing more and more outbound delivery delays recently. Most users have not witnessed this, as it represents a very tiny fraction of email our users send. We've made several attempts to mitigate this, which has even further reduced the scope of these events. However, the problem being statistically uncommon hasn't done much to provide comfort on our side, considering that outbound email is kind of our point of pride.

The cause of this has finally been tracked down to an old deployment (stopforumspam recipient block list) that was "fine" at the time, but given the growth of our platform it slowly became a larger issue. A change in how we deploy this is now reducing outbound email delays, to the point that it should completely do away with them.

If you experience outbound delivery delays, we do encourage you to open a support ticket. The chance that any delays you saw were related to this update are roughly 1 in 300,000. So if your emails are being delayed somewhere, let us check and tell you where (if we can).

Blocking the .monster TLD from our platform




The .monster TLD has been permanently banned from sending email to our platform. We have observed zero companies that need to converse with our users using this TLD, we discover an incredible amount of new domains registered every day on this TLD for the sole purpose of sending spam and then discarding. There is no way to stop these spammers in their tracks which captures their next move beforehand, with exception to halting all email from the TLD.

If any of our customers require inbound email from the .monster TLD, we will review their request and consider providing a refund so that they can find a new service. This move is a clear win that has the potential to cost us less than $50 in refunds, while potentially saving us thousands in cancellation requests over spam. There's no contest, this is the best option for us and our customers by a wide margin.

Push Notifications on iOS




We are slowly deploying push notification support for iOS users who use the Apple Mail app. This does not appear to require reconfiguration. However, the mail app does not appear to have alerts enabled by default, if this is desired. For that, go to Settings > Notifications > Mail > Customize Notifications > Select the account and enable Alerts.

Presently this is deployed on the Arrow server only. It will be slowly rolled out to all DirectAdmin-based servers (ex. every server with “” in the name, and a few others) within the next few weeks.

Edited to add servers as this is deployed:

1/25 - Redbull - Done

1/25 - Echo - Done

1/26 - Eagle - Done

1/27 - Pixel - Done

Outbound SMTP Delays Mitigated




Outbound email delays have been a problem for a while, but have been manually mitigated until today. We've determined that the actual fix is going to be further down the line, and so we should automate the mitigation to ensure consistency. The mitigation has been automated by running this every 15 minutes on our servers:

It's not the fix we want, but there are pros and cons to every solution to this problem in our stack, and this will be the least evil automation for it at the moment. While the delays impact less than 0.5% of all email that our users send, we want to make sure that these emails are not disregarded as statistically irrelevant. This will minimize the impact to such a degree that it is unlikely any user will ever visually recognize the result of the already rare delay.

This solution also adds logging so that we can further, and somewhat more reliably, audit the real impact of these delays. This will help to further prioritize a more permanent fix.

The Era of Migrations




Over the next month, we will migrate Blizzard, Sunfire, Pixel, and Echo servers. Each of these servers was deployed with a flaw that will cause excess downtime soon, and we are migrating them to new hardware to prevent customers from having to experience downtime. These migrations will be scheduled where possible, so long as we beat the upcoming downtime event (which we cannot accurately predict a time or date for). Email notices will be sent out to customers on these servers as relevant. So long as we beat the downtime event, users should not experience downtime.

All of your DNS records must point to our servers using a CNAME record, not an A record. The IP of each server will change. This is why we always recommend CNAME records instead of A records.

OVH blacklisted at MXRBL




OVH IP ranges have been blacklisted at our RBL, We have an extensive whitelist that is intended to mitigate false positives. Whitelist requests for OVH IPs will need to be sent to

The amount of spam coming from OVH is obscene, and this issue leads to two types of customers who are equally pissed at all times:

  1. The one who thinks blacklisting an ASN is heavy handed.
  2. The one who is tired of OVH's absolute failure to mitigate spam in 2022.

One of these two will be pissed off and there is literally nothing we can do to prevent that. So we're trying to get the numbers just right, to see if we can piss off the least amount of users possible.

Campaign against invalid sender/recipient domains




We're ramping up an internal campaign against invalid sender and recipient domains. Below should serve as a more detailed explanation.

As a general rule, we cannot assume that a domain which does not presently resolve is an invalid domain. The domain could be experiencing a temporary DNS issue, or we could be experiencing one ourselves. For this reason, email that you send to or from an invalid domain sits in queue and we try again to deliver it every few minutes. This becomes problematic when users collectively send to and from hundreds, or thousands, of actually invalid domains every hour. It causes email queues to explode in size, and it makes it more difficult for us to actually identify problems on our platform as the statistics can be masked by invalid domains that will stay in queue for the maximum amount of time configured.

Automating the blocking of invalid sender/recipient domains has proven to not be a reliable job, as a temporary DNS issue does occasionally occur, and that would cause us to block a valid domain as invalid. Moving forward, we will be performing audits on our platform for invalid sender/recipient domains multiple times throughout each day. The goal is this is to quickly return to you a clear error message at SMTP time when you've attempted to send email to or from an invalid domain.

An example of an invalid domain and one that we just blocked prior to posting this: @pop-os.localdomain