Warum ein vorgeschaltetes Gateway sinnvoll sein kann

Defense in depth: Zwei unabhängige Systeme müssen versagen, bevor eine schädliche Mail ein Postfach erreicht. Eine Schwachstelle in einem Produkt reicht allein nicht aus.
Zweite Antispam- und Antivirus-Engine: Proxmox Mail Gateway arbeitet mit eigenen Regeln, Bayes-Filter, SPF, DNSBL und ClamAV. Was der eine Filter übersieht, erkennt der andere oft.
Quarantäne: Verdächtige Mails werden im Gateway zurückgehalten und können von Administratoren oder Benutzern über den Spam-Report geprüft und freigegeben werden.
Entkopplung vom Internet: Nur das Gateway nimmt Verbindungen aus dem Internet auf Port 25 an. nextxch steht dahinter, Port 25 ist nur für das Gateway offen.
Pufferung bei Wartung: Ist nextxch wegen eines Updates oder einer Wartung kurz nicht erreichbar, hält das Gateway eingehende Mails in seiner Warteschlange und stellt sie danach zu.

Ehrlich eingeordnet: nextxch bringt eigenen Spamschutz mit (SpamGuard mit adaptivem Filter, SPF/DKIM/DMARC/ARC, Greylisting, DNSBL, Phishing-Heuristiken) und bindet ClamAV an. Für die meisten Installationen reicht das. Ein vorgeschaltetes Gateway ist optional und lohnt sich bei höheren Anforderungen: Vorgaben zu mehrstufiger Filterung, zentrale Quarantäne, mehrere Mailserver hinter einem MX oder eine strikte Netztrennung.

Architektur: Internet -> Proxmox Mail Gateway -> nextxch

Der MX-Eintrag zeigt auf das Gateway. Es nimmt Mails auf Port 25 an, filtert sie und leitet sie per SMTP an nextxch weiter. Optional sendet nextxch ausgehende Mails über den internen Port 26 des Gateways.

Durchgezogen: eingehender Weg (Pflicht). Gestrichelt: ausgehender Weg über das Gateway als Smart-Host (optional). Ohne Smart-Host stellt nextxch ausgehende Mails weiter direkt per DNS-MX zu.

Proxmox® ist eine eingetragene Marke der Proxmox Server Solutions GmbH. Der Name wird nur beschreibend verwendet; nextxch steht in keiner Verbindung zur Proxmox Server Solutions GmbH und wird von ihr weder unterstützt noch zertifiziert.

Einrichtung im Überblick

Die Reihenfolge ist so gewählt, dass kein Mailverlust entsteht: Erst das Gateway vollständig einrichten und testen, dann den MX-Eintrag umstellen, zuletzt Port 25 auf nextxch schließen.

Referenz / Konfiguration

1. Proxmox Mail Gateway installieren (ISO, auf Debian oder als LXC-Container)
2. Relay-Domains eintragen (alle Domains, die nextxch annimmt)
3. Default Relay = nextxch-Host, Port 25 (Mail Proxy -> Relaying)
4. Empfängerprüfung, TLS und Zertifikat im Gateway aktivieren
5. nextxch: Gateway-IP als vertrauenswürdiges Gateway eintragen (SpamGuard)
6. Testmail über das Gateway schicken, Message Trace in nextxch prüfen
7. MX-Eintrag auf das Gateway umstellen (alten MX erst nach TTL-Ablauf entfernen)
8. Firewall: Port 25 auf nextxch nur noch vom Gateway erlauben
9. Optional ausgehend: Gateway als Smart-Host in nextxch (Port 26, STARTTLS)

Beispielwerte auf dieser Seite:
  Gateway:  pmg.firma.de   203.0.113.25   (öffentlich, MX)
  nextxch:  mail.firma.de  10.0.0.20      (intern, Postfächer)

1. Proxmox Mail Gateway installieren

Proxmox Mail Gateway läuft als eigenständige Appliance (ISO-Installer auf Hardware oder als VM), als Paket auf einem bestehenden Debian-System oder als LXC-Container. Wer Proxmox VE nutzt, findet eine fertige Container-Vorlage im Appliance-Manager. Danach erfolgt die Verwaltung über die Weboberfläche auf Port 8006.

Referenz / Konfiguration

Variante A: ISO-Installer (Hardware oder VM)
  ISO von proxmox.com/downloads laden -> booten -> Installer durchlaufen
  Hostname:  pmg.firma.de   (FQDN, passend zum späteren MX und PTR)
  IP:        feste IP, z. B. 203.0.113.25 oder DMZ-Adresse hinter NAT

Variante B: auf bestehendem Debian
  Paketquelle von Proxmox einrichten und Pakete laut
  "Install Proxmox Mail Gateway on Debian" im PMG-Admin-Guide installieren

Variante C: LXC-Container in Proxmox VE
  Proxmox VE -> Storage -> CT Templates -> Templates -> Abschnitt "mail"
  -> Proxmox Mail Gateway Vorlage laden -> Container anlegen

Weboberfläche:  https://pmg.firma.de:8006   (Port 8006 nur aus dem Admin-Netz)

Paketquellen: Ohne Subscription die Quelle "pmg-no-subscription" eintragen.
Proxmox empfiehlt für den Produktivbetrieb die Enterprise-Quelle (mit Subscription).

2. Relay-Domains, Default Relay und Empfängerprüfung im Gateway

Alle Einstellungen liegen in der PMG-Weboberfläche unter Configuration -> Mail Proxy. Das Gateway nimmt nur Mails für eingetragene Relay-Domains an und reicht sie nach der Filterung an das Default Relay weiter.

Referenz / Konfiguration

Configuration -> Mail Proxy -> Relay Domains
  firma.de
  firma-gruppe.de          (jede in nextxch angelegte Domain, auch Alias-Domains)

Configuration -> Mail Proxy -> Relaying
  Default Relay:      mail.firma.de     (oder 10.0.0.20)
  Relay Port:         25
  Relay Protocol:     SMTP
  Disable MX lookup:  ja                (nextxch-Host direkt ansprechen)

Configuration -> Mail Proxy -> Ports
  External SMTP Port: 25   (aus dem Internet, nicht vertrauenswürdig)
  Internal SMTP Port: 26   (von nextxch, vertrauenswürdig, für ausgehende Mails)

Configuration -> Mail Proxy -> Options
  Verify Receivers:   550   (unbekannte Empfänger sofort ablehnen)
  SPF:                ja
  DNSBL Sites:        z. B. zen.spamhaus.org   (Nutzungsbedingungen der Liste beachten)

Mehrere interne Server: Configuration -> Mail Proxy -> Transports
(Domain oder einzelne Adresse -> eigener Zielserver)

3. MX-Eintrag auf das Gateway umstellen

Erst umstellen, wenn eine Testmail über das Gateway in nextxch angekommen ist (Message Trace in /admin/). Die TTL des MX-Eintrags vorher auf wenige Minuten senken. Den Eintrag für nextxch selbst (A/AAAA, PTR, Autodiscover) nicht ändern: Clients verbinden sich weiter direkt mit nextxch.

Referenz / Konfiguration

; Gateway
pmg.firma.de.      3600  IN  A     203.0.113.25
; PTR für 203.0.113.25 beim Provider: pmg.firma.de

; MX zeigt nur noch auf das Gateway
firma.de.          3600  IN  MX 10 pmg.firma.de.

; nextxch bleibt für Clients erreichbar (IMAP, SMTP-Submission, Webmail)
mail.firma.de.     3600  IN  A     198.51.100.20

Test vorher, ohne DNS-Änderung:
  swaks --to anna.weber@firma.de --server pmg.firma.de --port 25 --tls

4. Optional ausgehend: Gateway als Smart-Host in nextxch

Ausgehende Mails laufen dann ebenfalls durch die Filter des Gateways (z. B. Virenprüfung, Statistik). Im Admin-Cockpit unter SMTP, Queue-Steuerung & Live-MX-Tester (#pSmtpQueue) tragen Sie das Gateway als globalen Smart-Host ein, oder Sie leiten mit SMTP-Routen nur bestimmte Absender über das Gateway. Wichtig: Die öffentliche IP des Gateways muss dann im SPF-Eintrag Ihrer Domains stehen, und ihr PTR muss zum HELO-Namen des Gateways passen.

Referenz / Konfiguration

# A) Globaler Smart-Host: alle ausgehenden Mails über das Gateway
nextxch-cli update SmtpQueue --set outboundSmartHost=pmg.firma.de \
  --set outboundSmartPort=26 --set outboundSmartHostTlsMode=StartTlsRequired

# B) Ausnahme: eine Partner-Domain weiter direkt per DNS-MX (Route ohne Ziel-Host)
nextxch-cli create Route --set domain=partner.de --set bypassSmartHost=true \
  --set description="direkt per MX, nicht über das Gateway"

# C) Nur bestimmte Absender über das Gateway (#pSmtpQueue -> Domain-Routen)
#    Ziel-Domain:          *
#    Nur für Absender:     firma.de, *.firma.de      (SenderDomains)
#    Ziel-Host:            pmg.firma.de:26           (mehrere mit Komma = Failover)
#    TLS-Modus:            StartTlsRequired
#    Priorität:            50                        (kleiner = zuerst; Standard 100)

# SPF der Absender-Domain um die Gateway-IP ergänzen:
firma.de.  IN  TXT  "v=spf1 mx ip4:203.0.113.25 -all"

# Im Gateway: nextxch-IP unter Configuration -> Mail Proxy -> Networks eintragen,
# falls nextxch nicht im selben Subnetz wie das Gateway liegt.

5. Gateway-IP in nextxch als vertrauenswürdig eintragen

Ein Mail-Gateway nimmt die Mail selbst an und liefert sie neu ein. Für nextxch ist die einliefernde IP dann immer die Gateway-IP. Damit SPF, DMARC, Greylisting, DNSBL und die Reverse-DNS-Prüfung trotzdem den echten Absender bewerten, tragen Sie das Gateway unter SpamGuard & ClamAV (#pSpam) bei "Vertrauenswürdige Gateways" ein. nextxch liest bei Verbindungen von diesen IPs die Absender-IP aus dem Received-Header, den das Gateway geschrieben hat. Header werden nur bei Verbindungen von eingetragenen IPs ausgewertet, ein direkt einliefernder Absender kann seine IP so nicht fälschen. Die TrustedProxyCidrs (Cluster:EnableProxyProtocol) sind etwas anderes: Sie gelten nur für TCP-Proxys wie HAProxy mit PROXY-Protokoll.

Referenz / Konfiguration

# nextxch: Gateway als vertrauenswürdig eintragen (öffentliche und interne IP, CIDR erlaubt)
# (Admin-Cockpit: SpamGuard & ClamAV (#pSpam) -> "Vertrauenswürdige Gateways")
nextxch-cli update SpamGuard --set trustedRelayCidrs=203.0.113.25,10.0.0.25

# Prüfen: Testmail über das Gateway, dann im Spam-Analyzer bzw. Message Trace
#   TRUSTED_RELAY  Über Gateway 10.0.0.25, Absender-IP 198.51.100.7 aus Received-Header
#   SPF_PASS       (SPF jetzt gegen 198.51.100.7)

# Bleibt in nextxch aktiv:
#   SPF/DKIM/DMARC/ARC, Greylisting, DNSBL, adaptiver Inhaltsfilter,
#   Phishing-Heuristiken, Allow-/Blocklisten, ClamAV (falls aktiv)

# Verbindungslimit: alle eingehenden Mails kommen von einer IP.
# MaxConnectionsPerIp (#pSmtpQueue, Standard 48) bei hohem Volumen prüfen.

6. Firewall und TLS auf beiden Strecken

Port 25 auf nextxch schließen Sie in der Host- oder Perimeter-Firewall (Windows-Firewall, nftables, pfSense/OPNsense). Die IP-Regeln von nextxch eignen sich dafür nicht, weil sie für alle SMTP-Ports gemeinsam gelten und damit auch 465 und 587 der Clients träfen. Beide Strecken verschlüsseln: Internet <-> Gateway und Gateway <-> nextxch.

Referenz / Konfiguration

Firewall nextxch (eingehend)
  TCP 25         nur von 203.0.113.25 / 10.0.0.25 (Gateway)
  TCP 465, 587   Clients (SMTP-Submission)  -> unverändert offen
  TCP 993, 443   Clients (IMAP, Webmail, DAV, Push) -> unverändert offen

Firewall Gateway (eingehend)
  TCP 25         aus dem Internet
  TCP 26         nur von nextxch (Smart-Host, falls genutzt)
  TCP 8006       nur aus dem Admin-Netz

TLS Internet <-> Gateway
  Configuration -> Mail Proxy -> TLS: "Enable TLS" an
  Zertifikat: Certificates -> ACME (Let's Encrypt) für pmg.firma.de

TLS Gateway -> nextxch
  nextxch bietet STARTTLS auf Port 25 mit dem Zertifikat von mail.firma.de an
  Gateway: TLS Destination Policy für mail.firma.de = encrypt
           (oder verify, wenn der Default Relay als Hostname eingetragen ist)

TLS nextxch -> Gateway (Smart-Host)
  outboundSmartHostTlsMode = StartTlsRequired

7. DKIM/DMARC, Greylisting und Rückstreuung

Drei Punkte, die in der Praxis oft übersehen werden. Das Gateway darf ausgehende Mails nicht verändern, Greylisting sollte nur an einer Stelle laufen, und unbekannte Empfänger müssen schon im SMTP-Dialog abgelehnt werden.

Referenz / Konfiguration

DKIM / DMARC
  - nextxch signiert ausgehende Mails mit DKIM. Das Gateway leitet sie unverändert weiter.
  - Im Gateway keine Disclaimer-Regel für ausgehende Mails und keine Inhaltsänderung
    (sonst ist die DKIM-Signatur gebrochen und DMARC schlägt beim Empfänger fehl).
  - DKIM Signing im Gateway aus lassen; Disclaimer bei Bedarf in nextxch pflegen.

Greylisting
  - Bremst Spam-Bots, verzögert aber erste Mails neuer Absender (laut PMG-Doku meist < 30 Minuten).
  - Nur im Gateway betreiben; in nextxch wäre es hinter dem Gateway wirkungslos.
  - Für zeitkritische Absender (z. B. Login-Codes, Bestellbestätigungen) die Welcomelist nutzen
    oder Greylisting ganz auslassen, wenn die übrigen Filter genügen.

Rückstreuung (Backscatter) vermeiden
  - Verify Receivers = 550: Das Gateway fragt nextxch per RCPT TO, ob die Adresse existiert.
  - nextxch lehnt unbekannte Empfänger schon bei RCPT TO ab, die Prüfung greift also sofort.
  - Catch-all-Adressen in nextxch hebeln die Prüfung aus und sollten vermieden werden.

8. Lizenz und Kosten (Stand 01.11.2026)

Proxmox Mail Gateway ist Open Source unter der GNU AGPLv3 und ohne Subscription voll nutzbar; Updates gibt es dann über die Quelle pmg-no-subscription, die Proxmox für Test- und Nicht-Produktivsysteme vorsieht. Eine Subscription gilt je Host und Jahr, schließt laut Proxmox unbegrenzt viele Benutzer und Domains ein und gibt Zugang zur Enterprise-Paketquelle. Die Preise unten stammen von der Preisseite von Proxmox und können sich ändern; maßgeblich ist immer proxmox.com. nextxch verkauft keine Proxmox-Subscriptions.

Referenz / Konfiguration

Lizenz:   GNU Affero General Public License v3 (AGPLv3), seit PMG 5.0

Optionale Subscriptions je Host und Jahr (netto, laut proxmox.com, Stand 01.11.2026):
  Community    190 EUR    kein Ticket-Support (Forum)
  Basic        540 EUR    5 Tickets/Jahr, Reaktion 1 Arbeitstag
  Standard   1.260 EUR    15 Tickets/Jahr, Reaktion 4 Stunden
  Premium    1.900 EUR    unbegrenzt Tickets, Reaktion 2 Stunden
  (Reaktion = erste Antwort auf kritische Anfragen innerhalb der Geschäftszeiten)

Quellen:
  https://www.proxmox.com/en/products/proxmox-mail-gateway/pricing
  https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html   (Admin-Guide 9.1.1: Lizenz, Paketquellen, Ports)

Einstellungen, Standardwerte & Best Practices

Einstellung / Ort	Funktion	Standardwert	Best Practice im Betrieb
`PMG: Relay Domains (Mail Proxy)`	Liste der Domains, für die das Gateway Mails annimmt und weiterleitet. Mails an andere Domains lehnt es ab.	`leer`	Alle Domains eintragen, die in nextxch angelegt sind, auch Alias-Domains. Bei neuen Domains in nextxch die Liste im Gateway mitpflegen.
`PMG: Default Relay + Port (Mail Proxy -> Relaying)`	Ziel für eingehende Mails nach der Filterung (Postfix-Transport). Weitere interne Server pro Domain über Transports.	`Port 25 · SMTP`	mail.firma.de bzw. 10.0.0.20, Port 25, Protokoll SMTP. "Disable MX lookup" aktivieren, wenn ein Hostname eingetragen ist, der selbst einen MX besitzt.
`PMG: Verify Receivers (Mail Proxy -> Options)`	Empfängerprüfung: Das Gateway fragt nextxch vor der Annahme per RCPT TO, ob die Adresse existiert, und lehnt unbekannte Empfänger noch im SMTP-Dialog ab.	`aus`	Auf 550 stellen. Verhindert Rückstreuung (Backscatter), weil das Gateway keine Mails an Phantasie-Adressen annimmt, die es später zurückschicken müsste.
`PMG: TLS + Zertifikat`	STARTTLS für eingehende und ausgehende Verbindungen des Gateways. Ohne eigenes Zertifikat erzeugt PMG ein selbstsigniertes.	`TLS aus`	TLS einschalten, ein vertrauenswürdiges Zertifikat per ACME (Let's Encrypt) für pmg.firma.de beziehen und für den nextxch-Host eine TLS-Richtlinie "encrypt" setzen.
`PMG: Disclaimer & DKIM-Signatur`	Regel-Aktion Disclaimer hängt Text an den Mailtext an; DKIM Signing signiert Mails, die über den internen Port kommen.	`aus`	Beides aus lassen. nextxch signiert mit DKIM; jede Änderung am Inhalt im Gateway bricht die Signatur und damit DMARC. Disclaimer nur in nextxch pflegen (wird vor der Signatur eingefügt).
`nextxch: Smart-Host (#pSmtpQueue · outboundSmartHost)`	Globaler Smart-Host: Alle ausgehenden Mails gehen an dieses Relay statt direkt an den Empfänger-MX.	`leer (direkt per MX) · Port 25`	pmg.firma.de, Relay-Port 26 (interner Port des Gateways), TLS-Modus StartTlsRequired, ohne SMTP-AUTH. Im Gateway muss die nextxch-IP unter Networks stehen (gleiches Subnetz ist automatisch erlaubt).
`nextxch: Route · SenderDomains`	Absenderbedingung einer SMTP-Route: Domains (firma.de, .firma.de) oder Adressen (billing@firma.de, @firma.de). Leer = jeder Absender.	`leer`	Nur bestimmte Mandanten über das Gateway senden: Route mit Ziel-Domain * und SenderDomains = firma.de, Ziel-Host pmg.firma.de:26.
`nextxch: Route · Priority`	Reihenfolge unter Routen gleichen Rangs; die kleinere Zahl gewinnt, danach das spezifischere Muster.	`100`	Rang geht vor Priorität: Absender + Ziel-Domain, dann Ziel-Domain, dann nur Absender (Ziel ), dann , dann globaler Smart-Host, dann DNS-MX.
`nextxch: Route · BypassSmartHost`	Nur für Routen ohne Ziel-Host: Mails an diese Domain gehen direkt per DNS-MX, auch wenn ein globaler Smart-Host gesetzt ist.	`false`	Für einzelne Partner-Domains, die nicht über das Gateway laufen sollen. Hat die Route einen Ziel-Host, wird der Schalter ignoriert.
`nextxch: Vertrauenswürdige Gateways (#pSpam · trustedRelayCidrs)`	IPs oder CIDR-Netze vorgeschalteter Gateways. Kommt eine Verbindung von dort, nimmt nextxch die Absender-IP und den HELO aus dem obersten Received-Header, der nicht von einem eingetragenen Gateway oder von localhost stammt.	`leer`	Öffentliche und interne Gateway-IP eintragen, z. B. 203.0.113.25 und 10.0.0.25. Nur eigene Gateways: Received-Header von eingetragenen IPs gelten als wahr. Im Spam-Analyzer erscheint dann die Regel TRUSTED_RELAY mit der ermittelten Absender-IP.
`nextxch: SPF, DKIM, DMARC & ARC, Greylisting, DNSBL (#pSpam)`	Prüfen mit eingetragenem Gateway die echte Absender-IP. Ohne Eintrag sähen sie nur die Gateway-IP, SPF ergäbe dann für fremde Domains meist softfail oder fail.	`abhängig von der Konfiguration`	Eingeschaltet lassen. Doppelte Prüfungen in Gateway und nextxch sind unkritisch; wer Greylisting nur an einer Stelle will, lässt es im Gateway und schaltet es in nextxch ab.
`Firewall: Port 25 auf nextxch`	Nach der MX-Umstellung darf nur noch das Gateway nextxch auf Port 25 erreichen.	`offen für alle`	In der Host- oder Perimeter-Firewall Port 25 nur von 203.0.113.25 bzw. der internen Gateway-IP erlauben. 465, 587, 993 und 443 für Clients bleiben offen.