Eine sichere Domain macht nicht jede Nachricht sicher
SPF, DKIM und DMARC prüfen Domainberechtigungen und deren Zuordnung zu einer Nachricht. Sie können direkte Fälschungen einer Domain erschweren. Sie prüfen nicht, ob eine Rechnung berechtigt ist, ein Anhang Schadsoftware enthält oder ein echtes Konto inzwischen von einem Angreifer verwendet wird. Transportverschlüsselung wiederum schützt eine Verbindung und trifft keine solche Inhaltsentscheidung. RFC 9989 §§1, 2.2
Deshalb beginnen Sie mit einer konkreten Frage: Fehlen Nachrichten? Wird Ihre Domain gefälscht? Soll ein Newsletterdienst korrekt versenden? Geht es um vertrauliche Inhalte oder um ein verdächtiges Konto? Die Antwort bestimmt den Prüfweg. Ein und derselbe Gesamtpunktwert kann diese Fragen nicht ersetzen.
Welchen Weg eine E-Mail nimmt
- Verfassen: Eine Person oder Anwendung erstellt eine Nachricht mit sichtbarem
From, Empfängern, Betreff und Inhalt. - Einliefern: Der Mailclient oder Versanddienst übergibt sie an einen Einlieferungsserver. Dafür sind unter anderem Port 587 mit STARTTLS und Port 465 mit implizitem TLS vorgesehen; ein Webmailer oder eine API kann einen anderen internen Einstieg nutzen.
- Für den Versand vorbereiten: Das System setzt den SMTP-Rückpfad und kann die Nachricht mit DKIM signieren. Änderungen nach der Signatur können deren Prüfung scheitern lassen.
- Empfangsziel finden: Der sendende Mailserver ermittelt MX-Records der Empfängerdomain und versucht SMTP-Zustellung, üblicherweise auf Port 25. Weiterleitungen und Gateways können zusätzliche Hops erzeugen.
- Prüfen und entscheiden: Das empfangende System kann SPF, DKIM, DMARC, Reputation, Inhalte und lokale Regeln auswerten. Es entscheidet über Annahme, Ablehnung und weitere Behandlung.
- Bereitstellen: Eine angenommene Nachricht kann ins Postfach, in Spam oder eine andere Verarbeitung gelangen. Annahme beweist weder Posteingang noch Lesen. Nutzer greifen beispielsweise über Webmail oder IMAP darauf zu.
Quellen: RFC 5598, Internet Mail Architecture, RFC 5321, RFC 6409 §3.1, RFC 8314 §3.3.
Schematische Erklärung · keine Messung
Mailweg, DNS-Abfragen und Schutzgrenzen
Alice bei example.com schreibt an Bob bei example.net. Kontoschutz und Betriebsprozesse betreffen die beteiligten Konten während des gesamten Ablaufs.
Nachricht übertragen
- Client oder Anwendung
Alice erstellt die Nachricht.
-
Einlieferung
Einlieferungs- und VersandsystemDer Sender fragt MX und Transportregeln im DNS ab.
-
Servertransport; TLS gilt je Verbindung
Empfangender MXOptionale Weiterleitung oder Gateway fügt einen weiteren Hop und mögliche Änderungen hinzu.
Empfangen und entscheiden
- Authentifizierung und Filter
Der Empfänger prüft SPF und DKIM an Verbindung und Nachricht sowie DMARC-Alignment und Policy. Dafür fragt er auch DNS-Daten ab.
-
Ergebnisse und lokale Regeln auswerten
Ablehnung oder AnnahmeBei Annahme können weitere Filter und Verarbeitung folgen.
-
Nach weiterer Verarbeitung
Mögliche Bereitstellung im PostfachSMTP-Annahme ist noch kein Beleg für den Posteingang.
TLS endet an der jeweiligen Zwischenstation. Es gibt hier keinen durchgehenden TLS-Schutz von Autor zu Leser und kein Gesamtsicherheitssiegel.
Vollständige Beschreibung des Ablaufs
Alice bei example.com erstellt eine Nachricht für Bob bei example.net. Client oder Anwendung → Einlieferungs-/Versandsystem → empfangender MX → Empfängerprüfung → Postfach bilden den Hauptweg. DNS-Abfragen verzweigen vom Sender zu MX und Transportregeln sowie vom Empfänger zu SPF, DKIM und DMARC. Eine optionale Zwischenstation „Weiterleitung/Gateway“ zeigt einen zusätzlichen Transporthop und mögliche Änderungen. TLS liegt jeweils auf einer Verbindung; es gibt keinen durchgehenden TLS-Schutzbalken von Autor zu Leser. Am Empfang verzweigen die Entscheidungen in Ablehnung, Annahme mit weiterer Filterung und mögliche Bereitstellung. Ein Rahmen „Kontoschutz und Betriebsprozesse“ umfasst die beteiligten Konten, kein grünes Gesamtsiegel.
Sichtbare Adresse und technische Identität sind nicht dasselbe
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Angabe | Zweck | Häufiges Missverständnis |
|---|---|---|
| Anzeigename, etwa „Buchhaltung“ | Menschenlesbare Bezeichnung | Kann frei gewählt sein und beweist keine Person |
Domain im From | Sichtbare Absenderdomain; Bezugspunkt für DMARC | Muss nicht mit dem SMTP-Rückpfad identisch sein |
MAIL FROM / Rückpfad | SMTP-Identität für Rückmeldungen und den üblichen SPF-Pfad | Nach Zustellung oft als Return-Path sichtbar; kein sicherer Autorenname |
DKIM d= | Domain, die signiert hat | Ein Pass für irgendeinen Dienstleister ist nicht automatisch passend zum From |
| Verbindende IP | Server, der gerade einliefert | Kann ein Weiterleiter sein, nicht das ursprüngliche Versandsystem |
Für DMARC genügt ein erfolgreicher ausgerichteter SPF- oder DKIM-Pfad: Die dabei authentifizierte Domain muss nach dem gewählten Alignment-Modus zur From-Domain passen. Ein bloßes spf=pass oder dkim=pass ohne diesen Bezug reicht nicht. RFC 9989 §4.4
Vertrauen Sie bei der Diagnose nur den Authentication-Results Ihres vertrauenswürdigen Empfangssystems. Ein Angreifer kann ähnlich benannte Felder mitliefern; die Position allein beweist deren Herkunft nicht. Die genaue Einordnung erklärt Headerbefunde einordnen. RFC 8601 §5
Welche Maßnahme welche Frage beantwortet
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Maßnahme | Leistet | Leistet nicht |
|---|---|---|
| MX-Infrastruktur | Veröffentlicht Empfangsziele und Prioritäten | Beweist weder Versandberechtigung noch Ausfallsicherheit |
| SPF | Prüft, ob eine IP für die verwendete SMTP-Domain autorisiert ist | Authentifiziert nicht automatisch die sichtbare From-Domain oder den Inhalt |
| DKIM | Bindet signierte Nachrichtenteile an eine Signierdomain | Beweist keine wahre Aussage und keine ungefährlichen Anhänge |
| DMARC | Verbindet SPF/DKIM mit From-Alignment, Policy und Berichten | Verhindert keine ähnliche Domain, Anzeigenamentäuschung oder missbrauchte Konten |
| SMTP-TLS | Verschlüsselt einen Transporthop | Ist keine Ende-zu-Ende-Inhaltsverschlüsselung |
| MTA-STS / DANE | Können geeignete Sender zu TLS und passendem Servernachweis verpflichten | Erzwingen keine Verarbeitung bei jedem fremden Sender und keine Posteingangszustellung |
| DNSSEC | Authentifiziert DNS-Daten für validierende Nutzer | Verschlüsselt keine Mail und schützt nicht vor gültig signierten Fehlkonfigurationen |
| ARC | Übermittelt signierte Angaben beteiligter Zwischenstationen | Erzeugt nicht von selbst Vertrauen und repariert keine gebrochene Originalsignatur |
| BIMI | Ermöglicht optionale Markenanzeige nach Empfängerregeln | Ist kein allgemeiner Schutz- oder Zustellbeleg |
| Kontoschutz und Empfangsfilter | Begrenzen Zugangsmissbrauch und erkennen verdächtige Nachrichten | Einrichten allein belegt keine vollständige Wirkung |
| S/MIME oder OpenPGP | Können Inhalt verschlüsseln und signieren | Schutz hängt unter anderem von Schlüsselkontrolle, Endgeräten und tatsächlicher Verwendung ab |
| Organisatorische Freigaben | Prüfen etwa Änderungen von Zahlungsdaten über unabhängige Wege | Lassen sich durch keinen DNS-Record ersetzen |
TLS zwischen zwei Servern kann an jeder Zwischenstation enden. Dort verarbeiteter Klartext bleibt für diese Station zugänglich. Umgekehrt kann verschlüsselter Inhalt Metadaten und Endgeräte nicht pauschal absichern. Planen Sie nach dem tatsächlichen Schutzbedarf statt nach der Zahl aktivierter Kürzel.
Wer wofür zuständig ist
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Rolle | Typische Aufgabe | Benötigter Anschluss |
|---|---|---|
| Domainverantwortliche | Registrarzugang, DNS-Zuständigkeit, Senderinventar und Policy | Alle tatsächlichen Versanddienste und Delegationen kennen |
| DNS-Betreiber | Richtige Records, Signierung und Verfügbarkeit | Registrar/DS und fremde MX-Zonen berücksichtigen |
| Mail-/Versandanbieter | Signierung, Transport, Annahme und Kontofunktionen | Eigene Domainkonfiguration und realen Versand gemeinsam prüfen |
| Empfangsadministration | Filter, Authentifizierungsgrenze, Quarantäne und Meldungen | Gateways und Weiterleitungen richtig einbinden |
| Nutzer und Fachbereiche | Verdachtsfälle melden, Zahlungsänderungen unabhängig bestätigen | Erreichbarer Meldeweg, geeignete Anmeldung und klare Freigaben |
Ein DNS-Anbieter ist nicht automatisch Ihr Mailanbieter. Auch ein Postfachanbieter muss nicht jeden Newsletter-, CRM- oder Formularversand Ihrer Organisation kennen. RFC 5598 §§2, 4
In welcher Reihenfolge Sie vorgehen sollten
- Inventar und Zuständigkeiten: Domains, Subdomains, empfangende Systeme und alle versendenden Anwendungen erfassen. Auch seltene Rechnungs- oder Alarmmails berücksichtigen.
- Empfang und Konten prüfen: MX, tatsächlich genutzte Postfächer, administrative Zugriffe, starke Anmeldung und Wiederherstellungswege sichern. Kontoschutz nicht bis zum Ende eines DNS-Projekts verschieben.
- Versandwege authentifizieren: SPF-Autorisierung und DKIM pro Dienst einrichten; eigene Nachrichten beim Empfänger auf Ergebnisse und Alignment prüfen.
- DMARC beobachten: Berichtsziel betreuen, geeignete Beobachtungspolicy veröffentlichen und Berichte mit dem Inventar abgleichen. Der Domaincheck nimmt diese Berichte nicht entgegen.
- Policy bewusst wählen: Legitime Fehler schließen, Weiterleitungen und Mailinglisten bewerten, erst dann verschärfen.
p=rejectist kein zwingendes Ziel jeder allgemeinen Postfachdomain. Der neue DMARC-Standard RFC 9989 §7.4 nennt hierfür ausdrückliche Interoperabilitätsgrenzen. - Transport und DNS härten: MTA-STS/TLS-RPT oder DANE nach tatsächlicher Unterstützung planen, DNSSEC und Zertifikatswechsel koordinieren. Fehler können Zustellung verzögern oder verhindern.
- Betrieb fortsetzen: Neue Versanddienste vor dem Start einbinden, Berichte und Konten kontrollieren, verwaiste DNS-Verweise entfernen, Reaktions- und Wiederherstellungswege üben.
DMARC-Enforcement beschreibt die Policyumstellung. Alias-Strategie hilft beim gezielten Verteilen und Austauschen von Adressen. Compliance und Dokumentation ordnet den technischen Beitrag in organisatorische und rechtliche Anforderungen ein.
Domains, die weder senden noch empfangen sollen
Nur wenn tatsächlich kein Dienst mit der Domain sendet und kein Empfang benötigt wird, kommt die folgende Kombination in Betracht. Das Beispiel ist erfunden und nicht veröffentlicht:
example.net. IN MX 0 .
example.net. IN TXT "v=spf1 -all"
_dmarc.example.net. IN TXT "v=DMARC1; p=reject"Null MX erklärt den fehlenden Empfang, SPF -all autorisiert keinen Versandserver, DMARC fordert eine Behandlung von Fehlschlägen an. Diese Aufgaben sind getrennt. Ein eigener DMARC-Record kann außerdem auf Subdomains wirken; vorhandenen Versand dort vorher prüfen. Null MX darf nicht neben normalen MX-Records stehen. Ein Webserver unter derselben Domain ist dadurch nicht verboten. RFC 7505 §§3–4, RFC 7208 §10.1.2
Warum die Absenderprüfung allein nicht genügt
Eine gefälschte exakte Domain ist ein anderer Fall als eine ähnlich geschriebene Domain oder ein echtes übernommenes Konto. Auch QR-Codes, Kalendereinladungen und Anhänge benötigen Inhalts- und Verhaltensprüfung. Das Kapitel E-Mail-Bedrohungen ordnet diese Mechanismen, ihre Schutzgrenzen und sinnvolle Schritte bei Verdacht ein. Die dort verlinkten Lageberichte beschreiben jeweils begrenzte Erhebungen; daraus folgt keine persönliche Angriffsquote.
Der passende Einstieg für Ihre Aufgabe
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Ausgangsfrage | Einstieg |
|---|---|
| Wir richten eine eigene Domain ein. | MX, dann SPF/DKIM, DMARC und Transport nach obiger Reihenfolge |
| Ein Dienst versendet nicht zuverlässig. | Headerbefunde einordnen, Bounces und konkreten Dienst prüfen |
| Unsere Domain wird imitiert. | Spoofing, DMARC-Grenzen und Kontoschutz unterscheiden |
| Wir planen ein Gateway oder eine Weiterleitung. | ARC und Gateways, danach betroffene Transport- und Absenderwege testen |
| Wir brauchen belastbare organisatorische Nachweise. | Compliance und datierte Konfigurations-/Betriebsbelege |
Für die DKIM-Einrichtung gibt es gezielte Anleitungen: allgemeiner Ablauf, Google Workspace und Microsoft 365. Wählen Sie nach Ihrem tatsächlichen Versandweg.
Was der E-Mail Security Check tatsächlich untersucht
Der E-Mail Security Check untersucht öffentlich erreichbare Konfiguration und begrenzte Transportmerkmale als Momentaufnahme. Er ist keine Untersuchung einer empfangenen Nachricht.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Messweg | Aussagegrenze |
|---|---|
| SPF und DMARC aus DNS | Veröffentlichte Autorisierung/Policy, kein SPF-/DMARC-Erfolg echter Nachrichten |
| DKIM-Selektorsuche | Treffer unter begrenzt gesuchten Namen; freie andere Selektoren können fehlen, keine Signaturprüfung |
| SMTP | Bis zu drei gleich bevorzugte primäre MX-Ziele; EHLO, STARTTLS/TLS und QUIT, kein MAIL/RCPT/DATA |
| Messstandort und Cache | Primär-/Fallback-Probe liefert ein ausgewähltes vollständiges Ergebnis, keinen systematischen Standortvergleich; Messzeit und Cache beachten |
| MTA-STS | DNS-Hinweis, begrenzter HTTPS-Abruf und Parser-/MX-Abgleich; kein Nachweis aller Sendercaches oder realer Durchsetzung |
| TLS-RPT | Veröffentlichte Berichtsziele; keine Erzeugung, Annahme, Auswertung oder Alarmierung bestätigt |
| DNSSEC / DANE | Begrenzte Resolver-/TLSA-Befunde; keine vollständige eigene DNSSEC-Ketten- oder DANE-Zertifikatsprüfung |
| ARC, Gateway, BIMI | Ungewichtete Namens-/DNS-Hinweise, keine Filterwirkung, Kettenprüfung oder Logoanzeige |
Inhalte, Anhänge, QR-Codes, Anmeldesicherheit, Weiterleitungsregeln und DMARC-XML-Berichte werden hier nicht analysiert. Der Check betreibt keine laufende Überwachung Ihrer Domain. Ergebnisse und Produktgewichtung müssen im Kontext der erhobenen Daten gelesen werden; eine feste Laufzeit oder Punktzahl ist kein Sicherheitsversprechen. Details: Prüfumfang.
Häufige Fragen
Reichen SPF, DKIM und DMARC gegen Phishing?
Sie begrenzen bestimmte Domainfälschungen. Ähnliche Domains, Anzeigenamen, schädliche Inhalte und missbrauchte echte Konten bleiben eigene Risiken.
Ist TLS Ende-zu-Ende-Verschlüsselung?
Nein. Es schützt einzelne Verbindungen. Zwischenstationen können Nachrichten im Klartext verarbeiten; Inhaltsverschlüsselung hat andere Voraussetzungen.
Braucht jede Domain einen Mailserver?
Nein. Eine Domain ohne Mailbedarf kann das mit passenden Records erklären. Prüfen Sie vorher Formularmailer, Rückmeldungen und Subdomains.
Soll ich sofort p=reject setzen?
Nein. Erst Versandwege und Auswirkungen prüfen. Quarantine kann für allgemeine Postfachdomains passend sein; die Norm rät dort wegen indirekter Wege von einem pauschalen Reject-Ziel ab.
Kann ein DNS-Check die Echtheit einer Nachricht bestätigen?
Nein. Dazu braucht es die Nachricht und vertrauenswürdige Prüfung an ihrem Empfangsweg. Auch ein authentifizierter Domainbezug bestätigt nicht die Harmlosigkeit des Inhalts.
Beweist ein gutes Ergebnis Compliance?
Nein. Geltungsbereich, tatsächlicher Betrieb, Organisation und Dokumentation müssen gesondert beurteilt werden.
Quellen und Normstand
Stand 27. September 2026: RFC 5321 ist der veröffentlichte SMTP-Standard dieses Bezugs; sein Nachfolgeentwurf rfc5321bis befindet sich im RFC-Editor-Verfahren und ist kein bereits veröffentlichter Ersatz. DMARC steht in RFC 9989, Aggregate Reporting in RFC 9990 und Failure Reporting in RFC 9991. ARC nach RFC 8617 bleibt Experimental; der Historic-Vorschlag ist ein Entwurf. BIMI ist ebenfalls noch kein RFC.
Primärquellen: SMTP-Status, rfc5321bis, DMARC, Aggregatberichte, Failure Reports, ARC. Die verlinkten Fachkapitel erläutern die jeweiligen Bedingungen ausführlicher.
Zurück zum E-Mail-Security-Hub; als nächster technischer Einstieg: MX-Infrastruktur.