Changelog

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

27. September 2026 – SPF: kaputte include- und redirect-Ziele werden mit Grund genannt; DMARC: eine Report-Freigabe mit doppeltem Tag zählt nicht

SPF-Ziele mit mehreren Records oder Syntaxfehler sowie include- und redirect-Schleifen gelten als kaputt, und das Record Studio folgt redirect=-Ketten wie der Scan. Ein include:- oder redirect=-Ziel, das mehr als einen SPF-Record oder einen mit Syntaxfehler veröffentlicht, oder eine Kette, die zu einem Namen auf ihr selbst zurückführt, lässt Empfänger mit PermError antworten (RFC 7208 §4.5, §4.6, §4.6.4), genau wie ein Ziel ohne Record; der Scan bewertet die Zeile „SPF-include/redirect-Ziele gültig“ dafür jetzt mit Fehler und nennt jedes Ziel mit seinem Grund. Das Record Studio liest wie der Scan die ganze redirect=-Kette und ihren ersten all-Term.
Ein Autorisierungs-Record für externe DMARC-Reports, der ein Tag wiederholt, zählt nicht mehr als Freigabe. RFC 9990 liest den Record unter <domain>._report._dmarc.<ziel> wie einen DMARC-Policy-Record, und ein doppeltes Tag macht ihn ungültig, RFC-konforme Empfänger senden dorthin also keine Reports. Scan, Record Studio und Live-Mail-Test warnen jetzt davor und sagen, wenn ein nur in Groß-/Kleinschreibung wiederholtes Tag das Ergebnis vom Empfänger abhängig macht.

25. September 2026 – DMARC: ungültige pct-Werte werden bewertet und schließen das BIMI-Gate

Ungültige pct-Werte werden bewertet und öffnen das BIMI-Gate nicht mehr. Einen DMARC-Record, dessen pct-Wert die Syntax von RFC 7489 verletzt – 0050, 0100, 150 –, lasen Live-Mail-Test, Record Studio und BIMI-Prüfung als pct=100, obwohl Empfänger auf RFC-7489-Stand einen solchen Wert je nach Parser unterschiedlich lesen und Google für BIMI pct=100 verlangt. Live-Mail-Test und Record Studio bewerten ihn jetzt so, wie es der Scan schon tat, und keine der drei Oberflächen wertet das Logo noch als anzeigefähig.

24. September 2026 – DMARC: ein doppeltes Tag macht den Record ungültig, ein unbeantworteter Tree-Walk-Schritt ergibt keine Note, das Record Studio nennt Formular-Änderungen

Ein DMARC-Record mit doppeltem Tag gilt als ungültig, und ein Tree-Walk-Schritt ohne Antwort ergibt keine Note mehr. RFC 6376 §3.2, auf den RFC 9989 für DMARC verweist, erklärt eine Tag-Liste mit wiederholtem Tag für ungültig; RFC-konforme Empfänger überspringen einen solchen Record und setzen den Tree Walk fort – der Scan bewertet ihn am geprüften Namen als Fehler, Record Studio, Live-Mail-Test und Report-Viewer sagen es ebenso. Bleibt eine Abfrage auf dem Weg durch den Baum ohne Antwort und könnte sie ändern, welcher Record gilt, bewerten Scan und Live-Mail-Test den gefundenen Record nicht mehr, und das Record Studio zeigt ihn nicht mehr als geerbte Policy: Jede dieser Oberflächen sagt, dass sich die Policy nicht feststellen ließ, und nennt die Abfrage ohne Antwort.
Der Vergleich im Record Studio nennt Verhaltensänderungen, die Sie im Formular vornehmen. Wer einen veröffentlichten DMARC-Record im Formular änderte – p=reject auf none, ein strengeres Alignment, t=y –, bekam „Wirkungsgleich“ gemeldet; der Vergleich listet jetzt jede Änderung auf und warnt, wenn sie die Policy abschwächt.

23. September 2026 – SPF auf Hostnamen ohne MX nach der geltenden DMARC-Policy bewertet; Norm-Pills an allen Policy-Findings

Ein Hostname ohne MX und ohne SPF ist nur entschuldigt, solange eine durchgesetzte DMARC-Policy ihn deckt. Die geltende Policy ist der eigene DMARC-Record des Hosts, sonst sp (bzw. p) der Organisationsdomain; quarantine oder reject belässt die Warnung mit Gewicht 1, none, kein Record oder eine durch t=y auf none gesenkte Policy macht daraus ein fail wie bei jeder anderen Domain, und ein DMARC-Lookup ohne Antwort hinterlässt eine Warnung, die das sagt.
Norm-Pills stehen jetzt auch an den Policy-Findings – Nameserver, DNSSEC, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, Zertifikate, Weiterleitungen und HTTP-Header nennen die Pflichtstufe von BSI, Internet.nl und NIST, und jedes dieser Findings führt das zitierte Dokument unter seinen Quellen.

19. September 2026 – Kryptografie nach den BSI-Richtlinien bewertet: 3000-Bit-Schlüssel, Cipher-Suites mit BSI-, Internet.nl- und NIST-Spalte, Norm-Pills

RSA-, DSA- und DH-Schlüssel unter 3000 Bit ergeben jetzt eine Warnung. BSI TR-02102-2 verlangt seit 2023 3000 Bit; das Website-Zertifikat, das MX-Zertifikat (mit neuer Schlüsselspalte), der Empfangstest und die DNSSEC-Schlüssel folgen dem, ein 2048-Bit-Schlüssel fällt also von pass auf warn – ohne Notendeckel. ECDSA P-256, Ed25519 und Ed448 bestehen unverändert.
Cipher Suites werden nach BSI TR-02102-2 bewertet, mit Internet.nl und NIST daneben als Vergleichsspalten. Eine Regel für die Website und den Mailserver: fail, wenn alle drei Rahmenwerke eine Suite verwerfen, warn, wenn das BSI sie nicht empfiehlt oder keine Liste sie trägt, pass, wenn das BSI sie empfiehlt – Static-RSA-Suites ergeben damit auf beiden Wegen eine Warnung (bisher bestanden sie auf der Website und fielen auf dem Mailserver durch), während DHE und die CBC-SHA256/384-Suites auf dem Mailserver bestehen. Die Spalte „Bewertung“ der Suiten-Tabelle weicht BSI, Internet.nl und NIST, und die kryptografischen Findings tragen Norm-Pills mit der Pflichtstufe jedes Rahmenwerks.
Ein Mailserver, der nichts Neueres als TLS 1.0 oder 1.1 anbietet, fällt durch, und die Cipher-Suite-Reihenfolge auf dem Mailserver ist eine Warnung statt eines Durchfallens. Kein Rahmenwerk lässt einen Mailserver ohne TLS 1.2 zu, dieser Fall deckelt das Modul deshalb auf C – überall dort, wo ein solcher Host mit unserem Client überhaupt eine Sitzung zustande bringt, der selbst nichts unterhalb von TLS 1.2 anbietet und einen solchen Host in der Praxis als „keine TLS-Sitzung“ meldet. TLS 1.0/1.1, das nur als Fallback neben TLS 1.2 angeboten wird, bleibt eine Warnung ohne Deckel, was TR-03108 für die opportunistische Zustellung ausdrücklich erlaubt, und ein Reihenfolgeverstoß, der bisher durchfiel, warnt jetzt.
Wildcard-Zertifikate werden benannt, ohne Note. BSI TR-03116-4 verbietet sie für Bundesprojekte, das CA/Browser Forum erlaubt sie – der Bericht sagt das für die Website und je MX.

18. September 2026 – Mailserver-TLS bewertet wie Internet.nl: Cipher-Klassen, Cipher-Reihenfolge, DH-Parameter, Key-Exchange-Hash

Die Cipher Suites des Mailservers werden jetzt nach der NCSC-NL-Klassifikation von Mai 2025 bewertet, der auch Internet.nl folgt. Statisches RSA, CBC mit SHA-1 und CCM8 gelten als unzureichend und lassen den Check durchfallen; DHE, Camellia, ARIA und ECDHE mit CBC-SHA256/384 laufen aus und ergeben eine Warnung. Das Urteil stammt aus je einer Verbindung pro Klasse statt aus den aufgelisteten Suites, deshalb verliert ein Server, der eine solche Suite noch annimmt, hier auch dann Punkte, wenn die Liste an der Stichprobengrenze endet.
Neuer Check: die Reihenfolge der Cipher Suites auf dem Mailserver. Ein Server, der auslaufende Suites noch annimmt, muss die guten und ausreichenden vorziehen; folgt er stattdessen der Reihenfolge des Absenders und wählt eine auslaufende Suite, fällt der Check durch und nennt beide Suites. Gemessen so, wie Internet.nl es misst, für TLS 1.2 und darunter.
Diffie-Hellman-Parameter und der Hash des Key-Exchange werden benotet. Eine Finite-Field-DH-Gruppe unter 3072 Bit fällt jetzt durch, und eine elliptische Kurve außerhalb der empfohlenen Menge wird benannt; ein mit SHA-1 signierter Key-Exchange fällt durch, SHA-224 warnt, und bestanden gibt es nur, wo ein stärkerer Hash tatsächlich gemessen wurde. Zusammen mit den strengeren Cipher-Klassen verschiebt das Noten: ein Mailserver, der statisches RSA annimmt oder mit SHA-1 signiert, kann eine Notenstufe verlieren.

16. September 2026 – Anycast-Nameserver: weitere Betreiber erkannt, Zonen mit zwei Anbietern benannt

Mehr Zonen auf Anycast-Nameservern gelten nicht mehr als gebündelt. Akamai Edge DNS, DNS Made Easy/Constellix, Cloudflare, Bunny DNS, Oracle Cloud (mit Dyn), Rage4 und UltraDNS werden jetzt auch dann erkannt, wenn die Nameserver den Namen des Kunden tragen, und eine Zone, die zwei Anycast-Anbieter kombiniert, nennt beide. Der Bericht ergänzt, was er nicht sehen kann: ob die Maschine hinter einer solchen Adresse dem Anbieter gehört oder dem Zoneninhaber.

15. September 2026 – Post-Quantum-OpenPGP-Signaturen verifiziert; Anycast-Nameserver am Origin-AS und an veröffentlichten Adressbereichen erkannt; Links auf einen Abschnitt des Berichts

Post-Quantum-OpenPGP-Signaturen werden verifiziert (RFC 9980). Der security.txt-Check und der Live-E-Mail-Test verifizieren jetzt Signaturen mit den Post-Quantum-Verfahren aus RFC 9980 – den ML-DSA+EdDSA-Komposita (ein Komposit zählt nur, wenn beide Hälften halten) und SLH-DSA –, geprüft gegen die Testvektoren des Standards selbst. Nutzt eine Signatur einen Algorithmus, den dieser Scanner nicht verifiziert, nennt der Bericht jetzt den Algorithmus als Ursache statt eines fehlenden Schlüssels.
Anycast-Nameserver werden auch am Origin-AS erkannt, und ein Multi-Origin-Präfix zählt jedes AS, aus dem er announct wird. Zonen bei RcodeZero (nic.at) – auch mit den Kundennamen sec1/sec2.rcode0.* und White-Label-Namen auf denselben Adressen – galten als „alle in einem AS“; die Nameserver-Verteilung liest jetzt jedes Origin-AS eines Präfixes wie Zonemaster CONNECTIVITY03 und erkennt den Betreiber am AS, wo der Hostname nichts sagt. RPKI validiert jetzt jeden Origin eines solchen Präfixes (RFC 6811 bewertet je Route), benennt einen ungültigen oder nicht ermittelbaren Origin und validiert höchstens fünf je Adresse.
Weitere Anycast-Anbieter werden auch dann erkannt, wenn ihre Nameserver den Namen des Kunden tragen. Zonen, deren Nameserver nach dem Kunden statt nach dem Anbieter benannt sind, gelten nicht mehr als „alle in einem AS“, wenn diese Adressen zu einem erkannten Anycast-DNS-Betreiber gehören. Wo dasselbe Netz auch Server trägt, die ein Kunde selbst betreibt, bleibt die Warnung: Von außen lässt sich beides nicht unterscheiden.
Wo ein Betreiber veröffentlicht, welche seiner Adressen DNS beantworten, werden Nameserver darauf auch unter dem Namen des Kunden erkannt. Der Punkt davor ließ eine Lücke: In einem Netz, das auch Maschinen trägt, die Kunden selbst betreiben, blieb die Warnung stehen, weil sich beides von außen gleich ansieht. Wo der Betreiber diese Liste veröffentlicht, ist das nicht mehr so – für AWS Route 53 gibt es sie, und eine Zone, deren Nameserver auf diesen Adressen den Namen des Kunden tragen, gilt jetzt als Anycast statt als gebündelt; eine Adresse, die dieselbe Veröffentlichung einem anderen Dienst zuordnet, dagegen nicht.
Ein Link kann auf einen Abschnitt, ein Thema oder eine einzelne Prüfung des Berichts zeigen. Die Adresszeile folgt dem, was Sie öffnen (?domain=…#dns, #dns/caa, #dns/caa/caa-smime), und ein Link-Symbol an jedem Abschnitt, Themen-Panel und jeder Prüfzeile kopiert diesen Link. Wer ihn öffnet, sieht den Abschnitt, das Thema mit seinen Details oder die einzelne Prüfung aufgeklappt, sobald das Modul geladen ist – auf der deutschen wie der englischen Seite.

14. September 2026 – Neue RFCs umgesetzt: Finite-Field-DHE in TLS 1.2 veraltet, zwei Nameserver je Adressfamilie, noRevAvail-Zertifikate, Glue-only-Nameserver, schärfere ECH- und CDS-Prüfungen, Header-Schutz und Algorithmenbindung bei signierter Mail, Post-Quantum-Schlüsselvereinbarung benannt

Der Website-Test benennt die TLS-1.3-Schlüsselvereinbarung und ob der Server den Post-Quantum-Hybrid X25519MLKEM768 annimmt (RFC 10024). Eine neue informative Zeile, Gewicht 0: Die ausgehandelte Gruppe wird aus dem Handshake gelesen, wo die Laufzeit sie benennt, sonst über einen Handshake mit genau einer angebotenen Gruppe bestimmt. Ein abgelehnter Handshake wird als Antwort auf diese eine Verbindung berichtet; ein fehlender Hybrid wird nie behauptet.
SHA-1-Signaturen des Schlüsselaustauschs auf dem Mailserver (RFC 9155). Der Mailserver-Test gibt jetzt einen zusätzlichen STARTTLS-Handshake auf dem repräsentativen MX aus, der nur SHA-1-Signaturschemata anbietet, und vermerkt ohne Note, wenn der Server seinen TLS-1.2-Schlüsselaustausch weiterhin mit SHA-1 signiert – der Website-Test misst das seit August. Als Ablehnung zählt nur ein Alert, den der Server selbst gesendet hat; eigene Timeouts lesen sich als „nicht ermittelt“.
Signierte Mail: Header-Schutz, Algorithmenbindung, internationalisierte Adressen (RFC 9788, RFC 8933, RFC 9598, RFC 9980). Der E-Mail-Live-Test liest den Header-Schutz einer S/MIME- oder PGP/MIME-Signatur (hp=clear oder cipher), warnt, wenn die geschützte From-Adresse von der äußeren abweicht und kein Zertifikat oder Schlüssel an sie gebunden ist, benennt das überholte RFC-8551-Schema und meldet eine saubere Inline-PGP-Signatur als für konforme Clients ungeschützt (RFC 9787). Eine S/MIME-Signatur, die Inhalt und Attribute mit zwei verschiedenen Digest-Algorithmen bindet, fällt jetzt durch, das Attribut CMSAlgorithmProtection wird gelesen und angezeigt, internationalisierte Zertifikatsadressen werden verglichen, und die Post-Quanten-Algorithmen von OpenPGP werden benannt. Der Mailserver-Test warnt bei einem MX-Zertifikat, dessen Name nur über den commonName passt, was MTA-STS nicht akzeptiert (RFC 8461 §4.2).
Ein Nameserver, der nur über das Glue der Elternzone erreichbar ist, fällt nicht mehr durch (RFC 9471). Die Nameserver-Zählung liest das Glue jetzt ohne zusätzliche Abfrage aus dem Referral der Elternzone: Ein solcher Server warnt mit eigener Erklärung und zeigt im Drill-down „nur als Glue in der Elternzone“, und ein abgeschnittenes Referral wird nie für den Delegationsvergleich verwendet.
Schärfere ECH-, CDS- und From-Prüfungen (RFC 9849, RFC 10026, RFC 6854, RFC 7504). Das Abzeichen „+ ECH“ braucht eine ECH-Konfiguration der registrierten Version, und ein gemischter HTTPS-Record-Satz wird benannt; das CDS/CDNSKEY-Finding warnt, wenn der signalisierte Schlüssel nicht im eigenen DNSKEY-Satz der Zone steht, und sagt Zonen mit nur einem Typ, dass BCP 246 beide verlangt. Der E-Mail-Live-Test liest Gruppensyntax in From, prüft bei mehreren From-Adressen den Sender-Header, und eine 521-SMTP-Begrüßung wird als „Host nimmt keine Mail an“ gemeldet statt als mögliches Greylisting.
Finite-Field-DHE auf TLS 1.2 wird jetzt wie statisches RSA bewertet (RFC 10015). Die Forward-Secrecy-Findings des Website-Tests, des Mailserver-Tests und des E-Mail-Live-Tests warnen, wenn eine TLS-1.2-Verbindung eine DHE-Suite ausgehandelt hat oder anbietet: Die Sitzung ist weiterhin forward-secret, aber RFC 10015 verbietet diesen Schlüsselaustausch in TLS 1.2 ganz, die einzige Abhilfe dort ist ECDHE. Kein Notendeckel; TLS-1.3-Gruppen sind nicht betroffen. Das DH-Parameter-Finding behält seine Größenleiter und nennt ECDHE als Abhilfe für TLS 1.2, und die Cipher-Suite-Seite markiert die veralteten Schlüsselaustausch-Verfahren, statt sie „akzeptabel“ zu nennen.
Zwei Nameserver je Adressfamilie (RFC 10001, das neue BCP 91). Das AAAA-Finding besteht erst ab zwei IPv6-fähigen Nameservern und warnt bei einem; ein neues Zwillings-Finding prüft die IPv4-Seite genauso und fällt durch, wenn kein Nameserver einen A-Record hat, weil eine IPv6-only-Delegation für die meisten Resolver unerreichbar ist. Beide lesen veröffentlichte Records und kosten keine zusätzliche Abfrage.
Zertifikate, die keine Sperrinformationen ankündigen (RFC 9608). Ein Zertifikat mit der Erweiterung noRevAvail besteht das Sperrstatus-Finding mit eigener Erklärung, statt bemängelt zu werden; eines, das noRevAvail mit einem CRL Distribution Point oder einem OCSP-Responder kombiniert, fällt durch, weil der RFC Relying Parties anweist, es als ungültig zu behandeln.

11. September 2026 – Ein Live-E-Mail-Test für Senden und Empfangen; ein DMARC-Report-Viewer liest Ihre Aggregate-Reports im Browser

Versand-Test und Empfangs-Test sind jetzt eine Seite: der E-Mail-Live-Test. Senden Sie eine Nachricht an eine Einmal-Adresse und lesen Sie den Versandbericht; setzen Sie vor dem Erzeugen der Adresse das Häkchen „Auch die Empfangsseite testen“, läuft der Zustelltest gegen Ihre MX mit derselben Nachricht, ohne zweite E-Mail. Das Häkchen ist standardmäßig aus – ohne Ihre Wahl geht nichts an Ihre Server.
Die alten Adressen funktionieren weiter. /de/send-test.html und /de/receive-test.html leiten auf die neue Seite weiter, die zweite mit vorgesetztem Häkchen.
Neue Seite: der DMARC-Report-Viewer. Legen Sie die Aggregate-Reports ab, die Empfänger an Ihre rua-Adresse schicken (.xml, .xml.gz, .zip), und sehen Sie jede Versandquelle mit DMARC-, DKIM- und SPF-Ergebnis, eine Ampel in Rot, Orange oder Grün je Quelle und je Report, die Override-Gründe des Empfängers und jedes RFC-9990-Feld erklärt. Reports werden nur in Ihrem Browser gelesen; nichts wird hochgeladen.
Vier Eingänge. Die DMARC-Referenz öffnet ihr kommentiertes Beispiel im Viewer, der Test-Hub und der DMARC-Generator verlinken ihn, und der Scan-Bericht bietet ihn in der rua-Zeile an, sobald eine mailto:-Adresse veröffentlicht ist.
DMARC-Report-Viewer: optionaler DNS-Check. Ein Button bestimmt die Organisationsdomain jeder im Report genannten Domain per RFC-9989-Tree-Walk und holt den heute veröffentlichten DMARC-Record, sodass sich Relaxed-Alignment-Urteile und ein seit dem Report geänderter Record beurteilen lassen. Es werden nur Domainnamen gesendet, nichts wird gespeichert.

9. September 2026 – Der DNS-Lookup nimmt für SMIMEA eine E-Mail-Adresse entgegen; CDNSKEY, DNAME und der alte SPF-Typ kommen in den Scan

E-Mail-Adresse eingeben, SMIMEA- oder OPENPGPKEY-Record bekommen. Beide Records liegen unter einem gehashten Owner-Namen (<hash>._smimecert.<domain>, <hash>._openpgpkey.<domain>), den niemand von Hand tippt. Der Lookup nimmt jetzt die Adresse selbst an, berechnet den Owner-Namen in Ihrem Browser und fragt nur diesen Namen ab; die Adresse verlässt Ihr Gerät also nicht. SMIMEA ist die Vorgabe, OPENPGPKEY eine Wahl in der Typliste; das Ergebnis zeigt den abgefragten Namen mit Kopierknopf. Der Owner-Name funktioniert weiterhin als direkte Eingabe.
Ein Record in drei Schreibweisen ist keine „Uneinigkeit“ mehr. Manche Resolver liefern einen Zertifikats- oder Schlüssel-Record in der generischen Hex-Form (\# 1793 …), andere in der üblichen Darstellung; der Vergleich dekodiert die generische Form jetzt vor dem Vergleich, sodass ein SMIMEA-Record mit vollem Zertifikat nicht mehr wie ein Propagationsproblem aussieht.
Das DNSSEC-Modul liest CDNSKEY neben CDS. Eine Zone, die nur CDNSKEY veröffentlicht (RFC 7344 erlaubt jeden Typ allein), erscheint nicht mehr als „nicht veröffentlicht“; sind beide Typen veröffentlicht und widersprechen sich, warnt die Zeile. Der Drilldown ergänzt, ob die Elternzone einen DSYNC-Notify-Endpunkt (RFC 9859) veröffentlicht, ob sie also über ein neues CDS benachrichtigt werden kann, statt es abfragen zu müssen.
Zwei neue Zeilen: ein DNAME am Zonen-Apex und ein übrig gebliebener SPF-Record-Typ. Das DNS-Modul vermerkt einen Apex-DNAME (RFC 6672) mit seinem Ziel – erlaubt, aber er beantwortet jeden Namen unterhalb des Apex von anderswo. Das E-Mail-Modul warnt vor dem veralteten SPF-Record-Typ (99), den RFC 7208 ausgemustert hat: Empfänger ignorieren ihn, und er weicht mit der Zeit von der TXT-Policy ab.
DNAME und SPF im DNS-Lookup. Beide Typen lassen sich über die Resolver-Matrix abfragen; DNAME ist Teil der Übersicht.

8. September 2026 – Der Downgrade-Test funktioniert jetzt für Absender bei Microsoft 365 und Google

Der TLS-Downgrade-Test erreicht Absender hinter großen Mailanbietern. Microsoft 365, Google Workspace und ähnliche Plattformen verschicken jede Nachricht von einer anderen Adresse; ihre korrekte Verweigerung ließ sich deshalb Ihrem Bericht nicht zuordnen, und der Test lief einfach ab. Ein verweigernder Host zählt jetzt, sobald sein Reverse-Name bestätigt zu dem Anbieter gehört, der Ihre erste Nachricht zugestellt hat, und der Bericht sagt es, wenn ein Urteil darauf beruht.

6. September 2026 – Ein Knopf öffnet den ganzen Scan-Bericht; die Live-Mail-Tests lesen sich wie der Bericht

„Alles aufklappen“ neben „Alle neu prüfen“. Der Kopf der Übersicht im Scan-Bericht hat einen neuen Knopf.
Erst die Übersicht, dann „Was zuerst zu beheben ist“, dann ein Rahmen je Richtung. Versand- und Empfangs-Test gliedern ihr Ergebnis jetzt wie der Scan-Bericht.
Der zweite Bericht eines Tests erscheint darunter, und zwar geöffnet. Beim Versand-Test bekommt die freiwillige Prüfung Ihrer eigenen Empfangsseite einen eigenen Rahmen unter dem Sende-Ergebnis, sodass sich beim Eintreffen dieses Berichts nichts darüber verschiebt.
Eine vollständig verifizierte Prüfung verschwindet nicht mehr aus der Check-Anzahl. Die drei Zähler über einem Modul – bestanden, Warnungen, fehlgeschlagen – ließen ein viertes Urteil aus, das eine Prüfung tragen kann: „gut“, vergeben, wenn an einer Prüfung alles verifiziert ist.

5. September 2026 – Die Ergebnisseite ist neu gegliedert: Übersicht, Triage-Liste und Themen-Chips in jedem Modul

Erst die Übersicht, dann die Triage, dann die drei Dienst-Bereiche. Der Bericht beginnt jetzt mit einer Übersicht aus drei Dienst-Spalten – Website, E-Mail und DNS –, die je ihre zwei Module mit Note und Check-Anzahl als Sprunglinks aufführen.
Themen als Chips, ein Klick zu genau einer Karte. Jeder Modulblock zeigt seine Themen jetzt als Chips in der Kopfzeile; ein Klick auf einen Chip öffnet nur dieses Thema als Karte, während der Pfeil-Button daneben alle Themen auf einmal öffnet.
Gleiche Bedienung auf dem Handy, der Druck zeigt den aufgeklappten Stand. Auf dem Handy läuft der gesamte Bericht einspaltig mit derselben Bedienung wie auf dem Desktop; der Modulkopf zeigt dort den Ein-Satz-Befund („TLSv1.3, Zertifikat von …“) statt der feststehenden Frage des Moduls, und Themen-Chips wie Übersichtszeilen sind mindestens 44 px hoch wie jedes andere Bedienelement.

2. September 2026 – Record Studio: nichts bleibt von der vorherigen Domain übrig

Wer eine andere Domain eintippt, bekommt die Werte der vorherigen nicht mehr untergeschoben. Seit heute früh tragen die Generatoren die Einstellungen einer Domain nicht mehr in eine andere – allerdings nur dann, wenn ein Lookup für den neuen Namen ohne Record zurückkam.
Ein fehlgeschlagener Lookup gilt nicht mehr als ein Lookup, der nichts gefunden hat. Lässt sich eine DNS- oder HTTPS-Abfrage nicht durchführen, sagt der Server das ausdrücklich, statt eine Abwesenheit zu melden – und das Formular behält in diesem Fall seinen Inhalt, denn es wurde nichts gefunden, was ihn ersetzen könnte.

29.–31. August 2026 – Referenz-Clients gemessen statt geschätzt; Mozillas datierter Vertrauensentzug

Jeder simulierte Client bietet jetzt an, was der echte anbietet. Die Kompatibilitätsprüfung fragt, ob aktuelle Browser, Android, Java und OpenSSL sich mit Ihrem Server noch einigen können.
Auch die älteste TLS-Version, die ein Client akzeptiert, ist jetzt geprüft. Ein Profil sagt mehr als nur, welche Cipher Suites ein Client anbietet – es legt auch die älteste TLS-Version fest, die dieser Client noch spricht.
Ein Client, den wir nicht erreicht haben, gilt nicht mehr als inkompatibel. Bekommt eine der sechs Proben gar keine Antwort, sagt das Finding das seit jeher – das liegt an unserem Netz, nicht an Ihrem Server.
Der Scan kennt jetzt Mozillas zweite, datierte Form des Vertrauensentzugs. Bisher stellte der Bericht eine Frage zur Root, auf die Ihr Zertifikat zurückführt: Steht sie noch in Mozillas aktueller TLS-Root-Menge? Diese Frage kann einen Stichtag nicht sehen. Mozilla entzieht das Vertrauen aber auch „ab einem Datum“: Die Root bleibt in der Menge, doch Firefox lehnt jedes danach ausgestellte Zertifikat ab.
Dokumentation gegen ihre Quellen geprüft. In der Woche davor wurden weit über hundert Sätze der Erklärungen mit ihren Primärquellen verglichen und überall dort korrigiert, wo sie über die Quelle hinausgingen oder für Browser sprachen, die niemand gemessen hatte.

28. August 2026 – CSP-Kriterien gegen internet.nl gemessen, OpenPGP-Subkeys müssen ihre Bindung beweisen, unsichtbare Zeichen sichtbar gemacht

Die strengen internet.nl-Kriterien im CSP-Befund werden jetzt gegen diesen Checker gemessen statt nacherzählt. Eine wörtliche Kopie des internet.nl-Codes läuft neben unserer über dieselben Policies.
Das Record Studio prüft externe DMARC-Report-Ziele jetzt so wie der Scan. Es sah nur mailto:-Adressen an, eine als https-URI angegebene Report-Adresse wurde also ganz übersprungen; und es hörte bei „der Freigabe-Record existiert“ auf.
Unsichtbare Steuer- und Bidi-Zeichen in einem geprüften Wert erscheinen jetzt als [U+202E], statt still zu wirken. Ein TXT-Record, ein Zertifikatsname oder eine EHLO-Begrüßung kann ein Right-to-Left-Override enthalten, das die Leserichtung der umgebenden Zeile umkehrt, ohne ein einziges Zeichen zu ändern – ein Record lässt sich so lesen wie etwas, das er nicht ist.
Eine mit einem Unterschlüssel erstellte Signatur wird jetzt daraufhin geprüft, ob es der Unterschlüssel dieses Betreibers ist. Ein veröffentlichter Schlüsselblock kann Schlüsselpakete enthalten, die nichts darin an den Hauptschlüssel bindet – bisher sah diese Prüfung schlicht nicht hin.
Ein <img> oder <script>, das innerhalb eines Skripts oder eines Stylesheets steht, gilt nicht mehr als Element der Seite. Browser parsen es nicht – es wird nichts dafür abgerufen –, dieser Scanner tat es aber, und so konnte ein JavaScript-Bundle, das ein solches Fragment als Zeichenkette enthält, als unsicherer Mixed Content oder als Cross-Origin-Skript ohne Subresource Integrity gemeldet werden: über Markup, das nie gerendert wird.
Eine Zone, deren Nameserver nicht auflösen, verliert nicht mehr still vier Prüfungen. Hat keiner der Nameserver, die eine Zone veröffentlicht, eine eigene Adresse, gibt es nichts, wohin eine Direktabfrage gehen könnte – und drei Prüfungen (autoritative Antwort, Übereinstimmung der Server, Delegation passt zur Elternzone) samt dem Platzhalter, der eigentlich für sie einspringt, fielen aus dem Bericht heraus.
Ein CORS-Header, der niemandem etwas erlaubt, wurde als Erlaubnis gemeldet. Access-Control-Allow-Origin: https://*.example.com passt zu gar keinem Origin, denn Browser vergleichen den Header Byte für Byte mit dem anfragenden Origin.
Der Sende-Test benennt jetzt eine zurückgezogene Adress-Zertifizierung. Zwei sehr verschiedene Lagen lasen sich bisher gleich. Wenn Ihre Signatur gegen einen veröffentlichten OpenPGP-Schlüssel aufgeht, nennt der Bericht, woher dieser Schlüssel stammt.

27. August 2026 – Zertifikatslaufzeiten, wie Browser sie durchsetzen; Header und HTML gelesen, wie Browser sie parsen

Eine Zertifikatslaufzeit wird jetzt gegen die Grenze bewertet, die Browser wirklich durchsetzen – und die sind keine 398 Tage mehr. Chrome folgt der stufenweisen Verkürzung des CA/Browser Forums – 200 Tage für ab dem 15. März 2026 ausgestellte Zertifikate, 100 Tage ab März 2027, 47 Tage ab März 2029 – und zeigt darüber eine ganzseitige Fehlermeldung.
„Kein Mangel gefunden“ und „wir haben nie hingesehen“ werden bei großen RSA-Schlüsseln auseinandergehalten. Einen RSA-Schlüssel auf bekannt gebrochenen Inhalt zu prüfen (ROCA, Fermat-faktorisierbare Primzahlen) kostet bei sehr großen Schlüsseln Sekunden Rechenzeit, deshalb hört dieser Scanner oberhalb von 8192 Bit auf.
Eine Website-Note kann nicht mehr dadurch steigen, dass unsere eigenen Proben abgewiesen wurden. Der Scanner begrenzt, wie viele TLS-Proben er gleichzeitig gegen einen Host öffnet. Greift diese Grenze – bei einer stark ausgelasteten Seite oder unter Last hier –, laufen einzelne Prüfungen nicht, und ihre Punkte verlassen die Rechnung.
Unsere eigenen Grenzen und unsere eigenen Fehlschläge werden unterschieden. Eine Cipher-Enumeration, die an unserem eigenen Deckel endet, ist etwas anderes als eine, die an einer fehlgeschlagenen Probe endet – und nur Letztere wird als fehlende Abdeckung gemeldet.
Eine Permissions-Policy mit einem Leerzeichen um das = wird jetzt als ignoriert gemeldet – denn genau das tun Browser damit. camera =() oder camera= () macht den Header als Structured Field ungültig, und ein einziges fehlerhaftes Member genügt, damit ein Browser den ganzen Header verwirft: Es ist dann überhaupt kein Feature eingeschränkt.
Cookie-Attribute werden so gelesen, wie ein Browser sie liest. Um einen Attributnamen herum stehen nur Leerzeichen und Tabulatoren – ein geschütztes Leerzeichen gehört nicht dazu.
Eine Content-Security-Policy wird jetzt genau dort getrennt, wo ein Browser sie trennt. Der Parser behandelte jedes Unicode-Leerzeichen als Trenner. Eine Policy mit einem geschützten Leerzeichen – script-src, dann dieses Zeichen, dann 'none' – wurde hier als bestmögliches Ergebnis gemeldet, „keine Skriptquelle ist erlaubt, alle Skripte werden blockiert“, während Chrome jedes Skript der Seite ausführte: dort wird die ganze Direktive verworfen.
Die Delegations-Prüfung liest die Zonenseite jetzt von den Nameservern der Zone selbst. Sie vergleicht die Nameserver, die Ihr Registrar in der Elternzone veröffentlicht, mit den NS-Records in Ihrer Zone.
Ein neu gestarteter TLS-Downgrade-Test weist eine an die vorige Adresse gesendete Nachricht nicht mehr ab. Der Test vergibt eine Einmal-Adresse und beobachtet 90 Sekunden lang. Schließt dieses Fenster, ohne dass Ihr Anbieter sich verbunden hat – der Normalfall, wenn er die Zustellung noch nicht versucht hat –, können Sie ihn einfach erneut starten.
Deckelt ein Befund die Note eines Moduls, hängt die angezeigte Begründung nicht mehr an der Reihenfolge der Prüfungen. Deckelten zwei Befunde dieselbe Note, nannte der Bericht einen von beiden nach seiner Position – und das uneinheitlich: bei manchen Deckeln gewann der erste, bei anderen der letzte.

26. August 2026 – Der Versand-Test bewertet Forward Secrecy; Mailserver bekommen die Fragen der Website; Urteile, die von der Reihenfolge abhingen

Die Forward Secrecy Ihrer Zustellung zählt jetzt für die Note. Der Sende-Test hat gemessen, ob die Verbindung Ihres Servers zu uns Forward Secrecy bietet, hat es in der Detailzeile und in der Tabelle gedruckt – und nie zählen lassen.
Nameserver, die sich widersprechen, wiegen jetzt so schwer wie einer, der nicht antwortet. Liefern Ihre Nameserver auf dieselbe Frage unterschiedliche Records, bekommt ein Teil des Internets eine andere Antwort als der Rest – einen anderen Mailserver, eine andere Webadresse.
Der Sende-Test zieht für seine eigenen Grenzen keine Punkte mehr ab. Trägt eine Nachricht mehr OpenPGP-Signaturpakete, als diese Prüfung verifiziert, sagte der Bericht das korrekt – und berechnete es trotzdem.
Ein DMARC-Record ohne p-Tag wird nicht mehr angewandt, als wäre sein sp-Tag die Policy. Ein Record wie v=DMARC1; sp=reject sieht streng aus, aber Empfänger müssen einen Record ohne gültiges p-Tag als p=none behandeln – oder ganz ignorieren, wenn keine Report-Adresse dabeisteht.
Diffie-Hellman-Parameter werden jetzt auch auf dem Mailweg gemessen. Ein Mailserver, der diesen Schlüsselaustausch mit einer zu kleinen Gruppe fährt, hat dieselbe Schwäche wie ein Webserver mit derselben Einstellung – und bisher sah das Mail-Modul die Gruppengröße überhaupt nicht an, während das Website-Modul im selben Bericht es sehr wohl tat.
Jede TLS-Probe bietet jetzt dieselbe Protokollliste an wie der Haupt-Handshake. Acht Nebenproben – der Versionstest, die Cipher-Enumeration, der Cipher-Reihenfolgetest, der Signaturalgorithmus-Test und die sechs Referenzbrowser-Simulationen – kündigten nur HTTP/1.1 an, während der Haupt-Handshake auch HTTP/2 ankündigte.
DNSSEC: Eine auf unserer Seite gescheiterte Zonen-Abfrage meldet nicht mehr „DNSSEC ist nicht aktiviert“. Die Signaturschlüssel liegen am Zonen-Apex; wird ein Hostname wie www.example.com geprüft, muss also zuerst die umschließende Zone gefunden werden.
Der Website-Check beschuldigt nicht mehr die Seite, wenn unser eigenes Netz das Problem ist. Scheitert die Namensauflösung oder die Route aus diesem Scanner heraus, kommt gar keine Verbindung zustande – das wurde als „Website über HTTPS nicht erreichbar“ gemeldet und kostete das ganze Modul seine Note.
Eine gescheiterte MX-Abfrage wird nicht mehr als „diese Domain hat keine MX-Records“ gemeldet. Kommt die DNS-Abfrage nicht zustande, sagt das Record Studio das jetzt und bittet um einen neuen Versuch, statt eine Aussage über die Domain zu treffen.
Mail-TLS: Bei manchen Mailservern liefen die Verschlüsselungsprüfungen still gar nicht. Beim Aufwerten einer Mailverbindung auf TLS bot der Scanner einen Protokollnamen an, den eine Minderheit der Mailserver so beantwortet, dass der Handshake scheitert.
SPF: Bei zwei veröffentlichten Records hängt die Note nicht mehr davon ab, welchen Ihr Resolver zuerst liefert. Zwei Records lassen die ganze Policy scheitern, bevor irgendetwas davon ausgewertet wird – der Syntaxfehler, der Lookup-Zähler und vor allem ein ip4:0.0.0.0/0-Loch, das das ganze Internet autorisiert, wurden aber aus dem jeweils ersten Record gelesen, sodass derselbe Record-Satz zwei verschiedene Berichte ergab.
Die Mail-Tests können nicht mehr endlos auf „Warte auf Ihre E-Mail“ stehen bleiben. Scheiterte die Anzeige des Berichts, hielt die Seite das für eine Netzstörung und wiederholte denselben scheiternden Schritt alle 2,5 Sekunden – ein Erfolg war ausgeschlossen, und auf dem Bildschirm änderte sich nie etwas.
Ein Befund, der schwer genug ist, die Modulnote zu deckeln, wird jetzt auch dann benannt, wenn die Note ohnehin darunter liegt. Ein Deckel überstimmt den Durchschnitt – erwähnt wurde er bisher nur, solange er die Note tatsächlich gesenkt hat.
Die Gesamtnote sagt jetzt, was ein fehlendes Modul mit ihr macht. Ein Modul, das nicht bewertet werden konnte, verlässt den Durchschnitt vollständig – sein Gewicht zählt weder im Zähler noch im Nenner –, die Zahl deckt also weniger ab als die Prüfung vorsieht und kann höher ausfallen als bei einem vollständigen Lauf.

25. August 2026 – Eine Note sagt, wie viel sie abdeckt; Record Studio, Empfangs- und Versand-Test: wem ein Fehler gehört

Eine Weiterleitungskette über fünf Hops hinaus ergibt jetzt keine Note für die Seite statt einer schmeichelhaften. Eine Zwischenantwort, die zufällig Security-Header trägt – ein alltägliches CDN-Setup –, konnte eine Bestnote für eine nie gelesene Seite erzeugen, und die Kette absichtlich zu verlängern genügte, damit unbequeme Befunde nicht mehr zählen.
Eine Prüfung, die wir nicht durchführen konnten, hebt die Note nicht mehr. Sie verlässt die Rechnung vollständig und zählt damit nie gegen die Domain – genau das allein hieß aber: je weniger gemessen wurde, desto besser das Ergebnis.
Wo ein Notendeckel einen Abschnitt herunterzieht, sagt die Gesamtnote das jetzt. Die Gesamtzahl ist ein Durchschnitt über die sechs Abschnitte und trägt deren Deckel nicht: Ein wegen eines abgelaufenen Zertifikats auf F gedeckelter Abschnitt ging weiterhin mit seinem ungedeckelten Prozentwert ein.
DKIM-Schlüssel-Records werden als Records erkannt, nicht per Textsuche. Die alte Prüfung traf an beliebiger Stelle der Zeichenkette.
Die Record-Generatoren bewerten SPF jetzt wie der Scan. Ein Record mit ungültiger Adresse oder unbekanntem Mechanismus wurde dort als „gültig“ angezeigt, während der Scan ihn durchfallen ließ – auf derselben Seite, deren Generator genau diesen Wert zurückwies.
Die einzeilige Modul-Zusammenfassung hat jetzt drei Zustände statt zwei. Ein Kreuz bedeutete „nicht vorhanden oder kaputt“ – eine MTA-STS-Policy, die veröffentlicht ist und durchsetzt und nur einen kleinen Makel hat (manchmal nur gegenüber einer Schwelle von uns, nicht der Norm), stand damit als Kreuz direkt über einer Zeile, die sagt, TLS werde erzwungen.
Ein Record, der Ihre Root-CA pinnt, gilt nicht mehr als defekt. Es gibt zwei Trust-Anchor-Usages, und die Norm stellt für sie gegenläufige Regeln auf: Bei DANE-TA (2) muss das Zertifikat wirklich im Handshake des Servers mitkommen, bei PKIX-TA (0) darf es allein im Trust-Store des Clients liegen – Clients sind sogar verpflichtet, die Kette darüber hinaus weiterzubauen.
Ihre Note hängt nicht mehr davon ab, wie ausgelastet dieser Tester war. Unsere eigene Handshake-Frist, unser eigenes Verbindungsbudget, unsere eigene Grenze dafür, wie viel Serverantwort wir aufheben – jede davon senkte die Note, und eine deckelte sie mit den Worten „echter Mailverlust“ auf C. Ein Lauf, in dem unsere Kapazität ausging, sagt das jetzt und zieht nichts ab.
Ein Mailserver, der kurz „gerade nicht“ sagt, gilt nicht mehr als defekt. Eine temporäre Abweisung der Begrüßung wurde als „Mail an diesen Server wird im Klartext zugestellt“ gemeldet – Fehlschlag samt Notendeckel –, obwohl wir gar nicht dazu kamen, nach Verschlüsselung zu fragen.
Verschlüsselung wird am Handshake beurteilt, nicht an der Ankündigung. Ein Server, der STARTTLS anbietet und dann nicht herstellt, wurde benotet, als funktioniere die Verschlüsselung.
Eine Signatur gilt nicht mehr als gültig, wenn sie nur einen Teil Ihrer Nachricht abdeckt. Eine OpenPGP-Signatur schützt, was in ihrem Rahmen steht – nicht Text davor, nicht einen Footer, den eine Mailingliste dahinter gehängt hat, nicht eine zweite HTML-Fassung neben dem signierten Text und nicht zusätzliche Body-Teile in einer PGP/MIME- oder S/MIME-Nachricht.
Eine abgelaufene OpenPGP-Signatur ist nicht mehr gültig. Signaturen können ein Ablaufdatum tragen, und dieses Datum wurde nie gelesen – eine Signatur, die GnuPG als abgelaufen zurückweist, galt hier als gut.
Unsere eigenen Grenzen werden nicht mehr als Fehler Ihrer Nachricht gemeldet. Einer Nachricht mit mehr als 300 Teilen wurde gesagt, ihre MIME-Grenze fehle oder sei nicht abgeschlossen; mehr als 16 KB Header vor dem Content-Type ließen vier Prüfungen kommentarlos aus dem Bericht verschwinden; mehr Signaturen, Attribute oder Zertifikate, als wir verarbeiten, erschienen als „die Signatur verifiziert nicht“.

24. August 2026 – Kapazität: ein Lookup verdrängt keinen laufenden Check mehr; Versand-Test-Urteile, die uns nicht zustanden

Die Record-Lookups und die DNS-Lookup-Seite greifen nicht mehr auf den letzten Rest der geteilten Kapazität zu. Beide arbeiten bewusst ohne die Menschprüfung, weil ihre Seiten kein Widget tragen.
Ein hängendes Lookup hält seinen Platz nicht mehr bis zum nächsten Neustart. Die Prüfungen hatten diese Zusage bereits, die beiden Lookup-Endpunkte nicht.
Wenn unser eigener Listener Ihre Nachricht abgeschnitten hat, wurde es Ihnen angelastet. Endet eine Nachricht ihre Datenphase so, dass unser Listener sie nachsichtiger annimmt als der Standard es erlaubt, kann die Nachricht an dieser Stelle abgeschnitten werden – und der DKIM-Body-Hash bricht.
Eine DNS-Abfrage, die bei uns scheitert, wird nicht mehr zur Aussage über Ihr DNS. Blieb die DMARC-Abfrage ohne Antwort, behauptete der Bericht „kein DMARC-Record gefunden“ und listete Name für Name, dort sei nichts veröffentlicht.
Ein DMARC-Record mit t=y wird jetzt mit der Policy berichtet, die Empfänger wirklich anwenden. Das Tag senkt die Policy um eine Stufe: bei p=reject wird quarantäniert, bei p=quarantine gar nichts getan, und auf p=none wirkt es nicht.
Ein DKIM-Schlüssel im Testmodus schneidet nicht mehr besser ab als gar kein DKIM. Der Standard verlangt von Empfängern, Mail eines Signierers im Testmodus genau wie unsignierte zu behandeln; die Signatur bringt also nichts – trotzdem war die Note eine ganze Stufe besser als bei fehlender Signatur.
Eine Signatur, die einen Teil Ihres Nachrichtenkörpers unsigniert lässt, ist nicht mehr einfach „gültig“. Das l=-Tag begrenzt, wie viel vom Body die Signatur abdeckt; alles dahinter lässt sich unterwegs ersetzen und besteht trotzdem.
Ein fehlerhafter CAA-Wert liest sich nicht mehr wie ein Zertifikats-Ausfall. Ein Wert, der nicht der Syntax entspricht, autorisiert niemanden – CAA-Autorisierungen sind aber additiv, die übrigen Properties gelten also weiter.
MX-Records, die wir nicht lesen können, gelten nicht mehr als gar keine MX-Records – daraus entstand bisher eine Aussage darüber, wohin die Mail der Domain geht, hergeleitet aus Records, die niemand lesen konnte.
Einem ratenlimitierten Mailserver wurde bescheinigt, er biete kein STARTTLS. Weist ein Exchanger einen Scan schon bei der Begrüßung ab – häufig, wenn dieselbe Domain wiederholt gescannt wird –, kommen wir nie zur Frage nach Verschlüsselung.
Empfangs-Test: Ein Greylisting erzwingt nicht mehr die schlechteste Note. Ein Exchanger, der antwortet und die Sitzung zurückstellt, ist keiner, der keine Mail empfängt; eine Zurückstellung beim ersten Versuch ist normal.
Ein MX-Zertifikat, das nicht validiert, reißt nicht mehr den ganzen Mail-Abschnitt um. Sobald irgendein geprüfter Mailserver ein Zertifikat vorzeigte, das der Scanner ablehnt – selbstsigniert, abgelaufen, auf einen anderen Namen ausgestellt oder von einer unbekannten CA –, brach das Mailserver-Modul ab, und der Abschnitt kam als Fehler zurück statt als Bericht.
Forward Secrecy auf dem MX wird wieder für jede Domain bewertet. Das Finding lag versehentlich im DANE-Block und erschien deshalb nur für Domains mit TLSA-Records – während das TLS-Versions-Finding für alle darauf verwies („siehe das eigene Finding darunter“).
Ein Notendeckel nennt den Grund, der wirklich zutrifft. Kündigt ein Mailserver STARTTLS an, ohne dass eine TLS-Sitzung zustande kommt, druckte der Bericht bisher die erfüllte Bedingung („STARTTLS auf allen erreichbaren MX“) als Grund für den Deckel.

23. August 2026 – Eigene Ausfälle werden nicht mehr zu Ihrer Note; kein MX-Record heißt nicht mehr „empfängt keine Mail“; der Downgrade-Test ist eingezäunt

Ein DNS-Ausfall auf unserer Seite ergab bisher Note F für eine tadellose Domain. Kamen unsere Abfragen leer zurück – weil unsere eigenen Resolver nicht erreichbar waren oder weil eine Zone jede Abfrage mit einem Serverfehler beantwortete –, füllte der Bericht die Lücken, als hätte die Domain nichts: keine Nameserver, keine Adressen, keine Mailserver, kein CAA.
Eine Domain ohne MX-Record wird jetzt geprüft statt abgetan. Eine Domain mit Adress-Record und ohne MX empfängt sehr wohl Mail – auf genau dieser Adresse, und jeder sendende Server klopft dort auf Port 25 an.
Der Downgrade-Test ließ sich auf den ausgehenden Mailserver eines Fremden richten. Nach der Analyse Ihrer Nachricht können Sie uns bitten, die Zustellung unter absichtlich verschlechtertem TLS zu wiederholen, um zu sehen, ob Ihr Server trotzdem sendet.
Vier Checks hatten überhaupt keine Erklärseite. Ein Catch-all-IP-Bereich im SPF-Record, ein SPF-Syntaxfehler und die beiden Prüfungen, die Ihre MTA-STS-Policy und Ihr BIMI-Logo getrennt über IPv4 und IPv6 abrufen – zusammen die schwersten und die am leichtesten missverstandenen Befunde des Abschnitts – wurden benotet, ohne dass ein Wort sie erklärt hätte.
Eine Subdomain unter einem Hosting-Suffix wird nicht mehr gegen eine fremde Domain benotet. Bei einem Namen wie ihrname.github.io hielt der Scan das Hosting-Suffix für Ihre Organisationsdomain: SPF fiel von einem vollen Durchfallen auf eine milde Warnung, der Standardverhalten-Check verschwand, DKIM wurde nicht mehr benotet, und der Bericht riet dazu, Records auf einer Domain zu veröffentlichen, die Ihnen nicht gehört.
Ein defekter SPF-Record bekommt keine Punkte mehr für Teile, die niemand liest. Ein einziger Syntaxfehler macht den ganzen Record zu einem PermError, und Empfänger werten dann nichts davon aus.
Ein bewusster BIMI-Verzicht wird nicht mehr abgewertet. Ein Record, der erklärt „diese Domain veröffentlicht kein Logo“, wurde dafür benotet, DMARC nicht durchzusetzen – ein Rat zu etwas, das er nie wollte.
MTA-STS-Policies werden so streng gelesen wie von einem sendenden Mailserver. Die Norm schreibt die Feldnamen und die Werte von version/mode mit exakter Groß-/Kleinschreibung; eine Policy mit Mode: ENFORCE ist für einen strengen Absender nicht gültig.
CAA-Records werden jetzt so nachgeschlagen, wie eine Zertifizierungsstelle sie nachschlägt. Eine CAA-Regel gilt für jeden Namen darunter, und eine CA steigt den Namensbaum hinauf, bis sie eine findet.
Eine Abweisung wegen Ratenbegrenzung gilt nicht mehr als „nur Klartext“. Wenn eine große Mailplattform einen wiederkehrenden Besucher vorübergehend abweist, bevor das Gespräch beginnt, ist über ihre Verschlüsselung nichts gemessen worden.
Ein zwei Sekunden langer DNS-Aussetzer auf unserer Seite wird nicht mehr eine Stunde festgehalten. Ergebnisse werden eine Stunde zwischengespeichert, damit wir Ihre Domain nicht wiederholt abfragen. Meldet ein Modul, dass die Messung an UNS gescheitert ist, wird diese Antwort jetzt nur noch eine Minute behalten – lang genug, um einen Ansturm abzufangen, kurz genug, dass ein kurzer Ausfall Ihnen nicht hinterherläuft.
Drei Prüfungen hatten überhaupt keine Erklärseite. Ob Ihre Nameserver autoritativ antworten, ob sie untereinander übereinstimmen und ob die Delegation Ihres Registrars zu Ihrer Zone passt – drei Prüfungen, die durchfallen können und zusammen fünf der Bewertungspunkte dieses Abschnitts tragen – wurden benotet, ohne dass ein einziges Wort sie erklärte.

22. August 2026 – Website- und Header-Urteile entsprechen dem Browserverhalten; der Scan überlastet die Site nicht mehr; DNS-Panels behaupten nur, was sie gemessen haben

Die Web-Prüfung öffnet jetzt höchstens acht Verbindungen gleichzeitig. Protokoll-Proben, Cipher-Enumeration, sechs simulierte Browser, die Port-80-Anfrage und die HTTP/3-Probe starteten alle zusammen – gemessen waren das bis zu neunzehn gleichzeitige Verbindungen zu einem einzigen Host.
Forward Secrecy wird über alle angebotenen Suites beurteilt, nicht nur über die ausgehandelte. Unsere Verbindung erhält fast immer die beste verfügbare Suite, also stand dort „TLS 1.3 – immer Forward Secrecy“ und damit hatte es sich. Zwei von fünf Seiten, die beim Bau dieser Version gemessen wurden, bieten zusätzlich Suites ohne Forward Secrecy an: Ein Client, der nur diese unterstützt, bekommt eine Verbindung, deren mitgeschnittener Verkehr sich später entschlüsseln lässt, falls der Serverschlüssel je abhandenkommt.
Ein schwaches frame-ancestors lässt sich nicht mehr durch X-Frame-Options retten. Browser ignorieren X-Frame-Options vollständig, sobald eine durchgesetzte CSP ein frame-ancestors enthält – auch ein DENY.
Ein X-Frame-Options-Wert, auf den Browser nicht reagieren, ist jetzt ein Fehler statt einer Warnung. ALLOW-FROM, ein Tippfehler oder ALLOWALL bedeuten alle „Einbetten von überall erlaubt“ – genau dieselbe Blöße wie ein fehlender Header, den der Bericht längst als Fehler wertet.
Das HSTS-Preload-Urteil verwechselt nicht mehr zwei Hosts. Die Preload-Liste wurde für die eingegebene Domain abgefragt, der HSTS-Header aber dort gelesen, wo die Weiterleitungen endeten – bei der sehr häufigen Weiterleitung von der nackten Domain auf www sind das zwei verschiedene Hosts.
Ein über einfaches HTTP ausgelieferter HSTS-Header wird nicht mehr angerechnet. Endet die Anfrage auf http://, ignorieren Browser den Header vollständig (RFC 6797) – bisher wurde er bewertet, als würde er wirken.
Der Root-Store wird richtig gezählt – 146 Stellen, nicht 267. Der Zertifikatsbericht nannte eine Zahl, die dieselbe Root doppelt zählte, sobald sie aus zwei Quellen mit unterschiedlichen Zeilenumbrüchen kam; die Truststore-Seite hatte dagegen immer Zertifikate gezählt.
Eine von Mozilla entfernte Root wird nicht mehr stillschweigend akzeptiert. Unser Store kombiniert Betriebssystem, Node-Bundle und den wöchentlichen Mozilla/CCADB-Stand – er hat aber immer nur ergänzt, nie entfernt.
Eine abgelaufene Protokoll-Probe liest sich nicht mehr als „korrekt deaktiviert“. Jede TLS-Version wurde mit einer eigenen Verbindung geprüft, und jeder Fehlschlag – auch unsere eigenen Zeitüberschreitungen – galt als „der Server bietet das nicht an“.
Der erste Tag nach dem Ablauf einer DNSSEC-Signatur wurde als „läuft demnächst ab“ benotet. Die Restlaufzeit wurde auf ganze Tage gerundet, und eine Signatur, die vor weniger als 24 Stunden abgelaufen ist, ergab dabei negative Null – die in JavaScript nicht kleiner als null ist.
Ein Fehlschlag auf unserer Seite liest sich nicht mehr als „die Vertrauenskette ist unvollständig“. Der DNSSEC-Check stellt vier DNS-Abfragen parallel, und drei davon unterschieden bereits „wir haben keine Antwort bekommen“ von „die Zone hat ein Problem“.
Eine fehlgeschlagene Adressabfrage gilt jetzt als unser Fehler, nicht als „keine Adressen“. Ist jeder Resolver, den wir fragen, unerreichbar oder antwortet mit einem Fehler, ist das Ergebnis eine leere Liste – und die war bisher nicht davon zu unterscheiden, dass ein Name wirklich keine Adressen hat.
Nameserver, die die Auskunft verweigern, werden benannt statt als gesund gezählt. Ein Server, der mit REFUSED oder SERVFAIL antwortet, wurde nie auf seine Autorität geprüft – der Bericht sprach sie ihm trotzdem zu, in einem Satz, der lautete „alle antwortenden Nameserver autoritativ“.
Ein Filter, der mit einer Adresse antwortet, gilt jetzt als Filter. Das Blocklisten-Panel kannte vier Arten, wie ein Resolver Nein sagt – NXDOMAIN, REFUSED, eine Null-Adresse oder gar keine Adresse. Die fünfte kannte es nicht: eine Adresse des Betreibers selbst, hinter der eine Hinweisseite liegt.
„Wenige Verbindungen pro Scan“ untertrieb um eine Größenordnung. Ein vollständiger Scan öffnet einige Dutzend kurzlebige Verbindungen, weil jede Cipher Suite einzeln geprüft werden muss; zivil bleibt das durch die Drosselung, die immer nur eine Handvoll gleichzeitig zulässt.
Jede Erklärungsseite wurde gegen den Check gelesen, den sie beschreibt. Alle Erklärungen der Gruppen Website, HTTP-Header und DNSSEC wurden Satz für Satz mit ihren Checks verglichen; wo eine Seite ein Urteil versprach, das der Scan nicht fällt, oder eine Quelle zitierte, die etwas anderes sagt, wurde sie korrigiert. Die englischen und deutschen Erklärungen werden jetzt automatisch verglichen.

21. August 2026 – Neu: eine vollständige DMARC-Referenz; der DMARC-Generator zeigt, was ein Neu-Veröffentlichen ändert; Scanner und Record Studio stimmen überein

Neue Seite: DMARC erklärt. Bisher war DMARC ein Absatz auf der Seite zur E-Mail-Authentifizierung.
Der Tree Walk, wirklich gerechnet. Jede Erklärung im Netz erwähnt ihn; diese führt ihn aus, Abfrage für Abfrage, an einem Namen mit sieben Labels — und wiederholt dieselbe Nachricht anschließend mit einem psd=n-Record eine Ebene tiefer, um zu zeigen, wie sich die Antwort ändert.
Ein Fehlersuche-Baum. Vier Symptome — legitime Mail wird abgewiesen, es kommen keine Reports an, der Record wird nicht gefunden, nur Subdomain-Mail scheitert — jeweils verzweigt in Ursache, einen Prüfschritt, den Sie wirklich ausführen können, und die Behebung.
Veröffentlichten DMARC-Record laden und sehen, was ein Empfänger auf aktuellem Stand anders damit macht. Der DMARC-Generator stellt Ihren veröffentlichten Record jetzt neben den, den er erzeugen würde, und listet jeden Unterschied in einer von drei Gruppen: was tatsächlich das Verhalten ändert, was dieses einfache Formular beim Neu-Veröffentlichen weglassen würde, und was rein kosmetisch ist.
Bewertungsänderung für pct= im Domain-Scan. Es wird jetzt danach beurteilt, wie viel es wirklich ändert. Bei einem p=none-Record kostet es gar nichts mehr — es gibt nichts zu sampeln, und beide Standards führen zum selben Ergebnis.
Wir empfehlen nicht mehr, pct=100 zu veröffentlichen. Die BIMI-Empfehlung im Bericht, in der Doku und im Record Studio verlangte ein Tag, das derselbe Bericht zwei Zeilen weiter unten als hinfällig meldet.
„Voller Spoofing-Schutz“ ist raus. p=reject ist die stärkste Absenderpräferenz, aber RFC 9989 untersagt Empfängern ausdrücklich, allein deswegen abzuweisen, und gefälschte Anzeigenamen bei fremder Absenderdomain deckt DMARC überhaupt nicht ab.
Klar sagen, warum ein reduziertes pct das BIMI-Logo kostet. Die Regel bleibt, die Begründung war falsch. Ein DMARC-Record mit pct unter 100 gilt hier weiterhin als nicht BIMI-tauglich.
Die Logo- und Zertifikatsprüfung wartet nicht mehr auf einen perfekten Record. Sie lief bisher erst, wenn der BIMI-Record bereits vollständig war – Logo, Mark-Zertifikat und durchgesetzte DMARC-Policy – also genau dann, wenn man sie am wenigsten braucht.
Ein einzelner Abruf kann nicht sagen, ob beide Adressfamilien funktionieren. Das Betriebssystem wählt eine aus – ein Host, der über genau eine Familie kaputt ist, antwortet also normal und die Prüfung meldet Erfolg.
Die DMARC-Ermittlung läuft den Baum ab, statt zu raten. Beim Nachschlagen einer Subdomain probierte das Record Studio den exakten Namen und dann einmal die registrierbare Domain – jede Ebene dazwischen fiel durch.
ip4:0.0.0.0/0 ist +all in anderer Schreibweise und wird jetzt auch so bewertet. Ein /0-Bereich passt auf jede Adresse, ein abschließendes -all wird also nie erreicht: Mechanismen werden von links nach rechts ausgewertet, der erste Treffer gewinnt.
Ein widerrufener DKIM-Schlüssel zählt nicht mehr als Schlüssel. Ein leeres p= widerruft einen Selektor (RFC 6376 §3.6.1) – er bestätigt nichts mehr.
Eine MTA-STS-Policy ohne mx-Zeile gilt nicht mehr als bestanden. RFC 8461 §3.2 verlangt mindestens eine, und der Abgleich mit Ihren echten MX-Hosts wurde bei leerer Liste übersprungen – eine mode: enforce-Policy, die auf keinen Ihrer Server passt, galt damit als korrekt.
Ein Resolver-Fehler gilt nicht mehr als „kein Record“. Kam eine Abfrage als SERVFAIL zurück – meist eine DNSSEC-kaputte Zone –, sagte das Record Studio, der Record existiere nicht.

20. August 2026 – Drei neue Nameserver-Checks; der DNS-Lookup fragt die autoritativen Server; ein TLS-Downgrade-Test für Ihren Mailversand; neue SMTP-Checks

Drei neue Nameserver-Checks. Lame Delegation, Nameserver, die einander widersprechen, und eine Registry, die nicht mehr auf die richtigen Server zeigt – Fragen, die kein öffentlicher Resolver beantworten kann; der Scan spricht deshalb jetzt direkt mit Ihren Nameservern.
DNS-Lookup: die autoritativen Server neben den Resolvern. Der Lookup fragt jetzt zusätzlich die Nameserver, auf die die Delegation tatsächlich zeigt, und zeigt Antwort und Zonen-Serial jedes einzelnen in einem eigenen Panel – so werden auseinandergedriftete Server sichtbar.
Neu und optional: Wir spielen einen Mailserver, dessen Verschlüsselung kaputt ist. Nach dem fertigen Report lässt sich eine zweite, absichtlich verschlechterte Zustellung starten — entweder ganz ohne STARTTLS-Angebot oder mit einem Zertifikat, das weder zu unserem Hostnamen noch zu unseren veröffentlichten DANE-Records passt.
Das kann Ihre Note verändern. Eine Zustellung unter verschlechterten Bedingungen wird als Warnung gewertet, nicht als Durchfallen: Opportunistisches TLS ohne MTA-STS und DANE ist bei den meisten Mailservern Standardverhalten, Postfix braucht für beides zusätzliche Konfiguration.
Empfangs-Test: vier neue SMTP-Checks. Rollen-Postfächer (RFC 2142), was Ihr Server auf VRFY antwortet, moderne SMTP-Erweiterungen bewertet statt nur aufgelistet, und die SMTP-Begrüßung.
Der Bericht zeigt jetzt, ob Ihr Server ein TLS-Client-Zertifikat anbietet. Beim STARTTLS-Handshake fordert unser Listener eines an; nahezu kein öffentlicher Mailserver legt eines vor – das ist völlig normal und wird auch so ausgewiesen.
Der Sende-Test ermittelt die DMARC-Policy jetzt so, wie DMARCbis (RFC 9989) es vorschreibt. Statt auf die Public Suffix List zurückzufallen, läuft er den DNS-Baum von der From-Domain aufwärts, berücksichtigt psd= und wendet das Tag an, das die Nachricht wirklich regiert – sp= für eine Subdomain, np= für eine nicht existierende, sonst p=.
Das SPF-Ergebnis lässt sich jetzt Schritt für Schritt aufklappen. Jeder Term des Records in Auswertungsreihenfolge — inklusive der über include: oder redirect= eingebundenen Records, eine Ebene eingerückt — mit Treffer, Nicht-Treffer und dem Stand des 10-Lookup-Budgets bei jedem Schritt.
Neu: Authentifizierungs-Ergebnisse vorgelagerter Systeme. Lief die Mail über ein Relay oder eine Mailingliste, die einen Authentication-Results-Header gesetzt hat, zeigt der Bericht jetzt, was diese Systeme zu SPF, DKIM und DMARC behauptet haben.

18.–19. August 2026 – Neu: DNS-Lookup über 11 öffentliche Resolver; „nicht anwendbar“ ist kein Scan-Fehler; reine Mail-Domains bekommen kein F mehr für eine fehlende Website

Neuer DNS-Lookup: 11 öffentliche Resolver im direkten Vergleich. Beliebige Record-Typen abfragen und je Resolver Antwort, TTL, DNSSEC-Validierungsstatus und Antwortzeit sehen — mit automatischem Konsistenz-Urteil, das CDN-Rotation erkennt, und einem Blocklist-Panel, das zeigt, ob filternde Resolver (Quad9, DNS4EU, AdGuard, Cloudflare Security) die Domain blockieren.
Module, bei denen es bewusst nichts zu prüfen gibt, sehen nicht mehr wie Scan-Fehler aus. Hat eine Domain keine Website konfiguriert (reine Mail-Domain) oder keine Mailserver (reine Web-Domain), zeigen die betroffenen Module in den Übersichtsbalken und der kompakten Sticky-Leiste jetzt ein neutrales graues „n. a.“ – statt des Fehler-„!“, das bisher nach einem Problem aussah.
Eine Domain ohne Website wird nicht mehr wie eine kaputte Website behandelt. Hat weder die Domain selbst noch www A/AAAA-Records, meldet das Website-Modul jetzt „keine Website konfiguriert“ und bleibt ohne Bewertung – genau wie das Modul HTTP-Security-Header – statt mit F durchzufallen.
Der Null-MX-Generator im Record Studio erzeugt jetzt zusätzlich den Wildcard-DKIM-Widerrufs-Record (*._domainkey → v=DKIM1; p=) – damit ist der empfohlene Record-Satz für Domains ohne Mail-Nutzung komplett.

28. Juli 2026 – OpenPGP-Checks im Versand-Test; security.txt-Signaturen verifiziert

Der Sende-Test prüft OpenPGP-Signaturen jetzt genauso, wie er S/MIME schon lange prüft. Beide Nachrichtenformen werden abgedeckt: PGP/MIME (RFC 3156) und der ältere Inline-Stil.
Neu: Ist Ihr Schlüssel überhaupt auffindbar? Der Test schlägt die Absenderadresse im Web Key Directory ihrer eigenen Domain nach und, falls dort nichts liegt, auf keys.openpgp.org.
Autocrypt-Header werden gegen die Level-1-Spezifikation validiert – einschließlich der Regeln, die darüber entscheiden, ob ein empfangendes Mailprogramm den Header überhaupt annimmt: Die angekündigte Adresse muss zum Absender passen, unbekannte Attribute ohne Unterstrich-Präfix machen den Header ungültig, und zwei gültige Header in einer Nachricht lassen Clients beide verwerfen.
Der Domain-Scan prüft zusätzlich, ob die Kontaktadresse einer security.txt per Web Key Directory auffindbar ist.
Der Scanner verifiziert die OpenPGP-Cleartext-Signatur einer signierten security.txt jetzt gegen den Schlüssel, den die Datei selbst veröffentlicht. Der im Encryption-Feld verlinkte Schlüsselblock wird abgerufen und bewertet (verwertbarer öffentlicher Schlüssel, RSA-Schlüsselgröße, ROCA-/Fermat-Faktorisierbarkeit, kein offengelegter privater Schlüsselblock), und die Signatur wird gemäß RFC 9580 gegen genau diesen Schlüssel verifiziert – unterstützt werden RSA, ECDSA (NIST- und Brainpool-Kurven), EdDSA/Ed25519 und Ed448, v4- und v6-Signaturen.

20. Juli 2026 – Volle IPv6-Abdeckung für adressbasierte Checks; genauere MTA-STS-Diagnosen

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.
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.
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.
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.
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.
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).

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.
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.
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 – Klarere Berichte: Triage-Liste, Service-Gruppen, Noten je Gruppe in den Mail-Tests

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.
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.
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.
„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.
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.

12.–13. Juli 2026 – Neu: E-Mail-Empfangs-Test; der Versand-Test schaut viel tiefer

Ein neuer E-Mail-Empfangstest prüft, wie Ihre Domain Mail empfängt. Nachdem Sie die Kontrolle über die Domain nachgewiesen haben — durch eine authentifizierte Nachricht von ihr — verbindet sich der Test wie ein echter Sender mit Ihren 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 Ihr 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 erfahren Sie auch, ob ein Content- oder Größenfilter legitime Mail ablehnen würde.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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.

11. Juli 2026 – Record Studio: sicherere Schlüssel und ehrliche „Laden“-Warnungen; Versand-Test: unsichere DKIM-Signaturen gelten nicht mehr als gültig

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.
„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.
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“.

8. Juli 2026 – Screening schwacher Schlüssel, SHA-1 über die ganze Kette, CAA-Kontakt und ACME-Bindung, runder auf dem Handy

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.
SHA-1 über die ganze Kette, nicht nur das Leaf. Die Signaturalgorithmus-Prüfung untersucht jetzt auch die ausgelieferten Intermediate-CA-Zertifikate.
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.
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.
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 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).
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.

7. Juli 2026 – Neu: E-Mail-Versand-Test; tiefe BIMI-Prüfung mit verifizierten Mark-Zertifikaten; neue IPv6-Adresse des Scanners

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.
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.
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.
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).
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 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).
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.
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.

5.–6. Juli 2026 – Aus „Record-Generatoren“ wird Record Studio; CAA-Generator je Zertifizierungsstelle neu gebaut; Genauigkeits-Durchgang

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.
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.
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 integrierte CA-Liste wuchs von 13 auf 46 aktuell öffentlich vertrauenswürdige Zertifizierungsstellen (TLS und/oder S/MIME), darunter viele regionale und staatliche CAs.
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).
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).
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.

4. Juli 2026 – TLSA-Record aus dem Live-Zertifikat bauen; neuer SMIMEA-Generator; Ihr Mail-Provider im Scan-Bericht

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.
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.
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).
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.
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).
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.
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 SPF-Generator nutzt jetzt standardmäßig ~all (Softfail) statt -all – passend zur Empfehlung des Scanners.
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.
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.
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.
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).

3. Juli 2026 – Vollständige deutsche Version; DNS-Record-Generatoren; DMARCbis und 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.
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.
security.txt-Prüfung auf vollständige RFC-9116-Validierung ausgebaut: Syntax, Contact- und Canonical-URIs, Ablaufregeln und PGP-Signatur-Rahmen.
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.
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.

2. Juli 2026 – Tool-Vergleich, deutsche Landingpages, DMARCbis-Referenzen

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.
Alle DMARC-Verweise auf die neue RFC-Familie 9989–9991 umgestellt (DMARCbis, ersetzt RFC 7489).

14.–15. 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.
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.
HTTP/3-Unterstützung wird jetzt mit echten Ende-zu-Ende-QUIC-Proben verifiziert statt nur über den Alt-Svc-Header.
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.

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.
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.
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.
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.
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.
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.

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.
Missbrauchsschutz per Cloudflare Turnstile vor der Scan-API ergänzt.
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.

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.