MX für Postfix einrichten
Schritt-für-Schritt-Anleitung: MX-Record für Self-Hosted Postfix-Mailserver konfigurieren — DNS-Records, PTR/FCrDNS beim IP-Provider, main.cf-Hardening mit smtpd_recipient_restrictions und DNSSEC. Inklusive Wolf-Agents Email Security Check für 165-Punkte-Validierung.
MX-Records für Postfix (Self-Hosted Linux)
Postfix ist der weltweit am häufigsten eingesetzte MTA (Mail Transfer Agent) auf Linux-Servern — Standardmäßig auf Debian/Ubuntu vorinstalliert. Bei einem Postfix-Self-Hosted-Setup definieren Sie den MX-Hostnamen selbst (typisch mail.ihre-domain.de) und müssen drei DNS-Schichten + Reverse-DNS + Postfix-Hardening korrekt konfigurieren. Anders als bei Managed-Hostern liegt die volle Verantwortung für PTR/FCrDNS, TLS-Zertifikate und Spam-Filter beim Betreiber.
Als Maßnahme nach NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) und BSI TR-03108 ist die MX-Konfiguration die Basis für SPF, DKIM und DMARC. Bei Self-Hosted-Setups gehören die TOM-Verantwortung (Patches, PTR, Mailserver-Hardening, TLS-Zertifikate) komplett in die NIS2-Dokumentation. Der Wolf-Agents Email Security Check erkennt Postfix-Stack-Pattern automatisch (Banner-Detection für 220 mail.ihre-domain.de ESMTP Postfix), validiert PTR/FCrDNS für IPv4 und IPv6, scannt DNSSEC, prüft TLS-Zertifikate (Let's Encrypt-kompatibel) und erkennt typische Postfix-Misskonfigurationen (open relay, schwache TLS-Cipher-Suites).
Hardening-Pfad: Nach dem MX-Record folgt SPF für Postfix (Server-IP als ip4:/ip6:), DKIM mit OpenDKIM und DMARC mit OpenDMARC. Für Transport-Verschlüsselung: MTA-STS mit postfix-mta-sts-resolver und SMTP-TLS-Konfiguration. Bedrohungs-Cluster: Ein korrekt gehärteter Postfix-MX-Record schließt DNS-Hijacking-Spoofing und SubdoMailing über verwaiste Mailserver-Subdomains.
MX-Record + A/AAAA für eigenen Mailserver anlegen
Im DNS-Provider Ihrer Domain den MX-Record auf den selbst gewählten Mailserver-Hostnamen (typisch mail.ihre-domain.de) setzen und für diesen Hostnamen A- und AAAA-Records auf die Server-IP anlegen. Dual-Stack ist Pflicht für Bulk-Sender (Google/Yahoo seit Februar 2024).
; Postfix Self-Hosted Mailserver — DNS-Zone
ihre-domain.de. IN MX 10 mail.ihre-domain.de.
mail.ihre-domain.de. IN A 203.0.113.10
mail.ihre-domain.de. IN AAAA 2001:db8:42::10
; PTR-Records werden NICHT in der eigenen Zone gehalten —
; setzen Sie sie beim IP-Hosting-Provider (Hetzner Cloud Console etc.):
; 10.113.0.203.in-addr.arpa. IN PTR mail.ihre-domain.de.
; ...ip6.arpa. IN PTR mail.ihre-domain.de.Bei einem einzelnen Postfix-Server ist die RFC-5321-4-5-Tage-Retry-Queue beim Sender Ihre Backup-Strategie — ein eigener Backup-MX-Server ist optional. Wer einen zweiten Server für Hochverfügbarkeit will, konfiguriert ihn mit Priorität 20 und SMTP-Whitelist nur für den primären MX. Andernfalls droht das klassische MX-Bypass-Risiko: Angreifer senden direkt an den schwächer gefilterten Backup. Quelle: postfix.org/postconf.5.html (abgerufen 2026-05-14).
Die Postfix-Doku (SMTPD_ACCESS_README) warnt explizit zur Reihenfolge bei älteren Postfix-Versionen: Direktes Postfix-Zitat: „With Postfix before version 2.10 you should place non-recipient restrictions AFTER the reject_unauth_destination restriction, not before.“ Das verhindert versehentliches Open-Relay. Postfix 2.10+ Empfehlung: Trennung in zwei separate Direktiven — smtpd_relay_restrictions für Anti-Open-Relay (mit reject_unauth_destination) und smtpd_recipient_restrictions für Spam-Filter (RBL, Domain-Blacklists). Begründung aus offizieller Doku: „a permissive spam blocking policy will not result in a permissive mail relay policy.“ Diese Trennung ist Pflicht für NIS2-Audit-tauglicher Postfix-Konfiguration — Open-Relay-Server landen schnell auf Spamhaus PBL oder SORBS und blockieren ausgehende Mails komplett. Quelle direkt-verifiziert: postfix.org/SMTPD_ACCESS_README.html (abgerufen 2026-05-16).
Self-Hosted-MX-Stack — 3 Schichten DNS + MTA + TLS
Drei-Schichten-Architektur für Self-Hosted-MX: Schicht 1 DNS (MX/A/AAAA/PTR/DNSSEC/MTA-STS/TLSA). Schicht 2 MTA (Postfix smtpd_recipient_restrictions / Exim acl_smtp_rcpt / Mailcow Postfix+Rspamd). Schicht 3 TLS (Let's Encrypt + DANE TLSA + MTA-STS-Cert). Banner-Detection als Wolf-Agents-Stack-Detection-USP.
PTR/FCrDNS beim IP-Provider setzen
PTR-Records (Reverse-DNS) werden nicht in Ihrer eigenen DNS-Zone gehalten, sondern beim Hosting-Provider Ihrer IP-Adresse — Hetzner Cloud Console, IONOS, AWS Route 53 oder beim ARIN/RIPE für eigene IP-Blöcke. FCrDNS verlangt, dass PTR und A/AAAA bidirektional konsistent sind: PTR von 203.0.113.10 → mail.ihre-domain.de, A von mail.ihre-domain.de → 203.0.113.10.
Google Gmail lehnt eingehende Mails von Servern ohne gültigen PTR häufig als Spam ab — das gleiche gilt für ausgehende Mails. Bei VPS/Cloud-Servern haben generische PTRs wie vps12345.provider.com denselben Effekt. Setzen Sie den PTR exakt auf den MX-Hostnamen Ihrer Domain. Für IPv6 muss der PTR separat in der ip6.arpa-Zone gesetzt werden.
main.cf Hardening (smtpd_recipient_restrictions)
Postfix in /etc/postfix/main.cf härten — die wichtigsten Direktiven: smtpd_helo_required verhindert RFC-Verstöße, smtpd_recipient_restrictions blockiert Open-Relay und reject_unknown_recipient_domain, smtpd_tls_security_level aktiviert STARTTLS.
# /etc/postfix/main.cf — Hardening-Auszug
# FQDN + Hostname
myhostname = mail.ihre-domain.de
mydomain = ihre-domain.de
myorigin = $mydomain
# HELO-Pflicht
smtpd_helo_required = yes
# Empfaenger-Restriktionen
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
reject_unknown_recipient_domain
reject_invalid_hostname
reject_non_fqdn_helo_hostname
# TLS aktivieren
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.ihre-domain.de/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.ihre-domain.de/privkey.pemDNSSEC wird beim DNS-Provider (Cloudflare DNS, Hetzner DNS, BIND9-Self-Hosted) aktiviert — der DS-Record muss zum Registrar synchronisiert werden. Bei Self-Hosted-BIND9: dnssec-policy default in named.conf, anschließend DS-Record bei Registrar eintragen. Wolf-Agents Email Security Check prüft die DNSSEC-Kette bis zur Root-Zone.
DNSSEC + dig-Verifikation
Nach dem DNS-Setup und Postfix-Restart prüfen Sie alle Schichten: MX, A/AAAA, PTR/FCrDNS, DNSSEC und Postfix-Konfiguration.
# Linux / macOS
dig MX ihre-domain.de +short
dig A mail.ihre-domain.de +short
dig AAAA mail.ihre-domain.de +short
# Reverse DNS (PTR/FCrDNS-Prüfung)
dig -x 203.0.113.10
dig -x 2001:db8:42::10
# DNSSEC-Validierung
dig +dnssec MX ihre-domain.de | grep -E "RRSIG|ad;"
# Postfix-Konfiguration prüfen
postfix check
postconf -n | grep -E "myhostname|smtpd_helo_required|smtpd_recipient_restrictions"Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser erkennt Postfix-Stack-Pattern (Banner-Detection), validiert PTR/FCrDNS für IPv4 und IPv6, scannt die DNSSEC-Kette und prüft TLS-Zertifikat (Let's Encrypt-kompatibel) sowie typische Misskonfigurationen wie Open Relay oder schwache TLS-Cipher-Suites. Das Monitoring überwacht den Mailserver alle 6 Stunden.
Häufige Fehler bei Postfix MX-Records
Fehlender PTR-Record (NXDOMAIN)
Problem: dig -x <server-ip> liefert NXDOMAIN. Ursache: PTR wurde beim IP-Provider nicht gesetzt. Lösung: Im IP-Provider-Panel (Hetzner Cloud Console, IONOS, etc.) den Reverse DNS auf mail.ihre-domain.de setzen — für IPv4 und IPv6 separat. Wolf-Agents Email Security Check zeigt FCrDNS-Inkonsistenz explizit an.
CNAME als MX-Ziel
Problem: mail.ihre-domain.de ist ein CNAME auf app.cloudserver.com. Ursache: Bequemlichkeits-Konfiguration. Lösung: RFC 2181 § 10.3 verbietet CNAMEs als MX-Ziel — stattdessen direkte A/AAAA-Records anlegen. Strikte Resolver verweigern die Zustellung.
Open-Relay durch fehlende smtpd_recipient_restrictions
Problem: Postfix akzeptiert Mail-Relay an beliebige Domains. Ursache: smtpd_recipient_restrictions nicht gesetzt oder ohne reject_unauth_destination. Lösung: Restriktionen wie im Hardening-Beispiel setzen — Open-Relay-Server landen schnell auf Spam-Blacklists.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Postfix
Eine korrekt konfigurierte Postfix-Architektur mit DNSSEC, PTR/FCrDNS und Hardening-Direktiven ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung), lit. e (Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen) und BSI TR-03108. Bei Self-Hosted-Setups liegt die volle TOM-Verantwortung beim Betreiber — Patches, PTR, TLS-Zertifikate und Anti-Spam-Filter müssen kontinuierlich gepflegt werden. Diese Eigenverantwortung gehört in die NIS2-TOM-Dokumentation.
Postfix MX-Compliance-Stack: NIS2 lit. h (DNSSEC für MX, DNS-Provider aktivierbar) + lit. e (Mailserver-Hardening) + BSI TR-03108 (FCrDNS kundenseitig, smtpd_recipient_restrictions, TLS-Zertifikate) + DSGVO Art. 32 lit. b (Verfügbarkeit kundenseitig, eigene Backup-Strategie). Wolf-Agents-USP: Der Email Security Check erkennt Postfix-Stack (Banner-Detection für „ESMTP Postfix“), validiert PTR/FCrDNS für IPv4 und IPv6, scannt DNSSEC und prüft typische Misskonfigurationen wie Open Relay, schwache TLS-Cipher und smtpd_helo_required — kein anderer DACH-Scanner deckt diese vier Postfix-spezifischen Drift-Klassen ab. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing.
Wie steht Ihre Domain bei MX-Infrastruktur · Postfix?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.