Features
Everything below is in the product as shipped and described in the documentation inside the appliance. Items marked roadmap are planned and described on the RBL page. How these capabilities compare with other products, self-hosted and commercial, is on the comparison page.
Dashboard and mail metrics
| Panel | What you see |
|---|---|
| O/S Live Metrics | CPU %, memory %, one tile per real disk, 1-minute load, swap %, receive and transmit bits per second. Each tile carries a sparkline of the last 90 one-second samples; the page refreshes from one request per second. |
| System Information | Hostname, management address, OS, kernel, appliance version, uptime, load, CPU cores, memory, every disk with a usage bar, swap, antivirus signature version and age with an up-to-date / stale / attention badge, system time and time zone. |
| Services | Status of the 13 mail-path services, each with an in-app restart (confirm dialog, spinning icon until the real status returns, audit entry). |
| MAIL Live Metrics | Messages waiting in the queue (active / deferred / hold / incoming / maildrop on hover), established SMTP connections on 25, 465 and 587, scans per minute over the last 15 minutes, spam share, average scan time. |
| Mail Flow · Dispositions · Outcomes | Counts for 1 hour, 24 hours, 7 days, 30 days and 1 year: messages in / out / bounced; delivered, clean, greylisted, spam, blocked, deferred, bounced, SMTP-rejected; and the reasons: virus, phishing, banned attachment, Bayes spam, SPF / DKIM / DMARC failures, RBL listed, whitelisted, blacklisted, DNSBL block, greet fail, HELO reject, unknown recipient, relay denied, sender reject. |
Statistics
The scanner's cumulative counters (scanned, spam, ham, rejected, in quarantine, viruses blocked, Bayes learned), the action breakdown, and a stacked bar chart of outcomes over time rendered on the server as SVG: the last 24 hours by hour, 7 or 30 days by day, a year by week, with a totals table for the range. Hourly detail is kept for 90 days and daily totals for a year; the appliance keeps counts, not copies of your messages.
Anti-spam engine
| Area | Details |
|---|---|
| Before a message is accepted | Weighted DNSBL vote at the SMTP door (the appliance's own zone and its mirrored feeds alongside the public lists, each with its weight against one threshold), pre-greet enforcement, HELO must be a valid FQDN, sender and recipient domains must exist, relaying only for your networks. |
| Thresholds | Greylist, tag (add header) and reject at configurable scores; defaults 4 / 6 / 12. |
| Authentication | SPF, DKIM (verification, and signing for every hosted domain), DMARC policy enforcement, ARC. |
| Reputation and learning | Bayes with autolearn; sender reputation by IP, subnet, ASN and country and by SPF and DKIM domain with time decay; known-sender memory for first-contact detection with verified replies; spam traps that train Bayes from real traffic; neural post-classification; per-message scan history for "why was this handled that way". |
| Lists and lookups | IP blocklists, URL and domain blocklists, phishing feeds, short links dereferenced before URL checks, a check that the sender domain runs a reachable mail server. |
| Attachments | Banned file types, office-macro analysis of every office attachment, antivirus on every part; infected mail is rejected at SMTP time. |
| Rate limits | Six token buckets: per recipient, per recipient and sender address, per recipient / sender address / envelope sender, two for bounces, and one per authenticated user. An empty bucket soft-rejects, so mail is delayed, never lost. |
| Greylisting | Score-based greylisting with an on/off switch. |
Lists
| Page | Entry and effect |
|---|---|
| Banned IP Addresses | IP or CIDR; feeds the appliance's own blocklist zone, checked before a message is accepted. |
| Banned Domain Names, Banned Email Addresses | Envelope sender or From header: refused. |
| Banned Word List, Banned Phrases | Whole word or phrase in the text, case-insensitive: scored to the greylist threshold, once. Each page states that these are prone to false positives. |
| Character-Set Restrictions, File-Type Restrictions | Declared character sets to refuse; extensions or types to refuse. |
| Attachment Size Restrictions | Maximum message size. |
| Global Blacklist, Global Whitelist | Sender, IP or domain. Blacklisted addresses feed the local zone and banned senders are refused; a whitelisted sender is never checked against the banned lists and is never refused by spam scoring, while virus scanning still applies. |
| Country / Geo Blocking and Allow | Country codes; a match adds a score (not a blunt reject), the allow list subtracts; every unauthenticated message carries an X-MailtronX-Country header; both pages show how many messages matched over 24 hours, 7 days and 30 days. |
Every change rewrites the scanner's maps through the appliance, tests the configuration and reloads; every list page shows the live number of entries the engine enforces. The banned lists never apply to authenticated senders.
RBL management
The appliance serves its own blocklist zone (built from Banned IP Addresses and the Global Blacklist, rebuilt on change) and hourly-refreshed local mirrors of abuse.ch Feodo, PSBL, Emerging Threats compromised hosts, blocklist.de, CINS Army and the Tor exit list; Spamhaus DROP is applied in the firewall for all traffic. Public lists without a free mirror are queried through the appliance's own recursive resolver, never through a shared or open one. Per-zone weights and one threshold; hits and blocks per zone as time series with an hour-to-all-time window; Check an IP asks every zone the way the SMTP door does, plus the firewall set and your own lists. Details on the RBL page.
Mail-server policy
| Page | What it controls |
|---|---|
| Routing | Transport per domain, per subdomain tree or per recipient; the default relay host with optional SMTP AUTH credentials. Read live from the database by the mail server, effective at once. |
| Sender Relay | A relay host per sender address or per sender domain, with credentials keyed by relay or by sender. |
| Forwardings | Address to address, whole domain to one address, or same user in another domain; several destinations per rule. |
| BCC by Sender, BCC by Recipient, Archive | Hidden copies per address or per domain, plus one archive address that receives a copy of every message in either direction. |
| Submission (SMTP AUTH) | Ports 587 (STARTTLS) and 465 (TLS). Clients authenticate against their mailbox; a user may send only with their own address; relaying only when authenticated; the quota group's sending limits are enforced on every message; authenticated mail still passes the anti-spam engine. |
| Allow Relaying, HELO Restrictions, Antivirus Policy, Greylisting, Rate Limits | Networks that may relay; HELO rules; antivirus policy; greylisting switch; the live rate-limit configuration. |
| Mail Log | Live view with filter. |
Domains, mailboxes, groups
Domains with one enable/disable switch; a catch-all address per domain or an alias domain that delivers user@alias to user@target, neither ever capturing a real mailbox, group or forwarding; mailboxes with their quota group and live usage; mail groups scoped to one domain. Quota Groups give every mailbox, or every member of a mail group, a storage quota enforced by the mail store and a sending limit per hour, day and week enforced on Submission; every domain gets a Default group.
Domain SMTP Validation
One page per domain that shows the health of its public e-mail presence, one line per check with the record to fix and a status (PASS, FAIL, WARN, NOT SET, NOT CHECKED) and level (REQUIRED, RECOMMENDED, OPTIONAL): MX records and their hosts, forward-confirmed reverse DNS, SPF (one record, syntax, lookup count, final rule), DKIM (the selector this appliance signs with matches its key), DMARC (policy, coverage, report addresses), MTA-STS, TLS-RPT, DANE, DNSSEC; port 25 and STARTTLS with the certificate on every MX address; every MX address checked against the appliance's zones plus 21 public blocklists at the same time, each listing with the list's own reason and a Delist button that opens the operator's removal page. In-zone records are read from the domain's own authoritative name servers, and a Propagation column shows how many of 16 public resolvers worldwide already return the published value.
Mail Tests and Replay Corpus
| Tool | What it does |
|---|---|
| Mail Tests | Sends a well-formed test message from a mailbox on the appliance to an external deliverability tester and shows the verdict; for mail-tester.com the page offers a fresh one-time address and reads back the score and every section of the report. Every run is kept with its score. |
| Replay Corpus | Replays a real spam archive (an mbox, a Maildir, a directory, or a public corpus) through the appliance on the loopback interface, each message under its original client address and HELO name, so blocklists, reverse DNS, HELO rules, greylisting, geo scoring and every content rule judge the real source. Local-only mode keeps the public lists and the external fuzzy feed out of the run. The report shows the outcome, action and score of every message, the symbols hit most and a score histogram; the last 50 runs are kept. |
| Loopback, blacklist check, internet tests | An end-to-end e-mail loopback through the whole pipeline; whether the appliance's own address is listed on the curated set; reachability tests; live network view; system information; the scanner's own console. |
Certificates
A certificate store with common name, SANs, issuer, expiry and the services that use each entry. The installer obtains the first certificate from Let's Encrypt over HTTP-01, or installs the certificate you hand it; no self-signed certificate is installed. Afterwards: Let's Encrypt by HTTP-01 or by DNS-01 (RFC 2136 dynamic update with a TSIG key, for wildcards), import of your own certificates, a self-signed one for a lab, renewal after the number of days you set, assignment to the console, the mail server and the mail store with each configuration tested before reload. An existing ACME account can be imported, at install time or later, so the appliance issues under the account your CAA records name. Private keys never leave the appliance.
Backups
An encrypted configuration snapshot is taken automatically before every configuration change (configuration tables and the managed files, never keys or credentials). Full-appliance backups add every table, certificates and keys, the appliance settings, the scanner's state and a fresh Redis dump, for restore on this appliance or on a fresh one. Every archive is encrypted with your passphrase (AES-256, PBKDF2 600,000 rounds). Scheduled runs copy to NFS, S3-compatible object storage, SFTP, FTPS, Dropbox or Google Drive, each destination keeping its newest N; browse a destination and fetch an archive back. Nothing under the mail store is ever archived, and the network identity is left out so a restored archive never takes over the address of the original.
Patches and updates
Operating-system updates: check, dry run, run now, a weekly or daily schedule, a history of the last 100 events, optional automatic reboot when one is required, a configuration snapshot before every run. MailtronX itself updates from the signed release feed: the appliance verifies the ed25519 signature of the manifest with the release key built into it, checks the package's SHA-256, installs it next to the earlier releases and can roll back to any kept version.
Logging
Every log line forwarded by rsyslog to one receiver over TCP, TCP + TLS or UDP, with a disk-assisted queue so a receiver outage loses nothing, certificate verification against the system CAs or a private CA you paste, a connection test that reports latency and the verified certificate, and a live forwarder status. Local log rotation and audit-log retention are set on the same page.
System and network
Hostname, domain, DNS resolvers, search domains and per-interface address, prefix, gateway and MTU. Save & Apply backs up every file it touches, applies the change live and starts a 90-second countdown: click Keep to commit, or let the timer restore the previous configuration, so a wrong address never locks you out. Static routes applied at once and kept across reboots; live interfaces with throughput; date and time with the IANA time zone and authenticated NTS time sources (five NTS servers configured from the first boot) or plain NTP; SSH access; service control.
Users and access
Three roles: Admin, Ops (mail server, anti-spam, domains, quarantine, diagnostics) and Read-only; the last Admin is protected. Local accounts with argon2id password hashing, or sign-in through LDAP / Active Directory with group-to-role mappings and a bind test. API tokens with a role, an optional expiry, rotate and revoke; every call is audited under the token's name. Every change made through the console is written to an audit trail.
Built to be upgraded
Every file the mail stack reads is regenerated from the database when the console starts, after every change and as the last step of every installer run, so an upgrade never leaves a template where your configuration belongs.
Certificates, lists, routes, policies and schedules survive every patch and every installer re-run. A configuration canary ships with the appliance to prove it after each one.
Default-drop firewall with rate-limited administration access, key-only SSH, intrusion banning, kernel hardening and system auditing from the first boot. HTTPS only, signed sessions, CSRF protection, login throttling, a Content Security Policy that allows no inline scripts. The console runs without root privileges and cannot run shell commands: system changes are a fixed set of validated actions, with a snapshot before each one.
API
Every endpoint accepts the signed-in session or a bearer token: live metrics, diagnostics, network status and configuration with apply / confirm / revert, routes, time, logging, certificates and ACME, backups, patches, regeneration, who-am-i, plus an unauthenticated health check. Inputs are form-encoded, answers are JSON, and the token's role decides what it may change.