Thanks to Eric, Henrik, Panagiotis, Sylvain, Crystal,
Craig and Andy (sorry if I missed anyone)
Some very detailed information, and I am very grateful.
Appreciate the time spent.
The PF forwarding, dealing with spam etc were super insights.
I'm inspired to give it a go. :)
Much obliged folks.
On 18.09.2026 08:57, Henrik Krysteli Semark wrote:
I've been running MTAs for many years, and maintaining deliverability
is definitely not a set-and-forget operation.
For sending, you will need:
Authentication: SPF, DKIM, and DMARC at a minimum. MTA-STS is also
highly advised.
The DKIM "Gotcha": Stick to RSA (specifically RSA-2048) for your DKIM
keys. While dual-signing with Ed25519/ECDSA is a cool IT flex and
RFC-compliant (evaluators are supposed to pass the mail if at least
one signature is valid), in the real world, Microsoft will actively
fail your emails if its parser chokes on the elliptic curve signature,
ignoring your valid RSA key entirely.
The DMARC p=reject Reality: Even when you successfully reach a DMARC
policy of p=reject, be aware that Microsoft Office 365 ignores the
strict RFC definition for inbound mail. By default, they treat reject
exactly the same as quarantine, silently delivering spoofed mail to
the recipient's Junk folder instead of dropping it at the gate.
DNS Alignment: Your server must have the exact same HELO name as the
reverse-DNS for your IP. If you are dual-stacked, this needs to be
perfectly aligned for both IPv4 and IPv6 (forward and reverse). DNSSEC
for your domain is also recommended.
Monitoring: A deliverability reporting system (usually via DMARC
records) so you have a fighting chance of figuring out why something
gets blocked. I personally use Report URI for this since looking
through XML manually is tedious - and I have not looked into something
self-hosted.
Reputation: Be aware that major mailers often penalize low-volume
senders. Strict SPF alignment for the actual sending host is starting
to be expected, even if the big providers aren't strictly enforcing it
yet. The deliverability nightmare goes on and on.
For receiving and filtering:
Initial Gates: A good starting point is configuring postscreen with
DNSBLs (like Spamhaus, SpamCop, or Barracuda), utilizing greylisting,
and rejecting senders without correct DNS or TLS. (Keep in mind you
can't strictly require TLS 1.2/1.3 yet, as many senders still have
older capabilities).
The Spamhaus Gotcha: If you use Spamhaus as your DNSBL, do not query
it using public open resolvers like Cloudflare (1.1.1.1) or Google
(8.8.8.8). Spamhaus actively blocks queries from public resolvers and
will return an error code (127.255.255.254) instead of a valid result.
Depending on your MTA configuration, failing to parse this error code
correctly can cause your system to blindly treat all incoming mail as
spam, or conversely, let everything through. To use Spamhaus properly,
you must either query via a local, non-public DNS resolver or register
for their free Data Query Service (DQS) key. I've placed an Unbound
DNS with root-server resolving on the MTA server to use for this exact
reason.
Anti-Spam & AV: After the initial gates, pass the mail to a more
resource-intensive scanner. I switched to Rspamd after using
SpamAssassin for many years and have reduced incoming spam
significantly, despite being quite strict before.
Relaying: If you plan to relay through multiple hosts (like your VPS
tunnel), you should definitely look into ARC.
The VPS Privacy Question:
To answer your specific question about the VPS "seeing" your email: it
depends on how you route it. If you run OpenSMTPD on the VPS as a
relay, it terminates the TLS connection and absolutely "sees" the
unencrypted mail before passing it down the WireGuard tunnel. If
privacy is the goal, do what Sean suggested: use pf (or iptables) on
the VPS to simply forward TCP port 25 directly over the tunnel to your
home MTA. Your home server handles the TLS termination, and the VPS
only sees encrypted packets.
One final warning on the VPS: Check the IP reputation before you build
anything. Many cheap VPS IP ranges are heavily penalized or outright
blocked by major mailers because of spammers. You might end up
inheriting a worse reputation than your home IP.
Good luck! It's a fascinating journey to embark on, and it touches a
lot of different aspects of networking and security.
---
_Med venlig hilsen / Mit freundlichen Grüßen / Best Regards_
_ Henrik Krysteli Semark_
On 2026-09-18 07:31, Craig Skinner wrote:
Hello,
On Fri, 18 Sep 2026 00:05:57 drango wrote:
I am considering running my own email domain/server.
To protect my private home IP, I was thinking of using a VPS,
tunnelled back.
Will the VPS "see" my email this way, relaying off the VPS server to
my local server?
(see diagram)
Is there a better approach to retain privacy without revealing my IP?
Would appreciate any input on this, as I have never run email myself
before.
Thanks for any suggestions
DNS Domain VPS Host (static IP)
┌─────────┐ ┌──────────┐
│MX Record┼────►│OpenSMTPD │
└─────────┘ └────┬─────┘
│
│ Wireguard tunnel
▼
┌──────────┐
│pf.conf │ (allow mail in)
│OpenSMTPD │
└──────────┘
No need for the wireguard tunnel.
The VPS host is primary MX, so host dovecot there.
Your devices can collect mail from anywhere in the world via IMAPS
(SSL encrypted Internet Mail Access Protocol).
Your laptop Claws-mail, Thunderbird, mobile phone Android gMail app,
iOS MacMail app all connect to your VPS mail server via IMAP.
Job done.
Another way to do it is to have the VPS server as backup MX, your home
server on a _static_ IP address as primary MX with port 25 only open
to your VPS.
(If your ISP actually supplies static IPv4 addresses & permits port 25
traffic to & from customers.... If you can't get a static IPv4 address
at home with port 25 access both ways, forget it.)
Other mail servers try to send to your primary MX machine at your home
*static* IP address but the port is closed, so they fall back to
sending mail to the backup MX machine at your VPS host.
The VPS host spools the incoming mail & relays it to the primary MX
machine, where you host dovecot for your IMAP laptop & mobile device
clients anyway....
By the way:- running email servers is much more difficult & fiddly
than running web or SQL/LDAP database servers. Email has many hidden
worms & dragons to tame & overcome. rDNS, DKIM, SPF, ARC, DNSRBLs,
IMAP/POP, sieve, spamd(1), etc, etc, etc.
There's about 6 pernickety protocols to deal with in harmony, which
fight against each other.
Cheers,
Craig.
