DKIM-Signatur
Jede DKIM-Signature wird mit echter Kryptografie verifiziert (RSA & Ed25519), nicht nur im DNS gefunden – inklusive des l=-Body-Längen-Loopholes, fehlender Übersignierung und schwacher Schlüssel.
E-Mail-Versand-Test (MailFrom)
Prüfen Sie die Mail, die Sie versenden — die MailFrom-Seite, so wie ein empfangender Provider sie sieht. Der Domain-Sicherheitscheck liest Ihre DNS-Records; dieser Test liest eine echte Nachricht aus Ihrem Mailsystem: Senden Sie eine E-Mail an eine erzeugte Einmal-Adresse und sehen Sie genau, wie Ihr Versand auf der Leitung authentifiziert wird — die DKIM-Signatur wird kryptografisch verifiziert, SPF wird gegen die echte verbindende IP ausgewertet, und die DMARC-Ausrichtung wird für diese Nachricht entschieden, dieselbe Entscheidung, die ein Empfänger wie Gmail trifft.
Die Analyse selbst empfängt nur: Sie senden eine Nachricht an uns, und für ihre Auswertung geht nichts hinaus. Zwei optionale Schritte versenden sehr wohl, und zwar erst auf Ihren Klick: eine zweite Nachricht unter absichtlich unsicheren Bedingungen (der Downgrade-Test, der in die Note eingeht) und eine Probe an Ihre eigenen Mailserver, wenn Sie zusätzlich die Empfangsseite testen. Über das Ergebnis hinaus wird nichts aufbewahrt: Die Adresse ist einmalig und läuft ab, die Nachricht wird analysiert und verworfen, und der Bericht liegt nur kurz im Speicher. Ausnahme sind die Server-Logs – siehe Datenschutz. Keine Anmeldung, kein Tracking.
Senden Sie eine E-Mail von dem Mailsystem, das Sie testen möchten, an diese Adresse:
Was geprüft wird
SPF (echte IP)
SPF check_host() läuft gegen die IP, die die Nachricht tatsächlich zugestellt hat – mit dem 10-Lookup-Limit und Makro-Behandlung, das Ergebnis, das ein Empfänger berechnen würde.
DMARC-Ausrichtung
Ob diese Nachricht DMARC-ausgerichtet ist (From vs. eine bestandene DKIM-Domain oder die SPF-Identität), mit Strict-/Relaxed-Modus und veröffentlichter Policy – die Organisationsdomains ermittelt der DNS-Tree-Walk nach RFC 9989, nicht die Public Suffix List.
ARC-Kette
Hat ein Vermittler (etwa eine Mailingliste) eine ARC-Kette hinzugefügt, verifizieren wir sie wie ein Empfänger – jedes ARC-Seal und die jüngste ARC-Message-Signature werden neu geprüft – damit ein Empfänger Ihrem ursprünglichen SPF/DKIM/DMARC-Ergebnis auch nach Veränderung der Nachricht noch vertrauen kann. Validiert gegen die vollständige ValiMail-ARC-Testsuite.
Transport-TLS
Hat Ihr Server überhaupt STARTTLS genutzt, und mit welcher Version und welchem Cipher? Klartext-Zustellung und schwaches/veraltetes TLS werden markiert.
Reverse-DNS
Forward-bestätigtes Reverse-DNS (FCrDNS) der Absender-IP – von Gmail und Yahoo für jeden Absender verlangt – plus der IPv4/IPv6-Zustellpfad.
Zustellweg
Wir parsen den Received-Header-Verlauf Ihrer Nachricht und zeigen den Weg, den sie zu uns genommen hat – wie viele Relay-Hops sie passiert hat und wie lange sie unterwegs war – und markieren eine ungewöhnlich lange Kette oder große Verzögerung, die auf Queuing oder einen fehlkonfigurierten Ausgangsweg hindeutet.
Nachrichten-Hygiene
Message-ID, ein gültiges Date, doppelte oder mehrwertige From-Header, SMTP-Smuggling-Zeilenenden und weitere Signale, die Filter gewichten.
Nachrichten-Struktur
Wir parsen die MIME-Struktur und markieren, was Darstellung oder Zustellbarkeit schadet: ein Nur-HTML-Body ohne Text-Alternative, eine fehlende oder nicht terminierte multipart-Grenze, ein unbekanntes Content-Transfer-Encoding und ausführbare oder Skript-Anhänge, die die meisten Gateways blockieren. Nur die Struktur – wir dekodieren Ihren Inhalt nie.
List-Unsubscribe
Für Bulk-Mail verlangen Gmail und Yahoo eine One-Click-Abmeldung (RFC 8058). Wir prüfen auf den List-Unsubscribe-Header mit HTTPS-URI, den List-Unsubscribe-Post-One-Click-Marker und eine ausgerichtete DKIM-Signatur, die beide Header abdeckt.
BIMI-Logo
Dürfte diese Nachricht Ihr Markenlogo zeigen? Wir lösen den BIMI-Record auf, koppeln ihn an das DMARC-Ergebnis dieser Nachricht, rufen das SVG ab (Tiny PS-Profil) und verifizieren das Mark-Zertifikat – Kette zu einer BIMI-autorisierten CA und das darin gebundene Logo – so wie Gmail, Apple Mail und Yahoo es tun.
S/MIME-Signatur
Ist Ihre Nachricht S/MIME-signiert, wird die Signatur so verifiziert, wie es das Mailprogramm eines Empfängers tut – Inhalts-Integrität, die Zertifikats-Adresse gegen Ihre From-Adresse, eine Kette zu einer öffentlich vertrauenswürdigen E-Mail-Root (Mozilla/CCADB-Email-Trust-Bit) und moderne Algorithmen. Veröffentlichen Sie einen SMIMEA-Record (RFC 8162), bestätigen wir, dass er zu dem Zertifikat passt, das die Nachricht tatsächlich signiert hat – eine Prüfung, die kein anderes Tool gegen eine Live-Signatur durchführt. Unsignierte Mail bleibt neutral; S/MIME ist eine optionale Ebene zusätzlich zu DKIM.
OpenPGP-Signatur & Schlüsselabruf
Dieselbe Sorgfalt für OpenPGP: Eine PGP/MIME-Signatur (RFC 3156) oder der ältere Inline-Stil wird gegen einen Schlüssel geprüft, der für Ihre Adresse tatsächlich veröffentlicht ist – der Bericht sagt also, ob sie für die Nachricht in der angekommenen Form noch hält, und benennt ein Gateway, das sie durch nachträgliches Umschreiben zerstört hat. Zusätzlich schlagen wir Ihre Adresse im Web Key Directory Ihrer eigenen Domain nach: Wer den Schlüssel dort veröffentlicht, dessen Schlüssel finden die Mailprogramme aller Korrespondenzpartner von selbst – ohne manuellen Schlüsseltausch. Ein Autocrypt-Header wird gegen die Regeln geprüft, die darüber entscheiden, ob ein empfangender Client ihn überhaupt annimmt. Wie bei S/MIME kostet eine fehlende OpenPGP-Ebene nichts – nur eine Signatur, die behauptet wird und dann nicht hält.
Neu bei diesen Mechanismen? Die Leitfäden E-Mail-Authentifizierung und Mailserver-TLS & DANE erklären jeden einzelnen. Lieber zuerst die Records bauen? Öffnen Sie Record Studio.