The reality of relying on third-party email providers eventually hits a wall. When pricing structures change or accounts face unexpected suspensions, finding a new home for a custom-domain email address on short notice becomes a pressing issue. For a homelab operator already self-hosting almost everything else, the logical next step is self-hosting the mailbox itself. Surely this would be simple.
It is rarely simple.
What follows is a deep dive into the realities of modern email hosting: navigating nearly every free tier on the internet, discovering a surprising number of dead ends, redefining what "privacy" actually means in the context of an email relay, and finally arriving at a clean, self-hosted architecture that works reliably. This documentation exists because many operators eventually hit this exact same wall.
The constraints that make this hard
Before evaluating the options, it's important to understand the typical constraints of this architecture:
- Custom domain outbound is non-negotiable. For professional communication and official correspondence, relying on a generic @gmail.com or @proton.me address is rarely acceptable.
- Zero budget. The goal is a truly zero-cost solution, not merely a "limited budget" compromise.
- ISP blocks port 25. This is standard residential ISP behavior. Self-hosting outbound SMTP directly to the internet is almost never an option without utilizing a relay or a VPS.
- DNS is managed exclusively through Cloudflare. This means operating without a traditional web host, cPanel, or bundled email services.
- An existing Docker-based homelab. Because a server is already running, self-hosting the mailbox itself is on the table—even if email hosting is a notoriously complex new frontier.
That final point often turns out to be the key that unlocks the entire project, though the path there is rarely obvious.
The graveyard of options that don't work
Cloudflare Email Routing + Gmail send-as
A common first instinct is to leverage Cloudflare Email Routing for inbound mail (it is free, reliable, and integrates seamlessly with domains already on Cloudflare) while pairing it with Gmail's "send mail as" feature for outbound delivery. This approach is frequently suggested in various homelab communities.
The problem: Gmail's "send mail as" feature does not actually provide an SMTP server for a custom domain. It simply allows the use of external SMTP credentials through the Gmail compose interface. An independent outbound SMTP server is still required, as Gmail will not act as the outbound sender for a custom domain on the free tier.
Zoho Mail free tier
Zoho has long been the default recommendation for free custom-domain email, historically offering one domain, five users, and 5GB of storage completely ad-free. The well-known caveat has always been the lack of IMAP support on the free tier, restricting users to webmail only.
However, there is a more significant hidden catch today: Zoho's free tier is being quietly phased out across various regions. The website no longer prominently advertises it, and new signups frequently default to a paid trial rather than the legacy forever-free plan. Even when accessible, the strict no-IMAP limitation remains a fundamental dealbreaker for anyone needing proper integration with Thunderbird, Apple Mail, or standard mobile clients.
Attempting a multi-account workaround (registering one free account per domain) also falls apart, resulting in disjointed webmail-only inboxes that cannot be consolidated into a unified client.
Proton Mail free tier + ImprovMX
Proton's free tier remains a highly reliable and permanent option. Utilizing a service like ImprovMX allows inbound mail to be forwarded from a custom domain to any inbox, and Proton Mail explicitly supports receiving these forwarded messages.
On paper, this creates a clean separation: ImprovMX handles the inbound routing, while Proton provides the secure inbox.
The critical outbound flaw: Proton's free tier does not support custom domain sending. Custom domains remain strictly gated behind paid plans. While inbound mail arrives successfully, any replies must be sent from a generic @proton.me address. For a professional communication channel, this completely defeats the purpose of having a custom domain.
Forward Email
Forward Email (forwardemail.net) frequently emerges as the most privacy-aligned option available—fully open source, with 100% of the codebase on GitHub, utilizing in-memory processing with no logging to disk, and protected by quantum-resistant encryption. It is trusted by major organizations like Canonical and The Linux Foundation.
However, outbound SMTP requires a paid plan. The free tier is strictly limited to inbound forwarding only.
Brevo (formerly Sendinblue)
Through a process of elimination, Brevo emerges as the most viable answer to the outbound problem. Offering 300 free emails per day, full DKIM/SPF support, and robust deliverability, it stands out. Furthermore, operating as a French company under strict GDPR regulations, it offers structural privacy protections that many US-based ad-supported providers lack.
While exploring alternatives, Postmark often stands out as a premium competitor: US-headquartered, strictly transactional (meaning no ad business and no incentive to analyze content), offering configurable data retention down to 7 days, and disabling link rewriting by default.
The catch with Postmark is the lack of a meaningful free tier; the allowance stops at 100 test emails before transitioning to a paid model.
This inevitably leads back to Brevo, which in turn prompts a more foundational question regarding email architecture.
What does "privacy" actually mean for an outbound email relay?
This is where the architectural evaluation becomes critically important.
Every single SMTP relay service—Brevo, Postmark, Mailgun, SendGrid, and others—has the exact same fundamental access to outbound mail. They receive the payload in plaintext, execute the delivery, and log the associated metadata. While privacy differences between these providers exist, they are often marginal. The factors that actually move the needle are:
Jurisdiction. A French company operating under GDPR versus a US company operating under the CLOUD Act. Both have legal exposure, simply to different governmental bodies.
Business model. Ad-supported providers have a structural incentive to analyze message content. Pure infrastructure providers (like Postmark or Brevo) do not.
Retention defaults. How long does the provider hold message content and metadata? This varies significantly and is often configurable.
Link rewriting. Brevo rewrites outbound links by default to facilitate click tracking. This behavior is off-by-default on Postmark, but it is fully configurable on Brevo per domain and should be turned off.
What cannot be controlled. The recipient's mail server inherently sees the content as well. If a recipient is utilizing Google Workspace or Microsoft 365—which the vast majority are—those servers act as decryption endpoints regardless of the chosen relay. End-to-end encryption is theoretically possible via PGP, but in practice, very few professional contacts utilize it.
The honest conclusion: for business correspondence that isn't handling genuinely sensitive PII, Brevo—with link tracking explicitly disabled—is perfectly fine. The true privacy win isn't found in selecting the absolute perfect relay; it is found in avoiding ad-supported providers that treat correspondence as marketable inventory.
The solution that actually works
Once the focus shifts away from attempting to solve the entire problem with third-party services and returns to leveraging existing homelab infrastructure, the architecture clicks into place.
The stack:
- Inbound: Cloudflare Email Routing → home server (Cloudflare manages the MX records, forwarding inbound traffic directly to the server)
- Mailbox + webmail: mailcow (A comprehensive Dockerized stack featuring Postfix, Dovecot, Roundcube, and rspamd)
- Outbound: mailcow Postfix → Brevo SMTP relay → internet
- External access: Cloudflare Tunnel (exposes the webmail interface securely at
mail.[yourdomain]without ever exposing the home IP address) - Mobile: IMAP connects directly to mailcow, while outbound SMTP utilizes the Brevo credentials
mailcow represents the ideal choice here because it bundles everything seamlessly—eliminating the need to stitch together six separate containers and hope they communicate properly. Roundcube webmail is built-in. rspamd aggressively handles spam filtering. Let's Encrypt automatically provisions SSL certificates. Furthermore, the admin UI allows comprehensive domain and mailbox management without ever requiring manual edits to configuration files.
The Cloudflare Tunnel is crucial for two specific reasons: it completely avoids exposing the residential home IP, and it successfully sidesteps the ISP's inbound port 25 block for accessing the webmail UI. IMAP functionality for mobile clients does require direct TCP access (typically port 993), which mandates either manual port forwarding on the router or utilizing Cloudflare's advanced TCP tunneling—a separate architectural consideration depending on the specific network setup.
DNS records that must exist:
It is highly recommended to start DMARC policies at p=none (monitoring only). After verifying two weeks of completely clean delivery logs, the policy should be escalated to p=quarantine, and finally p=reject. Skipping this cautious progression is precisely how administrators accidentally begin bouncing their own legitimate mail.
What to know when starting from scratch
The free tier landscape for custom-domain email is significantly worse than it was just two years ago. Zoho's free plan is actively disappearing. Proton's free tier has never supported custom domains. Forward Email remains the most privacy-aligned option but requires payment for outbound services. The honest reality is that zero-cost custom-domain email featuring proper outbound delivery no longer exists without compromises—administrators are either paying a monthly fee, self-hosting the infrastructure, or accepting substantial tradeoffs.
For those with existing homelab infrastructure, self-hosting is absolutely the right answer. Deploying mailcow is not overly difficult for anyone already comfortable with Docker Compose. It provides total control over all mailbox data, eliminates reliance on third parties holding the inbox, and delivers a legitimate IMAP/SMTP stack compatible with every modern mail client. The sole component that cannot be self-hosted cleanly on a standard residential connection is outbound port 25—and utilizing a relay like Brevo solves that specific hurdle for free at lower volumes.
The ISP port 25 block is the only actual hard constraint. Everything else is solvable through modern engineering. Inbound delivery can be seamlessly handled by Cloudflare Email Routing. Webmail access can be securely exposed via Cloudflare Tunnel. IMAP operates over port 993, which ISPs routinely ignore. The only strict dependency on a third party is outbound delivery, and because that is a physical network constraint rather than a software configuration problem, it must be engineered around accordingly.
Privacy in email is primarily about securing the inbox, not the relay. Self-hosting the mailbox ensures that no third party permanently holds the stored mail archives. That is the most meaningful privacy victory available. The relay service inherently sees outbound messages in transit but does not store them long-term (or stores them only briefly). Furthermore, the recipient's mail provider will store the message permanently on the other end regardless of the chosen relay path. Attempting to optimize relay privacy beyond simply avoiding "ad-supported providers" quickly hits severe diminishing returns.
The final architecture
While it may take hours of navigating dead ends to arrive at this specific configuration, the resulting stack is exceptionally clean, all primary data lives entirely on local hardware, and the only third-party dependency is a reliable outbound relay handling mail that is being sent externally anyway.
Sometimes the homelab approach is the correct answer from the very beginning—it just requires ruling out every other convenient alternative first.
Running mailcow on Docker Compose utilizing a secure Cloudflare Tunnel. Outbound routing via the Brevo free tier. DMARC currently operating at p=none — scheduled to tighten after a week of verifiable clean delivery.
Hi, I'm Justin, an IT consultant and open-source advocate. I specialize in building robust self-hosted infrastructure, developing tools and exploring AI-driven workflows. I write about deploying solutions to common issues, the occasional hardware failure, and everything I learn along the way.