Project
Self-Hosted Infrastructure & Email Deliverability
A self-managed Debian homelab — GitLab, Vaultwarden, Grafana, Docker behind a reverse proxy — plus a from-scratch web and mail stack for a dozen-plus domains. Most recently, a fleet-wide email-auth remediation that fixed outbound mail silently failing at the major providers.
I run a Debian homelab and a from-scratch web and mail stack. The work on it that taught me the most was invisible from the outside: making sure mail that says it comes from a domain actually proves it.
Context
The homelab runs the usual suite — GitLab, Vaultwarden, Grafana, and Docker workloads behind a reverse proxy — alongside a full web and mail stack I configured from scratch, serving more than a dozen domains for family and a few clients. This site is self-hosted in the same spirit.
The problem
Outbound mail from the hosted domains was quietly failing authentication at Gmail and Microsoft — landing in spam or rejected outright. “Quietly” is the dangerous part: nothing errors on the sending side, so the only symptom is mail that never arrives.
Constraints
- One mail host, many domains, a single sending IP — the fix had to be correct for the whole fleet at once.
- Live mail couldn’t break while I fixed it.
- Verifiable from outside — authentication is judged by the receiver, so a local config check couldn’t be trusted.
Approach
I audited the fleet and found three compounding faults:
- DKIM signed with a key whose public DNS records were never published — every signature failed, with nothing to verify against.
- DMARC was largely absent, so providers defaulted to suspicion.
- The sending IP had a generic PTR and no IPv6 reverse DNS — a fast way to look like spam.
Then I deployed the fix end to end: published the DKIM records, set IPv6-aware
SPF, rolled DMARC out in phases (p=none → quarantine → reject) with
aggregate reporting, corrected forward-confirmed reverse DNS for IPv4 and IPv6,
and verified it all with scripted DNS-over-HTTPS auditing against public
resolvers.
Defense as routine
Owning a mail host means securing it too, on an ongoing basis. The box runs
fail2ban and valid TLS as a baseline, and I treat the attack surface as
something to audit on a schedule — what’s listening, what’s exposed to the open
internet, what can be closed or moved behind a VPN — rather than a one-time
hardening pass. The same network-reconnaissance tooling that’s fun to learn
offensively (packet crafting, port scanning) is how I check my own box the way an
attacker would.
Outcome
Outbound mail authenticates and reaches the inbox again, and DMARC is at an enforcing policy with reporting in place. The fix held across the whole fleet, not just the domain that surfaced it.