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.
