Bewertet am 4. November 2026English Русский Українська العربية Deutsch Español Français Italiano 日本語 한국어 Polski Português ภาษาไทย Türkçe Tiếng Việt 简体中文

So prüfen wir Ihre E-Mails

Wir prüfen, wo ein bestimmtes Exemplar gelandet ist und was über dessen Versandaufbau und Inhalt festgestellt werden kann. Die Ergebnisse beschreiben die Testpostfächer zu den aufgezeichneten Prüfzeiten. Die Abdeckung kann teilweise sein: Ein verfügbares Ergebnis beweist nicht, dass fehlende Tests bestanden wurden.

Wo die E-Mail gelandet ist

Sie senden eine E-Mail von Ihrem eigenen Versandsystem an die ausgewählten Testadressen. Wir suchen bei jedem Anbieter nach seiner Kopie und speichern seinen Ordner und die Erkennungszeit. Dabei werden bestimmte Postfächer berücksichtigt; es sagt keine ganze Kampagne voraus.

Posteingang, Spam, andere Ordner: Die Kopie wurde in diesem Ordner gefunden. Werbeaktionen und Newsletter gelten als erhalten, jedoch nicht als primärer Posteingang.
E-Mail nicht gefunden: Bei einer erfolgreichen Suche wurde bei der Prüfung kein passendes Exemplar gefunden. Dies stellt keine Ablehnung der Zustellung oder Spam-Platzierung dar.
Konnte nicht überprüft werden: Das Lesen des Postfachs ist fehlgeschlagen oder die Beweise reichen nicht aus. Wir ersetzen kein Spam oder Posteingang durch ein unbekanntes Ergebnis.

Wie der Prozentsatz des Posteingangs berechnet wird

Primärer Posteingang ÷ empfangene externe Kopien × 100

Beispiel: 3 Posteingang + 6 Spam + 1 nicht gefunden = 10 ausgewählte Postfächer. Es gingen neun Exemplare ein; Der Posteingangsanteil beträgt 3/9 oder 33 %. Lesen Sie immer den Zähler, den Nenner und die Beobachtungsabdeckung ab.

Das LDM-Diagnosepostfach ist von externen Zählungen und dem Prozentsatz des Posteingangs ausgeschlossen. Fehlende Exemplare, Bounces und nicht verfügbare Postfächer sind ebenfalls von diesem Prozentsatz ausgeschlossen. Eine unzureichende Stichprobe lässt die Gesamtbewertung unbekannt. Der Schwellenwert für die Anzeige einer Bewertung ist eine technische Serviceregel und keine statistische Garantie für Ihr Publikum.

Technische Zustände und Kopierabgleich

In der API ist eine bestätigte Suche ohne Kopie möglich Platzierung=not_received, provider_availability.status=verfügbar, reason=mailbox_read_succeeded. measured_at zeichnet die Lesezeit auf.

Ein gespeichertes not_received-Ergebnis mit einem bestätigten Lesefehler wird zu „seed_unavailable“ mit reason=mailbox_read_failed. Ein unvollendetes Ergebnis bleibt ausstehend, mit Lesefehlern in „provider_availability“. Fehlende Lesebeweise begründen keine abgeschlossene Suche.

Der Lieferverlauf und eine fehlgeschlagene Service-Control-Lieferung haben keinen Vorrang vor einer gespeicherten Messung. Jede Kopie behält ihren Anbieter, ihre Empfangszeit und ihre verfügbare Nachrichtenidentität. Ein Bericht kann verschiedene Absenderdomänen enthalten: Dies ist ein Unterschied zwischen den Kopien und kein Beweis dafür, dass eine nicht verwandte Nachricht gefunden wurde. Die Übereinstimmung hängt von den Bezeichnern und der verfügbaren Suche ab. Eine IMAP-UID ist an ihr Postfach und ihre UIDVALIDITY gebunden; Durch das Verschieben einer Nachricht kann sich deren UID ändern. Microsoft Graph verfügt über eigene Identitätsregeln. Bei einer begrenzten Suche kann eine Kopie übersehen werden.

24-Stunden-Beobachtungen

Erstes Ergebnis und spätere Kontrollen

Die erste Sammlung ist normalerweise nach etwa zehn Minuten abgeschlossen. Jede empfangene externe Kopie hat ihr eigenes 24-Stunden-Fenster, beginnend mit der ersten bestätigten Erkennung. Bei späteren Kontrollen wird dieselbe Kopie entdeckt; Wir versenden keine neuen E-Mails, um das Diagramm zu zeichnen.

Beobachtungen sind stündlich geplant. Das kompakte Diagramm zeigt ausgewählte Kontrollpunkte um 0 / 3 / 6 / 12 / 18 / 24 Stunden. Eine Farbe bestätigt den Ordner nur zum gespeicherten Messzeitpunkt. Der Ort zwischen den Prüfungen ist unbekannt, auch wenn benachbarte Ergebnisse übereinstimmen.

Zukünftige Punkte, Lücken und Fehler bleiben unterschiedliche Zustände. Ein späterer Fehler löscht nicht den zuvor bestätigten Ordner, bestätigt aber auch nicht den aktuellen Ordner. Ein abgeschlossenes Fenster bedeutet nicht, dass jede Messung erfolgreich war.

Änderungsbenachrichtigungen und die endgültige E-Mail hängen von den aktivierten Einstellungen und der Empfängerüberprüfung ab. Ihr Status wird im Bericht angezeigt. Abbestellte Empfänger erhalten keine Benachrichtigungen.

Was Diagrammzeitstempel bedeuten

Ein geplanter Versuch ist keine erfolgreiche Messung. Warteschlangen, Anbieterlimits und Fehler können eine Prüfung verzögern oder überspringen. Bestätigte Chartpunkte und die vollständige Liste der Versuche sind unterschiedliche Zählungen. Ein unbekannter Zeitplan beweist nicht, dass keine tatsächlichen Beobachtungen vorliegen.

Die erstmalige Erkennung im Spam bedeutet nicht, dass die E-Mail früher im Posteingang platziert wird. Zwischen den Prüfungen wird ein Ordnerwechsel festgestellt; Der genaue Zeitpunkt und die Ursache sind möglicherweise unbekannt. Das Endergebnis behält den letzten bestätigten Ordner und seine Zeit bei, einschließlich unvollständiger Beobachtungen; Eine erfolgreiche Messung genau um 24:00 Uhr ist nicht garantiert.

Absender und Server

Sendeschecks stammen von einer gespeicherten Kopie: zuerst der LDM-Diagnosekopie mit einer geeigneten Identität, andernfalls einer geeigneten externen Kopie. Wenn keine zuverlässige Übereinstimmung verfügbar ist, wird die ausgewählte Kopie als unsicher markiert. Details identifizieren die Quelle, die Uhrzeit, den Absender und die verfügbare IP. Wir ergänzen fehlende Ergebnisse nicht durch Ausweise anderer Kopien.

Authentifizierung aus der Domäne

Von ist die in der Nachricht angegebene Adresse. Der Erhalt einer Kopie und die Übereinstimmung mit der für den Test eingegebenen Adresse stellen keine Authentifizierung dar. Wir zeigen die From-Domain-Authentifizierung nur dann separat an, wenn ausreichende Beweise für eine erfolgreiche DMARC-Prüfung dieser Kopie vorliegen. Dadurch wird kein bestimmtes Postfach oder eine bestimmte Person überprüft.

SPF: Überprüft, ob die IP zum Senden für die SMTP-Envelope-Domäne berechtigt ist, die für die Rücksendeadresse verwendet wird. Es kann von „Von“ abweichen.
DKIM: Überprüft eine Signatur und die Integrität der signierten Nachrichtenteile. Die signierende Domäne kann von „Von“ abweichen. Keine Signatur und eine Signatur, bei der die Validierung fehlgeschlagen ist, sind unterschiedliche Ergebnisse.
DMARC: Erfordert eine erfolgreiche SPF- oder DKIM-Prüfung mit einer Domäne, die auf das sichtbare Von ausgerichtet ist. Eine Richtlinie von p=none bedeutet Überwachung und keinen Authentifizierungsfehler.

Wenn die Prüfungen die Domäne nicht authentifizieren, zeigen wir sie als nicht verifiziert an. Wenn die Beweise nicht ausreichen, bleibt das Ergebnis unbekannt. Ein Unterschied zwischen der eingegebenen Domain und From wird gesondert gekennzeichnet. Eine erfolgreiche Authentifizierung ist keine Garantie für die Platzierung im Posteingang.

Beweisquellen, Zusammenfassung und Spezifikationsversionen

Wir verwenden eine gespeicherte lokale Validierung der Originalnachricht oder ein vertrauenswürdiges Empfangsserverergebnis. Ein willkürlicher Authentication-Results-Header ist kein Beweis. Die SMTP-Herkunft ist wichtig: Eine IP in „Received“ kann zu einem Relay gehören; Der SMTP-Umschlag und HELO können nicht allein aus dem sichtbaren From rekonstruiert werden. Für die From-Authentifizierung ist ein erfolgreiches DMARC-Ergebnis erforderlich, das an die Domäne derselben Kopie gebunden ist. Ältere Aufzeichnungen ohne ausreichende Bindung bleiben unbekannt.

Die technische „All Clear“-Zusammenfassung erfordert erfolgreiche SPF-, DKIM-, DMARC- und PTR-Prüfungen, bekannte Quelldaten und abgeschlossene Sperrlistenabfragen ohne Treffer. Ein bestätigtes Problem führt zu „Probleme gefunden“; Fehlende Beweise oder Fehler ergeben. Konnte nicht überprüft werden. Probleme und unvollständige Beweise können nebeneinander bestehen. Widersprüchliche Ergebnisse für dieselbe Domäne und IP bleiben sichtbar.

Die Verfügbarkeit von SPF, DKIM und DMARC ist unabhängig: Fehlende SMTP-Beweise für SPF machen eine verfügbare DKIM-Signaturprüfung nicht ungültig. Jede Methode behält ihr genaues Ergebnis und ihren Verfügbarkeitsgrund. Dabei handelt es sich um Konventionen für Testzusammenfassungen und nicht um die Mindestanforderungen jedes Anbieters. Für das separate Ergebnis der Domänenauthentifizierung sind eigene Belege erforderlich. SPF behält „Bestanden“, „Nicht bestanden“, „Softfail“, „Neutral“, „Keine“ und „Fehler“ bei; Ein Null-SMTP-Reverse-Pfad verwendet die HELO-Identität. Eine DKIM-Schlüsselsuche benötigt ihren Selektor; Ein unbekannter Selektor stellt kein defektes DKIM her.

Eine strikte DMARC-Ausrichtung erfordert identische Domänen; Bei der entspannten Ausrichtung wird der Organisationsbereich gemäß den Regeln des Bewerters verwendet. Die aktuelle Spezifikation ist RFC 9989, die RFC 7489 und RFC 9091 überflüssig macht. Gespeicherte lokale Ergebnisse verwendeten Mailauth 4.6.8 und seine Domänenbewertungsregeln; Beim Öffnen eines Berichts werden sie gemäß der neuen Spezifikation nicht neu berechnet.

Gespeicherte Methodenversion: 2026-10-01; aktuelle Überarbeitung der Ergebnisinterpretation: 04.11.2026. Die Evaluator-Revision wird nur dort angezeigt, wo sie gespeichert wurde. Eine fehlende Überarbeitung in einem älteren Bericht wird nicht durch das heutige Datum ersetzt. Wir verwenden versionierte konservative Regeln: Unzureichende Beweise bleiben unbekannt. Bestätigte reproduzierbare Fälle erweitern versionierte Regeln erst nach Regressionstests; Nicht unterstützte Fälle bleiben unbekannt. Regeln lernen nicht automatisch aus Testergebnissen. Das Überprüfungsdatum dieses Dokuments ändert weder die Engine-Version noch die historischen Ergebnisse.

PTR, DNS und Blocklisten

IP → PTR → A/AAAA →gleiche IP

PTR wird bestanden, wenn die IP auf einen Hostnamen verweist, dessen A/AAAA-Einträge dieselbe IP enthalten. Der Hostname muss nicht mit der Von-Domäne übereinstimmen. Ein fehlender Datensatz oder eine IP-Nichtübereinstimmung schlägt bei der Prüfung fehl; Ein Suchfehler oder fehlende Beweise bedeuten, dass die Überprüfung nicht möglich war.

PTR- und Blocklist-Ergebnisse beschreiben die angegebene IP zum Prüfzeitpunkt. Details zeigen die IP-Quelle; Eine Adresse aus Headern kann zu einem Relay gehören. Diese Ergebnisse authentifizieren die Von-Domäne nicht.

IP-Blocklist-Prüfungen verwenden die IP, die für die ausgewählte gespeicherte Nachrichtenkopie identifiziert wurde. Wir zeigen die IP und ihre Quelle. Eine Adresse aus Nachrichtenheadern kann zu einem Relay gehören und authentifiziert den Absender selbst nicht. Wenn die IP nicht verfügbar ist, bleibt das Ergebnis unbekannt; Wir ersetzen keine MX-Adresse, keine von From abgeleitete Adresse oder die IP einer anderen Kopie. Wir fragen eine begrenzte Anzahl von IP-Blocklisten ab. „Nicht in geprüften Sperrlisten aufgeführt“ bedeutet lediglich, dass die abgeschlossenen benannten Prüfungen zum erfassten Zeitpunkt keine Auflistung gefunden haben. Auflistungen, Fehler und unvollständige Prüfungen werden gesondert ausgewiesen. Domain-Checks ersetzen keine IP-Checks. Keine Einträge sind keine Garantie für einen guten Ruf oder eine gute Platzierung im Posteingang.

Dabei handelt es sich um gespeicherte Ergebnisse: Das Öffnen des Berichts löst keine neue Prüfung aus. Die Empfangszeit für Kopien ist unabhängig von der Zeit für die Sperrlistenprüfung. Sofern die Prüfzeit nicht gespeichert wurde, weisen wir ausdrücklich darauf hin.

Wer konfiguriert PTR und wie unterscheidet sich HELO?

Der IP-Inhaber oder sendende Dienst konfiguriert PTR. Bitten Sie für Ihren eigenen Server den IP-Anbieter, PTR auf einen Hostnamen wie mail.example.org festzulegen und dann das A/AAAA dieses Hostnamens auf dieselbe IP zu verweisen. Ein PTR-Eintrag in der normalen Domänenzone konfiguriert nicht die IP-Reverse-Zone. Eine sendende Plattform verwaltet PTR für ihre eigenen Server.

Die Vorwärtssuche prüft den ersten zurückgegebenen PTR-Hostnamen: A für IPv4, AAAA für IPv6. Werden mehrere Namen zurückgegeben, werden die anderen nicht als geprüft gezählt; ihre Zählung wird im Detail festgehalten. HELO/EHLO ist der vom SMTP-Server angezeigte Name. Seine Konfiguration und zusätzliche Anbieteranforderungen sind vom PTR-Ergebnis getrennt. Fehlt der Name oder sein Prüfnachweis, wird nicht von einer Übereinstimmung ausgegangen.

Ein DNS-Eintrag ist eine veröffentlichte Einstellung, keine erfolgreiche Nachrichtenprüfung. Ein SPF-TXT-Eintrag, ein DKIM-Schlüssel oder eine DMARC-Richtlinie allein authentifiziert diese Kopie nicht. MX identifiziert eingehende Mailserver und legt nicht die ausgehende IP fest. Gespeicherte Berichtsprüfungen sind nicht jedes Mal, wenn Sie die Seite öffnen, neue DNS-Suchen.

E-Mail-Inhalt

Ein Zustellungstest analysiert die empfangene Kopie; Der separate Entwurfsprüfer analysiert hochgeladene Inhalte. Original-MIME von einer externen Kopie kann die lokale Authentifizierung unterstützen. MIME-Inhalte können technisch gesehen ohne vollständige SMTP-Beweise analysiert werden, Inhalte sowie SpamAssassin- und Rspamd-Ergebnisse werden jedoch nur angezeigt, wenn diese Prüfungen tatsächlich durchgeführt wurden. Verfügbares MIME allein bedeutet nicht, dass diese Prüfungen ausgeführt wurden. Der Bericht unterscheidet abgeschlossene, übersprungene und nicht verfügbare Prüfungen. Die Analysewerte sind kein Prozentsatz des Posteingangs oder eine nachgewiesene Ursache für Spam.

SpamAssassin und Rspamd verwenden unterschiedliche Regeln und Schwellenwerte; Ihre Ergebnisse werden nicht in eine Lieferwahrscheinlichkeit gemittelt. Ein gespeicherter Screenshot zeigt die Nachricht in ihrem erfassten Kontext, kein Test für jeden E-Mail-Client. Ein fehlender Screenshot macht eine Ordnermessung nicht ungültig.

Exemplar erhalten

Wir analysieren die verfügbare Nachrichtenkopie. Unvollständige, verschlüsselte oder nicht verfügbare Teile gelten nicht als erfolgreich geprüft.