maddy is a composable all-in-one mail server that aims to cover the core mail-server workflow with a single daemon: sending mail over SMTP as an MTA, receiving mail over SMTP as an MX, and providing mailbox access over IMAP. It tries to replace multi-component stacks such as Postfix, Dovecot, OpenDKIM, OpenSPF, and OpenDMARC, reducing maintenance complexity through unified configuration.
In terms of channels, maddy is clearly focused on email and does not cover SMS, voice, or IM. It supports SMTP, Submission, LMTP, and IMAP4rev1, and includes capabilities such as a local queue, remote MX delivery, transparent forwarding, mail-routing pipelines, and sender/recipient rewriting. On the security side, it covers DKIM, SPF, DMARC, DANE, and MTA-STS, and also supports ACME automatic certificates, DNSBL, Milter client functionality, and rspamd integration. However, the official documentation also notes that IMAP storage is still in beta; if you need stable, feature-rich IMAP, pairing it with Dovecot may still be the better choice.
The collected information does not show any commercial pricing; maddy is more like open-source, self-hosted software. The apparent software cost is low, but the real costs come from servers, domains, DNS, static IPs, reverse DNS, storage, backups, monitoring, and operations. The FAQ says that resource requirements for a small personal server are modest—around 1GiB RAM is enough—but deliverability is not determined by the software alone.
maddy provides the key technical protocols required for compliant email sending, but its FAQ clearly states that it cannot guarantee why Gmail puts messages in spam; users need to check rDNS, IP reputation, and DNSBLs. If a cloud provider blocks port 25, you must either request unblocking or relay via a smart host. As a result, it is suitable for users who understand mail infrastructure, not for those looking for a marketing email platform with “high deliverability out of the box.”
Its strengths are a lightweight architecture, few dependencies, and unified configuration. It does not require Docker, MongoDB, or Redis, making it suitable for personal mailboxes, small teams, self-hosted domain email, and mail-routing experiments. The drawbacks are also clear: the project describes itself as beta, single-process reliability involves trade-offs, there is no web admin interface, no webmail, and no built-in spam classification, so it requires CLI usage and integration with external components. For large-scale, multi-tenant, high-availability, or enterprise compliance scenarios, mature suites or hosted email services are a better fit.
The accessibility of the website and software from mainland China cannot be confirmed from the text alone, so it is marked as unknown. In real-world deployments, more important factors include domestic and overseas cloud providers’ restrictions on port 25, the reputation of overseas IPs with Gmail/Outlook, and the availability of paid cloud servers, domains, and DNS services. Alternatives to consider include MailCow, Mail-In-A-Box, or the traditional Postfix+Dovecot+Rspamd stack.
⚠ This review is compiled from public sources and does not constitute a purchase recommendation. Verify all facts on the vendor's official site. Verify on maddy.email official site.
maddy.email is an Unknown Comms & Email provider. TG4G tracks its product information, an overall rating of 8.0/10, and a China-accessibility score of China direct-connect friendly. Click "Visit Official Site" to reach maddy.email directly.