Domainkonfiguration, Transport und Nachricht auseinanderhalten
Beginnen Sie mit dem Gegenstand Ihrer Frage. „E-Mail sicher“ kann bedeuten, die eigene Absenderdomain abzusichern, eine verschlüsselte Verbindung zu verlangen oder eine verdächtige Nachricht zu beurteilen. Ein einzelner DNS-Befund beantwortet diese Fragen nicht gemeinsam.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Ihre Frage | Passender Beleg | Was dadurch offenbleibt |
|---|---|---|
| Welche Regeln und Schlüssel veröffentlicht meine Domain? | DNS-Einträge und veröffentlichte Policies, jeweils mit Name und Zeitpunkt | Ob jeder Versanddienst richtig eingerichtet ist und tatsächlich gültige Nachrichtensignaturen erzeugt |
| Wie ist der Empfang und Transport eingerichtet? | Tatsächliche MX-Ziele, passende Transportpolicy und Beobachtungen des bezeichneten Verbindungswegs | Andere Server, Verbindungen und der komplette Weg einer Nachricht |
| Was ist bei dieser einen Nachricht angekommen? | Originalheader, konkrete Versandidentitäten und Prüfergebnisse des vertrauenswürdigen empfangenden Systems | Andere Versandwege, andere Nachrichten und die spätere Behandlung durch andere Empfänger |
Die Prüfung, ob eine einzelne E-Mail-Adresse existiert, ist wiederum eine andere Aufgabe. Ebenso sind Spamfiltertests, die Prüfung von Anhängen und eine allgemeine Zustellbarkeitsanalyse kein Ergebnis eines Domainchecks.
SPF, DKIM und DMARC: den passenden Einstieg wählen
Diese drei Verfahren helfen, die Nutzung von Domains beim Versand einzuordnen. Sie verschlüsseln den Nachrichteninhalt nicht und bestätigen keine persönliche Identität.
Grundlagen nach Ihrer konkreten Frage.
-
… welche Server für eine Versanddomain senden dürfen
- Die kurze Einordnung
- SPF prüft die sendende IP anhand der veröffentlichten Regeln für die SMTP-Absenderdomain beziehungsweise die HELO-Identität. Das ist nicht automatisch die sichtbare From-Domain.
- Weiterführender Ratgeber
- SPF: Versandregeln und Auswertung verstehen
-
… ob eine Nachricht eine gültige Domainsignatur trägt
- Die kurze Einordnung
- DKIM prüft eine Signatur über die signierten Nachrichtenteile. Signierdomain und Selektor führen zum passenden öffentlichen Schlüssel. Dessen Veröffentlichung allein beweist keine gültige Nachrichtensignatur.
- Weiterführender Ratgeber
- DKIM: Signierdomain, Selektor und Signatur
-
… wie diese Ergebnisse zur sichtbaren Absenderdomain passen
- Die kurze Einordnung
- Für einen DMARC-Pass muss mindestens eine erfolgreiche Prüfung zur sichtbaren From-Domain ausgerichtet sein: SPF für die
MAIL FROM-Identität oder DKIM. Dieses Verhältnis heißt Alignment. Der Domaininhaber veröffentlicht außerdem eine gewünschte Behandlung für Nachrichten, die DMARC nicht bestehen. - Weiterführender Ratgeber
- DMARC: Alignment, Policy und Berichte
Bei leerem SMTP-Rückpfad wird die MAIL FROM-Identität für SPF aus dem lokalen Namen postmaster und der HELO-Domain gebildet. Ein eigenständiger HELO-Pass ist keine zusätzliche Alternative für DMARC. RFC 9989, Abschnitt 3.2.4.
Die Verfahren und ihre Grenzen sind in RFC 7208, RFC 6376 und dem aktuellen DMARC-Standard RFC 9989 beschrieben. Ein Authentifizierungs-Pass garantiert weder einen harmlosen Inhalt noch die Zustellung in den Posteingang. Empfangende Dienste berücksichtigen weitere Regeln.
Wenn ein Scan einen fehlenden oder unklaren DKIM-Befund zeigt, klären Sie zuerst den tatsächlichen Selektor Ihres Versanddienstes. Eine begrenzte Suche nach bekannten Selektoren kann einen vorhandenen Schlüssel übersehen. Soll die DMARC-Policy strenger werden, prüfen Sie vorher die legitimen Versandwege und deren tatsächliches Alignment. Ein veröffentlichtes p=reject ersetzt diese Arbeit nicht.
Wer muss welche Einstellung ändern?
Ein Postfachanbieter, ein Newsletterdienst und eine Website können für dieselbe sichtbare Absenderdomain verschiedene Versandwege verwenden. Auch Domainregistrierung und DNS-Verwaltung können bei unterschiedlichen Anbietern liegen. Der MX-Eintrag für den Empfang nennt deshalb nicht zuverlässig den Dienst, der ausgehende Nachrichten signiert.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Rolle | Worum sie sich kümmert | Was Sie für die nächste Handlung brauchen |
|---|---|---|
| Domaininhaber oder verantwortliche IT | Gewünschte Domainnutzung, legitime Versanddienste und Policyentscheidungen | Ein Verzeichnis der tatsächlich genutzten Versandwege, einschließlich Newsletter und automatischer Nachrichten |
| DNS-Verwalter | Die zuständige Zone und die vom jeweiligen Dienst benötigten Einträge | Vollständiger Name, Recordtyp und Wert aus der passenden Dienstkonfiguration |
| Versanddienst oder dessen Administration | Signierdomain, Schlüssel, Selektor und aktivierte Signierung | Die eigene Domainkonfiguration dieses Dienstes; Beispielwerte einer fremden Domain genügen nicht |
| Betreiber des empfangenden Systems | Authentifizierungsprüfung, Annahme und weitere Filterentscheidungen | Einen nachvollziehbaren Befund am tatsächlichen Empfangsweg |
Übernehmen Sie für zusätzliche Versanddienste deren konkrete Vorgaben. Ein pauschaler weiterer SPF-Record oder ein beliebiger DKIM-Schlüssel löst die Einrichtung nicht. Stimmen Sie die SPF-Regel auf die tatsächlich autorisierten Versandwege ab. Bei DKIM müssen DNS-Wert und tatsächlich verwendeter Signierer zusammengehören. Die allgemeine DKIM-Anleitung führt diese Angaben zusammen.
Einrichtungshilfe für Ihren Versanddienst
Wählen Sie eine Anleitung für das konkrete Verfahren. Ein privates Gmail- oder Outlook.com-Postfach ist kein Verwaltungszugang für eine eigene Google-Workspace- oder Microsoft-365-Domain.
DKIM einrichten: allgemeiner Ablauf und zwei konkrete Dienstwege.
-
Signierer, Selektor oder DNS-Zuständigkeit sind noch unklar
- Passende Anleitung
- DKIM allgemein einrichten
- Worauf Sie dabei achten
- Zuständigkeiten klären, Record veröffentlichen, Signierung aktivieren und eine Nachricht getrennt prüfen
-
Gmail versendet für Ihre eigene Workspace-Domain
- Passende Anleitung
- DKIM in Google Workspace einrichten
- Worauf Sie dabei achten
- Den Wert der gewählten Domain veröffentlichen und die Signierung im Dienst aktivieren
-
Exchange Online versendet für Ihre eigene Domain
- Passende Anleitung
- DKIM in Microsoft 365 einrichten
- Worauf Sie dabei achten
- Die beiden tatsächlich vorgegebenen CNAME-Ziele verwenden und den Signierstatus prüfen
Die Hersteller beschreiben Veröffentlichung und Aktivierung als getrennte Schritte: Google Workspace: DKIM einrichten und Microsoft 365: DKIM für eigene Domains. Nutzen Sie die Werte Ihrer Umgebung. Eine Anleitung ist kein Nachweis, dass die Einrichtung bei Ihnen erfolgreich war.
Empfang und Transport: MX, SMTP-TLS und MTA-STS
MX-Einträge nennen die Mailserver für den Empfang einer Domain. TLS kann eine SMTP-Verbindung verschlüsseln. Mit MTA-STS veröffentlicht die empfangende Domain zusätzlich eine Policy mit Anforderungen an TLS und passende MX-Ziele. Unterstützende sendende Mailserver berücksichtigen diese beim Verbindungsaufbau. DNS-Hinweis, über HTTPS bereitgestellte Policy und ihre Anwendung durch einen Sender sind verschiedene Schritte. SMTP: RFC 5321, Abschnitt 5, STARTTLS: RFC 3207, MTA-STS: RFC 8461.
Transportfrage und passender Anschluss.
-
Welcher Mailserver nimmt Nachrichten für meine Domain entgegen?
- Nächster Prüfschritt
- Zuerst tatsächliche MX-Ziele und die zuständige Administration klären
-
Was belegen STARTTLS und ein Zertifikat?
- Nächster Prüfschritt
- Richtung, Host, Port und Vertrauensmodell der Verbindung klären
-
Wie passen MX, HTTPS-Policy und unterstützende Sender zusammen?
- Einstieg
- MTA-STS und TLS-RPT verstehen
- Nächster Prüfschritt
- MX-Namen, Policyinhalt und Verhalten unterstützender Sender getrennt prüfen
Eine erfolgreiche Verbindung zu einem untersuchten MX belegt nicht sämtliche anderen Server oder Nachrichtenwege. Umgekehrt beweist ein gescheiterter Verbindungsversuch nicht, dass verschlüsselter Transport grundsätzlich fehlt. Lesen Sie Ziel, Zeitpunkt und offene Messungen zusammen mit dem Befund.
SMTP-TLS ist keine Ende-zu-Ende-Verschlüsselung des Inhalts. TLS-RPT hat ebenfalls eine eigene Aufgabe: unterstützende Sender können Transportberichte liefern. Ein veröffentlichtes Berichtsziel ist noch kein tatsächlich empfangener Bericht. TLS-RPT: RFC 8460.
Eine einzelne Nachricht untersuchen
Für die Frage „Welche SPF-, DKIM- und DMARC-Ergebnisse hat das empfangende System für diese Nachricht ermittelt?“ benötigen Sie die konkrete Nachricht und ihren Empfangskontext. In den Originalheadern lassen sich sichtbares From, SMTP-Identitäten, DKIM-Signature und Authentication-Results zuordnen. Vertrauen Sie dabei den Ergebnissen des zuständigen empfangenden Systems; ein vom Absender eingefügter gleichnamiger Header ist kein verlässlicher Nachweis. Die Einordnung von Headerbefunden erklärt diesen Unterschied. Die Vertrauensgrenze beschreibt RFC 8601.
Wolf-Agents bietet über den deutschen E-Mail-Check eine freiwillige private Testmail-Ergänzung als kostenlose Beta mit begrenztem Prüfumfang an. Sie dient einer eigenen neu versandten Testnachricht. Der öffentliche Domaincheck bleibt auch ohne diese Auswahl nutzbar. Die private Auswertung ergänzt Ihren Kenntnisstand; sie ändert nicht automatisch den öffentlichen Domainbefund oder dessen Note. Eine Testmail deckt nur den untersuchten Versand- und Empfangsweg ab.
Domaincheck und private Testmail einordnen
Eine angebotene Zusendung des Domain-Ergebnislinks ist ein anderer Vorgang als eine Testmailprüfung. Die Beta stellt keinen Sammeldienst für DMARC-Aggregatberichte (RUA) und kein fortlaufendes Monitoring bereit. Für Zustellprobleme brauchen Sie außerdem den konkreten Fehler, gegebenenfalls Versandprotokolle und die Rückmeldung des empfangenden Dienstes.
Nach einem Befund oder einer Änderung weiterarbeiten
- Die offene Frage benennen. Geht es um eine veröffentlichte Einstellung, die Aktivierung beim Versanddienst, den Empfangstransport oder eine bestimmte Nachricht?
- Die passende Grundlage und Anleitung wählen. Stimmen Sie Änderungen mit der zuständigen Person ab und verwenden Sie die Werte Ihrer eigenen Domain und Dienste.
- Den passenden Nachweis erneut ansehen. Eine DNS-Änderung braucht einen neuen DNS-Befund. Eine geänderte Signierung braucht zusätzlich einen Nachrichtenbefund über den betroffenen Versandweg. Halten Sie Zeitpunkt und Abdeckung getrennt fest.
Wenn Sie die öffentliche Konfiguration Ihrer eigenen oder einer berechtigt untersuchten Domain betrachten möchten, nutzen Sie den E-Mail-Domaincheck. Er untersucht veröffentlichte Angaben und ausgewählte erreichbare Mailserver-Signale. Er meldet keine Prüfung Ihres gesamten Mailbetriebs.
Müssen Sie einen beobachteten Domainstand an Ihre IT oder einen Dienstleister weitergeben, kann eine angebotene Reportunterlage diesen Stand mit Messgrenzen dokumentieren. Die Reportübersicht erklärt ihren Zweck. Ein Wolf-Report ist kein DMARC-Aggregatbericht, kein Compliancezertifikat und keine Zustellgarantie.
Weitere Fragen im vorhandenen Ratgeber
Bei einer verdächtigen Nachricht reicht die Domainauthentifizierung für eine Einschätzung nicht aus: Auch korrekt authentifizierte Nachrichten können täuschen. Der Bedrohungsratgeber führt zu Spoofing, Phishing, Geschäftsidentitätsbetrug und weiteren Nachrichtenthemen. Der Domaincheck untersucht keine Anhänge oder Postfachinhalte.
Weitere vorhandene Kapitel erschließen eigene Fragen:
-
Einführung in die E-Mail-Architektur
Für den Überblick über den Nachrichtenweg.
-
DMARC-Policy schrittweise einführen
Für die Planung anhand tatsächlicher Versandbefunde.
-
DNS-Sicherheit
Für DNSSEC und DANE; deren Belegumfang bleibt gesondert zu betrachten.
-
ARC und E-Mail-Gateways
Für indirekte Mailflüsse und zwischengeschaltete Systeme.
-
BIMI und Logoanzeige
Für eine optionale Funktion teilnehmender Empfängerdienste.
-
E-Mail-Aliase
Für die Organisation verschiedener Adressen.
-
Compliance und Dokumentation
Für eine getrennte Einordnung organisatorischer Anforderungen. Ein Scan bestätigt keine Rechtskonformität.
Häufige Einstiegsfragen
Muss ich alle Verfahren einrichten?
Die Auswahl hängt davon ab, ob Ihre Domain sendet, empfängt oder gar keine E-Mail nutzt. Klären Sie außerdem Ihre Versanddienste und die Anforderungen der Empfängerdienste. Authentifizierung, Transportschutz, Inhaltsverschlüsselung und optionale Logoanzeige erfüllen unterschiedliche Aufgaben. Eine vollständige Kapitelliste ist keine allgemeine Pflichtliste.
Reicht ein vorhandener DKIM-Eintrag als Kontrolle?
Er beantwortet die Frage, welcher öffentliche Schlüssel unter dem abgefragten Namen auffindbar ist. Zusätzlich muss der richtige Dienst signieren, und die Signatur der konkreten Nachricht muss die Prüfung bestehen. Ein DKIM-Pass trägt nur dann zu einem DMARC-Pass bei, wenn seine Signierdomain passend zur sichtbaren From-Domain ausgerichtet ist. Alternativ kann ein SPF-Pass für die passend ausgerichtete MAIL FROM-Identität genügen.
Warum landet eine authentifizierte Nachricht trotzdem im Spamordner?
Authentifizierung ist nur ein Teil der Empfängerentscheidung. Inhalt, Reputation, Versandpraxis und weitere Empfängerregeln können eine andere Behandlung bewirken. Lesen Sie die Rückmeldung des konkreten Dienstes; die Gmail-Absenderrichtlinien sind ein Beispiel für solche dienstbezogenen Anforderungen. Ein Domaincheck kann keine Inboxplatzierung versprechen.
Muss ich eine Nachricht einsenden, um den Ratgeber oder Domaincheck zu nutzen?
Nein. Der Ratgeber und der kostenlose Domaincheck lassen sich ohne eigene Testmail nutzen. Die private Testmail-Ergänzung ist eine freiwillige gesonderte Prüfung einer eigenen Nachricht. Sie ist kein Uploadweg zur allgemeinen Untersuchung fremder verdächtiger E-Mails.
Fachliche Grundlagen
Die Normen erklären Verfahren und Grenzen; sie bestätigen keine einzelne Konfiguration und erweitern nicht den Umfang eines Wolf-Checks.
- SPF: RFC 7208, insbesondere Abschnitte 2 und 3.
- DKIM: RFC 6376, insbesondere Abschnitte 1, 3 und 6.
- DMARC: RFC 9989, insbesondere Abschnitte 1, 4 und 5.
- SMTP-Zielauswahl: RFC 5321, Abschnitt 5 und STARTTLS: RFC 3207.
- MTA-STS: RFC 8461 und TLS-RPT: RFC 8460.
- Vertrauen in Authentication-Results: RFC 8601.
- Google Workspace: DKIM einrichten, Microsoft 365: DKIM konfigurieren und Gmail-Absenderrichtlinien.