E-Mail-Alias-Strategie: native Aliase, Privacy-Anbieter und Leak-Erkennung
Eine Alias-Strategie macht aus einer monolithischen E-Mail-Adresse ein modulares Identitäts-System: pro Dienst eine Adresse, sofortige Leak-Quellen-Identifikation und Pseudonymisierung im Sinne von DSGVO Art. 32. Diese Anleitung trennt vier verwandte Konzepte sauber (Alias ≠ Forwarding ≠ ARC ≠ BIMI), zeigt die nativen Alias-Mechaniken in Cloud, DACH-Hosting und Self-Hosted plus die sechs dedizierten Privacy-Anbieter mit ihrer Eigentümer-Struktur — SimpleLogin gehört seit 8. April 2022 zur Proton AG, addy.io wurde am 9. August 2023 rebrandet, Apple Hide My Email ist iCloud+-Subscription-pflichtig. Mit Auswahl-Matrix nach Souveränität und Leak-Erkennungs-Workflow nach haveibeenpwned.com.
Vier Konzepte sauber trennen: Alias, Forwarding, ARC und BIMI
Ein Email-Alias ist eine zusätzliche Adresse für ein bestehendes Postfach (Empfänger-Filter) oder eine einzelne Adresse für mehrere Postfächer (Verteiler). Die Mail bleibt im selben Mailsystem, beim selben Mailserver — es findet keine MTA-Weiterleitung an ein externes Postfach statt. Aliase sind ein in RFC 5321 Section 4.1.2 und RFC 5598 Section 4.5 dokumentiertes Grundkonzept des SMTP-Mailverkehrs.
In der Praxis werden vier verwandte Mechaniken regelmäßig verwechselt. Forwarding ist die MTA-Weiterleitung an ein externes Postfach (alias@firma.de → ziel@gmail.com) — die Mail verlässt das eigene System, SPF bricht durch den IP-Wechsel und ARC-Sealing wird relevant. ARC (Authenticated Received Chain, RFC 8617) ist die Authentifizierungs-Kette über Weiterleitungen hinweg — kein Alias, sondern eine reine Verifikations-Schicht. BIMI (Brand Indicators for Message Identification) ist ein DNS-/SVG-/VMC-Setup für Marken-Logos im Empfänger-Client und gar kein MTA-Feature. Dedizierte Privacy-Anbieter wie SimpleLogin kombinieren Alias-Pseudonymisierung mit Forwarding — sie sind weder klassisches Alias noch klassisches Forwarding, sondern beides zugleich.
Hardening-Pfad: MX-Records → SPF → DKIM → DMARC → DMARC-Enforcement → MTA-STS → DNS-Sicherheit → ARC & SEG → Alias-Strategie (dieses Kapitel). Bedrohungs-Cluster: Alias-Hygiene reduziert die Angriffsfläche für Phishing, Spear-Phishing und Business Email Compromise — pro Leak wird nur ein Service-Alias kompromittiert, nicht die zentrale Identität.
Vier Konzepte im Vergleich — Alias, Forwarding, ARC, BIMI plus Privacy-Alias-Anbieter
| Konzept | Was es ist | Provider-Mechanik |
|---|---|---|
| Alias | Zusätzliche Adresse für ein bestehendes Postfach — Mail bleibt im selben Mailsystem | Nativ via /etc/aliases (Postfix), virtual_aliases (Postfix Multi-Domain), Exim-Router, Mailcow-UI, Microsoft 365 Admin Center, Google Admin Console |
| Forwarding | MTA-Weiterleitung an externes Postfach — Mail verlässt das eigene System | Provider-Forwarding-Funktion + MTA-smtp:[host]-Routing. SPF bricht durch IP-Wechsel, ARC-Sealing wird relevant |
| ARC | Authentifizierungs-Kette über Weiterleitungen (RFC 8617) — keine Mail-Mechanik, sondern Verifikation | OpenARC-Milter (Postfix), Exim arc_sign ab 4.91, Mailcow via Rspamd. Siehe ARC & SEG |
| BIMI | Marken-Logo im Empfänger-Client — DNS-Record, SVG-Hosting, VMC-Bestellung | DNS + SVG + VMC — kein MTA-Feature. Siehe BIMI & VMC |
| Privacy-Alias-Anbieter | Pseudonym-Adresse mit Forwarding ins eigentliche Postfach — kombiniert beide Mechaniken | SimpleLogin (Proton-Tochter seit 8.4.2022), addy.io (vorher AnonAddy, Rebrand 9.8.2023), Apple Hide My Email (iCloud+), Firefox Relay (Mozilla), DuckDuckGo Email Protection, Proton Pass-Email |
# Vier Konzepte trennen — drei verwandte Mechaniken plus BIMI als Kontrast
#
# ALIAS: eine Adresse für ein anderes Postfach (Empfänger-Filter)
# -> info@firma.de -> admin@firma.de
# -> bleibt im selben Mailsystem, gleicher Mailserver
#
# FORWARDING: MTA leitet an externes Postfach (anderer Mailserver)
# -> alias@firma.de -> ziel@gmail.com
# -> verlässt das eigene Mailsystem
# -> SPF bricht (IP-Wechsel), ARC-Sealing nötig
#
# ARC: Authenticated Received Chain (RFC 8617)
# -> versiegelt SPF/DKIM/DMARC-Ergebnisse vor Weiterleitung
# -> KEIN Alias, KEINE Forwarding-Mechanik
# -> reine Authentifizierungs-Schicht für Forwarding
#
# BIMI: Brand Indicators for Message Identification
# -> DNS-Record + SVG-Hosting + VMC-Bestellung
# -> KEIN MTA-Feature, KEIN Alias, KEIN Forwarding
# -> Marken-Logo im Empfänger-Client (Gmail, Yahoo, Apple Mail)
#
# Dedizierter PRIVACY-ALIAS-Anbieter (SimpleLogin/addy.io/Apple/Firefox/DuckDuckGo):
# -> kombiniert Alias-Pseudonymisierung mit Forwarding-Mechanik
# -> zufällig generierte Pseudonym-Adresse beim Anbieter
# -> Weiterleitung an Original-Postfach
# -> Reply-as-Alias (Anti-Identitäts-Leak)Native Provider-Aliase: Cloud, DACH-Hosting und Self-Hosted
Native Provider-Aliase sind die Standard-Mechanik der drei Provider-Welten Cloud, DACH-Hosting und Self-Hosted. Sie sind im Lizenzpreis enthalten, zentral verwaltbar und für die meisten Unternehmensszenarien ausreichend. Anders als bei BIMI (DNS-/SVG-Setup mit Mythos-Risiko bei Self-Hosted-MTA) sind Aliase tatsächlich ein natives Feature aller relevanten Mailserver — Postfix konfiguriert sie via /etc/aliases, Exim via Router-System, Mailcow via Web-UI. Es gibt hier keine konzeptionelle Lücke wie bei BIMI-MTA.
Bei den Cloud-Providern gilt Microsoft 365 als großzügig konfiguriert: Bis zu 400 Aliase pro Postfach in Business und Enterprise (Exchange Online) ohne Zusatzkosten (learn.microsoft.com, Abruf 24. Mai 2026). Outlook.com-Consumer-Konten sind dagegen auf 10 Aliase begrenzt — ein typischer Drift-Punkt. Google Workspace erlaubt 30 Alternate Email Addresses pro Nutzer ohne Zusatzkosten (knowledge.workspace.google.com, Abruf 24. Mai 2026). Wer mehr braucht, weicht auf Google Groups oder Recipient Address Mapping aus.
Provider-Tier-Übersicht — native Alias-Limits 2026
| Provider | Limit pro Postfach | Mechanik |
|---|---|---|
| Microsoft 365 Business / Enterprise | bis 400 Aliase | Admin Center, PowerShell Set-Mailbox -EmailAddresses |
| Outlook.com Consumer | 10 Aliase | Microsoft-Konto-Verwaltung — abweichend vom Business-Tier |
| Google Workspace | 30 Alternate Email Addresses | Admin Console → Verzeichnis → Nutzer → Alternate Emails |
| Proton Mail (Premium) | bis 10 native Aliase + SimpleLogin-Integration | Proton-Account-Settings + SimpleLogin-Anbindung (Tochter seit 8.4.2022) |
| Mailbox.org (Heinlein Hosting GmbH, Berlin) | tarifabhängig — Mail-Plan ab 25 Adressen | Mailbox.org-Verwaltung |
| Posteo (Posteo e.K., Berlin) | 2 zusätzliche E-Mail-Adressen pro Konto | Posteo-Einstellungen |
| Tutanota / Tuta (Tutao GmbH, Hannover) | tarifabhängig — Aliase pro Premium-Tier | Tutanota-Verwaltung |
| DACH-Hosting (IONOS, Strato, All-Inkl, Hetzner Webhosting, Netcup) | tarifabhängig, zählen häufig gegen Postfach-Kontingent | Kunden-Panel pro Hoster (CCP / KAS / Konsoleh / My-Panel) |
| Self-Hosted (Postfix, Exim, Mailcow) | nahezu unbegrenzt | /etc/aliases, virtual_alias_maps, Exim-Router, Mailcow-UI |
Self-Hosted ist nativ korrekt — kein Mythos wie BIMI-MTA: Bei BIMI gilt die Aussage „Self-Hosted-MTA setzt BIMI um“ als Mythos, weil BIMI ein DNS-/SVG-/VMC-Setup ist und der MTA daran nichts beiträgt. Bei Aliasen ist die Lage anders: /etc/aliases, virtual_alias_maps (Postfix), das Router-System in Exim und die Mailcow-UI sind native MTA-Features für Alias-Routing. Die copy-paste-fertigen Anleitungen für Postfix, Exim und Mailcow finden Sie auf den Provider-Seiten dieses Kapitels.
# /etc/aliases — Postfix System-Aliase (RFC 5321 Section 4.1.2)
# Format: name: target1, target2, ...
# Nach Änderung Pflicht: sudo newaliases
# Funktions-Aliase (Role-Mailboxes nach RFC 2142)
postmaster: admin@firma.de
abuse: security@firma.de
hostmaster: admin@firma.de
webmaster: admin@firma.de
# Service-Aliase (Leak-Erkennung — pro Dienst eine Adresse)
hubspot-2026: marketing@firma.de
slack-2026: it@firma.de
aws-billing: buchhaltung@firma.de
github-2026: entwicklung@firma.de
# Verteiler (eine Adresse, mehrere Postfächer)
support: alice@firma.de, bob@firma.de, carol@firma.de# /etc/postfix/virtual — Virtual Aliases für Multi-Domain-Setups
# Format: voll-qualifizierte-adresse@dom target
# Nach Änderung: sudo postmap /etc/postfix/virtual && sudo systemctl reload postfix
# Service-Aliase pro Dienst (Privacy + Leak-Erkennung)
hubspot-2026@firma.de marketing@firma.de
slack-2026@firma.de it@firma.de
aws-billing@firma.de buchhaltung@firma.de
# Catch-All — AM ENDE der Datei (Postfix wertet von oben nach unten)
@firma.de catchall@firma.deSechs dedizierte Alias-Anbieter: Eigentümer-Struktur und Souveränitäts-Profil
Dedizierte Alias-Anbieter pseudonymisieren die echte E-Mail-Adresse über zufällig generierte oder selbstgewählte Relay-Adressen — eingehende Mail wird durch den Anbieter ans eigentliche Postfach weitergeleitet. Sechs Anbieter sind im DACH-Markt 2026 relevant, mit klar unterschiedlicher Eigentümer-Struktur und damit unterschiedlichem Souveränitäts-Profil. Wer DSGVO-konform und EU-souverän bleiben will, achtet auf die Mutter-Tochter-Kette — SimpleLogin ist seit 8. April 2022 Teil der Proton AG mit Sitz in Genf, Apple Hide My Email gehört Apple Inc., Cupertino mit US-CLOUD-Act-Exposition.
Dedizierte Alias-Anbieter im DACH-Kontext (Stand 24. Mai 2026)
| Anbieter | Eigentümer / Sitz | Souveränitäts-Tag |
|---|---|---|
| SimpleLogin | Seit 8. April 2022 Teil der Proton AG, Route de la Galaise 32, 1228 Plan-les-Ouates, Genf, Schweiz | EU-/CH-souverän, kein US-CLOUD-Act — Anti-CLOUD-Act über CH Art. 271 StGB |
| addy.io (vorher AnonAddy) | Open-Source-Projekt, Rebrand am 9. August 2023 — self-hostable, Cloud-Dienst durch Will Browning betrieben | self-hosted = volle Datensouveränität; Cloud-Dienst-Souveränität = abhängig vom Anbieter-Setup |
| Apple Hide My Email | Apple Inc., One Apple Park Way, Cupertino, CA, USA — Teil von iCloud+ (Subscription-Pflicht, kein Free-Tier) | US-Konzern, CLOUD-Act-exponiert |
| Firefox Relay | Mozilla Corporation, Mountain View, CA, USA | US-Konzern, CLOUD-Act-exponiert |
| DuckDuckGo Email Protection | DuckDuckGo Inc., Paoli, Pennsylvania, USA — seit Juli 2021 in Beta gestartet | US-Konzern, CLOUD-Act-exponiert |
| Proton Pass-Email (Hide-my-email) | Integriert in Proton Pass — gleiches Mutter-Unternehmen Proton AG (Genf), separat von SimpleLogin im Proton-Ökosystem | EU-/CH-souverän, kein US-CLOUD-Act |
Hinweis: SimpleLogin wurde am 8. April 2022 mit dem Proton-Blog-Beitrag „Proton and SimpleLogin join forces“ als Teil der Proton AG angekündigt (proton.me/blog/proton-and-simplelogin-join-forces). addy.io wurde am 9. August 2023 von AnonAddy umbenannt — die Open-Source-Variante ist self-hostable. Proton Pass-Email ist eine eigenständige Hide-my-email-Funktion im Proton-Pass-Passwortmanager und nutzt nicht zwingend die SimpleLogin-Infrastruktur.
Souveränitäts-Auswahl-Matrix der sechs Alias-Anbieter (Stand 24. Mai 2026, WebFetch-verifiziert)
Die sechs Alias-Anbieter unterscheiden sich nicht nur im Eigentümer-Sitz, sondern auch im Tarif-Modell, in der Custom-Domain-Verfügbarkeit und im Reply-Mechanismus. Die folgende Matrix konsolidiert die offiziellen Preise und Limits aus den jeweiligen Anbieter-Seiten (Abruf 24. Mai 2026) — sie ist die direkte Entscheidungsgrundlage für DACH-Unternehmen, die zwischen EU/CH-souveränen und US-Konzern-Diensten wählen müssen.
| Anbieter | Free-Tier | Premium / Pflicht-Subscription | Custom-Domain | Reply-Funktion | CLOUD-Act |
|---|---|---|---|---|---|
| SimpleLogin (Proton AG, Genf) | 10 Aliase, 1 Mailbox | kostenpflichtiges Premium-Abo — unbegrenzte Aliase + Catch-all/Wildcard + 5 Subdomains + 50 Verzeichnisse | Premium | Reverse-Reply (Premium) | kein US-CLOUD-Act |
| addy.io (Will Browning, UK) | unbegrenzt Standard-Aliase + 10 Shared Domain Aliases + 1 Empfänger + 10 MB Bandbreite | kostenpflichtiger Lite-Tarif — 50 Shared Domain Aliases + 1 Custom Domain + 5 Empfänger; kostenpflichtiger Pro-Tarif — unbegrenzt + 20 Custom Domains + 30 Empfänger | Lite/Pro | Reply-as-Alias (alle Tiers) | UK = nicht US-CLOUD-Act (jedoch UK-Investigatory-Powers-Act-Eingriffe möglich) |
| Apple Hide My Email (Apple Inc., USA) | nicht im Free 5-GB-Tier enthalten | iCloud+-Pflicht — kostenpflichtige iCloud+-Tiers (gestaffelt nach Speicher: 50 GB / 200 GB / 2 TB / 6 TB / 12 TB); Hide My Email in allen iCloud+-Tiers | via Custom Email Domain | Reply via Apple | US-CLOUD-Act |
| Firefox Relay (Mozilla, USA) | 5 E-Mail-Masken | kostenpflichtiges Premium (Email Protection / Email & Phone Protection) — wird laut relay.firefox.com/premium aktuell über eine Warteliste ausgerollt | Premium-only | Premium | US-CLOUD-Act |
| DuckDuckGo Email Protection (DDG Inc., USA) | kostenlos, unbegrenzte @duck.com-Aliase, Beta seit Juli 2021 | kein Premium-Tier vorhanden | nicht angeboten | via DDG | US-CLOUD-Act |
| Proton Pass-Email (Proton AG, Genf) | Free: 10 Hide-my-email-Aliase, 1 Nutzer | Pass Plus / Family / Proton Unlimited — unbegrenzte Aliase + Custom Domains for Aliases + Dark Web Monitoring | Pass Plus+ | via Proton | kein US-CLOUD-Act |
Praxisregel — Souveränitäts-Filter: Wer ein Anti-CLOUD-Act-Mandat hat (Berufsgeheimnisträger, Behörden, Schweizer Kunden), wählt SimpleLogin oder Proton Pass-Email — beide gehören der Proton AG in Genf und sind damit aus US-Konzern-Sicht inkompatibel mit CLOUD-Act-Zugriffen (analog Hornetsecurity-Proofpoint-Pattern aus dem ARC-SEG-Kapitel — aber als positive Variante: die Übernahme machte SimpleLogin CH-souveräner statt US-souveräner). addy.io (UK-inhabergeführt) ist die EU-nahe Alternative; im self-hosted Modus volle Datensouveränität. Apple/Firefox/DuckDuckGo bleiben für private Mitarbeiter-Empfehlungen sinnvoll, taugen aber nicht für regulatorisch sensiblen Forwarding-Datenfluss. Quellen: simplelogin.io/pricing, addy.io, apple.com/icloud, relay.firefox.com, duckduckgo.com/email, proton.me/pass/pricing (alle WebFetch 24.5.2026).
Apple iCloud+ Subscription — Hide My Email ist kein Free-Tier
Apple Hide My Email ist Teil der kostenpflichtigen iCloud+ Subscription und im kostenlosen iCloud-Tier (5 GB) NICHT enthalten. Die iCloud+-Tiers (laut apple.com/icloud, Abruf 24. Mai 2026) sind durchgehend kostenpflichtig ab dem Einstiegs-Tier und nach Speicher gestaffelt — vom 50-GB-Tier über 200 GB, 2 TB und 6 TB bis 12 TB. Hide My Email ist in allen iCloud+-Tiers enthalten — wer es nutzt, zahlt mindestens den 50-GB-Tarif. Die Behauptung „Apple Hide My Email ist kostenlos“ ist daher unzutreffend.
Firefox Relay (relay.firefox.com) hat dagegen ein echtes Free-Tier mit 5 Aliasen. Das Premium-Tier (Email Protection) bringt unbegrenzte Aliase plus Custom-Domain — Custom-Domain ist ausschließlich Premium-only. DuckDuckGo Email Protection (duckduckgo.com/email) ist seit dem Beta-Start im Juli 2021 vollständig kostenlos und erzeugt zufällige @duck.com-Adressen.
Alias-Anbieter-Souveränitäts-Matrix (6 Anbieter × 4 Dimensionen, Stand Mai 2026)
Vergleichs-Matrix der 6 dedizierten Privacy-Alias-Anbieter im DACH-Markt 2026 mit Eigentums-Tags und CLOUD-Act-Indikator. SimpleLogin und Proton Pass-Email = EU/CH-souverän (Proton AG Genf seit 8.4.2022). addy.io = UK-inhabergeführt + AGPL-3.0 self-hostable (Will Browning, Rebrand 9.8.2023). Apple iCloud+, Firefox Relay, DuckDuckGo = US-CLOUD-Act.
Apple iCloud+ Subscription-Pflicht-Tier-Matrix (Hide My Email)
Apple iCloud+ verlangt zwingend eine Subscription für Hide My Email — KEIN Free-Tier. 5 Tiers von $0.99/Monat (50 GB) bis $59.99/Monat (12 TB). Free 5 GB iCloud-Speicher OHNE Hide My Email. Im Vergleich zu SimpleLogin/addy.io/Firefox Relay/DuckDuckGo (alle mit Free-Tier) ist Apple das einzige Subscription-Pflicht-Modell.
Leak-Erkennung mit pro-Dienst-Aliasen und haveibeenpwned.com
Die operative Stärke einer Alias-Strategie zeigt sich erst nach dem ersten Leak: Wenn Sie pro externem Dienst einen eigenen Service-Alias vergeben — hubspot-2026@firma.de bei HubSpot, slack-2026@firma.de bei Slack, aws-billing@firma.de bei AWS — und plötzlich Spam an genau einen dieser Aliase eingeht, kennen Sie die Leak-Quelle mit Sicherheit. Ohne Alias-Strategie wüssten Sie nur, dass Sie Spam erhalten, aber nicht woher.
Leak-Workflow in sieben Schritten
- Verdächtigen Eingang identifizieren — Spam, Phishing oder ungewöhnliche Mail an einem Service-Alias (z.B.
hubspot-2026@firma.de). - Dienst zuordnen — Alias-Register konsultieren: welcher Dienst nutzt diese Adresse? (Hier: HubSpot.)
- Breach-Datenbanken prüfen — haveibeenpwned.com auf bekannte Breaches des identifizierten Dienstes prüfen. Domain-Suche per HIBP API v3 (Tiers Core, Pro, High RPM — Preis siehe HIBP-Subscription-Seite).
- Passwort sofort ändern — beim betroffenen Dienst und überall, wo dasselbe Passwort verwendet wird.
- Kompromittierten Alias deaktivieren — Phishing und Spam laufen nach Deaktivierung ins Leere.
- Neuen Alias erstellen — z.B.
hubspot-2027@firma.de— und beim Dienst hinterlegen. - Dokumentieren — Alias-Register aktualisieren (kompromittierter Alias, Datum, vermutete Quelle, neuer Alias). DSGVO-Rechenschaftspflichten nach Art. 5 Abs. 2.
Have I Been Pwned API v3: Drei Subscription-Tiers (Core, Pro, High RPM — exakte Preise auf haveibeenpwned.com/Subscription). Die Domain Search erlaubt eine API-Abfrage pro Domain für alle betroffenen E-Mail-Adressen, die Pwned Passwords API ist kostenlos und ohne Key. Die Domain-Verifikation läuft per DNS-TXT-Record oder per E-Mail an die Standardadressen admin@, hostmaster@, info@, security@, webmaster@ — selbst diese fünf Adressen sollten in Ihrem Alias-Register dokumentiert sein.
HIBP API v3 — vollständige Pricing-Matrix (Stand 24. Mai 2026, WebFetch-verifiziert)
Die HIBP API v3 ist in gestaffelte, kostenpflichtige Tiers gegliedert — vom kleinsten Core-Plan (Core 1) mit einer Domain und 10 RPM (Requests per Minute) Rate-Limit bis hin zu Hochdurchsatz-Plänen. Die Tier-Tabelle aus haveibeenpwned.com/Subscription ist die direkte Entscheidungsgrundlage für die Skalierung: Core-Pläne (Core 1 bis Core 5) decken eigene Domains bis 20 Domains, 1.000 RPM, ohne k-Anonymity-Email-Search und ohne Stealer Logs. Pro-Pläne (Pro 1 bis Pro 5) sind für MSPs gedacht — Kunden-Domains bis 800 Domains, 16.000 RPM, k-Anonymity-Email-Search, Stealer Logs APIs, Bulk-Enrollment. High-RPM-Pläne maximieren den Durchsatz bis 24.000 RPM mit k-Anonymity, dafür ohne tiefes Domain-Monitoring. Die Domänenzählung erfasst nur Domains mit mehr als 10 betroffenen Adressen — kleine Domains zählen nicht gegen das Limit.
Praxis-Empfehlung pro Unternehmensgröße: KMU mit einer Domain und kleinem Alias-Inventar = Core 1. KMU mit mehreren Marken-Domains = Core 3 (100 RPM, bis 5 Domains). MSPs mit Kunden-Domain-Monitoring brauchen mindestens Pro 1 (50 Kunden-Domains). Die Domain Search ist bei Core und Pro inkludiert; Pwned Passwords (k-Anonymity-Hash-Lookup) ist und bleibt kostenlos und ohne API-Key.
DSGVO Art. 6, 7, 17 und 32 — Aliase als technisch-organisatorische Maßnahme
Eine Alias-Strategie ist primär datenschutzrechtlich verankert. DSGVO Art. 32 (Sicherheit der Verarbeitung) erkennt Pseudonymisierung explizit als technisch-organisatorische Maßnahme an — pro-Dienst-Aliase sind genau das. DSGVO Art. 17 (Recht auf Löschung) lässt sich über Alias-Deaktivierung sauber und technisch sofort umsetzen. Art. 6 (Rechtsmäßigkeit) und Art. 7 (Bedingungen für die Einwilligung) sind die rechtliche Basis bei Newsletter-Anmeldungen und Drittdienst-Registrierungen. Eine pauschale NIS2-Pflicht für Alias-Strategien gibt es nicht — wer externe Alias-Anbieter einsetzt, berührt allerdings NIS2 Art. 21 Abs. 2 lit. d (Sicherheit der Lieferkette).
DSGVO-Verankerung pro Artikel
| Artikel | Bezug zur Alias-Strategie | Praxis-Umsetzung |
|---|---|---|
| Art. 6 — Rechtsmäßigkeit | Service-Alias bei Drittanbieter-Registrierung dokumentiert die Rechtsgrundlage (Vertrag, berechtigtes Interesse) | Alias-Register vermerkt pro Dienst die Rechtsgrundlage |
| Art. 7 — Einwilligung | Newsletter-/Marketing-Einwilligung pro Alias dokumentierbar — Widerruf durch Alias-Deaktivierung | Newsletter-Alias newsletter-verein-2026@firma.de |
| Art. 17 — Recht auf Löschung | Alias-Deaktivierung wirkt als technische Lösch-Maßnahme — der Dienst kann die Adresse nicht mehr erreichen | Alias deaktivieren bei Vertragsende |
| Art. 32 — Sicherheit der Verarbeitung | Pseudonymisierung ist als Schutzmaßnahme explizit anerkannt — pro-Dienst-Aliase sind eine Pseudonymisierungs-Maßnahme | Alias-Strategie als TOM dokumentieren |
| NIS2 Art. 21 Abs. 2 lit. d | Sicherheit der Lieferkette — bei externen Alias-Anbietern (SimpleLogin, addy.io, Apple, Firefox, DuckDuckGo) deren Datenverarbeitungs-Kette mitprüfen | AVV mit externem Alias-Anbieter; Souveränitäts-Filter (siehe Auswahl-Matrix) |
NIS2-Klarheit: Eine Alias-Strategie als solche ist KEINE NIS2-Pflichtmaßnahme (anders als SPF/DKIM/DMARC oder ein Secure Email Gateway, die direkt auf Art. 21 Abs. 2 lit. a einzahlen). Sie ist überwiegend DSGVO-motiviert. NIS2-Bezug entsteht nur, wenn externe Anbieter eingebunden werden — dann gilt Art. 21 Abs. 2 lit. d (Sicherheit der Lieferkette) bezogen auf den jeweiligen Anbieter. Diese Trennung sollten Unternehmen sauber kommunizieren — eine pauschale NIS2-Begründung für Aliase ist nicht belastbar.
Auswahl-Matrix Alias-Strategie: Native vs Externe vs Hybrid mit Souveränitäts-Filter
Die Alias-Strategie für 2026 lässt sich auf vier Entscheidungspfade verdichten. Wer eine zentrale, IT-verwaltbare Lösung im Lizenzpreis braucht, bleibt bei den nativen Provider-Aliasen. Wer EU-Souveränität ohne US-CLOUD-Act-Exposition will, wählt SimpleLogin (Proton-Tochter), Proton Pass-Email oder ein self-hosted addy.io. Wer Mitarbeiter-Privatnutzung von der Firmen-Identität trennen will, bringt Firefox Relay oder DuckDuckGo Email Protection als Mitarbeiter-Empfehlung — mit klarer Markierung der US-Konzern-Eigentumsstruktur.
Vier Entscheidungspfade mit Souveränitäts-Tag
| Pfad | Anbieter / Mechanik | Souveränitäts-Tag | Wann passend? |
|---|---|---|---|
| 1. Nativ Cloud | Microsoft 365 (bis 400/Postfach) oder Google Workspace (30/Nutzer) | US-Cloud-Konzern, EU Data Boundary (M365) bzw. EU-Region (Google) | Standard-Unternehmensszenario, im Lizenzpreis enthalten, zentral verwaltbar |
| 2. EU-/CH-souverän extern | SimpleLogin (Proton-Tochter seit 8.4.2022) oder Proton Pass-Email — beide Proton AG, Genf | EU-/CH-Sitz Mutter und Tochter, kein US-CLOUD-Act, CH Art. 271 StGB | Berufsgeheimnisträger, Anti-CLOUD-Act-Mandat, Schweizer Kunden |
| 3. Self-Hosted Open Source | addy.io self-hosted oder Postfix/Exim/Mailcow mit eigenem Alias-System | volle Datensouveränität — keine externe Verarbeitungs-Kette | KRITIS, BSI-Hochsensibel, eigene Mailserver-Kompetenz vorhanden |
| 4. US-Konzern-Empfehlung Mitarbeiter | Firefox Relay (Mozilla, Free + Premium) / DuckDuckGo Email Protection (kostenlos) / Apple Hide My Email (iCloud+-Pflicht) | US-Konzern, potenziell CLOUD-Act-exponiert — Mitarbeiter-Empfehlung mit Transparenz-Hinweis | Mitarbeiter-Privatnutzung, Trennung von Firmen-Identität |
Praxisregel: Wenn der CLOUD-Act-relevante Datenfluss (E-Mail-Inhalt der Forwarding-Kette) Vertragsgegenstand mit Kunden ist — etwa bei Berufsgeheimnisträgern (Recht, Heilkunde, Steuer) oder im Behördenumfeld — fallen Pfad 4 (US-Konzerne) und in vielen Fällen auch Pfad 1 (US-Cloud-Provider trotz EU Data Boundary) aus. Konkret übrig bleiben dann Pfad 2 (Proton-Ökosystem) und Pfad 3 (Self-Hosted). Diese Auswahl-Matrix folgt derselben Logik wie die DACH-SEG-Auswahl-Matrix im Kapitel ARC & SEG — Eigentümer-Struktur ist relevanter als der bloße Rechenzentrumsstandort.
Privacy-Tooling-Realität 2026: Mozilla Privacy Not Included und EFF decken keine Alias-Dienste ab
Wer einen unabhängigen Privacy-Bericht zu den sechs Alias-Anbietern sucht, wird in den naheliegenden Quellen nicht fündig — und das ist eine substanzielle Faktenbeobachtung statt einer Lücke des Ratgebers. Eine direkte Live-Verifikation der zwei meistgenannten Privacy-Studien zum 24. Mai 2026 ergab folgenden ehrlichen Befund:
Negativ-Befunde der Live-Verifikation (analog R4-W2-mailhardener-ARC-Pattern)
| Studie / Tool | Status zu Email-Alias-Diensten | Quelle (WebFetch 24.5.2026) |
|---|---|---|
| Mozilla Privacy Not Included | Email-Alias-Dienste sind NICHT im Scope. Mozillas Verbraucher-Privacy-Guide deckt Smart Home, Cars, Dating Apps, AI Relationship Chatbots, Wearables, Health-Apps, Reproductive Health, Toys & Games und Entertainment ab. SimpleLogin, addy.io, Apple Hide My Email, Firefox Relay (eigenes Mozilla-Produkt!) und DuckDuckGo Email Protection tauchen nicht als bewertete Produkte auf. Letzte sichtbare Saison-Ausgabe: „Holiday Guide 2023“. | mozillafoundation.org/en/privacynotincluded |
| EFF Privacy | Email-Alias-Dienste sind ebenfalls NICHT im Scope. Die EFF-Privacy-Seite konzentriert sich auf „Online Behavioral Tracking“, „Anonymity“, „Do Not Track“ und „End-to-End Encryption“. Aktuelle 2026-Themen sind Instagram-Wegfall von E2E-DMs und RCS-Verschlüsselung bei Apple/Android — keine spezifische Bewertung von SimpleLogin/addy.io/Apple/Firefox/DuckDuckGo. | eff.org/issues/privacy |
| DuckDuckGo spreadprivacy.com | Letzter dedizierter Post zur Email Protection: August 2022 („DuckDuckGo Email Protection Beta Now Open to All“). Seither keine weiteren Email-Protection-Updates im Blog. Privacy-Quartalsberichte gibt es nicht. | spreadprivacy.com |
Konsequenz für die Alias-Strategie: Die übliche Heuristik „lies den letzten unabhängigen Privacy-Bericht und richte dich danach“ funktioniert für Alias-Dienste 2026 nicht. Stattdessen sind die direkten Anbieter-Quellen (Impressum, Pricing-Seite, Datenschutzerklärung) plus die offizielle Eigentums-Historie maßgeblich — exakt wie in der Souveränitäts-Auswahl-Matrix oben dargestellt. Wer auf einen externen Privacy-Bericht warten will, sollte sich auf die jährlichen Transparenzberichte der Mutter-Konzerne (Apple Transparency Report, Mozilla Lean Data Practices, Proton Annual Transparency Report) konzentrieren — die behandeln zwar nicht Alias-Dienste im Detail, aber die übergeordnete Rechtsbehörden-Anfrage-Statistik der Mutter-Konzerne.
Leak-Erkennungs-Datenbanken im Kontext: Have I Been Pwned (haveibeenpwned.com) bleibt die am breitesten verifizierte Free-Search-Quelle (Pwned Passwords kostenlos, Domain Search ab dem kostenpflichtigen Core-1-Tier). SpyCloud (Austin, Texas, USA — spycloud.com) bedient den Enterprise-Markt mit Workforce/Endpoint Threat Protection, Session Identity Protection, Cybercrime Investigations und Stealer-Log-Recapture — Preise nicht öffentlich, Anfrage-basiert. Dehashed (dehashed.com) ist eine Alternative-Leak-Search-Engine — Pricing-Seite ist Anfrage-geschützt, eine WebFetch-Verifikation am 24.5.2026 ergab HTTP 403 (gated). Für DACH-Unternehmen bleibt HIBP die zuverlässigste API-zugängliche Quelle.
Wie Wolf-Agents Alias-Hygiene als Sicherheits-Pattern bewertet
Der Wolf-Agents Email Security Check prüft eine Domain auf 165 Punkte — Alias-Hygiene ist Teil der DNS- und Empfangs-Konfigurations-Bewertung. Der Scanner erkennt charakteristische Patterns wie das Vorhandensein eines Catch-All-Postfachs (oft ein Spam-Magnet), Role-Mailboxes nach RFC 2142 (postmaster, abuse, hostmaster, webmaster) und MX-Routing-Pattern, die auf externe Alias-Anbieter wie Cloudflare Email Routing hinweisen. Die Alias-Strategie selbst (welche Service-Aliase intern vergeben werden) ist von außen unsichtbar — sie wird im Alias-Register Ihrer Organisation dokumentiert, nicht im DNS exponiert.
Was der Scanner konkret erkennt: Catch-All-Detection (Wildcard-Annahme aller Adressen ist oft ein Spam-Risiko), Role-Mailbox-Check (RFC 2142 — die fünf Standard-Adressen postmaster, abuse, hostmaster, info, webmaster), MX-Pattern-Matching für externe Alias-Dienste (z.B. route1-3.mx.cloudflare.net für Cloudflare Email Routing). Ehrliche Grenze: Welche Service-Aliase intern verwendet werden (z.B. hubspot-2026@firma.de), sieht ein externer Scanner nicht — das ist organisations-intern. Wolf-Agents weist diesen blinden Fleck transparent aus. Prüfen Sie Ihre Domain im Email Security Check. Cross-Verweis: DMARC (Alias-Forwarding und DMARC-Authentifizierung), ARC & SEG (ARC-Sealing bei Forwarding) und Spear-Phishing (Alias-Hygiene als Identitäts-Schutz).
RFC 2142 — der historische Anker der Wolf-Agents-USP für Alias-Strategien
Historischer Standard RFC 2142 'Mailbox Names for Common Services, Roles and Functions' von D. Crocker, IMC (Internet Mail Consortium), publiziert Mai 1997 als Proposed Standard. Definiert die Pflicht-Aliase postmaster/abuse/security/hostmaster/webmaster — Foundation für alle modernen Email-Security-Scanner einschließlich der Wolf-Agents 165-Punkte-Prüfung.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Alias, Forwarding, ARC und BIMI?
Vier verschiedene Konzepte, die häufig verwechselt werden. Ein Alias ist eine zusätzliche Adresse für ein bestehendes Postfach (Empfänger-Filter) oder eine Adresse für mehrere Postfächer (Verteiler) — die Mail bleibt im selben Postfach. Forwarding ist die MTA-Weiterleitung an ein externes Postfach (z.B. user@firma.com leitet weiter an user@gmail.com). ARC (Authenticated Received Chain, RFC 8617) ist die Authentifizierungs-Kette über Weiterleitungen hinweg — kein Alias, sondern Forwarding-Verifikation. BIMI (Brand Indicators for Message Identification) ist ein DNS-/SVG-/VMC-Setup für Marken-Logos im Empfänger-Client — kein MTA-Feature.
Was sind die wichtigsten dedizierten Alias-Anbieter und wem gehören sie?
Sechs relevante Anbieter im Markt 2026 — mit unterschiedlicher Eigentümer- und Souveränitäts-Struktur. SimpleLogin gehört seit 8. April 2022 zur Proton AG (Genf, Schweiz). addy.io (vorher AnonAddy) wurde am 9. August 2023 rebrandet und ist als Open Source self-hostable. Apple Hide My Email ist Teil von iCloud+ (Subscription-Pflicht, kein Free-Tier) und gehört Apple Inc., Cupertino. Firefox Relay ist ein Mozilla-Dienst (5 Aliase gratis, Premium mit unbegrenzten Aliasen und Custom-Domain). DuckDuckGo Email Protection (DuckDuckGo Inc., Paoli/Pennsylvania) ist seit Juli 2021 in Beta gestartet und kostenlos. Proton Pass-Email ist die in Proton Pass integrierte Hide-my-email-Funktion, separat von SimpleLogin im selben Proton-Ökosystem.
Welche Alias-Limits haben die großen Cloud-Provider?
Microsoft 365 Business und Enterprise (Exchange Online) erlauben bis zu 400 Aliase pro Postfach ohne Zusatzkosten (Microsoft-Doku, Stand 2026). Google Workspace erlaubt 30 Alternate Email Addresses pro Nutzer. Outlook.com-Consumer-Konten sind auf 10 Aliase begrenzt — das ist ein typischer Drift-Punkt zwischen Business- und Consumer-Tiers. Bei DACH-Hosting (IONOS, Strato, All-Inkl, Hetzner Webhosting, Netcup) hängen die Alias-Limits vom konkreten Tarif ab und zählen häufig gegen das Postfach-Kontingent.
Wie funktioniert Leak-Erkennung mit pro-Dienst-Aliasen?
Das Prinzip: Sie vergeben für jeden externen Dienst einen eigenen Alias — z.B. hubspot-2026@firma.de bei HubSpot, slack-2026@firma.de bei Slack. Erhalten Sie Spam oder Phishing an einen dieser Aliase von einem anderen Absender, wissen Sie mit Sicherheit, welcher Dienst Ihre Adresse weitergegeben oder verloren hat. Ergänzend prüfen Sie regelmäßig gegen die Datenbank haveibeenpwned.com, ob Ihre Domain in bekannten Breaches auftaucht — die HIBP API v3 hat Tiers Core, Pro und High RPM für automatisiertes Monitoring.
Erlaubt Cloudflare Email Routing Aliase? Wie verhält es sich mit ARC?
Ja — Cloudflare Email Routing ist ein kostenloser Alias- und Forwarding-Dienst für Custom-Domains. Eingehende Mail an beliebige Adressen Ihrer Domain wird an Ziel-Postfächer (Gmail, M365, Yahoo) weitergeleitet. Beim Weiterleiten erzeugt Cloudflare Email Routing einen eigenen ARC-Seal-Header und nutzt SRS (Sender Rewriting Scheme), damit DMARC die Weiterleitung übersteht. Die Cloudflare-Dokumentation verlangt, dass eingehende Mail entweder SPF besteht oder DKIM-signiert ist. ARC-Sealing ist seit 2024 dokumentiert — die früher gelegentlich verbreitete Aussage „Cloudflare Email Routing hat keinen ARC-Support“ ist veraltet.
Ist eine Alias-Strategie eine NIS2- oder DSGVO-Pflichtmaßnahme?
Eine Alias-Strategie ist überwiegend datenschutzrechtlich und sicherheitsorganisatorisch motiviert, nicht eine NIS2-Pflichtmaßnahme im engeren Sinne. DSGVO Art. 32 (technische und organisatorische Maßnahmen zur Sicherheit der Verarbeitung) erkennt Pseudonymisierung explizit als Schutzmaßnahme an — pro-Dienst-Aliase sind genau das. DSGVO Art. 17 (Recht auf Löschung) lässt sich über Alias-Deaktivierung sauber umsetzen. Für NIS2 ist eine Alias-Strategie kein expliziter Pflicht-Baustein — wenn dedizierte externe Alias-Anbieter eingesetzt werden, berührt Art. 21 Abs. 2 lit. d (Sicherheit der Lieferkette) deren Datenverarbeitungs-Kette.
Wann ist ein dedizierter Alias-Anbieter sinnvoller als native Provider-Aliase?
Native Aliase (Microsoft 365, Google Workspace, DACH-Hosting) sind für die meisten Unternehmensszenarien ausreichend — sie sind im Lizenzpreis enthalten, zentral verwaltbar und integrieren sich in die Mailbox-Berechtigungen. Dedizierte Privacy-Anbieter wie SimpleLogin oder addy.io bieten zusätzliche Mechanik: zufällig generierte Pseudonym-Adressen, automatische Adress-Rotation, anonyme Reply-Funktion (Forwarding mit Absender-Verschleierung), tiefere Trennung zwischen privater und beruflicher Identität. Sie sind sinnvoll für Mitarbeiter, die private Registrierungen klar von Firmenadressen trennen wollen, oder für besonders schutzbedürftige Identitäten (Journalisten, Berufsgeheimnisträger).
Alias-Strategie-Anleitung für Ihren Provider:
Wie steht Ihre Domain bei Alias-Strategie und Leak-Erkennung?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.