Warum die sichtbare Adresse gefälscht werden kann
E-Mail wurde in einer Umgebung konzipiert, in der die angezeigte Identität nicht immer streng geprüft wurde. Betrügende können daher versuchen, den Domainnamen eines Unternehmens im für die Empfängerin bzw. den Empfänger sichtbaren Feld zu nutzen, insbesondere für Chef-Betrug oder eine gefälschte Änderung der Bankverbindung.
Domain-Authentifizierungsmechanismen beweisen nicht die menschliche Identität der Absenderin bzw. des Absenders und blockieren nicht jede Nachahmung. Sie erlauben es jedoch den empfangenden Servern einzuschätzen, ob die Domain-Nutzung den von ihrem Inhaber veröffentlichten Regeln entspricht.
SPF: autorisierte Server deklarieren
SPF nutzt einen DNS-Eintrag, um anzugeben, welche Server berechtigt sind, Nachrichten für eine im SMTP-Umschlag genutzte Domain zu versenden. Das Ergebnis hängt insbesondere von der IP-Adresse des sendenden Servers und der geprüften Domain ab.
Ein Unternehmen muss seine Mailbox, sein Rechnungstool, seine Marketing-Plattformen, seinen Support und alle Dienstleister erfassen, die Nachrichten versenden. Zu viele SPF-Einträge oder das Überschreiten bestimmter DNS-Auflösungsgrenzen kann Fehler verursachen; die Konfiguration muss daher konsolidiert und getestet werden.
DKIM: Nachrichten mit einem domaingebundenen Schlüssel signieren
DKIM fügt der Nachricht eine kryptografische Signatur hinzu. Der empfangende Server ruft den im DNS veröffentlichten öffentlichen Schlüssel ab und prüft, ob die signierten Elemente seit der Signatur nicht verändert wurden. Die signierende Domain kann dann mit der Nachricht verknüpft werden.
Die Verwaltung umfasst die Erstellung von Selektoren, Schlüsselrotation, Aktivierung bei jeder Absenderin bzw. jedem Absender und die Prüfung tatsächlicher Nachrichten. Eine gültige Signatur bedeutet nicht, dass der Inhalt legitim ist; sie zeigt, dass die Nachricht von einer Infrastruktur mit dem entsprechenden Schlüssel signiert wurde.
DMARC: ausrichten, eine Richtlinie veröffentlichen und Berichte erhalten
DMARC bewertet die Übereinstimmung zwischen der im From-Feld sichtbaren Domain und den durch SPF oder DKIM validierten Domains. Der Inhaber veröffentlicht eine DNS-Richtlinie, die je nach Protokollregeln und Entscheidung der Empfängerseite eine bloße Beobachtung, eine Quarantäne oder eine Ablehnung fehlgeschlagener Nachrichten verlangen kann.
Aggregierte Berichte helfen, legitime Quellen, Konfigurationsfehler und unbefugte Nutzungen zu identifizieren. Die DMARC-Spezifikationen wurden im Mai 2026 mit den RFCs 9989, 9990 und 9991 aktualisiert, die das frühere Basisdokument RFC 7489 ersetzen.
Mit einer Beobachtungsrichtlinie beginnen
Direkt zu einer Ablehnungsrichtlinie überzugehen kann legitime Nachrichten eines vergessenen Dienstes blockieren. Die Einführung beginnt üblicherweise mit der Bestandsaufnahme, der Aktivierung von SPF und DKIM, dann einer DMARC-Beobachtungsrichtlinie mit Berichten.
Berichte müssen über einen repräsentativen Zeitraum analysiert werden, der Kampagnen, Rechnungsstellung und gelegentliche Versendungen einschließt. Nicht konforme Dienste müssen korrigiert, ersetzt oder auf einer Subdomain isoliert werden, bevor die Richtlinie schrittweise verschärft wird.
Subdomains und Drittanbieterdienste berücksichtigen
Das Unternehmen muss entscheiden, welche Subdomains für Transaktions-E-Mails, Marketing oder interne Werkzeuge genutzt werden. Diese Trennung kann die Auswirkung eines Fehlers begrenzen und die Dienstleisterverwaltung erleichtern.
Jeder Drittanbieterdienst muss Umschlag-Domains, DKIM-Signaturen, Schlüssel, Berichtsadressen und Änderungsverfahren dokumentieren. Die Beendigung eines Dienstleisters muss den Entzug seiner DNS-Berechtigungen einschließen.
Die Grenzen dieser Mechanismen verstehen
SPF, DKIM und DMARC blockieren keine optisch ähnliche Domain, kein tatsächlich kompromittiertes Konto und keinen Betrug von einer legitimen Adresse aus. Sie sollten mit MFA, Kontoschutz, Zahlungsvalidierungsverfahren und Sensibilisierung kombiniert werden.
Die Überwachung der Berichte ersetzt auch nicht die Analyse von Mailbox-Warnmeldungen. Ziel ist es, direkte Domain-Usurpation zu verringern und Sichtbarkeit zu verbessern, nicht die Mailbox für unverwundbar zu erklären.
Ihre Situation sachlich darstellen
Beschreiben Sie Ihre Umgebung, Prioritäten und Schwierigkeiten, ohne Passwörter oder sensible Daten zu übermitteln. Mit Ihrer Zustimmung können Ihre Kontaktdaten an einen unabhängigen Partner weitergegeben werden, der allein für seine Analyse, seine Preise und seine Leistungen verantwortlich bleibt.
Zum FormularHäufige Fragen
Müssen SPF, DKIM und DMARC zusammen eingeführt werden?
Sie erfüllen ergänzende Rollen. DMARC stützt sich auf die Ausrichtung von SPF oder DKIM; die koordinierte Einführung aller drei bietet bessere Kontrolle über die Domain.
Kann man sofort zu p=reject übergehen?
Das ist riskant, wenn nicht alle legitimen Absender erfasst und ausgerichtet sind. Eine Beobachtungs- und Berichtsanalysephase ist in der Regel notwendig.
Verhindert DMARC jeden Bankverbindung-Betrug?
Nein. Es verringert bestimmte Szenarien direkter Domain-Usurpation, blockiert aber keine ähnlich klingenden Domains oder tatsächlich kompromittierten Konten.
Wer sollte DMARC-Berichte verwalten?
Eine Person oder ein Dienstleister sollte benannt werden, um sie zu sammeln, zu interpretieren und nicht konforme legitime Quellen zu korrigieren. Ohne Auswertung bringen Berichte wenig Wert.
Konsultierte offizielle Quellen
- IETF — RFC 7208, Sender Policy Framework
- IETF — RFC 6376, DKIM Signatures
- IETF — RFC 9989, DMARC
- IETF — RFC 9990, aggregierte DMARC-Berichte
- IETF — RFC 9991, DMARC-Fehlerberichte
Quellen geprüft am 24. August 2026. Genannte Organisationen und Spezifikationen können aktualisiert werden.
Verwandte Ratgeber
Diese Seite ersetzt weder ein Audit noch eine technische Analyse noch eine Rechtsberatung. Etwaige Entscheidungen und Eingriffe obliegen kompetenten Fachpersonen.