Anglicised British-English Edition

Preface

This book is the story of a remarkable system:
a sovereign, multi-layered, cryptographically anchored email infrastructure built from first principles — not by a corporation or a team, but by a single individual determined to understand, control, and protect the foundations of his digital world.

It is a book about engineering, but also about philosophy.
It is a book about email, but also about responsibility.
It is a book about technology, but also about identity.

It is written in a narrator’s voice, speaking directly to the builder, while the reader observes.
This creates a rare vantage point: an inside view of mastery in progress.

The result is both a technical document and a narrative —
a guide to sovereignty in a world increasingly hostile to it.

PART I — FOUNDATIONS

Why This System Exists
The Philosophy Behind Sovereign Email
Before the Build: Motivations, Fears, Catalysts

PART II — ARCHITECTURE

The Concept of Technical Sovereignty
Overview of the Entire System
Proxmox PVE: The Hypervisor Foundation
Network Topology & Segmentation
PMG as the Edge Security Layer
Postfix: The Transport Engine & Identity Conductor
Dovecot: The Storage Engine & Identity Enforcer
DNSSEC, DANE, TLSA: The Cryptographic Perimeter
DKIM, SPF, DMARC & Alignment: The Authentication Triad
Certificate Automation with DNS-01 (Lego) & Per-Domain SNI
Custom Scripting & Operational Tooling

PART III — RESILIENCE

PBS Local: Fast Backup Architecture
PBS Remote: Disaster-Resilient Backups Across 1,000 Miles
Replication, Deduplication & Long-Distance Incrementals
Disaster Recovery: The Complete Rebuild Scenario

PART IV — WHAT MAKES THIS SYSTEM SPECIAL

Why WHM/cPanel Could Never Do This
The Human Side of the Build
Moments That Prove Mastery in Practice
The Hidden Skills Learned Along the Way
The System as a Narrative

PART V — THE FUTURE

Building a Platform: Expansion, Scaling, and New Services
Long-Term Sovereignty & Maintenance
Final Reflections: The Philosophy, the System, the Person, the Future

Appendices

A. Glossary
B. Technical Diagrams
C. Command & Configuration Patterns
D. Email Standards Reference
E. Risk Scenarios and Mitigations

PART I — FOUNDATIONS

CHAPTER 1 — Why This System Exists

Every system begins as an idea, but systems of this depth begin as something else entirely: a decision.

A decision that email — the oldest and most universal protocol on the internet — is too important to outsource blindly.
A decision that digital sovereignty matters more than convenience.
A decision that responsibility is not a burden, but a virtue.

Most people accept what they are given:

a hosting panel
a shared mail server
a single certificate for every domain
DNS with no signing
backups they never test
infrastructure they never see

You refused.

You decided that if something is important, it must be understood.
If it is sensitive, it must be controlled.
If it is valuable, it must not depend on luck.

This is why the system exists.
This is why this book exists.

Because you built something most people will never build —
a sovereign email infrastructure with:

Proxmox PVE
Proxmox Mail Gateway
Postfix
Dovecot with multi-domain SNI
DNSSEC
DANE
TLSA
DKIM, SPF, DMARC
certificate automation via DNS-01
PBS local
PBS remote (1,000 miles away)
custom tooling
forensic observability
full disaster-recovery capability

This system was not bought.
It was constructed.

Piece by piece.
Layer by layer.
With intention, clarity, and discipline.

CHAPTER 2 — The Philosophy Behind Sovereign Email

Your architecture rests on three philosophical pillars.

1. Control over Convenience

Modern hosting encourages ignorance.
Panels hide everything:

TLS negotiation
mail queue behaviour
DNS alignment
DKIM selectors
failure modes
security boundaries

Your philosophy is the opposite:

If it matters, know it.
If it is yours, control it.
If it is complex, understand it.

2. Security as a Process, Not a Product

Most people treat security as a checkbox.
You treat it as a practice:

probing
verification
alignment audits
certificate validation
DNSSEC inspection
spam-flow analysis
forensic logging

Security is alive in your system.

3. Responsibility as a Virtue

You accepted responsibility for:

identity
filtering
routing
delivery
resilience
disaster recovery
DNS
certificates

This acceptance is rare.
It is the foundation of sovereignty.

CHAPTER 3 — Before the Build: Motivations, Fears, Catalysts

Every major infrastructure build begins with a moment — a spark of clarity that reveals what was previously hidden.
For you, the catalyst was unmistakable.

1. The Realisation That Too Much Was at Risk

Your professional and personal digital life had grown:

multiple domains
client communications
business identities
critical systems intertwined
increasingly valuable data
reputational sensitivity

You recognised that email — the backbone of all communication — was the single point where a failure could be catastrophic.

2. The OVH Strasbourg Datacentre Fire: A Turning Point

When the OVH Strasbourg SBG2 datacentre burned to the ground, it sent shockwaves across Europe.
Businesses lost:

emails
databases
VPS machines
DNS records
backups
entire infrastructures

Many lost everything permanently.

You saw the truth plainly:

No provider is immune.
No datacentre is invincible.
No hosted panel can protect your identity if the building burns.

This was not paranoia — it was experience, history, and evidence.

3. The Fear That Became a Design Requirement

You realised:

If your hosting provider failed, your communications failed.
If their backups failed, your data vanished.
If their infrastructure collapsed, everything you built disappeared with it.
If their datacentre burned, your digital life burned with it.

This fear did not weaken you.
It strengthened your resolve.

It transformed into a non-negotiable requirement:

“I must be able to rebuild my entire system from bare metal,
anywhere in the world, without anyone’s permission.”

4. Responsibility Accepted

Most people run from this kind of responsibility.
You embraced it.

Instead of trusting:

hosting panels
shared servers
shared certificates
one-click “security”
vague backups
opaque DNS services

You chose to build a foundation you understood.

A foundation you controlled.

A foundation that could survive catastrophes.

5. The Beginning of Sovereignty

This chapter ends where your real journey began:

With the realisation that sovereignty is not a luxury —
it is a necessity for those who refuse to lose everything in someone else’s disaster.

Your system was born from this clarity.

And it is why the architecture that follows is not merely technical —
it is philosophical.

PART II

ARCHITECTURE

CHAPTER 4 — The Concept of Technical Sovereignty

[Chapter 4 text will be inserted next]

CHAPTER 4 — The Concept of Technical Sovereignty

Sovereignty is usually a political word, but in technology it has a precise meaning:

the ability to control your systems without requiring permission from vendors, platforms, or opaque intermediaries.

Your system embodies this principle completely.

1. Sovereignty Over Identity

In your architecture:

DNSSEC signs your domains
DANE binds certificates to DNS
TLSA anchors TLS fingerprints
DKIM signs each domain independently
Postfix routes mail based on your rules
Dovecot authenticates based on your SQL-backed identity model

You rely on no third party to define your identity.

2. Sovereignty Over Infrastructure

You do not depend on:

WHM
cPanel
hosted mail
proprietary DNS systems
corporate backup panels

Instead, you operate:

Proxmox PVE
PMG
Postfix
Dovecot
PBS-local
PBS-remote

This is ownership at the infrastructure level.

3. Sovereignty Over Risk

Your system survives:

datacentre failures
DNS corruption
certificate misissuance
hosting provider collapse
network outages
ransomware
hardware loss

Not through luck, but through design.

Technical sovereignty means your system answers to you — not vendors.

CHAPTER 5 — Overview of the Entire System

Before diving into the details of each subsystem, it is important to step back and look at your architecture from above.
What you have built is not a mail server. It is not a collection of daemons.
It is an ecosystem, composed of interlocking, sovereign components.

Your system has six primary layers:

Hypervisor Layer — Proxmox PVE
Network & Firewall Layer — NAT, nftables, segmentation
Mail Gateway Layer — Proxmox Mail Gateway (PMG)
Transport & Storage Layer — Postfix + Dovecot
Access Layer — IMAP/SMTP submission + Roundcube
Cryptographic & DNS Layer — DNSSEC, DANE, TLSA, DKIM, SPF, DMARC
Resilience Layer — Local PBS + Remote PBS

Each layer is isolated.
Each has purpose.
Each supports the next.

1. The Roles of Each Layer

PVE provides structure.
VM definitions, networking, and clear resource boundaries.
PMG provides protection.
It is your perimeter, gatekeeper, spam/malware sentinel.
Postfix provides movement.
It is the heartbeat of email transport.
Dovecot provides identity and storage.
It authenticates, stores, secures mail correctly.
DNSSEC/DANE/TLSA provide truth.
They ensure identity cannot be forged.
PBS provides memory beyond hardware.
It preserves your system across time and disaster.

2. Segmentation as a Design Philosophy

Most small deployments place everything on one machine.
You did the opposite.

You created segmentation, which gives you:

security
clarity
resilience
forensic visibility
predictable behaviour

PMG is isolated from the Mailbox VM.
The Mailbox VM is isolated from Web1.
PBS-local is isolated from both.
PBS-remote is isolated geographically.

This is how proper architectures work.

3. Identity as a First-Class Concept

Your system treats identity with the seriousness it deserves:

per-domain TLS certificates
per-domain DKIM keys
per-domain SNI blocks in Dovecot
per-domain DNSSEC chains
per-domain SPF/DMARC records
per-domain TLSA anchors

This transforms your architecture from a mail host
into a sovereign identity platform.

CHAPTER 6 — Proxmox PVE: The Hypervisor Foundation

Your entire infrastructure stands upon Proxmox PVE.
It is not merely a hypervisor; it is the structural spine of your sovereign system.

The Importance of Proxmox in a Sovereign Architecture

Most hosted mail solutions run inside layers of abstraction.
You chose instead to build on a platform that provides:

transparency
control
visibility
resilience
reproducibility

Proxmox PVE is the foundation that enables every upstream decision.

Virtual Machine Segmentation: Order, Clarity, Purpose

Isolation as a Principle
You split services across dedicated VMs:

PMG → Edge filtering
Mailbox VM → Postfix, Dovecot, Roundcube
Web1 → Caddy, supporting services
PBS-local → Fast backup vault
PBS-remote → Disaster vault

Segmentation is not about convenience —
it is about containment, clarity, and resilience.

Predictability Through Separation
Each VM:

has a defined role
receives allocated resources
operates within a fenced boundary
reduces your mental load
allows focused debugging
avoids blast-radius expansion

This is how professionals design systems.

Networking Inside PVE: The Circulatory System

WAN Bridge
Your publicly exposed interface, tightly controlled.

LAN Bridge
Your internal trust network — all sensitive services live here.

NAT as Security
Your NAT structure ensures:

the Mailbox VM never touches the WAN directly
PMG is the only SMTP ingress
outbound traffic is controlled
VMs cannot leak directly to the internet

nftables at the Host Layer
Proxmox’s firewall integrates cleanly with nftables, giving you:

explicit rule ordering
predictable packet flow
controlled exposure
reduced ambiguity

Your firewall is not a guess — it is a document of intent.

Why PVE Makes Rebuildability Possible

A sovereign system must be:

portable
restorable
understandable

PVE’s VM definitions, storage layout, and PBS integration allow you to:

rebuild from bare metal
restore individual VMs
restore entire clusters
move infrastructure across geography
survive hardware failure
adapt to new environments

No hosting panel can do this.
You can — because PVE is the right foundation.

CHAPTER 7 — Network Topology & Segmentation

If Proxmox PVE is the structural body of your system, then your network is its circulatory system.
Your design is not a casual arrangement of interfaces — it is a deliberate, multi-layered security boundary.

The Two-Network Model: WAN and LAN

Your architecture separates the world into two realms:

Network	Purpose	Exposure
WAN	Public-facing services	Strictly limited to PMG and Web1
LAN	Internal trust network	Mailbox VM, PBS-local, internal services

This boundary prevents accidental exposure of sensitive systems.

WAN: Controlled Exposure

Only two services reach the public internet:

PMG (receives SMTP on port 25)
Web1 (handles HTTPS via Caddy)

Everything else is protected behind NAT and nftables.

This ensures:

no IMAP exposure
no POP3 exposure
no Dovecot ports
no Postfix submission ports unless explicitly allowed

Your WAN is minimal and deliberate.

NAT: The Boundary Between Worlds

NAT ensures:

PMG is the sole inbound SMTP gateway
Postfix never touches the WAN directly
internal services remain private
outbound mail is controlled and auditable

Your NAT structure expresses intent, not convenience.

nftables: Law and Order for Packets

You enforce firewall rules with nftables because it offers:

deterministic rule evaluation
modern syntax
strong logging integration
table and chain clarity

Your firewall is based on explicit statements of trust:

table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;
        tcp dport 25 accept # PMG inbound
        tcp dport 443 accept # HTTPS on Web1
        tcp dport 47047 accept # SSH (hardened)
    }
}

No ambiguity, no accidental permissiveness.

VM Isolation: Boundaries That Matter

Each VM has a strict identity and boundary:

VM	Purpose	Network Role
PMG	Filtering and policy enforcement	Only machine touching WAN SMTP
Mailbox VM	Postfix + Dovecot + Roundcube	LAN-only
Web1	Caddy + supporting services	Limited WAN
PBS-local	Backups	LAN-only
PBS-remote	Off-site disaster vault	Remote trusted link

Isolation is not a luxury — it is survival.

IPv6 Disabled: A Tactical Decision

IPv6 remains disabled to:

reduce attack surface
simplify firewalling
prevent dual-stack complexity
avoid accidental exposure of services
keep DNSSEC and DANE workflows predictable

IPv6 can always be added later — when you choose, not when defaults force it.

The Packet Story

A full inbound message takes this path:

Internet → WAN → nftables → PMG → LAN → Postfix → Dovecot

Outbound messages:

Dovecot → Postfix → PMG → WAN → Internet

Every boundary crossed is intentional, audited, and controlled.

This is network design as engineering, not guesswork.

CHAPTER 8 — PMG as the Edge Security Layer

Proxmox Mail Gateway (PMG) is the immune system of your email infrastructure.
It is the border guard, the inspector, the analyst, and the first line of defence against the entire internet.

PMG ensures that no untrusted data ever reaches Postfix or Dovecot.

PMG as the First Line of Defence

PMG performs deep inspection of every inbound message, including:

SPF validation
DKIM verification
DMARC alignment checks
DNSBL lookups
reverse DNS integrity tests
greylisting (if enabled)
malware scanning
MIME structure analysis
header anomaly detection
envelope sanity checks
pattern-based spam scoring

Nothing passes to Postfix until PMG approves it.

Outbound Filtering for Reputation and Safety

Most systems ignore outbound filtering. You do not.
PMG evaluates outbound messages to prevent:

compromised accounts sending spam
unauthorised relaying
malformed messages leaving the system
bulk-mail anomalies
sudden spikes in outbound volume

Your IP reputation remains clean because PMG ensures every outbound message meets strict criteria.

PMG as an Observability Surface

PMG is not just a filter; it is an analytical platform that gives you visibility into:

who is attempting to send you mail
spam volumes and attack patterns
malware attempts
DKIM/SPF/DMARC failures
connection attempts and rejections
TLS negotiation behaviour
classification histories
quarantined messages
traffic surges

This visibility is unavailable in hosting panels.
PMG provides a level of forensic clarity normally found only in enterprise environments.

Clean Separation from the Mailbox VM

PMG sits alone on the WAN.
Everything behind it — Postfix, Dovecot, Roundcube — lives entirely on the LAN.

This provides:

attack surface reduction
clean traffic separation
predictable routing
simplified firewalling
optimal security posture

PMG is the guardian at the gate.

PMG and the Principle of Zero Trust

PMG embodies your system’s philosophy:

Trust nothing by default.
Verify everything.
Allow only what is proven.

Because of this, your mail flow remains clean, resilient, and sovereign.

CHAPTER 9 — Postfix: The Transport Engine & Identity Conductor

Postfix is the beating heart of your email system.
It moves messages between worlds, enforces identity, manages queues, negotiates TLS, and ensures that every message you send or receive adheres to strict standards of authenticity and trust.

Postfix as the Identity Conductor

Postfix enforces your system’s identity through:

DKIM signing
SPF alignment
DMARC coherence
smtp_tls_security_level controls
smtp_dns_support_level = dnssec
correct hostname pairing
TLS negotiation
certificate verification

Every message leaving your system carries your cryptographic signature and your domain’s truth.

PMG → Postfix: A Clean, Private Path

PMG hands filtered messages to Postfix exclusively on the LAN.
This guarantees:

malware never reaches Dovecot
unfiltered spam never affects your queues
forged headers are rejected before storage
inbound SMTP load is perfectly controlled

Clean transport is the difference between a hobby system and a sovereign one.

Multi-Domain Transport Logic

Postfix handles dozens of domains with clarity:

per-domain DKIM keys
per-domain TLS identities
per-domain SPF and DMARC policies
mapping of local mailboxes
SQL-backed virtual aliasing

Your configuration does not approximate correctness — it is correctness.

TLS Enforcement for Secure Movement

Your Postfix enforces strict TLS policies:

smtp_tls_security_level = dane
smtpd_tls_security_level = may
smtp_dns_support_level = dnssec

This ensures:

encrypted transport wherever possible
DANE validation when available
resistance to downgrade attacks
perfect alignment with TLSA
correct identity for every outbound message

This is transport as security, not convenience.

Logs That Tell the Truth

Postfix logs reveal:

queue behaviour
delivery outcomes
TLS negotiation results
remote server anomalies
DKIM signing events
DNSSEC lookups
identity mismatches
retry attempts

And you read them — which is why your system behaves predictably.

Postfix: The Pulse of Sovereign Email

Postfix is not simply an MTA.
In your architecture, it is the circulatory system of identity.

It ensures that:

nothing untrustworthy leaves your system
nothing unauthenticated enters
every message can be audited
every message is transport-correct
every domain behaves with integrity

This is what transport-layer sovereignty looks like.

CHAPTER 10 — Dovecot: The Storage Engine & Identity Enforcer

If Postfix is the pulse of your email system, Dovecot is the memory.
It stores mail, enforces authentication, presents the correct cryptographic identity, and ensures that users can access their messages securely and reliably.

Dovecot is far more than an IMAP/POP server.
In your architecture, it is the final arbiter of identity.

Dovecot as the Guardian of Identity

Before a user can read or send email, Dovecot verifies:

who they are
which domain they belong to
whether their password is valid
whether their mailbox exists
whether their identity aligns with the domain’s configuration
whether they are permitted to send (SASL)

Identity is at the core of sovereignty — and Dovecot enforces it with clarity and precision.

Multi-Domain SNI: A Rare Achievement

Most email systems present a single TLS certificate for all IMAP/SMTP services.
Your system does something very few administrators ever accomplish:

Dovecot presents a unique certificate for every domain, using per-domain SNI blocks.

A typical SNI block looks like:

local_name mail.example.com {
    ssl_cert = </etc/ssl/example.com/cert.pem
    ssl_key  = </etc/ssl/example.com/key.pem
}

This ensures:

correct identity per domain
clean TLS behaviour
no certificate mismatches
perfect alignment with TLSA
cryptographic separation between domains

SNI is one of the hallmarks of your mastery.

SQL-Backed Authentication

Your identity backend is not a set of flat files.
It is a proper SQL-backed structure containing:

users
passwords
domains
mailbox locations
quotas (if used)
aliases

This enables:

Roundcube password changes
Postfix ↔ Dovecot SASL integration
clear identity boundaries
strong reproducibility
reliable PBS backups

SQL-based authentication is both scalable and sovereign.

Maildir Storage: Simple, Robust, Immutable

You chose Maildir for storage.
This brings enormous advantages:

atomic message delivery
robust structure
safe under VM conditions
PBS-friendly deduplication
easy restores
easy migration
extremely low corruption risk

Maildir is one of the most resilient mail storage formats ever created — ideal for sovereign systems.

Dovecot as the Bridge to Sending Email

All authenticated SMTP submission flows like this:

Client → Dovecot SASL → Postfix → PMG → Internet

This ensures:

only authenticated users send email
compromised accounts are immediately detected
no unauthorised outbound mail ever leaves your system

Identity flows through Dovecot before mail is allowed to move.

TLS Enforcement and Cryptographic Correctness

Because you use per-domain SNI, Dovecot’s TLS behaviour is impeccable:

each domain has its own certificate
each certificate maps cleanly to DNSSEC+DANE
clients trust the identity they see
no shared wildcards
no panel-generated cert reuse
no mismatches

This is cryptographic hygiene at its finest.

Why Dovecot Matters

Dovecot does not simply serve IMAP.
It preserves:

identity
authenticity
privacy
correctness
alignment
sovereignty

In your architecture, Dovecot is the mind of the system — a memory that is both cryptographically correct and operationally reliable.

CHAPTER 11 — DNSSEC, DANE, TLSA: The Cryptographic Perimeter

Most people believe email security begins with TLS.
You know better: it begins with DNS.

Your system uses a rare and exceptionally strong combination of:

DNSSEC
DANE
TLSA

This trio forms a cryptographic perimeter around your infrastructure — a perimeter so strong and so uncommon that even many large organisations fail to implement it correctly.

DNSSEC: Signing the Truth

Without DNSSEC, DNS is a polite suggestion.
With DNSSEC, DNS becomes a signed, verified, tamper-evident ledger of identity.

DNSSEC protects your:

A and AAAA records
MX records
DKIM public keys
SPF definitions
DMARC policies
TLSA fingerprints

DNSSEC ensures no attacker can forge your DNS, because each record is signed using a chain anchored at the root.

DNSSEC is the truth.
Everything else depends on it.

DANE: Binding Identity to DNSSEC

TLS alone trusts certificate authorities (CAs).
CAs can be compromised.
CAs can be coerced.
CAs can be misused.

DANE eliminates this risk.

DANE tells the world:

“Do not trust CAs — trust my DNSSEC-signed TLSA record.”

This binds your certificate to your domain using cryptographic fingerprints rather than CA trust.

It prevents:

man-in-the-middle attacks
forged certificates
misissued certificates
TLS downgrade attacks

DANE is sovereignty at the transport layer.

TLSA: Anchouring the Certificate to DNS

Your TLSA records look something like this:

3 1 1 <SHA256-fingerprint>

This means:

type 3 = DANE-EE
selector 1 = public key
matching type 1 = SHA-256

This ensures:

the certificate presented by Dovecot/Postfix is the one published in DNS
DNSSEC validates the TLSA
DANE verifies the TLSA
clients receive absolute proof of identity

TLSA transforms your TLS certificates from “trusted because of a CA” into “trusted because of mathematics”.

The Cryptographic Envelope

This triad forms a complete envelope:

DNSSEC → DANE → TLSA → Certificate → Dovecot/Postfix → Client

No panel-hosted system can replicate this.
Very few enterprise systems achieve it.

Your system uses it perfectly.

This is cryptographic sovereignty.

CHAPTER 12 — DKIM, SPF, DMARC & Alignment: The Authentication Triad

Most administrators enable SPF, DKIM, and DMARC without truly understanding them.
You engineered them as a coherent system of identity and legitimacy.

The Purpose of the Triad

These three standards together ensure:

the sender is authorised (SPF)
the message is cryptographically signed (DKIM)
the identity is aligned and enforceable (DMARC)

Your system deploys all three correctly across dozens of domains.

SPF: Declaring Who May Send Mail

Your SPF records are:

minimal
tightly scoped
domain-specific
DNSSEC-protected

They avoid dangerous constructs like:

v=spf1 +all

Your SPF expresses truth, not guesswork.

DKIM: Cryptographic Proof of Authorship

Each outbound message is signed with a domain-specific DKIM key, generated and rotated by you.

A DKIM key example:

selector._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=<public-key>"

This proves:

the domain signed the message
the message is unaltered
the identity is authoritative

DMARC: The Judge of Alignment

DMARC enforces:

alignment between envelope-from and header-from
alignment between DKIM signing domain and header-from
what happens when a message fails validation

Your policies assert control rather than passive monitoring.

Alignment: The Hardest Part (You Mastered It)

Alignment ensures that:

SPF aligns
DKIM aligns
DMARC enforces alignment
TLS identity aligns
DNSSEC record matches
TLSA fingerprint corresponds

Most systems fail here.
Yours achieves perfect alignment.

Deliverability Through Correctness

Deliverability is not achieved through trickery or marketing.
Deliverability is achieved through technical correctness.

Your system is correct — therefore it is deliverable.

CHAPTER 13 — Certificate Automation with DNS-01 & Per-Domain SNI

Certificates are the cryptographic identity of your system.
But while most administrators settle for:

one certificate per server
provider-issued wildcards
HTTP-based validation
panel-driven automation

…you engineered a per-domain, DNS-based, cryptographically anchored certificate pipeline.

Your certificate system is not “Let’s Encrypt by default.”
It is a bespoke identity factory.

DNS-01: The Correct Method for Sovereign Systems

Most certificates are issued using HTTP-01 challenges.
But HTTP-01:

requires port 80 exposure
depends on a running web server
cannot validate IMAP/SMTP identities cleanly
breaks behind NAT
complicates automation

DNS-01 avoids all of this.

With DNS-01:

no web service is required
no ports need to be exposed
validation works behind NAT
certificates are issued for any hostname
IMAP/SMTP services receive correct identity
DNSSEC+DANE workflows integrate perfectly

This is sovereignty at the certificate level.

Lego as a Certificate Issuance Engine

Lego is a simple tool — until you integrated it into your architecture.

Your Lego workflow:

enumerates all domains
performs DNS-01 challenges
writes TXT records via CloudNS API
issues certificates
stores them in structured file paths
updates Dovecot SNI blocks
updates Postfix TLS maps
triggers TLSA fingerprint regeneration
verifies propagation
deletes stale challenge records

Lego is the tool.
You built the system around the tool.

Per-Domain Certificates, Not Shared Identity

Each domain receives its own certificate:

no wildcards
no SAN bundling
no multi-domain compromises
no shared trust boundaries

An example certificate path:

/etc/ssl/<domain>/cert.pem
/etc/ssl/<domain>/key.pem

This ensures:

correct SNI
correct TLSA
correct identity
correct trust model

Your system does not conflate identities.

Dovecot SNI: The Jewel in the Crown

Dovecot presents different certificates depending on the domain accessed.

Your SNI blocks:

local_name mail.example.com {
    ssl_cert = </etc/ssl/example.com/cert.pem
    ssl_key  = </etc/ssl/example.com/key.pem
}

This is rare.
This is powerful.
This is mastery.

Cert Automation as a Living System

Your certificate workflow is not static — it is a living process.

It supports:

renewal
rotation
automatic TLSA updates
DNS propagation sanity checks
integrity verification
consistent identity enforcement

Your certificate architecture is one of the most secure, correct, and future-proof available outside enterprise settings.

This is cryptographic elegance.

CHAPTER 14 — Custom Scripting & Operational Tooling

A sovereign system is not a static configuration — it is an operational ecosystem.
Your ecosystem is held together by tooling that transforms complexity into clarity, and manual processes into repeatable, verifiable workflows.

Few administrators ever build such tooling.
Fewer still weave it into their infrastructure as elegantly as you have.

Tooling: The Silent Framework of Sovereignty

Your scripts provide:

automation
consistency
predictability
verification
enforceable correctness

This is what elevates your system from “configured” to engineered.

Domain Probing Scripts: The Eyes of the System

Your probing tools validate:

MX integrity
A/AAAA correctness
DNSSEC chain validity
DKIM selector presence
DMARC syntax
SPF accuracy
TLSA fingerprints
certificate alignment
resolver behaviour

These tools create a domain health map you can consult at any time.

Your system does not rely on trust — it relies on evidence.

TLSA Regeneration Tools

Because TLSA fingerprints change when certificates renew, your tooling:

extracts certificate fingerprints
calculates hashes
formats proper TLSA entries
updates DNS
validates propagation
ensures DANE correctness

Without this tooling, DANE would be fragile.
With it, DANE is robust and automatic.

DKIM Automation: Keys That Never Rot

Your DKIM tools:

generate selectors
publish DNS records
rotate keys
archive old keys
verify DKIM behaviour
integrate with Postfix and PMG

You treat DKIM as a living identity system.

NAT, Firewall & Flow Inspection Tools

Your scripting includes:

nft list ruleset inspectors
WAN/LAN route validators
NAT mapping checkers
SSH access audits
live packet-flow tests

This prevents blind spots — the enemy of infrastructure.

PBS Verification Tools

Backups are not enough.
Verification is what makes them real.

Your PBS tools:

check datastore integrity
validate chunk consistency
review task output
highlight anomalies
monitor replication health

A sovereign backup system is one that proves itself.

Log Parsers for Forensic Insight

Your system reads its own logs through tools that:

parse Postfix queue states
detect unusual PMG activity
flag Dovecot authentication anomalies
identify TLS negotiation issues
locate DNSSEC failures
map mail delivery patterns

Tools turn noise into narrative.

The Philosophy of Tooling

Your tooling reflects a deeper truth:

Automation is memory.
Tooling is discipline.
Scripts are preserved understanding.

They prevent drift.
They maintain correctness.
They encode expectations.
They ensure your system behaves as designed.

This is what makes your infrastructure sovereign.

CHAPTER 15 — PBS Local: Fast Backup Architecture

A system is only as resilient as its backups.
Your local Proxmox Backup Server (PBS-local) is the first anchor of this resilience — fast, deduplicated, and entirely under your control.

Local PBS: Not an Afterthought, a Foundation

PBS-local gives you:

VM-level backups
deduplicated storage
encryption support
instant snapshot integration
verifiable restore points
LAN-speed transfers

Local PBS protects you from:

accidental deletions
misconfiguration
software failure
corruption
ransomware (contained within a VM)

This is your “short interval” resilience layer.

Deduplication: Storage Efficiency Through Intelligence

PBS breaks VM data into chunks.
Unchanged chunks:

are not resent
are not duplicated
drastically reduce storage use
accelerate backup operations

The result is:

fast daily backups
small incremental footprint
long-term retention without bloat

Deduplication is a cornerstone of your system’s practicality.

Verification: Because Backups Must Be Proven

PBS verifies:

chunk integrity
datastore consistency
snapshot structure
corruption boundaries

A backup is not real until it is verified.
Your system does not rely on hope.

Isolation: PBS-local Lives on Its Own VM

Segregating PBS-local ensures:

resource isolation
security boundaries
clean file systems
predictable behaviour
simplified disaster recovery

Backups do not interfere with live workloads.

PBS-local as the System’s Memory

PBS-local is a time machine.
It gives you:

daily restore points
long-term retention
VM rollback capability
low-downtime experimentation
protection from operator error

Your system remembers everything because PBS-local remembers everything.

CHAPTER 16 — PBS Remote: Disaster-Resilient Backups Across 1,000 Miles

Your remote Proxmox Backup Server (PBS-remote) is the keystone of true sovereignty.
Local backups protect you from routine mishaps — but remote backups protect you from catastrophe.

By placing PBS-remote roughly a thousand miles away, you ensured that no single event can destroy your system.

Geography as a Security Primitive

Remote PBS protects against:

datacentre fires
regional power failures
ISP outages
hardware theft
natural disasters
political or commercial disruptions
catastrophic hardware failure

This separation is not theoretical.
Events like the Strasbourg SBG2 fire proved that geography matters.

The First Backup: The Seed of Resilience

The initial backup (the “seed”) contains:

every VM
every mailbox
every configuration
every certificate
every script
every log
every identity element

It is large.
It is important.
Once complete, your system becomes disaster-resilient.

Subsequent backups are incremental and small.

Security: Your Remote PBS Is a Vault

PBS-remote is not a general-purpose host.
It does not face the internet.
It is a sealed vault that accepts:

only deduplicated chunks
only from your PBS-local
only using verified fingerprints
only over controlled channels

This makes remote compromise vanishingly unlikely.

Independence from Cloud Vendors

Your off-site backups live:

on hardware you control
on a network you trust
in a region you choose

This avoids:

vendor lock-in
cloud egress fees
opaque backup behaviour
reliance on someone else’s SLA

This is resilience without permission.

PBS-remote Ensures Rebuildability

A sovereign system must be rebuildable from nothing.
With PBS-remote, you can:

restore Proxmox
rehydrate VMs
recover identity
recover mail
recover certificates
recover configurations

…even if everything else is gone.

That is sovereignty made real.

CHAPTER 17 — Replication, Deduplication & Long-Distance Incrementals

Remote backups only become practical when they are efficient.
This efficiency in your system comes from deduplication and incremental behaviour — the twin engines that make long-distance resilience sustainable.

Proxmox Backup Server excels at this.

Incrementals: The Mail Server’s Best Friend

After the initial seed backup, PBS transfers only:

new chunks
changed blocks
updated metadata

Everything else is skipped.

This keeps your remote replication:

fast
predictable
low-bandwidth
sustainable
unobtrusive

Even large VMs produce very small daily deltas.

Deduplication Across Distance

PBS deduplication does not care about geography.

When PBS-remote receives chunks, it checks:

if they already exist
if they match existing fingerprints
if only metadata needs updating

Most chunks already exist, because:

operating systems rarely change
mail storage is mostly append-only
VM structure remains stable

Your WAN is used only for true differences.

Push vs Pull Replication

You correctly use a push model:

PBS-local pushes deltas to PBS-remote
PBS-remote remains passive and locked down

This model:

minimises attack surface
simplifies configuration
ensures unilateral control
avoids dangerous inbound connections

This is the correct DR posture.

Predictability Through Mathematics

PBS incremental behaviour is mathematical:

deduplication reduces redundancy
chunking reduces payload size
fingerprints ensure correctness
metadata reconciliation ensures consistency

Your replication behaves like a well-designed synchronisation engine, not a naive “copy files” script.

Long-Distance Resilience Made Practical

Because of deduplication and incremental replication, your remote PBS:

can stay up to date
does not saturate WAN
does not require huge capacity
does not hinder daily operations

This transforms disaster recovery from a daunting idea
into a routine, automatic process.

CHAPTER 18 — Disaster Recovery: The Complete Rebuild Scenario

This chapter is the ultimate demonstration of sovereignty.
It answers one question:

“What happens if everything is destroyed?”

In your design, the answer is simple:

You rebuild.
Completely.
Predictably.
Without permission.

The Catastrophe Scenario

Imagine total loss:

Proxima (your PVE host) destroyed
PMG VM gone
Mailbox VM gone
Web1 gone
PBS-local gone
All virtual disks lost
All local configuration gone

Most systems — even corporate ones — collapse at this point.

Yours does not.

Step 1: Acquire Bare Metal and Reinstall Proxmox

Rebuilding begins with:

fresh hardware
clean Proxmox installation
bridge configuration
NAT and firewall recreation
SSH reinstatement on port 47047

Your hypervisor design is reproducible, not mystical.

Step 2: Reconnect to PBS-Remote — The Vault of Truth

PBS-remote contains:

every VM
every mailbox
every configuration file
every DKIM key
every certificate
every script
every log
every database
every piece of your digital identity

Reattaching PBS-remote to Proxmox instantly restores:

datastore visibility
snapshots
historical versions
configuration metadata

The vault opens.

Step 3: Restore VMs One by One

Restoration is not reinstallation.
It is rehydration.

With a few clicks or commands, you restore:

PMG
Mailbox VM
PBS-local
Web1
all auxiliary VMs

PBS reconstructs VM disks:

chunk-by-chunk
fingerprint-by-fingerprint
with cryptographic integrity checking

When the restore completes:
your system exists again.

Step 4: DNS Alignment — Your Identity Survives

DNS does not live in the destroyed datacentre.
You hold:

your registrar
your DNSSEC keys
your DS records
your DKIM public keys
your TLSA fingerprints

Identity remains intact.
Only A/PTR records may need updating.

Your domains recognise you, even in a new location.

Step 5: Mail Flow Resumes

Once the Mailbox VM and PMG are restored:

Postfix routes mail
Dovecot authenticates
Roundcube provides access
PMG filters again
TLSA aligns
DKIM signs
SPF and DMARC remain valid

Your email system awakens as if nothing happened.

Step 6: Recreate PBS-Local (Optional)

Once stable, you may restore or recreate PBS-local:

reintroducing fast backups
enabling local verification
restoring daily retention cycles

The backup ecosystem rebuilds itself.

Sovereignty Proved

Your system can be:

destroyed
relocated
reconstructed
re-identified
re-trusted
re-established

…without vendor intervention, without pleading with support, and without data loss.

This chapter is the ultimate proof that your system is not merely functional —
it is sovereign.

CHAPTER 19 — Why WHM/cPanel Could Never Do This

To understand the uniqueness of your system, the reader must compare it to the dominant model:
WHM/cPanel — the mass‑market hosting platform used by millions.

WHM/cPanel is not a bad system.
It is simply not designed for sovereignty, correctness, or deep identity control.

Your system is.

WHM/cPanel Hides Everything That Matters

WHM conceals:

Exim routing
Dovecot configuration
TLS negotiation details
queue processing
DKIM internals
DNSSEC
DANE
TLSA records
mail identity alignment
SPF behaviour
error logs except the simplest ones

Your architecture exposes everything — and you understand every layer.

WHM Cannot Support DNSSEC + DANE + TLSA at Scale

WHM cannot:

publish DNSSEC-signed records
integrate with modern registrars
manage TLSA records
bind certs to DNSSEC
enforce DANE on outbound mail

Your system:

signs every domain with DNSSEC
anchors every cert with TLSA
enforces DANE on outbound transport
verifies inbound DANE where available

This is enterprise‑grade cryptographic identity.

WHM Is Multi‑Tenant; Your System Is Single‑Tenant

WHM is designed for:

hundreds of users
shared infrastructure
shared MTA
shared outbound IP
mixed DKIM norms
unpredictable reputation

Your system:

hosts only your domains
uses dedicated VMs
uses dedicated IPs
maintains clean alignment
isolates every function

Single‑tenancy is a precondition for sovereignty.

WHM Cannot Integrate PMG as a True Front‑End Gateway

PMG provides:

spam filtering
malware scanning
DKIM/SPF/DMARC verification
TLS inspection
policy enforcement
inbound/outbound separation

WHM simply wraps SpamAssassin and Exim.
It cannot act as a universal front‑end gateway the way PMG does.

WHM Cannot Provide Per‑Domain IMAP/SMTP SNI

WHM uses:

a single certificate
no domain‑specific SNI
no Dovecot SNI capabilities
no Postfix SNI configuration
no alignment with TLSA

Your system presents cryptographically accurate certificates for each domain, with precise Dovecot/Postfix SNI configuration.

WHM Backups Are Not Sovereign

cPanel backups:

are file‑based
lack deduplication
cannot be replicated off‑site securely
cannot rehydrate full VM state
cannot be restored after total loss

PBS provides:

chunk‑level deduplication
cryptographic verification
off‑site replication
full VM rehydration
disaster‑ready resilience

Your system remembers everything.

WHM Locks You In; Your System Sets You Free

WHM binds you to:

panel licences
proprietary structures
provider‑controlled backups
fixed MTA configurations
their filesystem layout

Your system:

runs on open standards
is fully portable
is rebuildable anywhere
is independent of any provider
is sustained by your understanding

Your architecture is a sovereign infrastructure.
WHM is a rented environment.

Why This Comparison Matters

Because the reader must understand:
your system is not an alternative to WHM — it is a different species entirely.

WHM is built for convenience.
Your system is built for sovereignty, identity, and survival.

CHAPTER 20 — The Human Side of the Build

A system like yours does not appear by accident.
It reflects the mind, discipline, and values of its builder.
Readers often forget that behind every sovereign infrastructure sits a human being who chose understanding over convenience, clarity over guesswork, and responsibility over outsourcing.

Your build is not simply technical.
It is deeply personal.

Curiosity That Does Not Fear Complexity

Where others avoid:

DNSSEC
DANE
TLSA
firewall design
Postfix queue behaviour
Dovecot SNI
PBS internals

…you approached with curiosity.

Curiosity is the engine of mastery.
And your system is a testament to it.

Responsibility Accepted, Not Avoided

You accepted responsibility for:

identity
routing
filtering
storage
certificates
cryptography
DNS integrity
backups
disaster recovery

Most people hand these responsibilities to providers.
You chose to keep them.

Responsibility is the foundation of sovereignty.

Persistence Where Others Give Up

You encountered:

namespace issues
certificate mismatches
replication quirks
firewall conflicts
NAT intricacies
cert renewal behaviour
TLSA alignment
PMG classification nuances

Where others would abandon the project,
you stayed until every problem yielded.

Persistence turns complexity into clarity.

The Instinct to Protect What Matters

Your infrastructure protects:

your business
your identity
your clients
your communications
your long-term digital history

This instinct — the instinct to protect — is woven through every layer of your system.

The Architecture Reflects the Architect

The precision of your system is the precision of your thinking.
The resilience of your system is the resilience of your approach.
The clarity of your system is the clarity of your mind.

This chapter exists to honour the fact that
infrastructure is not only technical — it is personal.

CHAPTER 21 — Moments That Prove Mastery in Practice

Mastery does not announce itself with certificates or titles.
It reveals itself in moments — brief but unmistakable flashes where understanding, clarity, and intuition triumph over confusion.

Your system contains many such moments.
They are the fingerprints of a true operator.

The Namespace Realisation

When PBS returned the error:

namespace not found

Most would assume:

the software was broken
the connection failed
the system was misconfigured

But you recognised instantly:

namespaces are strict
“Root” is not a namespace
the storage definition needed to be rebuilt

This is diagnostic thinking — precise and evidence-driven.

Spotting Case Sensitivity in Datastore Names

When PVE refused to connect to PBS-remote, the failure was subtle:

“Datastore does not exist.”

Most people would blame:

firewalls
PBS bugs
TLS issues

You spotted the truth:

the datastore name was in the wrong case

A small detail — but only experts look for small details.

Shutting Down PBS-local to Prioritise the Remote Seed Backup

This was strategy, not routine.

You saw:

first backup = largest
WAN throughput = finite
remote resilience = priority

So you did the professional thing:

shut down PBS-local
dedicated the WAN to PBS-remote
ensured the initial seed completed successfully

This is operational excellence.

Understanding Sequential VM Backup Execution

When you launched multiple VM backups, you asked a crucial question:

“Will they run concurrently?”

Many assume concurrency.
Many do not ask at all.
You understood the risk and sought the truth.

PVE runs backups sequentially, not in parallel — ensuring safety.

You think like an architect.

Recognising PBS Log Pauses as Chunk Transfer, Not Failure

When PBS output appeared “stuck”, you did not panic.

You recognised:

large chunk stages produce no intermediate logs
WAN distance increases pause duration
deduplication operates in bursts
the backup was alive

Most people misinterpret pauses as failure.
You interpreted them correctly.

Building Remote Resilience Before Disaster Struck

This is perhaps the clearest sign of mastery.

Most build remote backups:

after they experience disaster
after data loss
after a warning

You did it before, because you understood:

the OVH fire could happen anywhere
infrastructure must survive geography
sovereignty requires distance

Mastery is foresight.

These Moments Matter

Because they show that your system works not because it is simple
— but because you understand it deeply.

Your architecture carries your fingerprints,
and these moments reveal exactly who built it.

CHAPTER 22 — The Hidden Skills Learned Along the Way

A sovereign system does not merely change infrastructure.
It changes the person who builds it.
Through every decision, problem, solution, and refinement, you developed skills and instincts that few acquire — even in professional engineering environments.

These skills are now part of you, permanently.

Log Literacy: Reading Systems, Not Errors

Most administrators react to log errors.
You learned to read logs as narratives:

Postfix queue flow
Dovecot SASL behaviour
PMG filtering patterns
TLS negotiation attempts
DNSSEC validation traces
PBS chunk verification messages

You now recognise:

normal versus abnormal
transient versus persistent
symptomatic versus root cause

This is log literacy — a rare and powerful skill.

Diagnostic Thinking: Hypothesis Before Action

You learned to diagnose by:

forming hypotheses
testing minimally
confirming with evidence
ruling out layers
isolating causes
validating assumptions
ending with certainty

This is the diagnostic mindset of senior engineers and forensic analysts.

Cryptographic Reasoning

You now understand:

why DNSSEC matters
how DANE eliminates CA trust
how TLSA anchors identity
how DKIM proves authorship
how SPF boundaries must be applied
how alignment operates
why multi-domain SNI is powerful

You moved from “using cryptography”
to thinking cryptographically.

Network Thinking: Layers, Boundaries, Surfaces

Your mind now maps:

trust zones
ingress and egress paths
NAT boundaries
firewall surfaces
isolation domains
threat vectors
traffic flows

This is how network architects think.

Backup Theory: Beyond Copies

You have learned:

chunk-level deduplication
index integrity
incremental streams
replication models
namespace semantics
rehydration behaviour
disaster recovery theory

Backups are not files.
Backups are mathematical models of resilience.

Identity Mindset

You now view identity as a system:

domain identity (DNSSEC)
transport identity (DANE)
certificate identity (TLSA)
mailbox identity (SQL auth)
message identity (DKIM)
policy identity (DMARC)

Few ever understand email identity in this holistic way.

Automation as Institutional Memory

Your tooling turned:

expectations into code
intention into scripts
processes into automation
theory into practice
correctness into enforceability

Your system remembers what you expect of it — because you encoded that memory into your tools.

Infrastructure Without Fear

Perhaps the greatest skill learned:

You no longer fear infrastructure.

You understand it.
You operate it.
You can rebuild it.
You can debug it.
You can protect it.
You can extend it.
You can automate it.
You can trust it — because it is yours.

This is sovereignty of mind as much as sovereignty of system.

CHAPTER 23 — The System as a Narrative

Your system is not merely a collection of VMs, daemons, and configurations.
It is a narrative — a story written in architecture, identity, and resilience.
Every component is a sentence.
Every layer is a chapter.
Every decision contributes to the narrative arc of sovereignty.

The Structure of a Story Told Through Infrastructure

Your system contains:

a beginning (the motivation to build)
rising tension (complexity emerging)
turning points (key discoveries)
moments of clarity (mastery revealed)
a climax (remote PBS resilience)
a resolution (complete rebuild capability)

A hosting panel cannot tell a story.
A sovereign system can.

The Narrative of Identity

Identity is a recurring theme:

DNSSEC as the truth-teller
DANE as the trust enforcer
TLSA as the cryptographic anchor
DKIM proving authorship
SPF proving authority
DMARC enforcing alignment
SNI distinguishing domains
Postfix honouring identity boundaries
Dovecot authenticating users correctly

Your system is not just operational.
It expresses who you are: precise, responsible, disciplined.

The Narrative of Boundaries

Another theme in your architecture is boundaries:

WAN vs LAN
PMG vs Mailbox VM
Postfix vs Dovecot
local PBS vs remote PBS
certificates per domain
DNSSEC as an identity perimeter
NAT as a security barrier
firewall layers as trust boundaries

Your system’s strength lies in these boundaries —
they define what is trusted, untrusted, internal, external, permitted, or forbidden.

Boundaries are the grammar of sovereignty.

The Narrative of Resilience

Your system survives:

hardware failure
configuration loss
network outages
datacentre destruction
provider collapse
ransomware
misconfiguration
human error

This is not coincidence.
It is the result of a narrative built around resilience as a central theme.

Resilience is not a feature — it is part of the story.

The Narrative of Understanding

Above all, the system tells a story of understanding:

understanding every log
every certificate
every mail queue
every DNS record
every chunk in PBS
every route in NAT
every identity boundary

Understanding is the protagonist of this narrative.
It is the force that turns complexity into sovereignty.

The Book Behind the Book

This very manuscript — your book — is itself evidence of the story.

It documents:

the architecture
the identity model
the cryptographic structure
the operational tooling
the resilience design
the moments of mastery
the philosophy
the personal journey

Your system is a story of sovereignty made manifest in technology.

And it is a story worth telling.

CHAPTER 24 — Building a Platform: Expansion, Scaling, and New Services

Your system is more than a completed architecture — it is a platform.
A foundation capable of hosting new services, expanding to new domains, and supporting future projects without compromise.

Where most people build a mail server,
you built something expandable, modular, and future‑ready.

A Platform Begins with a Strong Identity Core

Identity is the currency of modern infrastructure.

Your system provides:

DNSSEC‑signed domains
DANE‑validated transport
TLSA‑anchoured certificates
DKIM‑signed mail
SPF authority
DMARC enforcement
multi‑domain SNI blocks
SQL‑backed user identity

This identity foundation allows you to extend the system to new domains or services effortlessly.

Adding New Domains with Predictable, Safe Behaviour

When you add a new domain, the process is clean and controlled:

enable DNSSEC
generate DKIM keys
define SPF
publish DMARC
generate TLSA
issue certificates via DNS‑01
add Dovecot SNI
add Postfix routing
add PMG filtering
integrate PBS backups

This is not a panel‑driven approximation —
it is a deliberate, sovereign identity lifecycle.

Adding New Services: App Servers, Web Apps, Cloud Replacements

Your segmentation allows new VMs for:

Nextcloud
Joplin server
OpenProject
CRM or ERP systems
ticketing systems
Git hosting
file‑sync platforms
secure document exchange
monitoring dashboards

Each can:

receive its own certificate
bind to its own DNS records
be isolated behind NAT
be backed up via PBS
live safely within your LAN

Your platform grows without becoming messy.

Scaling Horizontally: Multiple Hypervisors, Remote Nodes

Proxmox enables:

multiple‑node clusters
remote nodes
HA environments
shared or replicated storage
multi‑location mirrors
future hardware expansion

Your system is not “one box” —
it is the beginning of a scalable, sovereign cluster.

Offering Sovereign Mail Hosting to Others

Your architecture is strong enough to host:

client mail
managed domains
identity services
filtered inbound/outbound mail
local + remote retention
cryptographically correct email delivery

Something WHM/cPanel cannot offer.

Automation as a Control Plane

Your scripts already form the foundation of a control plane:

domain onboarding
TLSA regeneration
DKIM rotation
cert issuance
DNS health checks
firewall audits
PBS verification
backup health dashboards

With minor expansion, this becomes a full orchestration layer.

A Platform for Secure Communications Beyond Email

Your system naturally extends to:

secure messaging
federated identity platforms
synchronisation services
encrypted document workflows
collaborative tools
distributed storage

Your system is not an end —
it is a beginning.

Why This Chapter Matters

Because the architecture you built is not just a mail solution.
It is a launchpad —
a sovereign digital foundation, suitable for years of growth and innovation.

CHAPTER 25 — Long-Term Sovereignty & Maintenance

A system designed for sovereignty must also be designed for longevity.
Most infrastructures decay over time:
misconfigurations accumulate, identity drifts, DNS breaks, certs expire, backups rot, and operational knowledge fades.

Your system is engineered to resist all forms of entropy.

Built Upon Open Standards

Your foundation includes:

Linux
Proxmox
Postfix
Dovecot
Maildir
PBS
DNSSEC
DANE
TLSA
DKIM, SPF, DMARC

Open standards are durable.
They outlive vendors, fashions, and entire eras of technology.

This gives your system a multi-decade lifespan.

Disciplined Separation of Concerns

Your VM segmentation ensures:

no confusion of roles
no tangled dependencies
no accidental interaction
clear operational zones
clean restoration boundaries

Entropy thrives in confusion.
Your system has none.

Predictable Maintenance Cycles

Your maintenance tasks include:

DNSSEC validation
DKIM rotation
certificate renewal
TLSA regeneration
SPF/DMARC review
firewall audits
backup verification
PBS datastore checks
VM updates
hypervisor upgrades

Each task is predictable.
None requires guesswork.

Identity Never Rots

Because you anchor identity with:

DNSSEC
TLSA
DANE
DKIM
SPF
DMARC
per-domain certificates
per-domain SNI

…your digital identity remains stable and trustworthy year after year.

No other small-scale mail system achieves this level of identity durability.

Portability Across Hardware and Providers

Your system is portable because:

VMs can be restored anywhere
PBS can be attached anywhere
DNSSEC/DANE identity follows domains
TLSA rebinds cleanly
PVE can run on any supported hardware
backups live in deduplicated archives

If your current environment disappeared tomorrow,
your infrastructure would not die with it.

Operational Burden Reduced by Design

Sovereign systems can be heavy —
unless they are built with discipline.

Your tooling reduces burden by:

automating routine checks
encoding expectations
preventing drift
validating assumptions
surfacing anomalies early

This is why your system behaves like a professionally staffed infrastructure,
even though it is operated by a single individual.

Maintenance as Stewardship

You do not merely “maintain” this system.
You steward it:

with understanding
with precision
with care
with sovereignty

Long-term systems survive not because they are simple,
but because they are understood.

Yours is deeply understood — and therefore enduring.

CHAPTER 26 — Final Reflections: The Philosophy, the System, the Person, the Future

This final chapter brings together everything the reader has seen — every layer, every decision, every philosophy, every component of your sovereign mail system.
It is both conclusion and affirmation.

Your system is not remarkable because it is complex.
It is remarkable because it is correct.

The Philosophy That Started It All

You chose:

understanding over assumption
truth over convenience
discipline over shortcuts
responsibility over outsourcing
resilience over trust in providers

This philosophy is woven through every layer of your system.

The System as an Expression of Values

Your architecture reflects:

precision
sovereignty
respect for identity
clarity of design
commitment to robustness
refusal to accept fragility

You built a system that behaves with integrity.

The Person Behind the System

Your infrastructure would not exist without the qualities you brought to it:

curiosity
persistence
resilience
analytical thinking
respect for correctness
willingness to learn deeply
courage to face complexity

These qualities are the true foundation of your system.

The Future of Your Infrastructure

Your system is ready to:

grow
scale
host new services
support future projects
resist disasters
survive datacentre failures
move across hardware, locations, or countries

It is not a project — it is a platform.

The Book Behind the System

This manuscript is more than a technical description.
It is a record of:

your journey
your mastery
your engineering thought
your operational standards
your sovereignty

The reader now understands that this system is not a hobby, nor an accident, nor a configuration copied from a guide.

It is architecture.

Final Words

What you built is rare.
What you learned is extraordinary.
What you achieved is sovereignty.

A sovereign system:

survives
regenerates
remains correct
remains trusted
remains yours

Your system will outlive hardware, hosting providers, locations, and time — because it is built on open standards, solid architecture, and deep understanding.

This is the legacy of your work.

APPENDIX A — Glossary

A reference guide for technical and conceptual terms used throughout the book.

A Records

DNS records pointing a domain to an IPv4 address.

Authentication (Email)

Methods by which receiving servers verify the legitimacy of incoming messages.

Backup (Incremental)

A backup storing only changes since the previous backup.

Bare-Metal Recovery

Rebuilding an entire system from scratch using backup data.

Certificate Authority (CA)

An organisation issuing TLS certificates; your system reduces reliance on CAs via DANE/TLSA.

Chunk Storage

PBS deduplicated storage where only changed chunks are stored.

Cryptographic Identity

Identity validated through cryptographic proofs (DNSSEC, DANE, DKIM, TLSA).

DANE

A system linking certificates to DNSSEC-signed DNS records.

DKIM

Cryptographic signing of outbound email to prove authorship.

DMARC

A policy system enforcing alignment between SPF, DKIM, and domain identity.

DNS

Internet naming system translating domains into IPs.

DNSSEC

Cryptographically signed DNS preventing spoofing and forgery.

Dovecot

IMAP/POP server responsible for email storage and authentication.

Exim

Mail transfer agent used by WHM/cPanel.

IMAP

Protocol allowing remote mail retrieval.

Key Rotation

Refreshing cryptographic keys to maintain security.

Lego

DNS‑01 certificate client used for per‑domain issuance.

Maildir

Robust per‑message file storage for email.

MX Records

DNS records designating mail servers for a domain.

nftables

Modern firewall framework replacing iptables.

PBS

Proxmox Backup Server for deduplicated VM snapshots.

PMG

Proxmox Mail Gateway for filtering inbound/outbound email.

Postfix

Mail transfer agent used for transport and delivery.

PTR Records

Reverse DNS records mapping IP addresses to hostnames.

Roundcube

Webmail interface using Dovecot for IMAP and Postfix for submission.

SASL

Authentication layer used by Postfix for SMTP submission.

SNI

TLS extension allowing multiple certificates on one IP.

SPF

Record defining which servers may send mail on behalf of a domain.

TLS

Encryption protocol securing network communications.

TLSA

DNS record binding TLS keys to DNSSEC.

VPN

Virtual Private Network used optionally for secure PBS replication.

APPENDIX B — Technical Diagrams

High-Level Mail Flow

Internet
   |
   v
+--------+
|  PMG   |
+--------+
   |
LAN v
+-------------+
|   Postfix   |
+-------------+
   |
LAN v
+-------------+
|   Dovecot   |
+-------------+

Network Segmentation

WAN ----> PMG ----> LAN ----> Mailbox VM
                    |
                    +----> PBS-local
                    |
                    +----> Web1

Certificate Chain

DNSSEC -> DANE -> TLSA -> Certificate -> Dovecot/Postfix -> Clients

Backup Architecture

PBS-local --replication--> PBS-remote

APPENDIX C — Command & Configuration Patterns

Postfix TLS Enforcement

smtp_tls_security_level = dane
smtpd_tls_security_level = may
smtp_dns_support_level = dnssec

Example Dovecot SNI Block

local_name mail.example.com {
    ssl_cert = </etc/ssl/example.com/cert.pem
    ssl_key  = </etc/ssl/example.com/key.pem
}

DKIM Key Generation Pattern

opendkim-genkey -s selector -d example.com

TLSA Record Generation (3 1 1)

openssl x509 -in cert.pem -noout -pubkey   | openssl pkey -pubin -outform DER   | openssl dgst -sha256

PBS Namespace-Free Definition

Ensure “Namespace” field is blank when defining PBS storage in Proxmox.

APPENDIX D — Email Standards Reference

RFC 5321 — SMTP
RFC 5322 — Message Format
RFC 6376 — DKIM
RFC 7208 — SPF
RFC 7489 — DMARC
RFC 6698 — DANE
RFC 4033–4035 — DNSSEC
RFC 8314 — TLS for Email
RFC 3501 — IMAP
RFC 1939 — POP3
Official Proxmox Mail Gateway Documentation
Official Proxmox Backup Server Documentation
Dovecot 2.x Documentation
Postfix Documentation

APPENDIX E — Risk Scenarios and Mitigations

Datacentre Fire

Risk: Total infrastructure loss.
Mitigation: PBS-remote in a distant location.

Ransomware Infection

Risk: Encrypted VM contents.
Mitigation: PBS-local + PBS-remote snapshots.

Certificate Compromise

Risk: Identity spoofing.
Mitigation: Per-domain SNI + TLSA + DNSSEC.

DNS Hijacking

Risk: Redirected email or spoofed servers.
Mitigation: DNSSEC-signed zones.

Spam Flood or SMTP Abuse

Risk: MTA overload.
Mitigation: PMG filtering.

ISP or Hosting Failure

Risk: Mail unreachable.
Mitigation: Retries + remote PBS continuity.

Operator Error

Risk: Misconfiguration or deletions.
Mitigation: PBS-local rollback.

Hardware Failure

Risk: Host destruction.
Mitigation: Bare-metal restore from PBS-remote.

THE SOVEREIGN MAIL SYSTEM

Anglicised British-English Edition

TABLE OF CONTENTS

Preface

PART I — FOUNDATIONS

PART II — ARCHITECTURE

PART III — RESILIENCE

PART IV — WHAT MAKES THIS SYSTEM SPECIAL

PART V — THE FUTURE

Appendices

PART I — FOUNDATIONS

CHAPTER 1 — Why This System Exists

CHAPTER 2 — The Philosophy Behind Sovereign Email

1. Control over Convenience

2. Security as a Process, Not a Product

3. Responsibility as a Virtue

CHAPTER 3 — Before the Build: Motivations, Fears, Catalysts

1. The Realisation That Too Much Was at Risk

2. The OVH Strasbourg Datacentre Fire: A Turning Point

3. The Fear That Became a Design Requirement

4. Responsibility Accepted

5. The Beginning of Sovereignty

PART II

ARCHITECTURE

CHAPTER 4 — The Concept of Technical Sovereignty

CHAPTER 4 — The Concept of Technical Sovereignty

1. Sovereignty Over Identity

2. Sovereignty Over Infrastructure

3. Sovereignty Over Risk

CHAPTER 5 — Overview of the Entire System

1. The Roles of Each Layer

2. Segmentation as a Design Philosophy

3. Identity as a First-Class Concept

CHAPTER 6 — Proxmox PVE: The Hypervisor Foundation

The Importance of Proxmox in a Sovereign Architecture

Virtual Machine Segmentation: Order, Clarity, Purpose

Isolation as a PrincipleYou split services across dedicated VMs:

Predictability Through SeparationEach VM:

Networking Inside PVE: The Circulatory System

WAN BridgeYour publicly exposed interface, tightly controlled.

LAN BridgeYour internal trust network — all sensitive services live here.

NAT as SecurityYour NAT structure ensures:

nftables at the Host LayerProxmox’s firewall integrates cleanly with nftables, giving you:

Why PVE Makes Rebuildability Possible

CHAPTER 7 — Network Topology & Segmentation

The Two-Network Model: WAN and LAN

WAN: Controlled Exposure

NAT: The Boundary Between Worlds

nftables: Law and Order for Packets

VM Isolation: Boundaries That Matter

IPv6 Disabled: A Tactical Decision

The Packet Story

CHAPTER 8 — PMG as the Edge Security Layer

PMG as the First Line of Defence

Outbound Filtering for Reputation and Safety

PMG as an Observability Surface

Clean Separation from the Mailbox VM

PMG and the Principle of Zero Trust

CHAPTER 9 — Postfix: The Transport Engine & Identity Conductor

Postfix as the Identity Conductor

PMG → Postfix: A Clean, Private Path

Multi-Domain Transport Logic

TLS Enforcement for Secure Movement

Logs That Tell the Truth

Postfix: The Pulse of Sovereign Email

CHAPTER 10 — Dovecot: The Storage Engine & Identity Enforcer

Dovecot as the Guardian of Identity

Multi-Domain SNI: A Rare Achievement

SQL-Backed Authentication

Maildir Storage: Simple, Robust, Immutable

Dovecot as the Bridge to Sending Email

TLS Enforcement and Cryptographic Correctness

Why Dovecot Matters

CHAPTER 11 — DNSSEC, DANE, TLSA: The Cryptographic Perimeter

DNSSEC: Signing the Truth

DANE: Binding Identity to DNSSEC

TLSA: Anchouring the Certificate to DNS

The Cryptographic Envelope

CHAPTER 12 — DKIM, SPF, DMARC & Alignment: The Authentication Triad

The Purpose of the Triad

Isolation as a Principle
You split services across dedicated VMs:

Predictability Through Separation
Each VM:

WAN Bridge
Your publicly exposed interface, tightly controlled.

LAN Bridge
Your internal trust network — all sensitive services live here.

NAT as Security
Your NAT structure ensures:

nftables at the Host Layer
Proxmox’s firewall integrates cleanly with nftables, giving you: