Tell me how you manage your mail and I'll tell you what kind of Hosting you are.

There's a question we always ask when a customer comes in who's switching from another provider, and it doesn't concern the number of cores, the gigabytes of RAM, the type of NVMe drive, or the advertised connection speed. The question is much simpler: how is the mail organized?

This isn't just technical curiosity. Email management is probably one of the best tests for understanding the type of hosting provider you're actually dealing with, because it's simultaneously one of the most difficult services to get right and one of the easiest to make malfunction invisibly.

Everyone sees a slow website. An unreachable site immediately generates a phone call. An email that doesn't arrive, however, is never seen by anyone: the sender thinks they sent it, the recipient doesn't know they should receive it, and the problem arises perhaps three weeks later, when an order, quote, invoice, contractual communication, or important request fails.

It's precisely this invisibility that makes email particularly insidious. An infrastructure can appear to be functioning perfectly, while silently a percentage of messages are classified as spam, temporarily delayed, rejected, or penalized by major providers.

The web today is a largely well-known problem. Put nginx in front of PHP-FPM, add a cache layer, size the resources correctly, fix the database, and with a few tweaks, you can achieve decent results even without building a particularly sophisticated infrastructure.

The post office no.

Email is a distributed ecosystem in which your service depends on the judgment of others : Google, Microsoft, Yahoo, Spamhaus, the recipient's anti-spam systems, public and private blacklists, proprietary reputation systems, and the policies applied by individual administrators.

You can have excellent hardware, lightning-fast storage, and a perfectly reachable server, but still fail to deliver an email because your IP address has lost reputation, a domain isn't properly authenticated, an account has been compromised, or the overall behavior of your infrastructure suddenly resembles that of a spam network.

This is why the way a hosting provider handles email reveals a lot: whether it actually has in-house system expertise or assembles components purchased from third parties; whether it understands how the service it sells works, or whether it will figure it out together with the customer the day something goes wrong.

So let's make an honest ranking, from worst to best.

Level 0: everything on the same machine, with a single IP

This is the scenario we still see very often, and it is the one we must run away from with all our might.

A server. Running on it are Apache or nginx, PHP, MySQL, or MariaDB, the websites of dozens or hundreds of clients, and, on the same machine and often with the same primary IP address, even Postfix and Dovecot.

The control panel—cPanel, Plesk, DirectAdmin, or any equivalent—presents this architecture as a convenience: a single place to manage your domain, website, database, DNS, and email accounts.

For the end user, it seems simple. For the provider, it means, above all, concentrating everything on the same infrastructure: one machine, one license, a few IP addresses, and fewer components to manage.

The problem is that this apparent simplicity creates a huge surface of interdependence.

It's a ticking time bomb, and the mechanism by which it explodes is almost always the same.

Out of two hundred WordPress, Joomla, Drupal, PrestaShop, or Magento sites, sooner or later one will be compromised. This isn't pessimism: it's simply statistical exposure. All it takes is an outdated plugin, an abandoned theme, a zero-day vulnerability, a recycled password, or an FTP login falling into the wrong hands.

The modern attacker rarely simply modifies the homepage, as was done twenty years ago. That doesn't add value. It's much more useful to install a PHP mailer and start sending phishing or spam messages.

Or you can abuse a poorly designed contact form. Or you don't even need to be compromised: all it takes is one customer who decides to send a newsletter to fifteen thousand addresses purchased from a list of questionable origin.

In all these cases, traffic may exit from the same IP address used by other customers' legitimate mail.

From that moment on, the problem of a single site becomes everyone's problem.

The real damage is not spam: it's shared reputation

What happens next is largely mechanical. Honeypots collect messages, reputation lists record activity, and major operators begin to associate that IP address with unwanted behavior.

Microsoft may begin rejecting messages or limiting their acceptance. Other providers may respond directly with SMTP errors. Gmail may continue to accept them but will progressively classify them more aggressively.

And this last scenario is one of the most dangerous, because technically the delivery has taken place.

The sending server sees a positive SMTP code. The message has been accepted. From Postfix's perspective, the job is done.

It's a shame that the message may have ended up in the recipient's spam folder.

And here's the typical ticket:

"Your emails show as delivered, so from our side everything is correct."

No. It just means that the remote server accepted them.

Deliverability and SMTP delivery are not the same thing.

A professional email provider must know this difference and have the tools to analyze it.

When everything shares the same IP, the risk multiplies

At that point the supplier discovers three things in rapid sequence.

The first is that it doesn't have a truly ready-to-use spare IP.

Having a second IP address assigned to your machine doesn't mean you have a second SMTP identity ready. An IP address for mail must have a consistent PTR, correct DNS forwarding, appropriate HELO, aligned SPF, and a reputation built over time.

Suddenly moving everything to an unused IP address doesn't automatically solve the problem. It means starting over with a nonexistent reputation, which can still be a risk factor for modern filters.

The second discovery is that delisting is not a button.

When a reputation is compromised, the first step is to understand what happened, stop the source of the spam, document the incident, and demonstrate that the anomalous behavior will not continue.

Requesting removal from a blacklist without having eliminated the cause simply means being blacklisted again a few hours later.

The third discovery, often the most painful, is that you don't even know where the spam came from.

On the same machine there are hundreds of virtual hosts, tens or hundreds of thousands of PHP files, cron jobs, plugins, CMS, custom scripts, contact forms, and applications.

The mail server log may tell you that a local process delivered a message to Postfix, but connecting that message to the exact site that generated it may require correlation tools that many standard installations simply don't have.

When these tools are missing, the solution becomes brutal: block sending to everyone until the culprit is found.

And a hundred innocent customers pay for one's problem.

Probability is not linear: it accumulates

Then there is a point that almost no one considers: the probability of an accident increases with the number of independent services that share the same reputation.

If we assume, for simplicity, that each site has a 1% annual probability of being compromised, with two hundred sites the probability that at least one will be compromised over the course of a year exceeds 86%.

This doesn't mean that every compromise will generate spam, of course. However, it does mean that aggregate exposure is radically different from that of a single site.

A professional email infrastructure should be designed with the assumption that something will eventually be compromised and ensure that the damage remains contained.

Putting the web and email on the same reputation means doing exactly the opposite.

If your supplier works like this, the question to ask him is not:

"Can it happen?"

The question is:

“When did this last happen, how did you locate the source, and how long did it take you to restore your reputation?”

The answer, or the embarrassment, will tell you a lot.

Level 1: separation, or the bare minimum

The more astute supplier has understood this problem, often because he has already experienced it.

And do the right thing: separate.

On one side are the web servers with the client sites and panels. On the other, an infrastructure dedicated exclusively to mail, with its own IP addresses, PTRs, SMTP configuration, and reputation.

The mail service becomes centralized: customers no longer necessarily use mail.ilmiodominio.it pointed to the same machine as the site, but are served by an independent infrastructure.

The benefits are real and should be recognized.

Reputation is isolated. If a website is compromised, the damage doesn't automatically affect the IP addresses used for regular mail.

Server lifecycles become independent. You can update PHP, migrate a site, change web stacks, or restart an application server without affecting IMAP, SMTP, or user mailboxes.

A minimum level of observability is created. With a dedicated infrastructure, it becomes natural to monitor the queue, message count, authentication attempts, abnormal volumes, and SMTP errors.

Mail storage is separate from website storage. This is important because a website and email archive have completely different characteristics. The former changes constantly but can be restored using code and a database; the latter often contains years of corporate correspondence and grows monotonously.

Capacity can be scaled separately. The web may require CPU, PHP workers, and cache; email may primarily require storage, IOPS, RAM for indexing, and the ability to handle many concurrent IMAP connections.

It is therefore a much better architecture than Level 0.

But this is still only the starting point.

If the provider moves the mail to another server but continues to handle it with exactly the same general-purpose tools as before, they have improved the topology without actually changing the operational model.

And here the real problem emerges.

The real problem: general purpose panels like Plesk, cPanel or DirectAdmin

To understand why tools like cPanel, Plesk, or DirectAdmin have structural limitations in professional email management, we need to remember what they were designed for.

cPanel was born in 1996. Plesk in the late 1990s and became widespread in the early 2000s. DirectAdmin arrived in 2003.

They were created to solve a very specific problem: allowing a non-systems administrator to manage shared hosting through a web interface.

It's a completely legitimate goal, and historically, those products have done their job very well.

The problem is expecting a suite designed to manage twenty different subsystems to simultaneously become a specialized product for each of them.

A general-purpose control panel should handle web servers, virtual hosts, PHP, DNS, databases, FTP users, backups, TLS certificates, mail, autoresponders, mailing lists, statistics, cron, and dozens of other functions.

This is its commercial strength.

But it is also its technical limit.

Modern email, meanwhile, has become a specialized field.

SPF, DKIM, DMARC, ARC, IP reputation, domain reputation, greylisting, DNSBL, URIBL, rate limiting, anomalous authentication, malware, phishing, statistical classifiers, feedback loops, and proprietary reputation systems have transformed the simple SMTP server of twenty years ago into a complex platform.

A dashboard that also needs to handle WordPress, MySQL, and DNS is unlikely to offer the same depth of email tools designed specifically for that purpose.

The accumulated technical debt

Added to this is the inevitable technical debt accumulated over decades of compatibility.

Layered configurations, automatically generated templates, inherited behaviors from previous versions, custom hook and include systems that must coexist with automatic updates.

Anyone who has managed these systems for a long time knows the problem even if they will never admit it due to obvious conflicts of interest.

A seemingly trivial change to Postfix, Dovecot, or the anti-spam engine cannot always be made directly on the configuration file, because that file is generated by the panel.

You then need to understand where the vendor allows you to insert the override, which template to modify, which updates can override it, and whether the customization will continue to work after a major release.

In a normal web installation this can be simply annoying.

In an email system with thousands of users, this becomes an operational limitation that is often insurmountable or forces you to accept unacceptable compromises.

The cost, which is higher than it seems

Then there is the economic question.

The licensing model for many panels has changed over the years, and what was a one-time fee 10 years ago is now tied to the number of accounts, domains, or instances and is applied per server.

This produces a curious effect just when the provider tries to improve its architecture.

Imagine a server with two hundred domains.

The provider correctly decides to separate the web from the mail.

If both servers need to continue using the same control panel and the same two hundred accounts need to exist on both the web and email platforms, the licensing cost can increase significantly.

The technically correct choice therefore becomes economically penalizing and often impossible.

And this creates a perverse incentive: leaving everything in the same machine costs less.

The problem isn't just the cost of the license itself. It's the fact that the product's economic model can end up pushing the architecture in the opposite direction from what would be technically preferable.

The limits that are truly felt

But the cost, in the end, is the least of the problems.

The serious problem arises when something doesn't work.

Try answering these questions through the standard interface of a general-purpose panel:

• A customer says he's not receiving emails from a certain sender. They're not in the spam folder; they're just not arriving. What control blocked them, what score did they receive and why?
• A mailbox has been compromised. When did the anomalous activity begin? From which IP addresses did it authenticate? How many messages did it send, and to what destinations?
• The queue contains four hundred messages. Which are legitimate and which are spam? Which domains are blocked? What error does the recipient return?
• A domain is using 90% of its sending limit. Does the system notify us before it reaches us, or do we only find out when the mail stops being sent?
• The customer wants to know what happened to the email from 14:32 PM on Tuesday. Can we reconstruct its entire path or can we just say that from the log it appears to have been delivered?
• An address suddenly authenticates from two different continents in a matter of minutes. Does the system highlight the anomaly or do we have to manually find it in the logs?
• A given legitimate sender is blocked on ten different domains. Can we verify if there is a common rule that generates the false positive?

On many general purpose panels the concrete answer is:

you go to SSH.

And here an interesting contradiction, almost a paradox, arises.

The panel is used by non-technical customers to create a mailbox, change a password, or set up an autoresponder.

But when you actually need to figure out what happened, the work is done outside the panel by someone who knows how to interpret the logs, namely a technician.

If that someone exists, the provider can still work.

If it doesn't exist, the ticket ends with the catch-all phrase:

«We checked and from our side everything seems correct.»

That sentence, when not accompanied by data, is not a diagnosis.

It is the admission of the absence of diagnostic tools.

The decisive test: “Why didn’t this email arrive?”

There is one question that alone separates a truly managed email service from a simply installed one:

"Why didn't this email arrive?"

No:

"Is the server working?"

No:

"Is Postfix active?"

No:

"Does the domain still have space available?"

But exactly:

"What happened to this specific message?"

Let's take one of the most common tickets:

"A client of mine, across multiple domains, is unable to receive some emails due to spam blocks. Is there a solution?"

Not much information. Maybe a couple of screenshots.

Yet there is already a fundamental clue: «across different domains».

If different, independent domains exhibit exactly the same behavior toward the same type of message, the probability that the problem lies in the configuration of each individual domain drops dramatically.

We need to look for what those domains have in common.

And what they often have in common is the filter.

The anatomy of a false positive

A modern spam engine rarely makes a decision based on a single rule.

It analyzes numerous signals: sender IP reputation, SPF and DKIM authentication, DMARC alignment, MIME structure, presence of URLs, reputation of domains contained in the message, attachments, linguistic characteristics, statistical patterns, sender history and numerous other indicators.

Each of these elements contributes to the final verdict.

The model works very well precisely because no single signal necessarily has to be decisive.

But it has an important consequence: a single rule with too much weight can alter the entire result.

A perfectly legitimate message can have ten positive indicators, a good reputation, correct SPF, valid DKIM, and a statistical classifier that considers it legitimate.

However, if a single feature triggers a rule with a sufficiently high score, the message can still pass the rejection threshold.

And when it happens, it's not a random message that gets hit.

A category is affected.

All messages produced by the same platform. All those containing a specific MIME structure. All those originating from a specific network. All those containing a certain combination of elements.

For this reason, the symptom often appears simultaneously on different domains.

It is not a coincidence.

It's a diagnostic signature.

What does it really take to solve it?

You need at least five tools, and none are optional.

1. An archive of blocked messages. You need to be able to see the original message, the final score, and the symbols that contributed to the verdict. If the message is simply rejected and disappears, the diagnosis starts with half the information missing.
2. The possibility of reproducing the verdict. You need to be able to run the message through the antispam engine and verify exactly which rules are triggered. A reproducible diagnosis is very different from a guess.
3. Configuration control. Identifying a bad rule is useless if the system does not allow it to be permanently modified.
4. An environment in which to test the fix. Blindly changing filter behavior on a server that handles thousands of mailboxes means using clients as a test environment.
5. Regression testing. Eliminating the false positive isn't enough. You need to ensure that the change hasn't simultaneously opened a door to the spam that the rule was designed to intercept.

This last point is fundamental.

Disabling a rule is easy.

Fixing it is another thing.

The professional solution is surgical: the legitimate message must get through, while the truly unwanted one must continue to be stopped.

And this difference must be measurable and demonstrable.

Without these tools, the provider cannot truly say that an email has been correctly filtered.

He can only note that it has not arrived.

And that's a huge difference.

Level 2: Dedicated infrastructure and specialized tools

The next level isn't just about putting your mail on a different machine.

It consists of treating it as an autonomous service.

This means designing SMTP, IMAP, anti-spam, antivirus, authentication, DNS, monitoring, storage, backup, and reputation separately.

It also means eliminating the idea that the mail server is just an accessory feature of web hosting.

A serious system should be able to continue functioning even if the entire web platform were shut down.

The customer can migrate the site, change the PHP version, move the database or modify their CMS without this having any effect on the email.

Likewise, an SMTP issue shouldn't compromise WordPress, Prestashop, or Magento.

Separating failure domains is one of the fundamental principles of systems administration.

Mail should be no exception.

How we do it professionally: the stack

At ManagedServer.it we have decided to break away from this logic.

No general purpose panels to manage the heart of the mail service.

We use an open source stack made up of specialized software chosen component by component, configured and integrated with the goal of doing only one thing: managing email in a controllable, observable and diagnosable way.

Postfix and postscreen

Postfix is ​​used as the MTA.

In front of it operates postscreen , which performs an extremely important function: eliminating a large amount of automated traffic before it reaches the most expensive components of the SMTP chain.

Bots that do not properly follow the protocol, hosts with suspicious characteristics, and automated systems can be identified without unnecessarily tying up all the backend resources.

It's a simple principle: there's no point in subjecting every connection from the Internet to all the most expensive checks if some of them can be eliminated at the entrance.

Dovecot and full-text search

Dovecot handles IMAP and POP3 access.

When a mailbox contains a few hundred messages, traditional search may be sufficient.

When it contains tens or hundreds of thousands of emails accumulated over ten years of business activity, the situation changes.

For this reason, we use full-text indexing through Solr , so as to avoid each search becoming a linear scan of the entire archive.

The difference seems minor until the day a user searches for a 2019 invoice inside a thirty-gigabyte mailbox.

rspamd

rspamd is the anti-spam engine.

It is probably one of the components that most differentiates the infrastructure.

Not only because it is very efficient, but above all because it is queryable, configurable and observable.

Each message can be associated with the symbols that contributed to the final score.

This allows you to transform a sentence like:

"the filter considers it spam"

in:

«the message received this score for these precise reasons».

It's the difference between a cloudy verdict and a diagnosis.

Antivirus, signature and shared status

ClamAV and amavis participate in the antivirus control chain, while OpenDKIM handles the cryptographic signing of outgoing messages.

Redis is used for information that needs to be accessed and updated quickly, such as statistics, rate limiting, and data shared between components.

Each component does its job.

It is the opposite of the monolithic approach in which a single pane of glass claims to govern every level of the infrastructure.

DNS, the component that almost no one considers

Then there is a detail that at first glance seems secondary but which can instead radically change the quality of the filtering: the local recursive DNS resolver.

An anti-spam system continuously performs DNS queries.

Check blacklists, domain reputation, SPF records, DKIM, DMARC, reverse DNS, and more.

If all these requests are sent through public or shared resolvers, some reputational sources may limit, reject, or alter the responses.

The problem is particularly insidious because the mail server apparently continues to function.

It doesn't necessarily appear to be an obvious error.

Simply some signals stop contributing correctly to the verdict.

Having a resolver under your control means knowing the behavior of queries, reducing external dependencies, and being able to diagnose this level of the chain as well.

And it's a perfect example of the difference between installing a mail server and actually managing a mail infrastructure.

Redundancy: Why "dedicated" doesn't necessarily mean "reliable"

Separating your email from the web is essential, but it's not enough.

If all your mail resides on a single server, that remains a single point of failure.

For this reason, a professional architecture must also think in terms of redundancy, backup, and disaster recovery.

The question to ask is not only:

"Do you have a dedicated mail server?"

But also:

“What happens if that server loses storage?”

"How long does it take to rebuild?"

"How many hours of mail do we potentially waste?"

"Is there a geographically separate copy?"

"Are backups actually verified?"

Making a backup does not necessarily mean you can restore it.

A backup is only useful when there is a realistic procedure for using it and when the time required for recovery is compatible with the service being sold.

For mail, this is especially important because a company archive can contain years of unreproducible documents and conversations.

M@il Admin: the panel that generalist panels don't have

On top of this stack we built what specialized tools typically lack: an interface designed exactly for the way we administer mail.

M@il Admin is the frontend developed internally to manage this infrastructure.

It is not a fork, it is not a graphic theme applied to a commercial product and it is not a layer that tries to hide an existing panel.

It is software written from scratch around the stack that actually exists underneath.

And this is precisely what allows us to expose functions that a general purpose panel could hardly offer.

Multi-level and multi-domain access

M@il Admin is multi-level and multi-domain.

There are different access profiles: global administration, domain administration, and end user.

Data separation is not simply graphical.

Filtering is applied server-side based on permissions.

This means that a domain administrator can diagnose their own mail without being able to access information belonging to other clients.

This is a fundamental aspect because the goal is not just to provide more functions to the user.

It is providing more autonomy without giving up separation and privacy.

Observability: Knowing what's happening

The main problem with many infrastructures is not that events are not recorded.

It's just that nobody sees them.

A log that contains the right information but requires twenty minutes of grep, manual correlations, and knowledge of the internal structure of the service is certainly useful to the system administrator, but it is still not observable.

Observability arises when that information is organized to quickly answer operational questions.

Mail Flow Dashboard

The dashboard shows outbound load and queue status in real time, with adaptive granularity.

The goal is not to produce a graph that is beautiful to display.

The goal is to answer a question in a few seconds:

“Is something strange happening now?”

A sudden increase in mailings may indicate a legitimate newsletter.

However, it can also be the first sign of a compromised mailbox.

The difference emerges when looking at the domain involved, the mailbox, the time, the destination and the historical behavior.

Queryable mail queue

The queue is not simply the output of postqueue.

You can filter by sender and recipient, group messages by error, and instantly identify which destinations are causing problems.

But above all, it is possible to go into the details of the message.

Subject, sender, recipients, headers, check results, body, and attachments become searchable elements.

You can also get the file .eml original for in-depth analysis.

HTML content preview is handled server-side, avoiding automatic loading of remote resources.

This is an important detail.

Opening a preview of a suspicious message should not, in fact, turn into a confirmation to the spammer that the mailbox exists and that the contents have been opened.

URLs remain visible, allowing you to quickly identify suspicious domains and phishing attempts.

The practical difference is enormous.

From:

“There are four hundred messages in the queue.”

we move on to:

“There are four hundred messages, three hundred and fifty are the result of a compromised account, and fifty are legitimate messages temporarily rejected by Microsoft.”

The first is information.

The second is an operational diagnosis.

Email Tracking

A message does not necessarily go through only one process.

It can enter via SMTP, be scanned by antivirus, pass through the antispam engine, be reinjected into the system, and generate different identifiers at various stages.

Simply searching for a single queue ID can therefore provide an incomplete view.

M@il Admin reconstructs the message path and identifies its direction: inbound, outbound, internal traffic, or failed delivery notification.

The result can be exported to PDF and sent to the customer.

When someone asks:

"What happened to the 14:32 PM email?"

we don't want to respond with:

«From the logs everything looks correct.»

We want to be able to produce a document with the events actually observed.

Sending volume

Submissions are aggregated by domain and mailbox.

You can check recipients, outcomes, and the percentage of consumption compared to the configured limit.

This allows us to quickly distinguish normal from abnormal behavior.

A management system that sends two thousand notifications every day isn't necessarily a problem.

A personal inbox that suddenly goes from ten messages a day to two thousand yeses.

The absolute number alone is of little use.

Context matters.

Archive of blocked messages

Anything that is stopped by the filter can be analyzed later.

The sender, recipient, score and symbols that determined the verdict become queryable.

It is precisely the tool needed to answer the question:

"Why didn't this email arrive?"

Without an archive one can only infer.

You can check with the archive.

Anti-spam dashboard by domain

Each domain has its own statistics.

The customer can see how much traffic is intercepted, which categories of checks are most frequent, and how the trend changes over time.

It's also a way to make a service visible that would otherwise only be noticed when it fails.

A good antispam, paradoxically, is almost invisible.

If it successfully deletes thousands of unwanted messages without generating false positives, the customer simply won't see them.

Statistics help show what's going on behind the scenes.

Security: noticing problems before customers do

Email security isn't just about blocking incoming viruses and phishing.

One of the main risks is the compromise of legitimate accounts.

When an attacker obtains the password for a mailbox, he does not need to crack Postfix or Dovecot.

It authenticates normally.

From a protocol point of view, he is a valid user.

The difference emerges from behavior.

Monitoring of anomalous shipments

An inbox that normally sends twenty messages a day and suddenly sends a thousand at three in the morning is saying something.

It is not necessarily compromised.

But it deserves attention.

For this reason, M@il Admin highlights anomalous volumes and trends, allowing you to reach the affected mailbox before the reputational damage becomes evident.

Anomalous accesses

The same principle applies to authentications.

Incompatible IP addresses, networks, and geographic origins can be a strong indicator of compromise.

For each IP address, you can obtain network and WHOIS information, so you can quickly distinguish a normal mobile connection from a server in a data center on the other side of the world.

The fundamental point is one:

Who notices it first?

In an infrastructure without observability, it is often the recipient.

SMTP errors start appearing. IPs lose reputation. Emails end up in spam.

Only then does someone investigate.

But by then the damage has already been done.

With the right tools, it is possible to intervene on anomalous behavior when it is still just an anomaly.

Granular sending limits

Rate limiting must be smart enough not to treat everyone the same.

A professional firm that sends ten emails a day doesn't have the same profile as a management system that sends thousands of notifications.

For this reason, the thresholds can be defined per domain and per individual mailbox, with the possibility of derogation.

The goal is not to prevent legitimate mass mailing.

The goal is to ensure that a compromised account cannot turn a local incident into a reputational problem for the entire infrastructure in a matter of minutes.

Sender Rules

Allow and block lists can be applied at different levels, so you can manage exceptions and preferences without having to intervene on the global system configuration each time.

Individual users can independently authorize or block specific senders for their mailbox, while administrators can define domain-wide rules or maintain a comprehensive view of the policies active across the infrastructure.

This allows you to quickly resolve many common cases, such as recurring false positives, unwanted senders, or specific exceptions requested by the customer, without necessarily involving technical support.

The benefit isn't just operational. Centralizing these rules in a dedicated interface reduces the number of tickets, makes changes more traceable, and most importantly, avoids improvised solutions applied directly in configuration files, which are difficult to document and potentially vulnerable during subsequent updates or changes.

Password Policies

Many compromises don't start with a sophisticated vulnerability.

They start with weak, reused, or already existing passwords in compromised databases.

This is why password policies are not a cosmetic feature.

They are an integral part of the security architecture.

The requirements are verified when choosing the password and the system can automatically generate strong credentials.

Bayesian filter training

The filter does not remain frozen at initial configuration.

When a user moves a message to the spam folder, that behavior can contribute to the classifier's training.

The same thing happens in the opposite direction when a message is recovered from spam.

The system then learns from the real behavior of users.

And this is especially important because the definition of “spam” is not the same for all organizations.

What constitutes legitimate business traffic to one company may be completely irrelevant to another.

Operability: Doing things quickly without doing things badly

A good panel is not judged only by the quantity of functions available.

It is judged by how many repetitive operations it eliminates and how much it reduces the probability of human error.

M@il Admin includes tools for bulk importing mailboxes , bulk password changes , generating strong passwords, and sending summaries.

It allows you to send configuration settings for the mail client to users , manage quotas , apply exceptions for specific mailboxes and access webmail directly.

A command palette allows you to quickly reach the main functions without having to constantly navigate through menus and submenus.

System resource monitoring with historical data is also present , because the behavior of the underlying infrastructure must also be correlated with the events observed in the mail.

Added to this is an integrated knowledge base of nearly ninety articles.

Documenting a product as you develop it also produces an extremely useful side effect: it forces you to verify that what the interface promises actually matches what the code does.

And it is precisely during this process that it is possible to discover inconsistencies, limiting behaviors and defects that would otherwise remain invisible.

The comparison, in short

The real difference: managing or simply hosting

At this point the difference should be obvious.

We are not comparing two graphical interfaces.

We're not arguing whether one button is better looking than another.

We are comparing two philosophies.

The first considers mail one of the many functions included in the hosting package.

The second considers mail as an autonomous infrastructure service, with its own problems, tools, metrics, and procedures.

In the first model, the panel defines what the provider can do.

In the second model, operational needs define the tools that must be built.

It's a huge difference.

Conclusion: it's not a question of budget, it's a question of attitude and know-how.

One might argue that building such a system internally requires skills and time that an average hosting provider doesn't possess.

It's true.

But this is precisely where the difference becomes clear.

Because the problem isn't that the tools don't exist.

Postfix, Dovecot, rspamd, Redis, Solr, and the other components used are mature, well-documented, and widely used software.

The question is whether to simply install them or understand them enough to control them.

Buying a license, installing a panel, and clicking “next” three times is much easier.

It's much easier to tell the customer:

«It appears to have been delivered.»

than to actually reconstruct what happened.

It's easier to leave your web and email on the same machine until nothing happens.

It's easier to blame a problem on Gmail, Microsoft, the sender, or the remote filter when you don't have the tools to analyze it.

But the convenience of the supplier should not become the risk of the customer.

A hosting provider selling email should understand how email works.

You should be able to interpret a spam score.

It should be able to reconstruct the path of a message.

You should be able to distinguish an SMTP rejection from a reputational issue.

He should recognize a box that has been compromised by the change in his behavior.

You should be able to determine why a filter rule classified a message a certain way.

And it should be able to answer customer questions with verifiable data.

No:

«In our opinion.»

No:

"Probably."

No:

«From our side, everything seems correct.»

But:

“This happened, at this time, for this reason.”

We also believe that this capability should not remain confined to the system administrator's shell.

Useful information must be transformed into tools that are understandable and available to those who administer the service on a daily basis.

That's why M@il Admin exists.

Not because there was a lack of panels on the market.

There are dozens of panels.

In our way of working, we were missing a tool capable of answering the question that really matters when a customer writes at six in the evening:

"Where did my email go?"

If your vendor can't answer that question with a fact—a log, a score, an SMTP event, a reason, or a report—then you already have the answer to the original question.

Tell me how you handle email, and I'll tell you what kind of hosting you are.