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.
Prüfen Sie die Mail, die Sie versenden, und auf Wunsch die Mail, die Sie empfangen — mit einer einzigen Nachricht. 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. Setzen Sie das Häkchen Auch die Empfangsseite testen, lässt uns der Nachweis in derselben Nachricht wie ein echter Absender mit Ihren MX verbinden.
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 nur, wenn Sie sie anfordern: Der Empfangstest (Häkchen vor dem Erzeugen der Adresse oder das Angebot unter dem Bericht danach) stellt eine signierte Test-Nachricht an genau die Absenderadresse zu, und der Downgrade-Test bittet Sie um eine zweite Nachricht unter absichtlich unsicheren Bedingungen. Ü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.
Sobald Ihre Nachricht die Kontrolle über die Domain bewiesen hat, verbinden wir uns wie ein echter Absender mit Ihren MX (STARTTLS, DANE, MTA-STS, RCPT, Catch-all, Postmaster, Greylisting, Open-Relay-Hinweis) und stellen eine signierte Test-Nachricht an genau die Absenderadresse zu – nie an Dritte. Standardmäßig aus: Ohne Häkchen geht nichts an Ihre Server.
Senden Sie eine E-Mail von dem Mailsystem, das Sie testen möchten, an diese Adresse:
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.
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.
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.
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.
Hat Ihr Server überhaupt STARTTLS genutzt, und mit welcher Version und welchem Cipher? Klartext-Zustellung und schwaches/veraltetes TLS werden markiert.
Forward-bestätigtes Reverse-DNS (FCrDNS) der Absender-IP – von Gmail und Yahoo für jeden Absender verlangt – plus der IPv4/IPv6-Zustellpfad.
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.
Message-ID, ein gültiges Date, doppelte oder mehrwertige From-Header, SMTP-Smuggling-Zeilenenden und weitere Signale, die Filter gewichten.
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.
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.
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.
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.
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.
Die ersten drei Mail-Exchanger der Präferenzreihenfolge werden aufgelöst und auf Port 25 angebunden, genau wie ein sendender Server (die Grenze verhindert, dass ein großer MX-Satz einen Test in Dutzende ausgehende Verbindungen verwandelt; der Bericht benennt sie) — inklusive Null MX (RFC 7505) und implizitem A/AAAA-Fallback.
Bewirbt jeder geprobte MX STARTTLS? Ein einziger reiner Klartext-Exchanger zieht die ganze Domain herunter, weil Sender auf den schwächsten MX ausweichen. Zertifikatsvertrauen, TLS-Qualität, DANE, MTA-STS und TLS-RPT werden hier ebenfalls benotet — der Haupt-Scan ergänzt die vollständige Cipher-Aufzählung je MX und prüft dieselben Namen von der DNS-Seite.
Ob Ihr MX den Empfänger bei RCPT annimmt (250), temporär zurückstellt (4xx) oder ablehnt (5xx) — das echte „kommt hier Mail an?“-Signal. Diese Prüfung endet bei RCPT.
Ein zufälliger, nicht existenter Empfänger wird geprüft: Wird er angenommen (250), ist die Domain ein Catch-all — mehr Spam-Exposition und keine frühe Ablehnung ungültiger Mail.
RFC 5321 §4.5.1 verlangt, dass jede mailempfangende Domain postmaster@ annimmt. Wir prüfen, dass sie es tut — ein kleines, aber echtes Konformitätssignal.
Eine 4xx-Zurückstellung bei RCPT ist das Kennzeichen von Greylisting. Legitime Sender versuchen es erneut und kommen durch; wir weisen es aus, damit ein langsamer Erstkontakt keine Überraschung ist.
Nach einem externen Sender sollte ein RCPT an eine Fremddomain abgelehnt werden (RFC 2505 / BCP 30). Wird er angenommen, weisen wir auf ein mögliches Open Relay hin — es wird nie eine Nachricht weitergeleitet.
Zuletzt wird genau eine signierte Beweis-Nachricht über die vollständige SMTP-DATA-Phase an exakt die Adresse zugestellt, deren Kontrolle Sie bewiesen haben — nie an Dritte — damit Sie sehen, ob echte Mail durchgängig ankommt, nicht nur, ob RCPT angenommen wird. Die Nachricht enthält eine Abmeldemöglichkeit (Antwort oder abuse@).
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.