E-Mail-Sicherheit für SaaS: SPF, DKIM, DMARC und sichere Versandprozesse

SPF legt erlaubte Versandwege fest

Ein SPF-TXT-Eintrag beschreibt, welche Server im Namen deiner Domain senden dürfen. Führe die Einträge aller legitimen Dienste in einer einzigen, überschaubaren Richtlinie zusammen. Mehrere SPF-TXT-Einträge sind kein Ersatz für eine gemeinsame Policy. Halte die Liste klein, entferne alte Includes und dokumentiere, welcher Dienst welchen Eintrag benötigt. Zu viele DNS-Abfragen können die Prüfung scheitern lassen. Ein SoftFail oder HardFail entscheidet nicht allein über die Zustellung, sondern wird zusammen mit DKIM und DMARC bewertet.

Verwende für jede Versandquelle eine klare Zuständigkeit. Wenn dein Produktdienst, ein Supportsystem und ein Newsletterwerkzeug dieselbe Organisationsdomain nutzen, muss die Regel alle legitimen Quellen abdecken. Besser ist oft eine eigene Subdomain für eine Quelle, damit ein Wechsel nicht die gesamte Hauptdomain betrifft. Nach jeder Änderung prüfst du eine echte Testnachricht bei mehreren Empfängerdiensten und kontrollierst, ob die sichtbare Absenderadresse zur geplanten Domain passt.

DKIM macht Nachrichten nachvollziehbar

DKIM signiert ausgewählte Header und den Inhalt einer Nachricht mit einem privaten Schlüssel. Der öffentliche Schlüssel liegt als DNS-Eintrag unter einem Selector. Dein Versanddienst verwaltet den privaten Teil; du veröffentlichst nur den öffentlichen Schlüssel. Verwende unterschiedliche Selector für Umgebungen oder Dienste, wenn die Verwaltung dadurch klarer wird. Ein geplanter Schlüsseltausch braucht zwei kurze Übergangsphasen: den neuen öffentlichen Eintrag veröffentlichen, danach die Signatur umstellen und den alten Eintrag erst entfernen, wenn keine alten Nachrichten mehr geprüft werden müssen.

Kontrolliere, ob wirklich jede wichtige Nachricht signiert wird und ob die DKIM-Domain zur sichtbaren From-Domain ausgerichtet ist. Weiterleitungen können SPF verändern, während DKIM oft erhalten bleibt. Ein Signaturfehler darf nicht einfach als Zustellproblem abgetan werden: Er kann auf eine nachträgliche Änderung, einen falsch konfigurierten Dienst oder einen kompromittierten Zugang hinweisen.

DMARC in drei Policy-Stufen

DMARC verbindet SPF und DKIM mit einer Entscheidung für Nachrichten, die weder SPF noch DKIM erfolgreich und ausgerichtet bestehen. p=none lässt die Zustellung grundsätzlich zu und dient dem Beobachten. Reports zeigen, welche Quellen deine Domain verwenden. p=quarantine bittet Empfängerserver, fehlgeschlagene Nachrichten wie verdächtige Post zu behandeln, häufig durch einen Spamordner. p=reject fordert die Ablehnung. Der Wechsel sollte schrittweise erfolgen, damit vergessene SaaS-Integrationen nicht plötzlich wichtige Produktmails verlieren.

Setze rua für aggregierte Reports und, falls benötigt, ruf für forensische Meldungen bewusst ein. Verwende eine Adresse, deren Zugriff geschützt und deren Datenvolumen beherrschbar ist. Prüfe die Reports auf unbekannte IPs, veraltete SPF-Includes, DKIM-Fehler und Absender, die eine andere Domain ausrichten. Definiere außerdem eine Subdomain-Policy, wenn Unterdomains eigene Regeln haben. Dokumentiere, wer Änderungen freigibt und wann eine Policy-Stufe angehoben werden darf.

Alignment nicht übersehen

Bei relaxed Alignment genügt in der Regel dieselbe Organisationsdomain; bei strict Alignment müssen die Domains exakt übereinstimmen. Entscheide dich nicht nur nach dem Namen des Versanddienstes, sondern nach dem tatsächlichen Header-Aufbau. Ein Dienst kann SPF mit einer eigenen Return-Path-Domain bestehen lassen, während DKIM mit deiner Subdomain ausgerichtet ist. Für DMARC reicht dann die ausgerichtete DKIM-Prüfung. Teste From, Return-Path und DKIM-d in einer Nachricht und halte das Ergebnis für jede Domain schriftlich fest.

BIMI verständlich einordnen

BIMI kann bei unterstützenden Postfächern ein Markenlogo neben einer Nachricht anzeigen. Dafür veröffentlichst du einen BIMI-DNS-Eintrag, der auf eine passende SVG-Datei verweist. Die sichtbare Darstellung hängt vom Empfängerdienst ab und ersetzt keine Authentifizierung. Eine strenge DMARC-Policy, ein korrektes Logo und je nach Postfach zusätzliche Nachweise können erforderlich sein. Behandle BIMI daher als sichtbare Ergänzung nach der DMARC-Einführung. Das Logo sollte keine privaten Daten enthalten und über eine kontrollierte, dauerhaft erreichbare Adresse ausgeliefert werden.

MTA-STS und TLS-RPT kurz erklärt

MTA-STS beschreibt für empfangende Mailserver, ob sie eine verschlüsselte TLS-Verbindung verlangen und wie sie bei einem fehlenden Zertifikat reagieren sollen. TLS-RPT sammelt Berichte über fehlgeschlagene TLS-Verbindungen. Beide Verfahren schützen den Transportweg zwischen Mailservern; sie bestätigen nicht, dass der Absender fachlich berechtigt war. Prüfe, ob dein Domainbetrieb die Richtlinien, das Zertifikat und die Reportadresse zuverlässig pflegen kann. Ein veralteter MTA-STS-Modus kann legitime Zustellung verhindern, deshalb gehören Monitoring und ein dokumentierter Rollback dazu.

Phishing im Namen deiner Marke erschweren

Angreifer können eine bekannte Marke in der sichtbaren Absenderzeile nachahmen oder eine ähnlich geschriebene Domain registrieren. SPF, DKIM und DMARC erschweren das direkte Spoofing deiner Domain, verhindern aber keine Lookalike-Domain. Verwende konsistente Absendernamen, verlinke sensible Aktionen auf deine echte Produktdomain und erkläre Supportteams, wie gefälschte Nachrichten gemeldet werden. Eine Passwortmail sollte niemals das Passwort selbst enthalten. Bei Rechnungen und Zahlungsänderungen führt der Link in eine geschützte Sitzung, in der die Person die Domain und den Vorgang prüfen kann.

Transaktionale und Marketingmails trennen

Nutze unterschiedliche Subdomains, Streams oder Projekte für Passwort-Resets, Rechnungen und Sicherheitsmeldungen einerseits sowie Newsletter und Kampagnen andererseits. Lege pro Weg eigene DKIM-Selector, DMARC-Ausnahmen und Verantwortliche fest. Eine Marketingabmeldung darf nicht automatisch eine notwendige Konto- oder Sicherheitsnachricht blockieren; die Anwendung muss den Zweck jeder Nachricht kennen. Auch Vorlagen, Empfängerlisten und Webhooks sollten getrennte Namensräume haben. So ist nachvollziehbar, welcher Prozess eine Adresse sperrt und welcher nur einen redaktionellen Versand beendet.

API-Keys nach Least Privilege

Erzeuge Schlüssel mit der kleinsten erforderlichen Berechtigung: Ein Dienst, der nur senden muss, braucht keinen Zugriff auf Empfängerexporte, DNS-Einstellungen oder Abrechnung. Trenne Schlüssel für lokale Entwicklung, Staging und Produktion. Speichere sie in einem Secret Store, maskiere sie in Logs und verhindere, dass sie in Frontend-Code oder Fehlermeldungen auftauchen. Plane Rotation als wiederkehrenden Prozess. Ein neuer Schlüssel wird getestet, danach wird der alte widerrufen. 2FA oder SSO für das Anbieter-Konto schützt zusätzlich die Personen, die Projekte, Domains und Rollen verwalten.

Webhook-Signaturen prüfen

Ein Webhook-Endpunkt ist eine Eingangsfläche in deiner Anwendung. Prüfe die Signatur über den unveränderten Request-Body und einen geheimen Schlüssel, bevor du Daten akzeptierst. Schütze dich gegen Replay-Angriffe mit Zeitstempel oder einer gespeicherten Ereignis-ID. Schreibe das authentifizierte Ereignis zuerst in eine dauerhafte Warteschlange und antworte erst dann erfolgreich. Der Worker verarbeitet es idempotent: Ein mehrfach zugestelltes Bounce-Ereignis darf keine widersprüchlichen Zustände erzeugen. Überwache fehlende, verspätete und fehlerhafte Ereignisse genauso wie erfolgreiche Zustellungen.

Sensible Daten gehören hinter einen Login

Eine E-Mail ist kein vertraulicher Datenspeicher. Vermeide vollständige Rechnungsadressen, interne Notizen, Tokens mit langer Gültigkeit und Zahlungsdaten im Klartext. Baue kurze, einmal nutzbare Links zu einer HTTPS-Seite, deren Session zusätzliche Prüfungen verlangen kann. Beschränke Vorschautext und Betreff auf das Nötige. Auch Empfängeradressen, IPs und Message-IDs sind personenbezogene Daten, wenn sie sich einer Person zuordnen lassen. Maskiere sie in Entwicklungslogs und teile Supportauszüge nur mit den Personen, die sie brauchen.

Ein brauchbares Versandprotokoll enthält interne Vorgangs-ID, Provider-ID, Domain, Template-Version, Status, Zeitpunkte und Fehlerklasse. Speichere nicht automatisch den gesamten HTML-Body. Trenne Diagnosemetadaten von Inhalten und begrenze Zugriffe nach Rolle. Kurze Provider-Fristen können für Support zu knapp sein; exportiere dann ausgewählte Statusereignisse in dein eigenes Monitoring. Lange Fristen erhöhen dagegen das Datenschutzrisiko. Lege Löschjobs, Backups und Wiederherstellungen gemeinsam fest, damit gelöschte Daten nicht unbegrenzt in einer Kopie bleiben.

Für die DSGVO prüfst du, welche Daten dein Versanddienst im Auftrag verarbeitet und welche an Unterauftragsverarbeiter weitergegeben werden. Ein AV-Vertrag sollte Zuständigkeiten, Sicherheitsmaßnahmen, Löschung und Unterstützung bei Betroffenenrechten abbilden. Frage nach Speicherregionen, Supportzugriffen, Sicherungen und möglichen Übermittlungen außerhalb des EWR. Dokumentiere deine Rechtsgrundlage für notwendige Produktmails und Marketingnachrichten getrennt. Prüfe außerdem Trackingpixel, Klickmessung und Abmeldelinks: Sie können zusätzliche Zwecke und Einwilligungen auslösen.

Vor dem Produktstart erstellst du eine Datenflusskarte: Von welchem Ereignis kommen Empfängeradresse und Inhalt, welcher Dienst verarbeitet sie, wohin gehen Webhooks und wann werden Logs gelöscht? Ergänze Verantwortliche, Notfallkontakt und einen Testfall für kompromittierte Schlüssel. Diese Karte hilft bei Anbieterwechseln und bei Auskunftsanfragen, weil du nicht erst im Quellcode suchen musst.