Changelog

Nutzersichtbare Änderungen: neue und verbesserte Checks, Bewertungsänderungen, Funktionen und Doku-Updates am Domain-Scanner, den beiden Live-Mail-Tests (Versand und Empfang) und dem Record Studio. Der Domain-Scan führt 108 Einzelchecks in sechs Modulen aus – jeder davon auf der Seite Checks & Bewertung erklärt; der Live-Versand- und Empfangs-Test ergänzen tiefe Prüfungen auf Nachrichtenebene (SPF/DKIM/DMARC/ARC, S/MIME, STARTTLS/DANE/MTA-STS und mehr), und eine einzige E-Mail deckt nun beide Richtungen ab. Datumsangaben sind Deployment-Daten.

20. Juli 2026 – Record Studio verifiziert HTTP(S)-Records über IPv4 und IPv6

Die Generatoren für MTA-STS, security.txt und BIMI holen beim Laden des aktuellen Records jetzt über beide Adressfamilien. Jede Ressource (die MTA-STS-Policy, die security.txt-Datei, das BIMI-Logo) wird separat über IPv4 und über IPv6 abgerufen, sodass ein kaputter oder abweichender Endpunkt einer Familie – den das Verbindungs-Rennen des Browsers sonst verdecken würde – erkannt wird. Ist der Host nur über IPv6 erreichbar, warnt der Generator, dass reine IPv4-Clients oder -Absender ihn nicht abrufen können; löst er nur auf private/interne Adressen auf, warnt er, dass niemand im öffentlichen Internet ihn erreicht; und liefern IPv4 und IPv6 unterschiedliche Inhalte, wird die Abweichung markiert.

20. Juli 2026 – TLSA-Generator liest das Zertifikat über IPv4 und IPv6

Record Studio: Der TLSA-/DANE-Generator holt Ihr Live-Zertifikat jetzt über beide Adressfamilien. „Aktuellen Record & Zertifikat laden“ verbindet sich über IPv4 und IPv6 und zeigt, von welcher Adresse das Zertifikat gelesen wurde. Liefern IPv4 und IPv6 unterschiedliche Zertifikate aus, wird gewarnt, dass der erzeugte Record nur zu einer Familie passen würde – so können Sie die Zertifikate angleichen oder einen TLSA-Satz veröffentlichen, der beide abdeckt. Bisher wurde das Zertifikat über eine einzelne, nicht deterministische Familie gelesen, ohne zu sagen, welche.

20. Juli 2026 – IPv6 bei Zonentransfer- und Nameserver-Verteilungs-Check

Zonentransfer (AXFR) wird jetzt über IPv4 und IPv6 getestet. Die Zugriffskontrolle für Zonentransfers gilt je Listener, ein Nameserver kann also über eine Adressfamilie ablehnen und über die andere offen sein. Der Check testete bisher nur eine Adresse pro Nameserver; jetzt wird jede veröffentlichte Familie getestet, sodass eine Exposition, die nur auf dem IPv6-Listener besteht, nicht mehr übersehen wird.
Nameserver-Verteilung (RFC 2182) zählt jetzt beide Familien. Die Autonome-System-Abfrage deckt IPv4- und IPv6-Adresse jedes Nameservers ab, sodass ein Server, dessen IPv4 Einzel-AS-Anycast ist, dessen IPv6 aber in einem anderen AS liegt, für diese Diversität angerechnet wird; der Netz-Fallback bewertet IPv4 /24 und IPv6 /48 jetzt je Familie, und auch reine IPv6-Nameserver-Sätze werden bewertet. Der Drill-down zeigt die IPv6-Adressen und ihre Netze neben IPv4.

20. Juli 2026 – Volle IPv6-Abdeckung für adressbasierte Checks

Reverse DNS der Mailserver (FCrDNS) deckt jetzt beide IP-Familien ab. Der Check zog bisher bis zu vier Adressen in IPv4-zuerst-Reihenfolge – bei Mailservern mit vier oder mehr IPv4-Adressen (bei großen Providern üblich) wurden die IPv6-Adressen daher nie geprüft oder angezeigt. Jetzt werden beide Familien je Host geprüft, und es wird vermerkt, wenn nur eine Stichprobe vieler veröffentlichter Adressen geprüft wurde. Der FCrDNS-Check des Empfangs-Tests erhält denselben Fix.
RPKI validiert jetzt IPv4 und IPv6. Die Route-Origin-Validierung deckte bisher nur die primäre IPv4-Adresse ab – IPv6-only-Domains bekamen gar kein RPKI-Ergebnis, und das IPv6-Präfix von Dual-Stack-Domains wurde nie geprüft. Jetzt werden beide Familien validiert und angezeigt; das schlechtere Ergebnis bestimmt das Urteil.
Reverse-DNS-Drill-down der Domain-Adressen inklusive IPv6. Die PTR-Tabelle im DNS-Bereich listete bisher nur IPv4; jetzt zeigt sie beide Familien, und auch IPv6-only-Domains erhalten eine PTR-Tabelle. Die Nameserver-Adress-Hygiene prüft ebenso beide Familien jedes Nameservers statt einer v4-zuerst-Stichprobe.
Probes nennen die getestete Adresse. Die STARTTLS-Tabelle und der Empfangs-Test nennen jetzt die IP (und Familie), über die die Verbindung tatsächlich lief, und der Empfangs-Test vermerkt, dass die andere Familie eines Dual-Stack-Hosts nicht separat getestet wird. Ist die bevorzugte Familie eines Mailservers nicht erreichbar, probiert der Empfangs-Test jetzt einmal die andere Familie, bevor er ihn als unerreichbar meldet.
HTTP/3-(QUIC-)Probe versucht die andere IP-Familie. Ein Dual-Stack-Host, dessen zuerst aufgelöste Familie keine UDP-Antwort liefert, wird jetzt einmal über die andere Familie getestet, und das Ergebnis nennt die getesteten Familien.
Mailserver werden jetzt über beide Adressfamilien getestet. Jeder MX-Host erhält eine STARTTLS-/TLS-Verbindung je veröffentlichter Familie (IPv4 und IPv6), jeweils mit eigenem Protokoll-, Zertifikats- und DANE-Urteil – Abweichungen je Familie (z. B. ein kaputtes Zertifikat nur über IPv6) werden sichtbar statt hinter einer einzelnen Verbindung zu verschwinden. Eine veröffentlichte Adressfamilie, die auf Port 25 nicht antwortet, während die andere funktioniert, wird als Warnung markiert.
Vollständige Adresslisten statt Stichproben. Die Reverse-DNS-Tabellen (Domain-Adressen, Mailserver, Nameserver) decken jetzt bis zu vier Adressen je IP-Familie und Host ab – genug, um alle Adressen typischer Setups vollständig zu listen; ein Stichproben-Hinweis erscheint nur darüber hinaus.

20. Juli 2026 – Präzisere MTA-STS-Diagnose

Klare Ursachen bei nicht abrufbarer Policy. Wenn die MTA-STS-Policy-Datei nicht abrufbar ist, nennt der Befund jetzt die tatsächliche Ursache: einen Policy-Host, der nur auf private/interne IP-Adressen auflöst (aus dem öffentlichen Internet nicht erreichbar), fehlende Address-Records (A/AAAA), einen HTTP-Status ungleich 200 oder einen verbotenen Redirect (RFC 8461 §3.3) – statt des bisherigen generischen Hinweises.
Neue Warnung: Policy-Host nur über IPv6 erreichbar. Wird die Policy-Datei von einem Host ohne öffentliche IPv4-Adresse ausgeliefert, können reine IPv4-Absender sie nicht abrufen und stellen – ohne zuvor gecachte Policy – auch ohne MTA-STS-Schutz zu; der Check weist jetzt darauf hin (Dual-Stack-Absender sind nicht betroffen).
Passende Empfehlungen. Bei nicht abrufbarer Policy-Datei adressiert die Empfehlung jetzt das Abruf-Problem (erreichbare Adresse veröffentlichen, Policy per HTTPS ausliefern), statt mode: enforce vorzuschlagen.
Empfangs-Test. Auch der MTA-STS-Check des Empfangs-Tests nennt private/interne Policy-Host-Adressen als Ursache des Abruf-Fehlers.

18. Juli 2026 – Neues visuelles Design

Überarbeitete Oberfläche. Die gesamte Site – Scanner, Live-Mail-Tests, Record Studio und Dokumentation – erhält ein neues, dokumentartiges Design: weiße und tintenfarbene Flächen mit einem einzigen Kobalt-Akzent, scharfe Ecken, Haarlinien statt Schatten und die Schriften Inter und IBM Plex Mono. Das dunkle Farbschema und die automatische/manuelle Umschaltung bleiben erhalten.
Neue Noten-Darstellung. Die Gesamtnote und jede Bereichsnote erscheinen jetzt als umrandetes Noten-Quadrat mit Statusstreifen statt als Ring; die Bereichsbalken wurden zu schmalen Balken in der Notenfarbe des jeweiligen Bereichs. Punkte, Noten und alle Prüfungen sind unverändert.
Neues Logo. Ein Kobalt-Quadrat mit Haken ersetzt das Schild – inklusive Favicon, Startbildschirm-Symbol und Link-Vorschaubild.
Druckbarer Bericht. Der Scan-Bericht lässt sich jetzt sauber drucken: Navigation und Formulare werden ausgeblendet, und alle Funde erscheinen – auch in zugeklappten Abschnitten – mit ihren Bestanden-/Warn-/Fehlermarkierungen.

15. Juli 2026 – Strukturierte Berichte für Versand- und Empfangs-Test

Gruppierte Ergebnisse. Beide Live-Mail-Tests ordnen ihre Ergebnisse jetzt unter flachen Themen-Überschriften mit je einer Klartext-Frage: der Versand-Test unter SPF, DKIM, Domain-Richtlinie & Alignment, Transportsicherheit, Absender-Infrastruktur, Nachrichtenformat, S/MIME und SMTP-Diagnose; der Empfangs-Test unter Mailserver & Erreichbarkeit, Transportverschlüsselung, Verschlüsselungs-Richtlinien (DANE · MTA-STS · TLS-RPT), Annahme & Zustellung und SMTP-Diagnose. Bewertung, Noten und die einzelnen Checks sind unverändert.
„Was zuerst zu beheben ist“. Wie der Domain-Scan beginnen beide Test-Berichte jetzt mit einer Triage-Liste aller fehlgeschlagenen und warnenden Checks, das Schwerwiegendste zuerst — jede Zeile springt direkt zum Fund.
Auch die eingebetteten Berichte. Die Bonus-Versand-Analyse im Empfangs-Test und die optionale Empfangsseiten-Sektion im Versand-Test nutzen dieselbe Gruppierung — und jede trägt ihre eigene Liste „Was zuerst zu beheben ist“, genau wie die eigenständigen Tests.
Aufklappbare Gruppen. Jede Themen-Gruppe ist eine aufklappbare Karte wie die Abschnitte des Domain-Scans: eine Kopfzeile mit der Frage der Gruppe und ihren Bestanden-/Warnung-/Fehler-Zählern, die einzelnen Ergebnisse einen Klick dahinter. Die Liste „Was zuerst zu beheben ist“ öffnet die passende Gruppe automatisch.
Noten je Gruppe & Übersicht im Scan-Stil. Jede Themen-Gruppe trägt jetzt ihre eigene Note (berechnet mit derselben Formel und denselben Noten-Deckeln wie die Gesamtnote), und beide Test-Berichte — einschließlich der eingebetteten Bonus-Bereiche — beginnen mit der Übersicht des Domain-Scans: Noten-Ring mit Prozentwert neben Bereichs-Balken, die direkt zur jeweiligen Gruppe springen.

15. Juli 2026 – Dienst-Überschriften auf der Ergebnisseite & Hinweis auf die Live-Mail-Tests

Sichtbare Dienst-Gruppen. Die sechs Ergebnis-Abschnitte stehen jetzt unter drei flachen Überschriften – Website, E-Mail und DNS – passend zu den Dienst-Blöcken in der Übersicht. Die Abschnitte selbst bleiben unverändert: jeder behält seine eigene Note, seinen Refresh-Button und seine Details.
Live-Test-Hinweis. Die E-Mail-Gruppe endet jetzt mit einem kurzen Hinweis auf die beiden Live-Tests: Die Prüfungen im Bericht sind passiv, während Versand-Test und Empfangs-Test eine echte Nachricht und eine echte Zustellung untersuchen.

15. Juli 2026 – Übersichtlicherer Bericht: Triage-Liste, Dienst-Gruppen und Klartext-Untertitel

Triage-Liste „Was zuerst zu beheben ist“. Die Scan-Übersicht enthält jetzt eine abschnittsübergreifende Liste aller fehlgeschlagenen und warnenden Checks, das Schwerwiegendste zuerst – Fehler vor Warnungen, notendeckelnde Funde vor den übrigen. Jede Zeile springt direkt zum Fund im jeweiligen Abschnitt – Sie müssen nicht mehr sechs Abschnitte öffnen, um zu sehen, was wirklich zu tun ist.
Dienst-Gruppen in der Übersicht. Die sechs Kategorie-Balken sind jetzt unter den drei Diensten gruppiert, die sie schützen – Website, E-Mail und DNS – und die Abschnittskarten folgen derselben Reihenfolge (Website / HTTPS-TLS, HTTP-Security-Header, E-Mail-Authentifizierung, Mailserver-TLS & DANE, DNS, DNSSEC).
Klartext-Untertitel. Jeder Abschnitt trägt jetzt die Frage, die er beantwortet, als einzeiligen Untertitel („Kann jemand E-Mails im Namen Ihrer Domain fälschen?“) – so ist ohne Fachwissen klar, worum es in einem Abschnitt geht.
Einheitliche Formulierungen & Querverweise. Ein Null MX (RFC 7505) wird jetzt in allen drei Abschnitten, die ihn erwähnen, mit identischem Wortlaut beschrieben; DANE-Funde, die an fehlendem DNSSEC scheitern, verweisen auf den DNSSEC-Abschnitt; die Zertifikatsvertrauen- und CAA-Funde referenzieren einander; und die beiden unterschiedlichen Redirect-Checks (Port 80 vs. finale Seite) erklären jetzt ihren Unterschied.

13. Juli 2026 – Die Empfangsseite direkt aus dem Versand-Test testen — ohne zweite E-Mail

Versand-Test — optionaler Empfangsseiten-Test. Wenn Ihre gesendete Nachricht die Kontrolle über ihre Domain beweist (ein streng ausgerichteter SPF- oder DKIM-Pass), bietet das Versand-Test-Ergebnis nun einen Ein-Klick-Button, um zusätzlich zu testen, wie Ihre Mailserver Mail EMPFANGEN — STARTTLS, DANE, MTA-STS, Zertifikatsvertrauen und mehr — und verwendet dabei denselben Beweis wieder, ohne dass eine zweite E-Mail nötig ist. Der ausgehende Test läuft weiterhin nur, wenn Sie ihn ausdrücklich anfordern, und nur gegen Ihre eigene, gerade bewiesene Domain — der Versand-Test hält also sein Versprechen: Er sendet nie, außer Sie klicken. Zusammen mit der zeitgleich ausgelieferten umgekehrten Erweiterung liefert eine einzige E-Mail nun Ihr vollständiges Mail-Sicherheitsbild in beide Richtungen.

13. Juli 2026 – Der Empfangs-Test analysiert jetzt auch die Nachricht, die Sie senden

Empfangs-Test — Bonus-Versandanalyse. Der Empfangs-Test verlangt ohnehin, dass Sie eine authentifizierte Nachricht senden, um die Kontrolle über Ihre Domain zu beweisen. Genau diese Nachricht wird nun zusätzlich durch den vollständigen Versand-Test geschickt — so liefert eine einzige E-Mail beide Bilder auf einmal: die Transportsicherheit Ihrer Mailserver (die Empfangsseite) und eine komplette Ausgangsanalyse der gesendeten Nachricht — SPF, DKIM, DMARC, ARC, TLS, MIME-Struktur, S/MIME und mehr. Sie erscheint automatisch unter dem Empfangs-Ergebnis; keine zweite E-Mail nötig. Selbst ein Beweis, der nicht ausreicht, um die Empfangsseite freizuschalten, liefert weiterhin die volle Ausgangsanalyse und macht aus einer Ablehnung nützliche Diagnostik. Rein additiv: Der Test sendet weiterhin ausschließlich an Ihre eigenen Mailserver, und nur nachdem Sie die Kontrolle bewiesen haben.

13. Juli 2026 – S/MIME-Signatur- & SMIMEA-Prüfung (Sende-Test)

Sende-Test — S/MIME-Signatur. Ist Ihre Test-Nachricht S/MIME-signiert, verifizieren wir die Signatur jetzt so, wie es das Mailprogramm eines Empfängers tut: Wir prüfen kryptographisch, dass der Inhalt unverändert ist, dass die Adresse im Signatur-Zertifikat zu Ihrer From-Adresse passt (RFC 8550), dass es auf eine öffentlich vertrauenswürdige E-Mail-Root zurückführt (die Mozilla/CCADB-„Email“-Vertrauensliste) und dass moderne Algorithmen und ein starker Schlüssel verwendet werden. Eine defekte Signatur — meist verursacht durch ein Gateway oder eine Listen-Fußzeile, die die Nachricht nach dem Signieren verändert — wird bemängelt, denn Empfänger werten das schlechter als gar keine Signatur. Unsignierte Mail bleibt neutral und beeinflusst die Note nie: S/MIME ist eine optionale Ebene zusätzlich zu DKIM. Der Zertifikatsprüfer ist ein abhängigkeitsfreier CMS/PKCS#7-Parser, gehärtet gegen fehlerhafte Eingaben.
Sende-Test — SMIMEA-Record (RFC 8162). Wenn Sie einen SMIMEA-DNS-Record für Ihre Adresse veröffentlichen, gleichen wir ihn mit dem Zertifikat ab, das die Nachricht tatsächlich signiert hat, und bestätigen, dass die DNS-Zone DNSSEC-signiert ist — damit Empfänger mit DANE-artiger Zertifikatsermittlung das korrekte Zertifikat erhalten. Ein Record, der nicht mehr zu Ihrem Zertifikat passt (typischerweise nach einem Zertifikatswechsel), wird bemängelt. Nach unserem Kenntnisstand gleicht kein anderes Tool einen veröffentlichten SMIMEA-Record gegen eine Live-Signatur ab.

13. Juli 2026 – Korrektur: SHA-1-Root in der MX-Kette wird nicht mehr bemängelt (Empfangs-Test)

Die Zertifikatsketten-Prüfung des Empfangs-Tests warnt nicht mehr bei einer SHA-1-Signatur auf einer selbstsignierten Root-CA (z. B. DigiCert Global Root CA). Ein Trust-Anchor wird über seine Identität validiert, nicht über seine Signatur — eine SHA-1-Selbstsignatur des Roots ist also keine Schwäche; geprüft werden nur Leaf- und Intermediate-Zertifikate, wie im Haupt-Scan. Das entfernt eine Fehlwarnung, die die Note ansonsten gesunder Mailserver leicht senken konnte.

13. Juli 2026 – Öffentlich vertrauenswürdiges MX-Zertifikat (Empfangs-Test)

Empfangs-Test — öffentlich vertrauenswürdiges Zertifikat. Wir prüfen jetzt, ob das STARTTLS-Zertifikat jedes Ihrer Mailserver auf eine öffentlich vertrauenswürdige Root-CA zurückführt, geprüft gegen denselben kombinierten Root-Store wie der Haupt-Scan (mit Zwischenzertifikats-Reparatur, sodass ein Server, der lediglich Zwischenzertifikate weglässt, nicht fälschlich markiert wird). Opportunistische Sender prüfen das nicht, aber ein Sender, der MTA-STS oder DANE-PKIX durchsetzt, verlangt ein öffentlich vertrauenswürdiges Zertifikat — für ihn bedeutet eine nicht vertrauenswürdige Kette echten Mailverlust.

12. Juli 2026 – Zustellweg-Verlauf (Versand-Test) & Reverse-DNS-Prüfung (Empfangs-Test)

Versand-Test — Zustellweg. Wir werten jetzt den Received-Header-Verlauf Ihrer Test-Nachricht aus und zeigen den Weg, den sie zu uns nahm — durch wie viele Relay-Hops sie lief und wie lange sie unterwegs war — und markieren eine ungewöhnlich lange Kette oder große Verzögerung, die auf Warteschlangen oder einen fehlkonfigurierten Ausgangsweg hindeuten kann.
Empfangs-Test — vorwärts-bestätigtes Reverse DNS (FCrDNS). Wir prüfen jetzt, dass jede IP-Adresse Ihrer Mailserver einen Reverse-DNS-(PTR-)Record hat, der vorwärts wieder auf dieselbe IP auflöst. Das betrifft den Empfang von Mail nicht, aber Reverse DNS, das nicht vorwärts-bestätigt, verschlechtert die Zustellbarkeit von Mail, die Ihr Server sendet — Bounces, Auto-Antworten und NDRs —, die strenge Empfänger ablehnen.

12. Juli 2026 – ARC-Ketten-Prüfung (Versand-Test)

Versand-Test — Authenticated Received Chain (ARC, RFC 8617). Trägt Ihre Test-Nachricht eine ARC-Kette (von einem Weiterleiter wie einer Mailingliste hinzugefügt), verifizieren wir sie jetzt so, wie es ein Empfänger täte: Wir prüfen jedes ARC-Seal und die jüngste ARC-Message-Signature unabhängig nach und melden, ob die Kette intakt ist. ARC erlaubt es einem Weiterleiter, zu bezeugen, dass Ihre Nachricht SPF/DKIM/DMARC bestanden hat, bevor er sie verändert hat, sodass der finale Empfänger dem ursprünglichen Ergebnis weiter vertrauen kann. Unser Prüfer ist gegen die vollständige ValiMail-ARC-Testsuite (das implementierungsübergreifende Referenz-Korpus) validiert.

12. Juli 2026 – MIME-Struktur-Prüfungen (Versand-Test)

Versand-Test — Nachrichten-Struktur. Wir parsen jetzt die MIME-Struktur Ihrer Test-Nachricht und melden Probleme, die Darstellung oder Zustellbarkeit beeinträchtigen: einen reinen HTML-Body ohne Text-Alternative, eine deklarierte multipart-Grenze, die fehlt oder nie geschlossen wird, ein unbekanntes Content-Transfer-Encoding sowie ausführbare oder Skript-Anhänge, die die meisten Mail-Gateways blockieren. Der Parser prüft nur die Struktur (er dekodiert Ihre Inhalte nie) und ist gegen fehlerhafte Eingaben gehärtet.

12. Juli 2026 – MTA-STS-Durchsetzungs-Simulation, TLS-RPT (Empfangs-Test) und One-Click-Abmeldung (Versand-Test)

Empfangs-Test — MTA-STS-Durchsetzungs-Simulation. Wir holen jetzt Ihre MTA-STS-Policy und gleichen sie — als Einzige — mit den Mailservern ab, mit denen wir tatsächlich verbunden waren, und den Zertifikaten, die sie vorlegten: Unter mode: enforce wird ein Mailserver, der von keinem mx:-Muster abgedeckt ist, kein STARTTLS bietet oder ein namens-abweichendes Zertifikat ausliefert, als echter Mailverlust markiert (ein policy-treuer Sender verweigert ihn). Außerdem prüfen wir Ihren TLS-RPT-Record — den Kanal, der diese Transport-Sicherheitsfehler meldet.
Versand-Test — One-Click-Abmeldung (RFC 8058). Für Bulk-Mail prüfen wir jetzt den vollständigen Gmail/Yahoo-One-Click-Ablauf: ein List-Unsubscribe mit HTTPS-URI, einen List-Unsubscribe-Post-One-Click-Marker und eine ausgerichtete DKIM-Signatur, die beide Header abdeckt.

12. Juli 2026 – DNSSEC-Status der Auth-Records und Zustellbarkeit der Bounce-Adresse (Versand-Test)

DNSSEC-signierte Authentifizierungs-Records. Der Versand-Test zeigt jetzt, ob Ihre SPF-, DKIM- und DMARC-Records DNSSEC-signiert sind — unsignierte Records können gegenüber Resolvern gefälscht werden, die DNSSEC nicht validieren, was ihren Schutz schwächt.
Zustellbarkeit der Bounce-Adresse. Wir prüfen jetzt, ob Ihre Envelope-Return-Path-Domain Zustellfehler-Berichte empfangen kann: ein Null MX oder eine Domain ohne MX/A bedeutet, dass Bounces kein Ziel haben (und manche Empfänger lehnen Mail ab, deren Return-Path nichts empfangen kann).

12. Juli 2026 – SPF-Record-Hygiene-Prüfungen (Versand-Test)

SPF-Record-Hygiene. Über das Pass/Fail-Ergebnis hinaus prüft der Versand-Test Ihren SPF-Record jetzt auf häufige Fehler: ein „+all“, das das ganze Internet autorisiert, eine zu breite CIDR, Mechanismen nach „all“ (die nie ausgewertet werden) und ein redirect= neben einem „all“-Mechanismus (wodurch das redirect wirkungslos wird).

12. Juli 2026 – DMARC-Autorisierung externer Reports und DKIM-Konfigurationshinweise (Versand-Test)

Autorisierung externer DMARC-Reports. Gehen Ihre DMARC-Reports an eine andere Domain (z. B. einen Monitoring-Anbieter), muss diese Domain einen Autorisierungs-Record veröffentlichen — sonst senden Empfänger dorthin still gar nichts. Der Versand-Test prüft das jetzt (RFC 7489 §7.1) und markiert ein externes Report-Ziel ohne Autorisierung — ein häufiger, unsichtbarer Grund, warum DMARC-Reporting scheitert.
DKIM-Konfigurationshinweise. Wir markieren jetzt fragile DKIM-Entscheidungen: einfache Header-Kanonisierung (jede Whitespace-Änderung eines Relays bricht die Signatur) und ein Signatur-Ablauffenster unter fünf Tagen (eine verzögerte oder wiederholte Zustellung kann DKIM scheitern lassen).

12. Juli 2026 – Prüfung auf schwache DKIM-Schlüssel und DMARC-Reporting (Versand-Test)

Erkennung schwacher/kompromittierter DKIM-Schlüssel. Der Versand-Test prüft Ihren öffentlichen DKIM-Schlüssel jetzt auf bekannt-schwaches RSA-Material (die ROCA-Schwachstelle und Fermat-faktorisierbare Schlüssel), bei denen der private Schlüssel wiederherstellbar ist und Ihre Signaturen gefälscht werden können — dieselbe Prüfung, die wir auf Mailserver-Zertifikate anwenden.
DMARC-Aggregate-Reporting-Prüfung. Wir markieren jetzt einen DMARC-Record ohne rua=-Adresse: ohne sie erhalten Sie keine Aggregate-Reports und sind blind dafür, wer als Ihre Domain sendet und für Authentifizierungsfehler — genau die Daten, die Sie zum sicheren Verschärfen der Policy brauchen.

12. Juli 2026 – Zertifikatsketten-Drilldown (Empfangs-Test) und HELO-SPF + Reverse-DNS-Prüfung (Versand-Test)

Empfangs-Test — Zertifikatsketten-Drilldown. Der Bericht zeigt jetzt die vollständige Zertifikatskette jedes Mailservers (Subjekt, Schlüsseltyp/-größe, Signaturalgorithmus, Rolle), markiert eine schwache SHA-1-/MD5-Signatur irgendwo in der Kette und weist OCSP-Must-Staple und Certificate-Transparency (SCT) aus.
Versand-Test — HELO-Identitäts-SPF und Reverse-DNS-Qualität. Wir werten SPF jetzt zusätzlich separat für den HELO/EHLO-Namen aus (RFC 7208 §2.3, wie es manche Empfänger tun) und markieren einen generischen oder dynamisch wirkenden Reverse-DNS-Namen der Sende-IP — ein Muster, das Gmail und Yahoo abstrafen.

12. Juli 2026 – DANE-Prüfung im Empfangs-Test und weitere Nachrichten-Hygiene im Versand-Test

Empfangs-Test — DANE (DNSSEC-gepinntes TLS). Wir holen jetzt die TLSA-Records Ihrer Mailserver und verifizieren sie kryptografisch gegen das Zertifikat, das jeder Server tatsächlich vorlegt. Ein korrektes DANE-Setup wird bestätigt; ein nicht passendes oder nicht DNSSEC-signiertes — bei dem DANE-fähige Sender (große Teile des deutschen Ökosystems) die Zustellung verweigern — wird als Mailverlust-Risiko markiert, und wir prüfen die Rollover-Bereitschaft (ein zweiter TLSA-Record für sichere Schlüsselrotation).
Versand-Test — mehr Nachrichten-Hygiene. Neue Prüfungen für zu lange Zeilen (das 998-Oktett-Limit, das DKIM weiter unten bricht), nicht deklarierten 8-Bit-Inhalt, doppelte Singleton-Header, fehlenden Subject-Header und das REQUIRETLS-Signal (RFC 8689).

12. Juli 2026 – Versand- & Empfangs-Test: deutlich tiefere TLS-, Zertifikats- und Authentifizierungs-Analyse

Empfangs-Test — eine vollständige Per-Mailserver-TLS- & Zertifikats-Matrix. Für jeden geprüften Mailserver zeigt der Bericht jetzt die ausgehandelte TLS-Version und den Cipher (mit Forward-Secrecy-Einstufung), Gültigkeit, Namensabgleich und Vertrauen des Zertifikats, eine Prüfung auf schwache/kompromittierte RSA-Schlüssel (ROCA/Fermat), eine STARTTLS-Command-Injection-Prüfung und die vollständige SMTP-Konversation — Tiefe, die bisher nur im Haupt-Scan steckte.
Versand-Test — mehr Einblick in DKIM, SPF und DMARC. Der Bericht zeigt jetzt, welche Anzeige-Header Ihre DKIM-Signatur tatsächlich abdeckt (und ob sie übersigniert sind), erkennt doppelte RSA+Ed25519-Signierung, warnt vor SPF-Void-Lookups, bevor sie zum harten PermError werden, ergänzt eine MIME-Version- und eine HELO/EHLO-Identitätsprüfung und zeigt die vollständige SMTP-Konversation sowie 8BITMIME-/SIZE-Details.
DMARC-Bewertung korrigiert. Eine DMARC-Policy mit pct<100 (z. B. p=reject; pct=0) wird jetzt korrekt als nur teilweise Durchsetzung angezeigt — zuvor wurde sie wie volle Durchsetzung bewertet. Ein reduziertes pct kennzeichnet die Domain zudem korrekt als BIMI-untauglich.

12. Juli 2026 – Empfangs-Test: genauere Bewertung und klarere Meldungen

Genauere Noten. Eine Domain, deren MX-Host nicht auflöst, fällt jetzt klar durch (statt zu melden, der Test habe nicht laufen können), und wenn einige Mailserver erreichbar waren, andere aber diesmal nicht getestet werden konnten, vergibt das Modul keine Worst-Case-Note mehr für Server, die es gar nicht erreicht hat. Ein Test, der überhaupt nicht laufen konnte, zeigt jetzt keine Note statt einer irreführenden.
Ehrliches Open-Relay-Ergebnis. Erreicht die Open-Relay-Probe die Empfänger-Phase nicht, meldet sie jetzt „nicht bestimmbar“, statt zu suggerieren, Relaying sei abgelehnt worden.
Klarere Rückmeldung. Eine zu große Beweis-Mail wird als zu groß gemeldet (statt scheinbar nie anzukommen), und jede Probe-Nachricht enthält eine funktionierende Abmeldemöglichkeit (Antwort oder abuse@).

12. Juli 2026 – Neu: E-Mail-Empfangstest (kommt Mail an deinem MX an?)

Ein neuer E-Mail-Empfangstest prüft, wie deine Domain Mail empfängt. Nachdem du die Kontrolle über die Domain nachgewiesen hast — durch eine authentifizierte Nachricht von ihr — verbindet sich der Test wie ein echter Sender mit deinen Mailservern und meldet, was auf dem Draht passiert: Ist ein Mail-Exchanger erreichbar, bietet er STARTTLS, wird der Empfänger bei RCPT angenommen, nimmt er jede Adresse an (Catch-all), akzeptiert er postmaster@ (von RFC 5321 verlangt), ist Greylisting aktiv, und wird ein fremder Empfänger weitergeleitet (Open-Relay-Hinweis)?
Ein optionaler End-to-End-Zustelltest. Wenn dein Mailserver den Empfänger annimmt, kann der Test eine echte, harmlose, klar gekennzeichnete Nachricht zustellen und bestätigen, dass sie nach der DATA-Phase angenommen wird — so erfährst du auch, ob ein Content- oder Größenfilter legitime Mail ablehnen würde. Wir stellen nur an genau die Adresse zu, die uns kontaktiert hat, nie an eine eingetippte Adresse, und jede Probe trägt ein Ein-Klick-Opt-out.
Der Empfangstest ergänzt den bestehenden E-Mail-Versand-Test (der die Mail prüft, die du sendest) und den Domain-Security-Check (der deine DNS-Records liest).

11. Juli 2026 – Record Studio: sicherere Schlüssel, korrektere Records, ehrliche „Laden“-Hinweise

Der DKIM-Generator veröffentlicht keinen privaten Schlüssel mehr. Wird ein privater Schlüssel als reines Base64 eingefügt (ohne die -----BEGIN … PRIVATE KEY------Zeilen), erkennt und verweigert der DKIM-Generator ihn jetzt, statt daraus einen DNS-Record zu machen. Ebenso werden ein abgeschnittener oder beschädigter Schlüssel, Schlüssel unter 1024 Bit und Schlüssel oberhalb des von Empfängern zu unterstützenden 4096-Bit-Bereichs gekennzeichnet.
Erzeugte Records sind auch bei heikler Eingabe gültig. Logo-, Report- und Kontakt-URLs in den BIMI-, TLS-RPT- und security.txt-Generatoren werden in gültige URIs normalisiert (Leerzeichen kodiert, internationalisierte Hosts in Punycode); Report-E-Mail-Adressen mit einem % werden korrekt kodiert; und lange DMARC-, BIMI-, TLS-RPT- und MTA-STS-Records werden wie bei SPF und DKIM in 255-Byte-Strings aufgeteilt. security.txt akzeptiert nun openpgp4fpr:- und dns:-Encryption-URIs, verlangt bei Telefon-Kontakten ein führendes „+“ und erinnert daran, den Signaturschlüssel bis zum Expires-Datum der Datei gültig zu halten.
„Aktuellen Record laden“ ändert Ihre Policy nicht mehr stillschweigend. Enthält ein veröffentlichter Record etwas, das das einfache Formular nicht abbilden kann, warnt das Laden jetzt vor dem erneuten Export — ein negativer SPF-Mechanismus (z. B. -ip4:), DMARC pct=/fo=/psd=, CAA-Konto-/Validierungsparameter, unbekannte CAA-Tags wie issuevmc, ein Critical-Flag auf einer eigenen CA, ein BIMI-lps=-Tag oder zusätzliche security.txt-Felder — statt sie klammheimlich zu verwerfen oder umzukehren.
Genauere Gültigkeitsprüfungen beim Laden. SPF wird jetzt nach seinem ersten all bewertet (wie es Empfänger tun), sodass +all -all korrekt beanstandet wird; ein http://-BIMI-Logo oder ein ungültiges TLS-RPT-Ziel gilt nicht mehr als „gültig“; und die TLSA-Prüfung versteht vollständige Trust-Anchor-Records sowie das generische DNS-Format, das manche Resolver liefern, sodass ein korrekter Record nicht mehr falsch gelesen wird.
Diverse kleinere Korrekturen: strengere Prüfung von MTA-STS-Hosts und max_age, CAA-Aussteller-Domains und Wildcard-Regeln, DKIM-Selektor-Länge und E-Mail-Adressen sowie Verbesserungen bei Formulierung und Barrierefreiheit.

11. Juli 2026 – Mail-Sende-Test: genauere Bewertungen und klarere Fehler

Unsichere DKIM-Signaturen gelten nicht mehr als gültig. Der Mail-Sende-Test wertet eine Signatur mit SHA-1 (rsa-sha1) oder einem schwachen RSA-Schlüssel unter 1024 Bit jetzt als fehlgeschlagen — so, wie moderne Empfänger sie behandeln — statt als grünes „gültig“. Mehrere SPF- und DMARC-Sonderfälle werden nun so ausgewertet, wie es ein echter Empfänger täte: der veraltete ptr-Mechanismus, internationalisierte (IDN-)Domains und eine Domain mit mehr als einem DMARC-Record.
Klarere Behandlung, wenn etwas schiefgeht. Kann die Analyse nicht abgeschlossen werden oder werden Sie beim Warten kurz ausgebremst, zeigt der Sende-Test jetzt eine schlichte „bitte erneut versuchen“-Meldung statt eines irreführenden Ergebnisses, und eine fehlgeschlagene Test-Adresse blockiert keinen sofortigen neuen Versuch mehr.

8. Juli 2026 – CAA: Signed HTTP Exchanges (cansignhttpexchanges)

Der CAA-Check erklärt jetzt den cansignhttpexchanges-Parameter, und der Generator kann ihn erzeugen. Wenn ein CAA-issue-Record cansignhttpexchanges=yes trägt (z. B. 0 issue "pki.goog; cansignhttpexchanges=yes"), erklärt der Domain-Check jetzt, dass er die CA berechtigt, Signed-HTTP-Exchange-(SXG-)Zertifikate auszustellen — ein Google/WICG-Mechanismus, den Sie entfernen können, wenn Sie keine Signed Exchanges ausliefern. Der CAA-Generator hat eine erweiterte Option, ihn zu erzeugen (für Google Trust Services / pki.goog), und behält ihn beim Laden verlustfrei; beim Laden eines Records mit einem anderen, nicht unterstützten issue-Parameter warnt er, bevor dieser beim Re-Export verloren ginge.

8. Juli 2026 – Record-Generatoren: die Gültigkeits-Zusammenfassung bleibt stehen

Das Laden eines Records lässt die Validierungs-Zusammenfassung nicht mehr beim ersten Klick verschwinden. Nach dem CAA-Fix gilt dasselbe Ein-Ansicht-Verhalten jetzt auch für die SPF-, DMARC-, BIMI-, MTA-STS-, TLS-RPT- und security.txt-Generatoren: Die farbige Gültigkeits-Zusammenfassung des geladenen Records bleibt oben stehen, während Sie das Formular darunter anpassen, statt beim ersten Edit von einer schlichteren Ansicht ersetzt zu werden. Auch die BIMI-Logo-Vorschau bleibt nicht mehr stehen, wenn Sie zu einer anderen Domain wechseln.

8. Juli 2026 – CAA-Generator: eine konsistente Ausgabe

Das Laden der CAA-Records einer Domain wechselt nicht mehr unerwartet das Layout. Bisher zeigte der CAA-Generator nach dem Laden eine Validierungs-Zusammenfassung und baute sich beim ersten Klick abrupt in ein anderes Einzel-Record-Layout um (und der neue Sortier-Schalter erschien nur dort). Jetzt gibt es eine einzige Ansicht: die Gültigkeits-Zusammenfassung oben, den Sortier-Umschalter und alle Records in einer Box mit Copy-All — gleich, ob man einen bestehenden Record lädt oder neu baut.

8. Juli 2026 – CAA-Generator: sortierbare Ausgabe

Die erzeugten CAA-Records erscheinen jetzt in einer klaren, sortierbaren Reihenfolge. Im CAA-Generator wird die Liste standardmäßig nach Typ gruppiert (issue, issuewild, issuemail, dann Kontakt/iodef) und innerhalb jeder Gruppe nach Flag und dann Domain geordnet – statt der Reihenfolge der Checkboxen zu folgen. Ein kleiner Sortieren nach-Umschalter über der Ausgabe erlaubt das Umsortieren nach Typ, Flag oder Domain. (Das DNS ignoriert die Record-Reihenfolge, das dient also nur der Lesbarkeit.)

8. Juli 2026 – security.txt-Generator: Telefon-Kontakte korrigiert

Ein tel:-Kontakt mit Leerzeichen funktioniert jetzt. Im security.txt-Generator wurde ein Telefon-Kontakt wie tel:+49 30 5550100 bisher an den Leerzeichen zerteilt und abgelehnt. Er bleibt jetzt erhalten und wird zu einer gültigen RFC-3966-tel:-URI normalisiert; außerdem stellt das Feld nun klar, dass eine tel:-Nummer neben E-Mail-Adresse und HTTPS-URL ein zulässiger Kontakt ist.

8. Juli 2026 – CAA-Generator: korrektes Kontakt-Telefon-Format

Das Kontakt-Telefon nutzt jetzt das vorgeschriebene internationale Format. Der CAA-Generator schreibt contactphone jetzt als RFC-3966-„Global Number“ — mit zwingendem führenden + und Ländervorwahl und ohne Leerzeichen —, also im Format, das eine Zertifizierungsstelle braucht, um es zu verwenden (CA/Browser-Forum Baseline Requirements). Eine Nummer ohne Ländervorwahl wird jetzt beanstandet statt stillschweigend übernommen. Außerdem stellt er sicher, dass contactemail immer als reine Adresse geschrieben wird – ein versehentliches mailto:-Präfix wird jetzt entfernt (anders als iodef, das eine URL ist und genau ein mailto: behält).

8. Juli 2026 – Besser auf dem Handy: kein seitliches Scrollen, größere Bedienelemente

Kein seitliches Scrollen mehr auf dem Handy. Lange Beispiel-Records (BIMI, TLSA und Ähnliches) auf den einzelnen Test-Seiten schieben die Seite auf dem Smartphone nicht mehr über den Rand hinaus — jeder Code-Block scrollt jetzt in seiner eigenen Box, und ein seitenweiter Schutz verhindert, dass ein zu breites Element das Layout verschiebt.
Größere, leichter treffbare Bedienelemente. Der Theme-Umschalter, die Aktualisieren-Buttons pro Prüfung und die Record-Studio-Bedienelemente — Erzeugen- und Kopieren-Buttons, die CAA- und Versanddienst-Checklisten samt Checkboxen und Auswahlmenüs — sind auf kleinen Bildschirmen jetzt angenehm groß für die Fingerbedienung.
Responsive BIMI-Logo-Vorschau. Die Logo-Vorschau im BIMI-Generator skaliert auf schmalen Bildschirmen jetzt sauber herunter und bricht um, statt überzulaufen.

8. Juli 2026 – Prüfung auf schwache Schlüssel und Signatur-Check über die ganze Kette

Prüfung auf kompromittierte RSA-Schlüssel. Die Schlüsselstärke-Prüfung untersucht RSA-Zertifikate jetzt auf bekannte kompromittierte Schlüssel: den ROCA-Fingerprint (CVE-2017-15361) sowie nahe beieinanderliegende Primzahlen / Fermat-faktorisierbare Moduli. Passt ein Schlüssel, lässt sich sein privater Teil aus dem öffentlichen berechnen — das Zertifikat wird als Fehler gemeldet, mit dem Hinweis, den Schlüssel zu ersetzen; genau diese schwachen Schlüssel müssen CAs laut CA/Browser-Forum ablehnen (§6.1.1.3). Gesunde Schlüssel sind nicht betroffen.
SHA-1 über die ganze Kette, nicht nur das Leaf. Die Signaturalgorithmus-Prüfung untersucht jetzt auch die ausgelieferten Intermediate-CA-Zertifikate. Ein SHA-1-/MD5-signiertes Intermediate wird markiert — Browser lehnen SHA-1 in der Kette ab, und das CA/Browser-Forum beendet die verbleibende SHA-1-Nutzung zum 15. September 2026 (§7.1.3.2.1). Selbstsignierte Roots werden korrekt ignoriert (ihre Signatur wird nicht geprüft).

8. Juli 2026 – CAA-Kontakt-Properties sowie schärfere Laufzeit- & Hostnamen-Prüfung

CAA-Kontakt-Properties im Generator und im Check. Der CAA-Generator kann jetzt einen Domain-Kontakt veröffentlichen — contactemail und contactphone —, den eine Zertifizierungsstelle für die Domain-Kontakt-Validierung nutzen kann (CA/Browser-Forum BR §3.2.2.4.13/.17); ein Kontakt lässt sich auch allein ohne issue-Regel erzeugen. Der Domain-Check erklärt diese Properties jetzt und weist bei vorhandenen CAA-Records darauf hin, dass CAs ab dem 15. März 2026 CAA-Lookups DNSSEC-validieren müssen (eine DNSSEC-signierte Zone macht Ihre CAA-Records fälschungssicher).
Zertifikatslaufzeit: Fehler statt Warnung. Ein Zertifikat mit mehr als 398 Tagen Laufzeit wird jetzt als Fehler gemeldet — Browser lehnen es seit 2020 ab, die Seite ist in Chrome, Safari und Firefox kaputt. Ein Zertifikat, das nur über dem strengeren kommenden CA/Browser-Forum-Limit für sein Ausstellungsdatum liegt (SC-081-Zeitplan: 200 Tage ab 2026, 100 ab 2027, 47 ab 2029), bleibt eine Warnung, mit klarer Formulierung, dass Browser es noch nicht ablehnen.
Zertifikate ohne Subject Alternative Name. Ein Zertifikat, das nur über den veralteten commonName (ohne SAN) zum Hostnamen passt, wird jetzt als Warnung markiert — moderne Browser ignorieren den CN und lehnen Zertifikate ohne SAN ab.
Klarere OCSP-Must-Staple-Formulierung. Angepasst an die Tatsache, dass gängige Browser Must-Staple nicht mehr hart erzwingen und OCSP zurückgezogen wird (CA/Browser-Forum SC-063), sodass ein Must-Staple-Zertifikat ohne Stapling heute eher ein Renewal-/Fehlkonfigurations-Risiko als ein Sicherheitsgewinn ist.

8. Juli 2026 – CAA: Bindung an Konto und Validierungsverfahren (RFC 8657)

Der CAA-Generator kann jetzt die RFC-8657-Parameter ergänzen. Ein neuer optionaler Abschnitt „ACME-Bindung“ bindet die Ausstellung an ein bestimmtes ACME-Konto (accounturi) und/oder an ausgewählte Validierungsverfahren (validationmethods: dns-01, http-01, tls-alpn-01). Die Parameter werden an Ihre issue/issuewild-Regeln angehängt; beim Laden eines vorhandenen Records werden sie wieder ins Formular übernommen. Der Generator warnt, wenn eine accounturi mit mehr als einer ausstellenden CA kombiniert wird (nur eine CA kann sie erfüllen), und weist eine fehlerhafte URI zurück.
Der Domain-Check liest diese Parameter jetzt aus. Der CAA-Check meldet, wenn die Ausstellung zusätzlich an ein ACME-Konto oder ein Validierungsverfahren gebunden ist, und markiert eine Property mit mehr als einer accounturi als unerfüllbar (RFC 8657 §3). Ab dem 15. März 2027 müssen alle öffentlich vertrauenswürdigen CAs diese Parameter beachten (CA/Browser-Forum Baseline Requirements §4.2.2.1.2).

8. Juli 2026 – SPF-Generator: Atlassian und SAP Cloud ergänzt

Atlassian und SAP Cloud im SPF-Generator ergänzt. Die Liste „Weitere Versanddienste" im SPF-Generator enthält jetzt Atlassian (_spf.atlassian.net) und SAP Cloud for Customer / S/4HANA Cloud / Business ByDesign (_spf.cmail.ondemand.com). Haken Sie den Dienst an, der auch für Ihre Domain Mail versendet, und sein include: wird dem Record hinzugefügt; beim Laden Ihres aktuellen SPF werden die bereits veröffentlichten Dienste angehakt. Beide Includes wurden gegen Live-DNS geprüft und lösen zu einem v=spf1-Record auf.

8. Juli 2026 – SPF-Generator: CodeTwo Email Signatures

CodeTwo Email Signatures 365 im SPF-Generator ergänzt. Die Liste „Weitere Versanddienste" im SPF-Generator enthält jetzt CodeTwo. Da CodeTwo pro Azure-Rechenzentrumsregion eine eigene Versandumgebung betreibt, hat der Eintrag ein Regions-Dropdown — wählen Sie die Region Ihres Microsoft-365-Tenants, und nur der include: dieser Region wird ergänzt, damit Sie nicht das falsche Rechenzentrum mit autorisieren. Beim Laden eines bestehenden Records wird die Region automatisch erkannt.

7. Juli 2026 – Neue IPv6-Adresse des Scanners

Die IPv6-Adresse des Scanners hat sich von 2a0a:4cc0:c2:23fb:9839:e2ff:fe98:1fd1 auf die einfachere 2a0a:4cc0:c2:23fb::1 geändert; die IPv4-Adresse (159.195.68.98) bleibt unverändert. Wer den Scanner per IP freischaltet oder blockiert, sollte seine Regeln aktualisieren — die Scanner-Seite listet immer die aktuellen Adressen. Reverse DNS bleibt forward-confirmed domainsecuritycheck.de.

7. Juli 2026 – Record Studio: Enter lädt den Record

In jedem Generator löst die Enter-Taste im Domain-Feld (bzw. im Selector-, Host- oder E-Mail-Feld, das die Abfrage parametrisiert) jetzt direkt „Aktuellen Record laden" aus — der Griff zum Button entfällt.

7. Juli 2026 – Tiefe BIMI-Validierung im Domain-Check und im Versand-Test

Die volle BIMI-Messlatte überall. Die in Record Studio eingeführten tiefen BIMI-Prüfungen laufen jetzt auch im Domain-Check und im E-Mail-Versand-Test: Das SVG-Logo wird abgerufen und validiert (Tiny PS-Profil, kein aktiver Inhalt), das Mark-Zertifikat wird verifiziert — BIMI-Kennzeichnung, Gültigkeit, Kette zu einer BIMI-autorisierten CA (DigiCert, GlobalSign, SSL.com) — und das ausgelieferte Logo muss dem im Zertifikat hinterlegten Bild entsprechen (RFC 3709). Ein BIMI-Record gilt nur als vollständig gültig, wenn all das verifiziert; die BIMI-Details im Bericht zeigen jedes Ergebnis.
Der Domain-Check meldet außerdem einen mehrdeutigen Satz mehrerer BIMI-Records, den Empfänger ignorieren.

7. Juli 2026 – VMC-Zertifikate werden jetzt kryptografisch verifiziert

Das Mark-Zertifikat wird gegen die CAs geprüft, die es tatsächlich ausstellen. Wenn der BIMI-Generator Ihr Logo in der Vorschau zeigt, verifiziert er jetzt, dass die Zertifikatskette des VMC kryptografisch bei einem gepinnten Root einer BIMI-autorisierten Zertifizierungsstelle endet — aktuell DigiCert, GlobalSign und SSL.com (gemäß BIMI-Group-Registry). Ein selbstsigniertes oder anderweitig nicht anerkanntes Zertifikat, das lediglich die BIMI-Kennzeichnung trägt, wird jetzt korrekt abgelehnt, und die Vorschau nennt die CA, zu der das Zertifikat führt.
Und das Logo ist an dieses Zertifikat gebunden. Das unter Ihrer l=-URL ausgelieferte SVG muss zum exakten Bild hashen, das die CA im VMC hinterlegt hat (RFC-3709-Logotype-Extension) — so wird auch ein nach der Ausstellung ausgetauschtes Logo erkannt. Zusammen mit der Ketten-Prüfung führt die Vorschau jetzt jede Prüfung durch, die ein Mail-Anbieter vornimmt, bevor er ein BIMI-Logo anzeigt.

7. Juli 2026 – BIMI ohne Mark-Zertifikat (VMC) ist jetzt eine Warnung

Ein BIMI-Logo ohne VMC/CMC gilt nicht mehr als sauberes „bestanden". Ein Record, der ein Logo (l=) über durchgesetztem DMARC veröffentlicht, aber kein Mark-Zertifikat (a=) hat, wird jetzt im Domain-Check, im Record Studio und im E-Mail-Versand-Test als Warnung bewertet — denn Gmail und Apple Mail, der Großteil der Postfächer, zeigen ein BIMI-Logo nur mit VMC oder CMC (Yahoo-artige Anbieter zeigen es auch ohne).

7. Juli 2026 – Record Studio: BIMI-Logo-Vorschau

Das echte Logo sehen, nicht nur den Record. Laden Sie im BIMI-Generator einen Record: Besteht er jede Prüfung — genau ein BIMI-Record, durchgesetztes DMARC, ein SVG-Tiny PS-Logo ohne aktiven Inhalt und ein aktuell gültiges Mark-Zertifikat (VMC) — wird Ihr live veröffentlichtes Logo automatisch abgerufen und angezeigt, genau so, wie es im Posteingang erscheinen würde.
Lässt sich das veröffentlichte Logo oder Zertifikat nicht vollständig prüfen (z. B. liefert die URL einen 404 oder das Zertifikat ist abgelaufen), zeigt eine Checkliste genau, was nicht stimmt. Das Logo wird aus einem gekapselten data:-Bild gerendert (Skripte im SVG können nie ausgeführt werden), und der Abruf ist SSRF-geschützt und – wie unsere anderen ausgehenden Prüfungen – rate-limitiert.

7. Juli 2026 – Neu: E-Mail-Versand-Test (MailFrom)

Eine E-Mail senden und sehen, wie Ihr Versand wirklich authentifiziert wird. Der neue E-Mail-Versand-Test (MailFrom) erzeugt eine Einmal-Adresse; senden Sie eine Nachricht von dem zu prüfenden System dorthin und erhalten Sie einen Live-Bericht über die tatsächliche Nachricht – nicht nur über deren DNS-Records. Der Test empfängt nur – er versendet selbst keine einzige E-Mail.
Er verifiziert kryptografisch jede DKIM-Signatur (RSA und Ed25519, inkl. des l=-Body-Längen-Loopholes und fehlender Übersignierung), wertet SPF gegen die echte verbindende IP aus und entscheidet die DMARC-Ausrichtung für diese Nachricht anhand der echten Public Suffix List – dieselbe Entscheidung, die ein Empfänger wie Gmail trifft.
Zusätzlich zeigt er den genutzten Transport (STARTTLS an/aus, TLS-Version und Cipher), forward-bestätigtes Reverse-DNS (FCrDNS), den IPv4/IPv6-Zustellpfad und die Nachrichten-Hygiene (Message-ID, ein gültiges Date, doppelte oder mehrwertige From-Header, SMTP-Smuggling-Zeilenenden).
Er prüft auch die BIMI-Berechtigung der Nachricht: Er löst den BIMI-Record auf (inkl. BIMI-Selector-Header und Organisationsdomain-Fallback), koppelt ihn an das DMARC-Ergebnis dieser Nachricht und eine durchgesetzte Policy und ruft das SVG-Logo ab, um ein sauberes SVG-Tiny PS zu bestätigen – die Prüfungen, die Gmail, Apple Mail und Yahoo vor dem Anzeigen Ihres Markenlogos anwenden.
Die Test-Adresse ist einmalig und läuft ab (5 Minuten), die Nachricht wird analysiert und anschließend verworfen, und der Bericht liegt auf Deutsch und Englisch vor. Ohne Anmeldung.

6. Juli 2026 – Genauigkeits-Durchgang bei DNSSEC-, DANE-, Mail- und Header-Checks

DNSSEC-Bewertung robuster. Eine gesunde, signierte Zone wird nicht mehr fälschlich mit F bewertet, wenn ein Scan auf den zweiten DNS-Resolver ausweicht oder auf einen vorübergehenden Abfragefehler stößt; und die Erläuterungen zu schwachen Schlüsselalgorithmen nennen jetzt den korrekten Standard (RSA/SHA-1 vs. MD5/DSA).
DANE-/TLSA-Urteile genauer. TLSA-Records mit unbrauchbaren Parametern lösen kein falsches Fehlurteil mehr aus; der Website-DANE-Check gleicht jetzt gegen die Zertifikatskette ab, die der Server tatsächlich sendet (ein Record, der eine nicht gesendete Root pinnt, wird korrekt bewertet); und die Formulierung für die seltenen Usage-0/1-Records beim Mailserver entspricht RFC 7672.
E-Mail-Authentifizierung. Ed25519-DKIM-Schlüssel werden jetzt erkannt statt als „Länge unbekannt“ gemeldet; die SPF-Lookup-Zählung und die Auswertung des Standardverhaltens (all) sind korrekter; ein DMARC-Record mit ungültigem sp/np-Wert wird jetzt so bewertet, wie Empfänger ihn tatsächlich behandeln (RFC 9989 §4.10.1); und MTA-STS / TLS-RPT melden nicht mehr „kein MX“, wenn die MX-Abfrage lediglich fehlgeschlagen ist.
HTTP-Security-Header. Mehrere Sonderfälle behoben: mehrere Strict-Transport-Security-Header, einige Strict-CSP-Kriterien, ein unbekannter Referrer-Policy-Wert sowie fälschlicher „Mixed Content“ durch auskommentierte oder nicht ladende Ressourcen.
Record Studio „Aktuellen Record laden“. Korrekturen im SMIMEA-Ablauf (Leerzeichen am Ende, klarere Netzwerkfehler-Meldungen, keine unnötige „Aussteller einfügen“-Warnung beim erneuten Laden eines Vollzertifikat-Records), eine SPF-Warnung für hostspezifische a:/mx:-Mechanismen, DMARC-Report-Adressen mit veraltetem Größen-Suffix und MTA-STS-Records, deren Policy-Datei nicht erreichbar ist.
Vollständige deutsche Übersetzungen. Mehrere Texte, die auf den deutschen Seiten noch englisch erschienen — Record-Prüf-Details, Server-Fehlermeldungen und der Design-Umschalter — sind jetzt übersetzt.

6. Juli 2026 – Schlichtere Werkzeugnamen im Record Studio

Jedes Werkzeug im Record Studio heißt jetzt nur noch nach seinem Record-Typ: Die Seiten SPF, DKIM, DMARC, BIMI, TLSA, SMIMEA, MTA-STS, TLS-RPT, CAA, security.txt und Null-MX haben den Zusatz „…-Record-Generator“ aus Überschrift und Titel verloren. Das liest sich übersichtlicher und weniger repetitiv; Seiten, Funktionen und URLs bleiben unverändert.

6. Juli 2026 – Aus „Record-Generatoren“ wird „Record Studio“

Die Record-Werkzeuge können längst mehr als nur erzeugen — sie laden den bereits veröffentlichten Record, bewerten ihn farbig und zeigen das dahinterstehende Zertifikat — daher heißt der Bereich jetzt Record Studio. Seine Seiten sind von /generators… nach /record-studio… umgezogen; jedes einzelne Werkzeug — der CAA-, TLSA-, SMIMEA-… Record-Generator — behält seinen eigenen Namen.

6. Juli 2026 – CAA-Generator: Certigna entfernt (stellt kein öffentliches TLS mehr aus)

Nach der heutigen Erweiterung der CA-Liste ergab ein Abgleich mit den Root-Stores von Chrome, Mozilla und Microsoft, dass Certigna (Dhimyotis) am 14. Juni 2026 die Ausstellung öffentlich vertrauenswürdiger TLS-Zertifikate eingestellt hat — der verbliebene Chrome-Root ist eingeschränkt und Apple hat ihn nie anerkannt, sodass sich kein browser-vertrauenswürdiges Zertifikat mehr beziehen lässt. Certigna wurde aus der integrierten CA-Liste entfernt (jetzt 45 CAs), die nur noch CAs führt, die tatsächlich ein browser-vertrauenswürdiges Zertifikat ausstellen können. Wer Certigna für S/MIME nutzt, kann es weiterhin über das Feld „Weitere issuemail-CAs“ autorisieren.

6. Juli 2026 – CAA-Generator: viele weitere Zertifizierungsstellen, jetzt durchsuchbar

Die integrierte CA-Liste wuchs von 13 auf 46 aktuell öffentlich vertrauenswürdige Zertifizierungsstellen (TLS und/oder S/MIME), darunter viele regionale und staatliche CAs. Ein Suchfeld filtert die Liste nach Name oder Domain, und die Liste scrollt jetzt in fester Höhe mit fixiertem Kopf. Nicht mehr vertrauenswürdige oder ausgestiegene CAs (z. B. Entrust, AC Camerfirma, e-Tugra, Chunghwa Telecom, NETLOCK, Symantec) sind bewusst weggelassen; jede andere CA lässt sich weiterhin über die Felder „Weitere … CAs“ autorisieren.

5. Juli 2026 – CAA-Generator-Grid jetzt als Tabelle mit Zeilentrennern

Das Per-CA-Auswahlraster ist jetzt eine echte Tabelle mit dezenten Zeilentrennern und Zeilen-Hover, damit man leichter sieht, welche Checkboxen zu welcher Zertifizierungsstelle gehören.

5. Juli 2026 – CAA-Generator: Critical-Flag-Auswahl pro CA

Jede CA im Grid hat jetzt eine Flag-Auswahl (0 oder 128), die das CAA-Record-Flag setzt. Standard ist 0; eine Warnung erscheint, wenn Sie Flag 128 mit issuemail kombinieren, weil eine CA, die issuemail nicht versteht, dann jede Ausstellung ablehnen müsste — auch TLS (RFC 9495 §6).

5. Juli 2026 – CAA-Generator: Grid mit issue / issuewild / issuemail pro CA

Der CAA-Record-Generator ist jetzt ein Grid: jede Zertifizierungsstelle hat eigene issue-, issuewild- und issuemail-Checkboxen, sodass Sie genau zusammenklicken können, welche Ausstellungstypen jede CA durchführen darf. „Weitere CA-Domains“ wurde durch drei Felder pro Typ (issue / issuewild / issuemail) ersetzt.

5. Juli 2026 – Doku: CAA für S/MIME (issuemail)

Die Checks-&-Bewertung-Doku hat jetzt einen eigenen Abschnitt zu issuemail (RFC 9495): wie es S/MIME-Zertifikatsaussteller einschränkt, warum es unabhängig von issue/issuewild ist, und der Flag-128-(Critical-)Interoperabilitäts-Hinweis.

5. Juli 2026 – CAA-Generator: S/MIME-Zertifikatsaussteller einschränken (issuemail)

Der CAA-Generator kann jetzt issuemail-Records (RFC 9495) erzeugen, um festzulegen, welche CAs S/MIME-(E-Mail-)Zertifikate für Ihre Domain ausstellen dürfen — ein eigenes Feld für die erlaubten S/MIME-CAs und eine Option, S/MIME ganz zu verbieten (0 issuemail ";"). Die issue/issuewild-Regeln decken S/MIME nicht ab. Auch beim Laden eines aktuellen Records wird issuemail erkannt, und der CAA-Befund im Bericht zeigt jetzt die S/MIME-Aussteller.

5. Juli 2026 – Generator-Listen sortiert & aufgeräumt

Die Zertifizierungsstellen-Liste (CAA-Generator) und die Versanddienst-Liste (SPF-Generator) sind jetzt alphabetisch sortiert, Inxmail wurde zur Versanddienst-Liste ergänzt, und die Wert-Angaben in Klammern wurden enger gesetzt.

5. Juli 2026 – Scan erkennt Newsletter-/Marketing-ESPs auf Versand-Subdomains

Die Mail-Anbieter-Erkennung im Bericht kennt jetzt 15 E-Mail-Versanddienste — Inxmail, Emarsys, Optimizely / Optivo Campaign, Mapp, artegic ELAINE, Sarbacane, Selligent, Mailingwork, SendGrid, Mailgun, SparkPost, Mailjet, Postmark, Brevo und Mailchimp Transactional (Mandrill). Dedizierte Newsletter-/Versand-Subdomains (z. B. news.example.com) richten ihren MX direkt auf den ESP; ein Scan benennt jetzt den Absender und schlägt dessen dokumentierten SPF-Include vor, falls er fehlt. Jeder Include wurde gegen Live-DNS geprüft.

5. Juli 2026 – SPF-Generator: Versanddienst-Includes per Klick hinzufügen

Der SPF-Generator hat eine neue Auswahlliste reiner Versanddienste — SendGrid, Mailchimp, Mandrill, Mailgun, Amazon SES, Postmark, SparkPost, Brevo, Mailjet, Salesforce Marketing Cloud / Pardot, Marketo, SMTP2GO, MailerLite, Campaign Monitor, Elastic Email und mehr (25 insgesamt). Haken Sie die Dienste an, die ebenfalls Mail für Ihre Domain versenden, und ihr include: wird zum Record ergänzt; beim Laden Ihres aktuellen SPF-Records werden die bereits genutzten automatisch angehakt. Jeder Include wurde gegen Live-DNS geprüft und löst zu einem v=spf1-Record auf.

4. Juli 2026 – SPF-Generator: 20 weitere Mail-Anbieter erkannt

Der „Include vom Mail-Anbieter vorschlagen“-Button des SPF-Generators erkennt jetzt 20 weitere Hosted-Mail- und Webhosting-Anbieter — darunter Spacemail, StartMail, MXroute, Mailo, Disroot, Soverin, Zone.eu, Loopia, Simply.com, OpenSRS/Hover, Atmail Cloud, Kerio Cloud, Register.it, Locaweb, UOL Host, Onet, Interia, Wirtualna Polska und Sina Enterprise Mail. Jeder SPF-Include wurde gegen Live-DNS neu geprüft und löst weiterhin zu einem v=spf1-Record auf.

4. Juli 2026 – CAA-Generator: mehr Zertifizierungsstellen

Die Liste der Zertifizierungsstellen im CAA-Record-Generator ist länger: neu sind Buypass, GoDaddy/Starfield, SSL.com, Certum, Actalis, HARICA und IdenTrust; bei Sectigo ist jetzt vermerkt, dass ZeroSSL darüber ausstellt, und Amazon deckt seinen kompletten Satz an AWS-Trust-Domains ab. Jeder Identifier wurde gegen den CCADB-CAA-Identifiers-Report und die Doku der jeweiligen CA geprüft — ein falscher Identifier kann die Ausstellung blockieren, daher gibt ein Häkchen jetzt alle gültigen Identifier der CA aus.

4. Juli 2026 – Gültigkeitsprüfung & Details beim Laden eines Records — jetzt für jeden Generator

Die farbige Gültigkeitsprüfung (grün/gelb/rot) mit geparsten Details, bisher nur im TLSA- und SMIMEA-Generator, läuft jetzt auch beim Laden des aktuellen Records im SPF-, DKIM-, DMARC-, BIMI-, TLS-RPT-, CAA-, MTA-STS- und security.txt-Generator. Sie geht über den reinen Record-Text hinaus: SPF löst Ihre Includes auf, um das echte 10-DNS-Lookup-Limit zu zählen und kaputte Ziele zu erkennen; DKIM liest Schlüsseltyp und -länge und markiert widerrufene oder schwache Schlüssel; DMARC bewertet die Policy-Stärke; BIMI prüft, ob DMARC wirklich durchgesetzt ist; MTA-STS holt und validiert die HTTPS-Policy-Datei (Modus, MX-Abgleich, max_age); security.txt wird gegen RFC 9116 geprüft, inklusive Expires-Datum; CAA und TLS-RPT ebenfalls. Unter dem Record stehen jeweils die geparsten Details (Schlüssellänge, Policy, erlaubte CAs, Ablauf, …).

4. Juli 2026 – TLSA-Generator: Zertifikatsdetails direkt unter dem passenden Record

Wenn eine Domain mehrere TLSA-Records veröffentlicht, werden die Details des Zertifikats, auf das ein Record zeigt, jetzt direkt unter genau diesem Record angezeigt statt in einer gemeinsamen Liste — so ist immer klar, welches Zertifikat zu welchem Record gehört (etwa wenn zwei Records zwei verschiedene Kettenzertifikate pinnen).

4. Juli 2026 – TLSA- & SMIMEA-Generator: Zertifikatsdetails beim Laden eines Records

Beim Laden eines Records wird jetzt auch das dahinterstehende Zertifikat angezeigt, nicht nur der reine DNS-Wert. Bei TLSA sehen Sie die vollständige Zertifikatskette, die Ihr Server ausliefert — Inhaber, Aussteller, Gültigkeit samt Restlaufzeit, Schlüsseltyp und -länge, Signaturalgorithmus, SANs und SHA-256-Fingerprint, jeweils als Leaf / Intermediate / Root gekennzeichnet. Bei SMIMEA wird — wenn das ganze Zertifikat veröffentlicht ist (ein 3 0 0-Record) — das eingebettete Zertifikat dekodiert und genauso dargestellt. So sieht man auf einen Blick, auf welches Zertifikat ein Record tatsächlich zeigt.

4. Juli 2026 – TLSA- & SMIMEA-Generator: farbige Gültigkeitsprüfung beim Laden eines Records

Wenn Sie den aktuellen TLSA- oder SMIMEA-Record einer Domain laden, ist jeder Record jetzt grün, gelb oder rot nach Gültigkeit markiert. Bei TLSA wird geprüft, ob der Record tatsächlich zum Zertifikat passt, das Ihr Server ausliefert, ob die gepinnte Position zur Usage passt und ob die Zone DNSSEC-signiert ist (was DANE voraussetzt). Bei SMIMEA werden Format und — wenn das ganze Zertifikat veröffentlicht ist (ein 3 0 0-Record) — geprüft, ob dieses Zertifikat aktuell gültig und für die Adresse ausgestellt ist, ebenfalls mit DNSSEC-Anzeige. So sehen Sie auf einen Blick, ob ein veröffentlichter Record korrekt ist.

4. Juli 2026 – SMIMEA-Generator: 3 0 0 als Default, „Aktuellen Record laden“ füllt jetzt das Formular

Der SMIMEA-Generator nutzt jetzt standardmäßig 3 0 0 (DANE-EE, vollständiges Zertifikat, kein Hash) und veröffentlicht damit Ihr ganzes Zertifikat im DNS — die richtige Wahl für S/MIME-Discovery, bei der ein Absender Ihr Zertifikat abruft, um Ihnen verschlüsselt zu schreiben (ein Hash erlaubt nur, ein bereits vorhandenes zu verifizieren). Außerdem füllt „Aktuellen Record laden“ jetzt das Formular aus dem, was veröffentlicht ist — Usage, Selector, Matching und, bei einem Vollzertifikat-Record, das Zertifikat selbst — statt nur das Ergebnis darunter anzuzeigen.

4. Juli 2026 – Neu: SMIMEA-Record-Generator (DANE für S/MIME)

Ein neuer Generator erstellt SMIMEA-Records (RFC 8162) — das S/MIME-Gegenstück zu TLSA/DANE, das ein S/MIME-Zertifikat im DNSSEC-signierten DNS an eine E-Mail-Adresse bindet. Zertifikat einfügen, Usage/Selector/Matching wählen — der Record wird lokal im Browser berechnet, inklusive der generischen RFC-3597-Form (TYPE53) für DNS-Oberflächen ohne native SMIMEA-Unterstützung. „Aktuellen Record laden“ liest einen bereits für die Adresse veröffentlichten Record. Die Hinweise sind klar benannt: DNSSEC ist Voraussetzung, der RFC ist experimentell (begrenzte Client-Unterstützung), und die Veröffentlichung legt einen Hash der Adresse offen (Zone mit NSEC3 signieren).

4. Juli 2026 – Jeder Record-Generator hat jetzt eine eigene Seite

Die Seite mit den Record-Generatoren ist jetzt eine Übersicht, die auf eine eigene Seite pro Generator verlinkt (SPF, DKIM, DMARC, BIMI, TLSA/DANE, MTA-STS, TLS-RPT, CAA, security.txt und Null MX). Jeder Generator hat eine eigene Adresse – zum Beispiel /de/record-studio/tlsa.html – und ist so leichter zu finden, zu teilen und zu speichern. Bestehende Links funktionieren weiter: Die Übersicht leitet alte Lesezeichen auf die passende Seite um.

4. Juli 2026 – SPF-/DMARC-/TLS-RPT-Generatoren: Warnung bei mehreren veröffentlichten Records

Eine Domain darf nur einen SPF-, einen DMARC- und einen TLS-RPT-Record veröffentlichen – mehr als einer ist ungültig (SPF schlägt mit einem PermError fehl, ein doppelter DMARC-Record führt dazu, dass die Policy komplett ignoriert wird, und ein doppelter TLS-RPT-Record macht den Satz ungültig). Wenn Sie im Generator den aktuellen Record laden und mehrere veröffentlicht sind, warnt er jetzt vor der ungültigen Dopplung (und lädt den ersten), statt still einen zu nehmen.

4. Juli 2026 – TLSA-Generator: unter mehreren veröffentlichten Records wählen

Wenn Sie die aktuellen TLSA-Records einer Domain laden und mehrere veröffentlicht sind (z. B. während eines Key-Rollovers oder ein DANE-EE-/DANE-TA-Paar), listet ein neues Dropdown unter dem Button „Aktuellen Record laden“ alle auf. Jeder Eintrag zeigt, welches Zertifikat der ausgelieferten Kette er pinnt; der zum aktuell ausgelieferten Zertifikat passende Record ist vorausgewählt. Die Auswahl richtet Zertifikatsauswahl und Formular auf diesen Record aus.

4. Juli 2026 – DANE-TA-Root-Pin-Hinweis (2 0 0 bevorzugen)

Ein DANE-TA-Record (Usage 2), der eine Root-CA pinnt, validiert nur, solange der Server diese Root in seiner Kette mitsendet. Eine cross-signierte Root (z. B. Let's Encrypts ISRG Root X2, cross-signiert von ISRG Root X1) fällt aus der Kette, sobald die Cross-Signatur abläuft – DANE würde dann brechen. Der Web-DANE-Check wertet einen solchen Record weiterhin als bestanden, gibt aber jetzt einen Hinweis auf einen DANE-TA-2 0 0-Record (vollständiges Root-Zertifikat im DNS), der nicht davon abhängt, dass der Server die Root mitsendet. Ein Record, der die Root bereits per 2 0 0 pinnt, gilt als robust und besteht sauber – ohne den Hinweis.
Die Root-Pin-Warnung im TLSA-Record-Generator verweist jetzt auf 2 0 0 als robuste Art, eine Root zu pinnen, und benennt die Cross-Signatur-Ablauf-Falle.

4. Juli 2026 – Robuste Root-CA-Erkennung (cross-signierte Roots)

Manche Root-CAs sind aus Legacy-Kompatibilitätsgründen zusätzlich von einer älteren Root cross-signiert und erscheinen daher in einer Kette, ohne self-signed zu sein (z. B. „Amazon Root CA 3“, präsentiert signiert von einer älteren Starfield-Root). Root vs. Intermediate wird jetzt aus dem wöchentlich aktualisierten Truststore bestimmt (Public-Key-Abgleich) statt aus der bloßen Kettenposition — solche cross-signierten Roots werden dadurch korrekt als Root erkannt.
TLSA-Record-Generator: Die Zertifikatsauswahl kennzeichnet eine cross-signierte Root jetzt als „Root-CA“ (vorher „Zwischen-CA“) und zeigt den Root-Pinning-Hinweis für DANE-TA.
Domain-Check (Web-DANE): Ein PKIX-TA-Record (Usage 0), der eine in der Kette enthaltene cross-signierte Root pinnt, wird jetzt als gültiger Root-Pin behandelt statt als Intermediate-Pin gewarnt.

4. Juli 2026 – DNSSEC-Check: Konsistenz & Genauigkeit

Zonen, die mit einem SHA-1-Signaturalgorithmus signiert sind (RSASHA1, RSASHA1-NSEC3-SHA1), fallen jetzt beim Schlüsselalgorithmus-Check durch – RFC 9905 verbietet SHA-1 zum DNSSEC-Signieren. RSA/SHA-512 und unbekannte Algorithmen bleiben eine Warnung.
Eine abgelaufene Signatur auf einer signierten, aber nicht verankerten Zone (kein DS-Record beim Parent) wird nicht mehr mit F bewertet – dort prüfen validierende Resolver die Signaturen nicht, die Erreichbarkeit ist also nicht betroffen; es ist jetzt eine Warnung.
Temporäre DNS-Abfragefehler werden nicht mehr fälschlich als „bogus“ oder „nicht signiert“ gemeldet – der Check weist nun aus, dass der Status nicht bestimmt werden konnte, und bittet um einen erneuten Versuch – einheitlich über alle DNSSEC-Befunde.
Der DS-zu-DNSKEY-Abgleich vergleicht jetzt auch den Algorithmus (RFC 4034), sodass eine 16-Bit-Key-Tag-Kollision keinen veralteten DS-Record mehr maskieren kann.

4. Juli 2026 – Mail-DANE-Check: PKIX-TA/EE-Records (Usage 0/1) gemäß RFC 7672

Für SMTP schreibt RFC 7672 §3.1.3 vor, PKIX-TA- (Usage 0) und PKIX-EE-Records (Usage 1) zu behandeln, als existierten sie nicht. Der Mail-DANE-Check berücksichtigt das jetzt: Ein MX, dessen TLSA-Records ausschließlich PKIX (0/1) sind, gilt weder als gültiger DANE-Match noch wird er als Fehler gewertet – er wird als „DANE nicht wirksam“ ausgewiesen (kein Noten-Cap), und die bestehende DANE-Konfigurations-Warnung verweist auf Usage 2/3.
Das behebt zwei Randfälle: Ein nicht-matchender PKIX-Record (z. B. PKIX-TA auf die Root) führte zuvor zu einem harten Fehler mit Noten-Cap, und ein matchender PKIX-Record wies zuvor DANE-Schutz aus, den SMTP-Clients gar nicht honorieren.

4. Juli 2026 – Web-DANE-Check: intelligentere Behandlung von PKIX-TA-Records (Usage 0)

Der HTTPS-DANE-Check unterscheidet jetzt, wie ein PKIX-TA-Record (Usage 0) genutzt wird. Wird damit ein Intermediate gepinnt, gibt es eine milde Warnung mit Hinweis: Für einen Trust-Anchor-Pin unter DNSSEC passt DANE-TA (Usage 2) beim Intermediate besser – oder ein DANE-TA-2 0 0-Record, um die vollständige Root zu pinnen.
Ein PKIX-TA-Record, der die Root-CA pinnt, wird nicht mehr fälschlich als Fehler gewertet: Server senden die Root im Handshake nicht mit, sie lässt sich also nicht gegen die ausgelieferte Kette prüfen – der Record ist aber gültig (Clients validieren ihn über den eigenen Truststore), daher weisen wir ihn jetzt informativ statt als harten Fehler aus.

4. Juli 2026 – TLSA-Generator: Root vs. Intermediate pinnen (PKIX-TA vs. DANE-TA)

Der TLSA-Generator erklärt jetzt einen feinen DANE-Punkt: DANE-TA (Usage 2) verlangt, dass das gepinnte Zertifikat in der Kette liegt, die Ihr Server tatsächlich sendet — und Server senden Intermediates, aber nicht die Root (RFC 7671 §5.2). Für DANE-TA also ein Intermediate pinnen. Um die Root zu pinnen, funktioniert PKIX-TA (Usage 0), weil es über den Truststore des Clients validiert — wobei PKIX-Usages für SMTP abgeraten werden (RFC 7672).
Wenn Sie im Ketten-Auswähler das Root-Zertifikat wählen, weist jetzt ein kurzer Hinweis darauf hin, damit Sie keinen DANE-TA-Record veröffentlichen, der nicht validiert.

4. Juli 2026 – SPF-Generator empfiehlt jetzt Softfail (~all)

Der SPF-Generator nutzt jetzt standardmäßig ~all (Softfail) statt -all – passend zur Empfehlung des Scanners. Ein kurzer Hinweis erklärt warum: Mit DMARC kann weitergeleitete Mail SPF nicht bestehen, und -all würde sie ablehnen, bevor DMARC sie über eine gültige DKIM-Signatur durchlassen kann — Softfail ist also genauso streng, hält legitime weitergeleitete Mail aber zustellbar. -all nur ohne DMARC oder für nicht versendende Domains wählen.
Auch die SPF-Hinweise des Scanners und die Dokumentation nutzen jetzt ~all in ihren Beispielen, sodass die Empfehlung über Scanner, Doku und Generator hinweg einheitlich ist.

4. Juli 2026 – Von einem Befund direkt zum passenden Record-Generator

Wenn der Bericht einen DNS-Record bemängelt, der erstellt oder korrigiert werden sollte — SPF, DKIM, DMARC, DANE/TLSA, MTA-STS, CAA, BIMI, TLS-RPT, security.txt oder ein Null-MX-Record —, verlinkt der Befund jetzt direkt auf den passenden Record-Generator, gescrollt zum richtigen Formular.
Der Link erscheint nur dort, wo es etwas zu erstellen oder zu beheben gibt, direkt neben „Warum & wie beheben?“.

4. Juli 2026 – Ihr Mail-Anbieter im Prüfbericht

Der E-Mail-Abschnitt des Berichts nennt jetzt den aus Ihren MX-Records erkannten Mail-Anbieter — Google Workspace, Microsoft 365, Zoho, Proton, mailbox.org und über 70 weitere, inklusive regionsspezifischer Varianten.
Die Angabe ist rein informativ und ändert die Note nie. Da MX die eingehende Mail beschreibt, ist der erkannte Anbieter nur bei gehosteten Mailbox-Anbietern ein starker Hinweis auf den Absender; vorgelagerte Security-Gateways (Mimecast, Proofpoint, Barracuda, Cisco …) werden erkannt und deutlich als Filter vor der eigentlichen Mailbox gekennzeichnet.
Wird ein gehosteter Anbieter erkannt, fehlt aber sein dokumentierter SPF-include: für ausgehende Mail im SPF-Record, schlägt ein Hinweis vor, ihn zu ergänzen — damit über den Anbieter versandte Mail SPF besteht.

4. Juli 2026 – Passenden SPF-Include aus Ihrem Mail-Anbieter vorschlagen

Der SPF-Generator erkennt jetzt Ihren Mail-Anbieter: Domain eingeben, auf Include vom Mail-Anbieter vorschlagen klicken, und wir lesen Ihre MX-Records, erkennen den Anbieter dahinter und ergänzen den passenden include: — für über 70 Anbieter und E-Mail-Security-Gateways (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, GMX, IONOS, mailbox.org und viele mehr, inklusive regionsspezifischer Includes).
Da MX die eingehende Mail beschreibt, SPF aber die ausgehende autorisiert, deckt der Vorschlag nur Ihren Mailbox-Anbieter ab — Sie werden daran erinnert, Includes für weitere Dienste zu ergänzen, die für Sie versenden (Newsletter, CRM, Transaktionsmail).
Eingehende Security-Gateways (Mimecast, Proofpoint, Barracuda, Cisco u. a.) werden erkannt und deutlich gekennzeichnet, da Ihr eigentlicher Versand-Anbieter dahinterliegt und sich nicht aus den MX-Records ablesen lässt.
Bereits in Ihrem veröffentlichten SPF vorhandene Includes werden erkannt und nicht doppelt hinzugefügt. Jeder vorgeschlagene Include wurde gegen einen echten, auflösbaren SPF-Record verifiziert.

4. Juli 2026 – TLSA-Record aus Ihrem Live-Zertifikat bauen

Der TLSA-Generator kann das Zertifikat jetzt direkt von Ihrem Server abrufen: Host und Port eingeben, wir bauen eine TLS-Verbindung auf (SMTP-STARTTLS auf Port 25/587, direktes TLS auf 443/465/993/995, DNS over TLS auf 853, implizites FTPS auf 990), lesen die präsentierte Zertifikatskette und erzeugen den fertigen 3 1 1-Record.
Präsentiert der Server eine ganze Kette, können Sie wählen, welches Zertifikat gepinnt wird — Leaf für DANE-EE, eine Zwischen- oder Root-CA für DANE-TA — die Usage passt sich automatisch an.
Ein Klick auf Aktuellen Record & Zertifikat laden erledigt alles auf einmal: liest den in Ihrem DNS veröffentlichten TLSA-Record, ruft Ihr Live-Zertifikat ab und wählt automatisch genau das Zertifikat vor, das der Record pinnt — per Hash-Abgleich ermittelt — so sehen Sie sofort, was live ist, und können es bearbeiten.
Usage, Selector oder Matching-Type ändern — der Record wird lokal neu berechnet, das Zertifikat bleibt im Formular, keine zweite Abfrage nötig.
Die Menüs für Usage und Matching-Type decken jetzt alle Werte aus RFC 6698 ab: PKIX-TA (0) und PKIX-EE (1) neben DANE-TA (2)/DANE-EE (3) sowie Full (0 — exakter Abgleich ohne Hash) neben SHA-256/512, jeweils mit Hinweis, wo PKIX-Usages unüblich sind (SMTP, RFC 7672) und dass Full große Records erzeugt (RFC 7671).
Ein Protokoll-Auswähler (tcp / udp / sctp) setzt das Transport-Label im Record-Namen (_port._proto), gemäß RFC 6698 §3 — Standard tcp. udp/sctp betreffen DTLS-/SCTP-Dienste; der Live-Zertifikat-Abruf bleibt TCP-only, dort fügen Sie das Zertifikat ein.
Wir haben online keinen anderen TLSA-Generator gefunden, der den Record aus Ihrem Live-Zertifikat erzeugt.
Die Verbindung ist SSRF-geschützt und auf die Standard-Mail-/Web-TLS-Ports begrenzt; an unseren Server gehen nur Host und Port, und es wird ausschließlich das öffentliche Zertifikat gelesen — nie ein privater Schlüssel.
Klarere Erläuterung des Certificate-Usage-Felds — neben der Usage-Auswahl und in der DANE/TLSA-Dokumentation: PKIX (0/1) verlangt weiterhin, dass das Zertifikat gegen eine öffentliche CA validiert, und fügt nur einen Pin hinzu, während DANE (2/3) die öffentliche CA ersetzt und den DNSSEC-signierten Record selbst zum Trust-Anchor macht; TA (0/2) pinnt die ausstellende CA, EE (1/3) das Zertifikat selbst. Der Generator nutzt jetzt standardmäßig Port 25, den Haupt-Anwendungsfall von DANE.

3. Juli 2026 – Veröffentlichten Record in die Generatoren laden

Jeder Generator hat jetzt einen Button „Aktuellen Record laden“: Domain eingeben, und der aktuell im DNS veröffentlichte Record wird ausgelesen und ins Formular geladen – so bearbeiten Sie einen bestehenden Record, statt bei null anzufangen.
Funktioniert für SPF, DKIM, DMARC, BIMI, TLSA, MTA-STS, TLS-RPT, CAA und security.txt (die MTA-STS-Policy-Datei und security.txt werden per HTTPS geholt).
Die Generatoren laufen weiterhin vollständig im Browser; nur die abzufragende Domain geht an unseren Server, der sie im öffentlichen DNS nachschlägt – genau wie ein Scan. Nichts sonst, was Sie eingeben, und kein erzeugter privater Schlüssel wird je übertragen.

3. Juli 2026 – DNS-Record-Generatoren

Neue Seite Record-Generatoren mit 10 Generatoren: SPF, DKIM, DMARC, BIMI, TLSA, MTA-STS, TLS-RPT, CAA, security.txt und ein Record-Satz für nicht sendende Domains.
Alles läuft lokal im Browser – die DKIM-Schlüsselerzeugung nutzt WebCrypto, nichts wird übertragen.
Die erzeugten Records folgen den aktuellen Standards, einschließlich DMARCbis (RFC 9989).
Der BIMI-Generator und der BIMI-Check unterstützen das Avatar-Präferenz-Tag (avp=) aus dem aktuellen BIMI-Draft.

3. Juli 2026 – Komplette deutsche Version, DMARCbis & security.txt

Die gesamte Seite ist jetzt vollständig zweisprachig (Englisch/Deutsch) – einschließlich des Live-Scan-Berichts mit allen Findings, Empfehlungen und Detailansichten.
Vollständiger deutscher Dokumentations-Korpus veröffentlicht: jede Check-Erklärung plus die Bewertungsmethodik.
Dokumentation in sechs Themenseiten pro Sprache aufgeteilt – Web-TLS, HTTP-Security-Header, DNS, DNSSEC, E-Mail-Authentifizierung, Mail-TLS & DANE – mit verlinkender Übersicht; Scan-Findings verlinken direkt auf die passende Themenseite.
Sechs neue deutsche Seiten ergänzt: Tool-Vergleich, Scanner-Details, Cipher-Suites, Truststore, Impressum und Datenschutzerklärung.
DMARC-Prüfung tiefgreifend an DMARCbis (RFC 9989–9991) angepasst: vollständiger DNS-Tree-Walk, Bestimmung der Organisationsdomain, Salvage-Regeln für fehlerhafte Records, Testmodus-Semantik (t=y) und ein neues DMARC-Syntax-Finding. Die Dokumentation umfasst jetzt 106 Checks.
security.txt-Prüfung auf vollständige RFC-9116-Validierung ausgebaut: Syntax, Contact- und Canonical-URIs, Ablaufregeln und PGP-Signatur-Rahmen.
Unvollständige Zertifikatsketten werden jetzt gegen die ~1.700 öffentlich bekannten CCADB-Intermediate-Zertifikate gegengeprüft (wöchentlich zusammen mit dem Root-Store aktualisiert): Eine Kette, die Browser noch vervollständigen können, wird von einer wirklich nicht vertrauenswürdigen unterschieden und mit B statt T bewertet.
Die Gesamtnote erscheint jetzt erst, wenn alle sechs Module abgeschlossen sind; eine Warteanzeige ersetzt die laufende Teilnote.
Besucher mit deutschsprachigem Browser sehen auf der englischen Startseite einen ausblendbaren Hinweis auf die deutsche Version – ganz ohne Cookies.
Die häufigen Fragen sind von der Startseite auf eine eigene FAQ-Seite umgezogen – die Startseite wird dadurch schlanker.

2. Juli 2026 – Auffindbarkeit & Genauigkeits-Fixes

Neue Seite Tool-Vergleich: Abdeckung im Vergleich zu SSL Labs, securityheaders.com, internet.nl, Hardenize und MxToolbox.
Deutsche Landingpages ergänzt: eine deutsche Startseite mit Scan-Formular plus Themenseiten zu DANE für Mailserver, SPF/DKIM/DMARC, DNSSEC und HTTP-Security-Headern.
Die Check-Dokumentation wird jetzt statisch in die Seiten gerendert; robots.txt, Sitemap, llms.txt, Open-Graph-Bilder und strukturierte Daten kamen hinzu – für Suchmaschinen wie für KI-Assistenten.
Alle DMARC-Verweise auf die neue RFC-Familie 9989–9991 umgestellt (DMARCbis, ersetzt RFC 7489).
Reihe von Genauigkeitsfehlern behoben: SPF-Include-Lookups mit DNS-Serverfehlern ergeben jetzt einen temporären Fehler statt eines harten Fails, die HSTS-Preload-Prüfung berücksichtigt TLD-weites Preloading (.dev/.app) und anstehende Entfernungen, und ein fälschliches Bestehen der CSP-frame-ancestors-Prüfung wurde korrigiert – neben weiteren Fixes.
Zeitweise leere Antworten bei HTTP-zu-HTTPS-Weiterleitungen und Fehlerseiten behoben (Absturz eines Webserver-Moduls).

15. Juni 2026 – Anycast-Anbieter & DKIM-Selektoren

Anycast-DNS-Anbieter-Erkennung auf über 35 Anbieter ausgebaut – jeder gegen echte Nameserver-Daten verifiziert – gegen falsche Single-Point-of-Failure-Warnungen.
Die DKIM-Erkennung prüft jetzt 91 kuratierte Provider-Selektoren statt zuvor 30.

14. Juni 2026 – DNS-Tiefenprüfungen & weniger False Positives

Zonemaster-inspirierte DNS-Prüfungen ergänzt: Probe auf offenen Zonentransfer (AXFR) bei jedem Nameserver, Routbarkeits- und Reverse-DNS-Prüfung der Nameserver-IPs sowie Nameserver-Diversität auf Ebene der autonomen Systeme.
Die Nameserver-Verteilungs-Prüfung erkennt jetzt große Anycast-DNS-Anbieter (Cloudflare, AWS Route 53, Google Cloud DNS und weitere) und erzeugt keine falschen Single-Point-of-Failure-Warnungen mehr; eine Detailansicht listet Adressen und Netz jedes Nameservers.
Die HSTS-Preload-Prüfung fragt zusätzlich die offizielle hstspreload.org-Liste ab und meldet Domains, die eingetragen sind, aber keinen konformen Header mehr senden.
Der Signatur-Hash beim Schlüsselaustausch wird jetzt pro TLS-Version bewertet – mit Detailansicht der betroffenen Cipher-Suites; False Positives auf modernen Servern, die SHA-224 nur für Legacy-Clients tolerieren, wurden beseitigt.
DNS-Bewertung neu kalibriert: SOA-Replikations-Timer sind informativ, fehlendes IPv6 wiegt geringer, und ein fehlender CAA-Record oder eine fehlende RPKI-ROA ist ein Hinweis statt einer Warnung.
Cross-Origin-Isolation-Header (COOP/COEP) fließen nicht mehr in die Note ein – vorhandener Schutz erscheint als „good“, Fehlen nur als Hinweis.
Die Technologie-Preisgabe-Prüfung hält Produktnamen mit Ziffern (etwa AmazonS3) nicht mehr für Versionsnummern.
HTTP/3-Unterstützung wird jetzt mit echten Ende-zu-Ende-QUIC-Proben verifiziert statt nur über den Alt-Svc-Header.
Den ungefähren SSL-Labs-Score aus dem Web-Modul entfernt; maßgeblich bleiben die einzelnen Findings.
Der Zeitstempel in der Übersicht zeigt, wann die Prüfungen tatsächlich liefen – nicht, wann die Seite neu geladen wurde.
Die PGP-signierte security.txt dieser Seite wurde mit dediziertem Security-Kontakt neu signiert und ihr Ablaufdatum an den Signaturschlüssel angeglichen.

13. Juni 2026 – Mailserver-Tiefenanalyse & Backend-Profiling

Mailserver-Prüfungen erweitert: Forward-confirmed Reverse DNS für jede MX-Adresse, Downgrade-Proben auf Legacy-TLS 1.0/1.1 sowie Vertrauensprüfung der Zertifikatskette (vertraut, selbstsigniert, DANE-EE-gepinnt).
Mail-Cipher-Suites werden jetzt pro TLS-Version auf dem primären MX enumeriert; bis zu fünf MX-Hosts werden getestet und auf identische Konfiguration verglichen.
Mail-TLS-Ergebnisse erklären, warum dieser Scanner Legacy-TLS 1.0/1.1 auf Mailservern findet, die manche anderen Tools übersehen.
Neuer Web-Backends-Check: Die IPv4- und IPv6-Backends hinter einer Domain werden TLS-profiliert (repräsentative Adressen vollständig, weitere per Handshake bestätigt), Konfigurationsunterschiede zwischen Backends werden gemeldet, und bekannte CDNs (CloudFront, Akamai, Fastly, Cloudflare und weitere) werden benannt.
Zwei Transparenz-Seiten ergänzt, die den Root-CA-Truststore des Scanners und seinen vollständigen Cipher-Suite-Katalog live zeigen.
Scan-Ergebnisse werden bis zu einer Stunde zwischengespeichert – mit Aktualisieren-Buttons pro Modul, „Alle neu prüfen“ und Cooldown-Countdown; die Datenschutzerklärung dokumentiert den In-Memory-Cache.

12. Juni 2026 – RFC-Audit, QUIC-Probe & Redesign

Alle Prüfungen gegen die aktuellen RFCs auditiert und sieben neue Checks ergänzt: MX-Ziel-Validierung, SOA-Timer, DNSKEY-Schlüsselstärke, CDS/CDNSKEY, fehlende SPF-Include-Ziele, DMARC-Testmodus und Cookie-Präfixe (__Host-/__Secure-).
Erste DMARCbis-Anpassung (RFC 9989): Testmodus-Warnung (t=y), kombinierte Subdomain-Policy-Bewertung (sp=/np=) und aktualisierte Tag-Referenz.
DNSSEC-Algorithmus-Bewertung auf RFC 9904 aktualisiert; Online-Signer mit kurzen Signaturfenstern lösen keine falschen Ablauf-Warnungen mehr aus.
Echte QUIC-Versions-Negotiation-Probe (RFC 8999/9000) ergänzt, die HTTP/3 direkt verifiziert; ein zusammengefasstes HTTP-Versionen-Finding zeigt HTTP/1.1, HTTP/2 und HTTP/3 an einer Stelle.
TLS-1.3-Cipher-Suites werden jetzt einzeln geprüft statt abgeleitet, und der Cipher-Score misst, was tatsächlich aktiviert ist.
Die Cipher-Detailansicht zeigt die offiziellen IANA-/RFC-Namen zusätzlich zu den OpenSSL-Namen.
Die Zertifikats-Laufzeitprüfung folgt dem CA/Browser-Forum-Fahrplan: erlaubtes Maximum sinkt von 398 auf 200, 100 und schließlich 47 Tage.
DANE-Behandlung nach RFC 7672 verfeinert: Namens- und Ablauf-Abweichungen werden bei verifizierten DANE-EE-Pins ignoriert, teilweise TLSA-Abdeckung über die MX-Hosts wird gemeldet.
OCSP-Stapling wird als „nicht anwendbar“ ausgewiesen bei Zertifikaten von CAs, die OCSP abgeschaltet haben (Let's Encrypt, Google Trust Services, HARICA).
Die Client-Kompatibilitäts-Simulation deckt jetzt aktuelle Chrome-, Firefox- und Safari-Versionen plus Android 14, Java 17 LTS und OpenSSL 3.x ab.
Scans prüfen zuerst, ob die Domain existiert, und zeigen bei nicht existierenden Domains eine klare Meldung; E-Mail-Checks für www-Hostnamen bewerten die Elterndomain – mit transparentem Hinweis im Bericht.
30 Korrektheits- und Robustheitsprobleme aus einem vollständigen Code-Audit behoben.
Komplettes visuelles Redesign mit neuer Display-Schrift, Ultramarin-Akzentfarbe und überarbeiteten Light-/Dark-Themes; zusammengehörige Findings wurden zu weniger, klareren Zeilen zusammengeführt, und Modul-Karten behalten beim Scannen eine konstante Höhe.
Eigene Seiten für Impressum und Datenschutzerklärung ergänzt.
Diese Seite selbst läuft jetzt mit HTTP/3 (QUIC), hybridem Post-Quanten-Schlüsselaustausch (X25519MLKEM768) und ausschließlich 256-Bit-Cipher-Suites und veröffentlicht HTTPS-DNS-Records.

11. Juni 2026 – Genauigkeits-Review & Bericht-UX

Vollständiger Review aller Scan-Module mit rund 70 Genauigkeits-Korrekturen: DNSSEC unterscheidet jetzt kaputte (bogus) Zonen und veraltete DS-Records von unsignierten, mehrere CSP-Header werden korrekt zusammengeführt, SPF-/DKIM-/DMARC-Parsing wurde gehärtet, DANE wird strikt nach RFC 7671 validiert, und Resolver-Ausfälle zählen nicht mehr als Findings.
Neue Checks: HTTP/2-Unterstützung, CNAME am Zonen-Apex (RFC 2181), HTTPS-zu-HTTP-Redirect-Downgrades und Null MX.
Scans von Hostnamen wie www werden fair bewertet: Prüfungen auf Zonenebene laufen gegen die umschließende Zone, CAA-Records werden den DNS-Baum hinauf gesucht (RFC 8659), und Domains ohne Mailversand werden nicht für fehlende DKIM-Schlüssel oder DMARC-Reportadressen abgewertet.
Aufklappbare Detailansichten zu jedem Finding ergänzt: Zertifikatsketten, Cipher-Listen, TLSA-Records, DNSKEY-/DS-Tabellen, erklärte SPF-Terme und DMARC-Tags, rohe Response-Header.
Mobile-Layout überarbeitet und Sticky-Mini-Übersicht mit Live-Noten ergänzt; Übersichtsbalken springen direkt zum jeweiligen Modul.
Manuellen Theme-Umschalter (Auto/Dunkel/Hell) und neuen Status „good“ ergänzt – ein hellgrüner Haken für erfüllte, aber nicht bewertungsrelevante Kriterien.
Missbrauchsschutz per Cloudflare Turnstile vor der Scan-API ergänzt.
Neue Seite Über den Scanner (erkennen & blockieren); Scanner-Anfragen identifizieren sich mit einem transparenten Bot-User-Agent, der dorthin verlinkt.
Internationalisierte Domainnamen werden als Eingabe akzeptiert, und die Gesamtnote bleibt ehrlich – sie zeigt „unvollständig“, wenn ein Modul fehlschlägt.
Diese Seite selbst erreicht jetzt 100 % bei internet.nl mit strikter Content Security Policy ohne unsafe-inline – und dieselben Strict-CSP-Kriterien wurden als Check in den Scanner aufgenommen.
PGP-signierte security.txt (RFC 9116) für diese Seite selbst veröffentlicht.

Juni 2026 – Erstveröffentlichung

Start mit sechs Modulen – Web-TLS, Mail-STARTTLS & DANE, DNS, DNSSEC, E-Mail-Authentifizierung und HTTP-Security-Header – benotet von A+ bis F, mit Erklärungen und Behebungstipps zu jedem Finding.
Bewertungs-Caps nach SSL-Labs-Vorbild: Ein einzelnes schweres Problem (abgelaufenes Zertifikat, nicht vertraute Kette, …) deckelt die Modulnote; Sondernoten T (nicht vertrauenswürdig) und M (Hostname-Abweichung).
Cipher-Suite-Enumeration mit Erkennung schwacher Cipher, Erkennung der Server-Cipher-Präferenz und Handshake-Simulation für Referenz-Clients.
Zertifikatsprüfungen auf SHA-1-/MD5-Signaturen, Certificate Transparency (SCTs), OCSP Must-Staple und OCSP-Stapling; Validierung gegen einen kombinierten Truststore aus Betriebssystem-, Node.js- und Mozilla/CCADB-Roots, wöchentlich aktualisiert.
Überwachung der DNSSEC-Signatur-Restlaufzeit und NSEC-/NSEC3-Analyse nach RFC 9276; RPKI-Route-Origin-Validierung der Haupt-IP-Adresse.
Tiefenanalyse der HTTP-Header: CSP-Qualität, Referrer-Policy-Werte, Reporting, Permissions-Policy, Cross-Origin-Isolation, CORS, Cookie-Flags und Informationslecks.
Jeder Check dokumentiert: was geprüft wird, warum es zählt, wie bewertet wird und wie man es behebt.