Can You Run a Mail Server From Home?

You can receive mail on a TunnelNet address. You cannot send it: we drop outbound TCP/25 at our edge, deliberately, and no address in our range has a PTR record yet — either one alone stops outbound mail working. Here is why both are true, what to use instead, and the one case where none of this matters.

The short answer, split in two

Receiving mail: yes. Nothing stops inbound TCP/25 reaching your machine. You open it the same way you open any other port, and mail addressed to your domain can be delivered to a server in your house.

Sending mail: no. Outbound TCP/25 from our address range is dropped at our edge — both IPv4 and IPv6, deliberately, and it is not something we turn off on request. Separately, no address in our range currently has a PTR record, and most large receivers reject mail from an address without one. Either of those alone is enough to stop outbound mail. Both are true today.

If sending mail from your own address is the reason you were about to buy, stop reading and do not buy. That is the honest answer and the rest of this page is the explanation.

Why we drop outbound 25

Reputation on the internet is collective and it is attached to address blocks, not to customers. We announce a single /24. If one machine in it starts sending spam, the blocklists do not learn to distrust that one address — they learn to distrust the range, and every other customer in it loses mail delivery they had nothing to do with.

That risk is not hypothetical and it is not symmetrical. A block that has never sent mail has no reputation to spend. Getting listed takes hours; getting delisted takes weeks of correspondence with people who owe you nothing, and some lists never fully forget. One compromised machine — not even a malicious customer, just a WordPress install someone forgot to update — can do that to everybody.

So the drop is a design decision rather than an oversight. We would rather refuse to sell you something than sell it and have it poison the block for the people already here. The rule logs before it drops, at a low rate, so we can see when someone hits it and tell them why rather than leaving them to debug a silent timeout.

Nothing else outbound is filtered. Ports 587 and 465 — the ones you actually use to hand mail to a provider — are open, along with everything else. The block is specifically port 25, which is server-to-server mail transfer, and which is the port spam leaves by.

The part that would stop you even if we allowed it

Mail receivers check that the address a message arrives from has a PTR record — a reverse DNS entry mapping the address back to a name — and that the name maps forward to the same address. That round trip is called forward-confirmed reverse DNS, and large receivers treat its absence as a strong spam signal. Some reject outright at connection time.

No address in our range has a PTR record today. The reverse zone for our block is delegated and answering; the records inside it have not been created yet. This is on our list and it is not done, and until it is, mail sent from one of our addresses would be rejected by a meaningful share of the internet even with port 25 wide open.

We are telling you this rather than letting you discover it after paying, because it is exactly the kind of thing that produces a refund request and a bad afternoon for both of us.

What actually works: relay through somebody who does deliverability for a living

The normal answer for self-hosted mail in 2026 is that you run the mailbox and somebody else runs the sending. Your server holds your mail, applies your rules, and hands outbound messages to a provider over port 587 with authentication. The provider owns the sending reputation, the warm-up, the feedback loops with the big receivers, and the compliance paperwork.

This is not a compromise you are making because we block a port. It is what almost everyone running their own mail does, including people on connections with no restrictions at all, because reputation is a full-time job and it does not scale down to one machine.

Concretely: configure your mail server's smarthost or relay setting to point at the provider, on port 587, with the credentials they issue. Postfix calls this relayhost. Most providers have a free tier that covers a personal domain comfortably, and the paid tiers start around the price of a coffee. Your inbound path — the part that needs a real address — is unaffected.

Receiving mail on a TunnelNet address

This part works, and it is the half a public address genuinely helps with. Inbound mail needs something a tunnel or a shared IP cannot easily give you: an address that an MX record can point at, reachable on port 25 from any sending server in the world, without a hostname in somebody else's domain in the middle.

You open the port the way you open any other:

sudo tnet ports allow tcp 25

Then point your domain's MX record at your address, and make sure your server presents a valid TLS certificate for the name it claims. From there it is an ordinary self-hosted mail setup.

Be realistic about what you are taking on. An internet-facing SMTP server is one of the most probed services there is, it will receive a constant stream of spam and dictionary attacks from the first hour, and misconfiguring it as an open relay is how a machine ends up on a blocklist within a day. If you have not run one before, this is a project, not an afternoon.

The case where none of this matters

Plenty of people who ask about mail do not actually want to run a mail server. They want one of these:

Sending notifications from a script or an application. A backup job that emails you when it fails, or an application that sends password resets. This wants a transactional mail API or an SMTP relay, not a mail server, and it works fine on any connection. You do not need a public address for it at all.

A mailbox on your own domain that you control. A hosted provider gives you this for a few dollars a month, with your domain on it, without you operating anything. This is the right answer for most people who think they want self-hosted mail, and it is worth pricing before committing to the alternative.

Everything else you were going to host. If mail was one item on a longer list — a game server, a Git remote, a media server, webhook receivers — the rest of that list is exactly what a routed public address is for, and only the mail item is affected by anything on this page.

Where TunnelNet fits

We lease you a real, globally routable IPv4 address from our own block and route it to hardware you already own, over a WireGuard tunnel that works from behind NAT or CGNAT with no port forwarding. Inbound traffic reaches your machine on whatever ports you open. That is the product, and mail is the one application where we say plainly that half of it does not work.

If that changes — if PTR records ship and we find a way to allow outbound mail that does not put the block at the mercy of its least careful customer — this page will say so. Until then, treat the sending half as unavailable rather than as something to negotiate.

If the rest of what you want to host is unaffected by that, the plans and prices are one page over, and the CGNAT guide covers the mechanics of getting traffic to a machine your ISP has put behind a shared address.