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 — 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.
Dieser Test empfängt nur — er versendet nie: Es geht keine E-Mail an Sie oder Dritte hinaus; Sie senden eine Nachricht an uns. Über das Ergebnis hinaus wird nichts gespeichert: Die Adresse ist einmalig und läuft ab, die Nachricht wird analysiert und verworfen, und der Bericht liegt nur kurz im Speicher. Keine Anmeldung, kein Tracking.
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 – anhand der echten 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.
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.