Alias-Strategie für Postfix — /etc/aliases und virtual_alias_maps
Anders als bei BIMI (DNS-/SVG-/VMC-Setup, kein MTA-Feature) sind Aliase bei Postfix ein echtes natives MTA-Feature. Postfix unterstützt zwei verwandte Mechaniken: /etc/aliases für lokale System-Aliase (gemäß RFC 2142 für Role-Mailboxes wie postmaster, abuse, hostmaster, webmaster) und /etc/postfix/virtual für Multi-Domain-Aliase mit vollqualifizierten Adressen. Nach jeder Änderung sind newaliases (für /etc/aliases) bzw. postmap und systemctl reload postfix (für virtual) Pflicht. Diese Anleitung zeigt beide Mechaniken, den Unterschied, die Bestandsaufnahme per postconf/postmap-Lookup und eine optionale Privacy-Layer-Empfehlung.
Postfix-Alias-Strategie — zwei Mechaniken, beide nativ
Aliase bei Postfix sind ein echtes natives MTA-Feature — anders als bei BIMI (wo Self-Hosted-MTA-Setup ein Mythos ist, weil BIMI ein DNS-/SVG-/VMC-Setup ohne MTA-Komponente ist), sind Aliase Standard-SMTP-Mechanik nach RFC 5321 Section 4.1.2. Postfix bietet zwei verwandte Mechaniken: /etc/aliases für lokale System-Aliase (Localpart-only, ohne Domain) und /etc/postfix/virtual für Virtual-Aliases mit vollqualifizierten Adressen (Multi-Domain-Setup). Die Wahl hängt vom Setup ab — bei einer Domain reicht /etc/aliases, bei mehreren Domains ist /etc/postfix/virtual sauberer.
Beide Mechaniken brauchen nach einer Änderung einen Hash-Build-Schritt. /etc/aliases wird mit newaliases in /etc/aliases.db übersetzt (intern postalias). /etc/postfix/virtual wird mit postmap /etc/postfix/virtual in /etc/postfix/virtual.db übersetzt — und Postfix muss anschließend mit systemctl reload postfix neugeladen werden. Wer den Hash-Build vergisst, wundert sich über nicht-wirkende Aliase. Die Postfix-Doku (postfix.org/aliases.5.html und postfix.org/virtual.5.html) ist die kanonische Referenz.
Hardening-Pfad: MX → SPF → DKIM → DMARC → DMARC-Enforcement → MTA-STS → ARC & SEG → Alias-Strategie (dieser Guide).
Aktuelle Aliase prüfen — /etc/aliases und virtual_alias_maps
Bestandsaufnahme: aktuelle Aliase auflisten, virtual_alias_maps-Konfiguration prüfen, Datenbankdateien verifizieren.
# Aktuelle System-Aliase auflisten
cat /etc/aliases
# Format: name: target1, target2, ...
# Kommentare mit #
# Virtual-Alias-Konfiguration pruefen
postconf virtual_alias_maps
# Erwartet (Beispiel):
# virtual_alias_maps = hash:/etc/postfix/virtual
# Aktuelle virtual-Aliases auflisten
cat /etc/postfix/virtual
# Format: alias@domain target@domain
# (Multi-Domain mit vollqualifizierter Adresse)
# Datenbankdatei pruefen (postmap-Hash)
ls -la /etc/postfix/virtual.db /etc/aliases.db
# MX-Pattern bei Self-Hosted Postfix
dig MX ihre-domain.de +short
# Typisch: mail.ihre-domain.de/etc/aliases gilt nur für lokale Empfänger (Localpart-only, ohne Domain) und wird vom local(8)-Delivery-Agent verarbeitet. virtual_alias_maps gilt für vollqualifizierte Adressen (alle: lokal, virtuell, remote) und wird vom cleanup(8)-Daemon vor der Zustellung verarbeitet. Bei Multi-Domain-Setups oder rein virtuellen Mail-Konten (keine lokalen Unix-User) ist virtual_alias_maps die richtige Wahl.
Service-Aliase via /etc/aliases oder /etc/postfix/virtual anlegen
Pro externem Dienst ein eigener Service-Alias. Nach jeder Änderung Hash-Build-Pflicht.
# /etc/aliases — System-Aliase (lokale User)
# Editor: sudo nano /etc/aliases (oder vim)
# Funktions-Aliase (RFC 2142 Role-Mailboxes)
postmaster: admin@firma.de
abuse: security@firma.de
hostmaster: admin@firma.de
webmaster: admin@firma.de
www: webmaster
# Service-Aliase fuer Leak-Erkennung
hubspot-2026: marketing@firma.de
slack-2026: it@firma.de
aws-billing: buchhaltung@firma.de
github-2026: entwicklung@firma.de
# Verteiler (mehrere Ziele)
support: alice@firma.de, bob@firma.de, carol@firma.de
# PFLICHT nach Aenderung
sudo newaliases
# Schreibt /etc/aliases.db neu.
# /etc/postfix/virtual — Virtual-Aliases (Multi-Domain)
# Format: voll-qualifiziert@domain target@domain
sudo nano /etc/postfix/virtual
hubspot-2026@firma.de marketing@firma.de
slack-2026@firma.de it@firma.de
@firma.de catchall@firma.de # Catch-All AM ENDE
# PFLICHT nach Aenderung
sudo postmap /etc/postfix/virtual
sudo systemctl reload postfixPostfix wertet Virtual-Alias-Einträge von oben nach unten aus — spezifische Matches haben Vorrang vor dem Catch-All. Der Catch-All-Eintrag (@firma.de catchall@firma.de) muss daher nach allen spezifischen Aliasen stehen. Catch-All erhöht das Spam-Risiko (Dictionary-Attack-Bots probieren systematisch gängige Adressen) — Empfehlung: nur temporär oder mit striktem SPF/DKIM/DMARC-Filter aktivieren.
Postfix-native-MTA-Aliase: 3-Layer Top-Down-Auswertung (RFC 5321 §4.1.2 + RFC 2142)
Postfix Alias-Routing als nativ-natives MTA-Feature mit 3 Layern in Top-Down-Auswertung: Layer 1 /etc/aliases (System-Aliase, RFC 2142 Role-Mailboxes lokal — postmaster/abuse/security/hostmaster/webmaster). Layer 2 /etc/postfix/virtual (Multi-Domain Virtual-Aliase). Layer 3 Catch-All AM ENDE (@firma.de catchall@firma.de) — Reihenfolge KRITISCH. KEIN Mythos wie BIMI-MTA.
Externe Privacy-Anbieter optional empfehlen
Self-Hosted-Postfix ist vollständig datensouverän — eigene Server, eigene Verarbeitungs-Kette. Zusätzliche Privacy-Anbieter sind sinnvoll, wenn Mitarbeiter private Identitäten klar von Firmen-Adressen trennen wollen.
Self-Hosted (volle Datensouveränität): addy.io (vorher AnonAddy, Rebrand 9. August 2023) self-hosted auf eigenem Server — Open Source, ideale Ergänzung zum self-hosted Postfix-Setup. EU-/CH-souverän (Cloud): SimpleLogin (Proton-Tochter seit 8. April 2022, Genf) oder Proton Pass-Email. US-Konzern: Firefox Relay, DuckDuckGo Email Protection, Apple Hide My Email. Detail in der Auswahl-Matrix im Kapitel-Index.
Verifikation und Leak-Erkennung via Service-Alias plus HIBP-Monitoring
Verifikation per postmap-Lookup, Mail-Log und Test-Mail. Dauerhaft Spam-Erkennung an Service-Aliasen plus HIBP.
# Test-Mail an Service-Alias senden (extern)
# z.B. von externer Adresse an hubspot-2026@firma.de
# Mail-Log pruefen
sudo tail -f /var/log/mail.log
# Erwartet: postfix/local oder postfix/virtual mit
# "from=, to=, orig_to="
# Alias-Lookup direkt pruefen
postmap -q "hubspot-2026@firma.de" hash:/etc/postfix/virtual
# Erwartet: marketing@firma.de
# Local-Alias-Lookup
postalias -q hubspot-2026 /etc/aliases
# Erwartet: marketing@firma.de
# Leak-Erkennung — Spam an Service-Alias = Leak-Quelle
# Mail an "hubspot-2026@firma.de" von unbekanntem Absender
# -> HubSpot hat Adresse weitergegeben oder wurde geleakt.
# HIBP API v3 fuer Domain-Search
curl -H "hibp-api-key: IHR-32-ZEICHEN-API-KEY" \
https://haveibeenpwned.com/api/v3/breacheddomain/firma.de
# Wolf-Agents Email Security Check erkennt selbst-betriebenen
# Postfix ueber MX-Hostname und prueft Role-Mailboxes (RFC 2142). Häufige Fehler bei der Postfix-Alias-Strategie
newaliases oder postmap vergessen — Aliase wirken nicht
Problem: Neue Aliase in /etc/aliases oder /etc/postfix/virtual eingetragen, aber Mail an die Aliase wird nicht zugestellt. Ursache: Die Datenbankdateien (.db) sind nicht neu aufgebaut. Lösung: Nach /etc/aliases-Änderung sudo newaliases, nach /etc/postfix/virtual-Änderung sudo postmap /etc/postfix/virtual && sudo systemctl reload postfix.
/etc/aliases mit vollqualifizierten Adressen befüllt
Problem: hubspot-2026@firma.de: marketing@firma.de in /etc/aliases — die Source-Adresse wird nicht erkannt. Ursache: /etc/aliases akzeptiert nur Localpart-only (ohne Domain) — vollqualifizierte Adressen gehören in /etc/postfix/virtual. Lösung: Für vollqualifizierte Multi-Domain-Aliase /etc/postfix/virtual nutzen — /etc/aliases nur für System-User.
Catch-All vor spezifischen Aliasen — Reihenfolge bricht
Problem: Catch-All @firma.de catchall@firma.de steht vor spezifischen Aliasen — alle Mail landet im Catch-All. Ursache: Postfix wertet von oben nach unten aus, spezifische Matches müssen vor dem Catch-All stehen. Lösung: Catch-All-Zeile ANS ENDE der Datei verschieben, postmap + reload.
Aliase als „kompliziertes BIMI-MTA-Feature“ missverstanden
Problem: Aliase werden mit BIMI verwechselt, das fälschlich als MTA-Feature gilt. Ursache: Konzept-Drift zwischen BIMI (DNS-/SVG-/VMC-Setup) und Aliasen (echtes MTA-Feature). Lösung: Aliase sind Standard-SMTP-Mechanik nach RFC 5321 §4.1.2, nativ in jedem Postfix-Setup verfügbar — keine Drittsoftware nötig. BIMI dagegen ist DNS+SVG+VMC, kein MTA-Feature.
DSGVO Art. 32, MITRE M1054 und volle Datensouveränität bei Self-Hosted-Postfix
Eine Alias-Strategie in Postfix zahlt direkt auf DSGVO Art. 32 (Sicherheit der Verarbeitung) ein — Pseudonymisierung ist als technisch-organisatorische Maßnahme explizit anerkannt. Self-Hosted-Postfix bedeutet volle Datensouveränität: eigene Server, eigene Verarbeitungs-Kette, kein externes Eigentum, keine US-CLOUD-Act-Berührung (vorausgesetzt der Server steht in EU/CH).
Postfix-Alias-Compliance-Stack: DSGVO Art. 32 (Pseudonymisierung als TOM) + DSGVO Art. 17 (Alias-Deaktivierung als Lösch-Maßnahme) + RFC 5321 §4.1.2 (SMTP Mail Aliasing als Standard-Mechanik) + RFC 2142 (Role-Mailboxes als Pflicht-Aliase) + MITRE M1054 (Software Configuration). Wolf-Agents-USP: Der Email Security Check erkennt selbst betriebene Postfix-Setups über MX-Hostnamen und prüft Catch-All-Konfiguration plus Role-Mailboxes (RFC 2142). Cross-Verweis: DMARC für Postfix, ARC & SEG für Postfix und Exim / Mailcow als alternative Self-Hosted-Stacks.
Mehrwert — Postfix native Alias-Mechanik plus RFC-2142-Role-Mailbox-Hygiene
Postfix bringt Aliase als natives MTA-Feature mit — anders als bei BIMI gibt es hier keinen Mythos „Self-Hosted-MTA setzt das um, was eigentlich ein DNS-/SVG-Setup ist“. Aliase sind im RFC 5321 §4.1.2 als kanonische SMTP-Mechanik dokumentiert (rfc-editor.org/rfc/rfc5321, Oktober 2008). Drei Layer mit klarer Top-Down-Auswertung: Layer 1 System-Aliase in /etc/aliases (lokal, postmaster/root via newaliases); Layer 2 Virtual Aliases in /etc/postfix/virtual (Multi-Domain — voll-qualifizierte Adresse → target, Pflicht postmap /etc/postfix/virtual && systemctl reload postfix); Layer 3 Catch-All AM ENDE der Datei (@firma.de catchall@firma.de — Postfix wertet die Tabelle von oben nach unten aus).
RFC-2142-Role-Mailbox-Pflicht-Setup (Dave Crocker, Internet Mail Consortium, Proposed Standard Mai 1997 — datatracker.ietf.org/doc/rfc2142): Die Standard-Pflicht-Mailboxen sind postmaster@ (SMTP), hostmaster@ (DNS), abuse@, noc@, security@ (Network-Betrieb), plus info@, marketing@, sales@, support@ (Business). Groß-/Kleinschreibung ist irrelevant. Mail-Provider eskalieren Reputations-Reklamationen an abuse@; eine fehlende abuse-Mailbox ist ein Reputations-Risiko.
Bestandsaufnahme-Snippet für Postfix-Aliase: postmap -s hash:/etc/postfix/virtual | sort | uniq -c | sort -rn | head -20 listet die Verteilung der Forwarding-Ziele. Validity-Datum-Mechanik fehlt nativ in Postfix (im Gegensatz zu Mailcow mit Auto-Disable). Workaround: separate Tabelle /etc/postfix/virtual.expired, cronjob mit Move-/Restart-Logik. Wolf-Agents-USP: Der 165-Punkte-Scanner erkennt Self-Hosted-Postfix über MX-Hostnamen-Custom-Domain-Pattern (keine Anbieter-Cloud-MX) und prüft Catch-All-Konfiguration plus RFC-2142-Role-Mailbox-Belegung. Cross-Verweis: Exim (alternative MTA mit Router-System) und Mailcow (Postfix-basierte Container-Suite mit UI).
Alias-Strategie-Anleitung für weitere Provider:
Wie steht Ihre Domain bei Alias-Strategie · Postfix?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.