Methodik – So funktionieren die Webalyzr-Analysen
Transparenz ist ein Grundprinzip von Webalyzr. Auf dieser Seite wird für jedes Analyse-Tool detailliert erklärt, welche Pruefungen durchgefuehrt werden, welche Protokolle und Methoden zum Einsatz kommen und welche Einschraenkungen bestehen. Alle Checks nutzen ausschliesslich öffentlich zugaengliche Informationen: DNS-Abfragen, HTTP-Requests, TLS-Handshakes und WHOIS-Lookups. Es werden keine invasiven Scans durchgefuehrt und keine Daten auf dem Zielserver veraendert.
Methodik & FAQ
Hier erfahren Sie, wie jedes unserer Analyse-Tools technisch funktioniert: welche Protokolle und Methoden verwendet werden, was genau geprüft wird und welche Einschränkungen es gibt.
Netzwerk & Server15
Was wird geprüft?
Prüft die Erreichbarkeit eines Hosts und misst die Antwortzeit (Latenz).
Wie funktioniert es?
Es werden 5 TCP-Verbindungen zum Zielhost aufgebaut (Port 443). Gemessen werden Minimum, Durchschnitt und Maximum der Antwortzeiten sowie Paketverlust.
Beispiel-Ergebnis
google.com → Min: 12ms, Avg: 14ms, Max: 18ms, Paketverlust: 0%
Hinweise
Kein ICMP-Ping, sondern TCP-Connect. Einige Firewalls blockieren TCP-Verbindungen auf Port 443.
Was wird geprüft?
Zeigt den Netzwerkpfad (alle Zwischenstationen) zwischen unserem Server und dem Zielhost.
Wie funktioniert es?
UDP-Pakete werden mit schrittweise erhöhtem TTL-Wert (Time-to-Live) gesendet. Die Ergebnisse werden per SSE-Stream in Echtzeit übertragen.
Beispiel-Ergebnis
Hop 1: 10.0.0.1 (1ms) → Hop 2: 192.168.1.1 (5ms) → ... → Hop 9: 142.250.185.14 (14ms)
Hinweise
Maximal 30 Hops. Einige Router antworten nicht (erscheinen als *).
Was wird geprüft?
Prüft, welche Netzwerk-Ports auf einem Host geöffnet sind.
Wie funktioniert es?
TCP-Connect-Scan auf 21 gängige Service-Ports: 21 (FTP), 22 (SSH), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 465 (SMTPS), 587 (Submission), 993 (IMAPS), 995 (POP3S), 1234 (Misc), 3306 (MySQL), 3389 (RDP), 4444 (Misc/Metasploit), 5432 (PostgreSQL), 5900 (VNC), 8080 (HTTP-Alt), 8443 (HTTPS-Alt), 9443 (HTTPS-Alt). Für jeden Port wird versucht, eine TCP-Verbindung aufzubauen (Timeout: 3 Sekunden). Antwortet der Port, gilt er als offen.
Beispiel-Ergebnis
example.com → Port 80 (HTTP): offen, Port 443 (HTTPS): offen, Port 22 (SSH): geschlossen, ...
Hinweise
Nur TCP, kein UDP-Scan. Ports werden in 6er-Batches geprüft, um den Zielhost nicht zu überlasten.
Was wird geprüft?
Umfassende DNS-Analyse: Fragt alle Record-Typen (A, AAAA, MX, TXT, CNAME, NS, SOA, CAA, SRV) ab und entdeckt Subdomains automatisch über mehrere Methoden.
Wie funktioniert es?
1) Zone Transfer (AXFR) wird versucht – liefert bei Erfolg sämtliche DNS-Records der Zone. 2) Certificate Transparency Logs (crt.sh) werden abgefragt, um Subdomains mit SSL-Zertifikaten zu entdecken. 3) Bekannte Subdomain-Muster werden geprobt: gängige Hostnames (www, mail, ftp, autodiscover, etc.), DKIM-Selektoren verschiedener Provider (Microsoft 365, Google, IONOS, Mailchimp, Proton Mail u.a.), Mail-Konfiguration (_dmarc, _mta-sts, _acme-challenge) und SRV-Records (Autodiscover, SIP, XMPP, IMAP). Wildcard-DNS wird erkannt und herausgefiltert, ebenso wie CNAME-aufgelöste A/AAAA-Records, die keine echten Einträge sind. Alle Abfragen laufen parallel über Google/Cloudflare DNS.
Beispiel-Ergebnis
example.com → @ A: 93.184.216.34, @ MX: mail.example.com (Prio 10), ftp A: 93.184.216.34, _dmarc TXT: v=DMARC1; p=reject, selector1._domainkey CNAME: ...
Hinweise
Da DNS kein "Alle Records auflisten"-Kommando hat, können nur Records gefunden werden, deren Hostnamen bekannt sind oder durch AXFR/CT-Logs entdeckt werden. Provider-spezifische Records mit zufälligen Namen (z.B. IONOS-interne DKIM-Hashes) sind von außen nicht auffindbar.
Was wird geprüft?
Zeigt Registrierungsinformationen einer Domain: Registrar, Erstellungsdatum, Ablaufdatum und Nameserver.
Wie funktioniert es?
Primär wird das RDAP-Protokoll (Registration Data Access Protocol) verwendet. Bei Domains ohne RDAP-Unterstützung erfolgt ein Fallback auf den zuständigen Whois-Server per TCP.
Beispiel-Ergebnis
example.de → Registrar: DENIC eG, Erstellt: 2005-01-01, Ablauf: 2026-01-01, Status: connect
Hinweise
Aufgrund der DSGVO/GDPR werden bei europäischen Domains (z.B. .de, .at, .eu) kaum noch personenbezogene Daten wie Inhabername oder Adresse angezeigt. Die meisten Registrare reduzieren die Whois-Ausgabe auf technische Daten (Nameserver, Ablaufdatum, Registrar).
Was wird geprüft?
Ermittelt Geolocation, Netzwerkzugehörigkeit (ASN) und Reverse-DNS einer IP-Adresse.
Wie funktioniert es?
Abfrage bei RIPE/ARIN über das RDAP-Protokoll für Netzwerkdaten. Reverse-DNS wird per PTR-Record-Abfrage ermittelt.
Beispiel-Ergebnis
8.8.8.8 → Google LLC, AS15169, Mountain View, US, Reverse-DNS: dns.google
Was wird geprüft?
Prüft das SSL/TLS-Zertifikat einer Domain auf Gültigkeit, Ablaufdatum und Zertifikatskette.
Wie funktioniert es?
Ein TLS-Handshake wird durchgeführt und das Zertifikat samt Kette ausgelesen. Geprüft werden: Common Name, SANs, Aussteller, Gültigkeitszeitraum und Ketten-Vollständigkeit.
Beispiel-Ergebnis
example.com → Aussteller: Let's Encrypt, Gültig bis: 2026-05-15, Kette: 3 Zertifikate, TLS 1.3
Was wird geprüft?
Verfolgt die komplette Weiterleitungskette einer URL und zeigt jeden HTTP-Statuscode.
Wie funktioniert es?
HTTP-Requests werden mit manueller Redirect-Behandlung (redirect: manual) durchgeführt. Jeder Hop wird mit Statuscode, Location-Header und Antwortzeit protokolliert.
Beispiel-Ergebnis
http://example.com → 301 → https://example.com → 301 → https://www.example.com → 200 OK
Hinweise
Maximal 10 Hops, um Endlosschleifen zu vermeiden.
Was wird geprüft?
Prüft, ob ein Server HTTP/2 und HTTP/3 unterstützt.
Wie funktioniert es?
HTTP/2-Erkennung über ALPN-Negotiation beim TLS-Handshake. HTTP/3-Erkennung über den Alt-Svc-Header in der HTTP-Antwort.
Beispiel-Ergebnis
example.com → HTTP/1.1: ja, HTTP/2: ja, HTTP/3: nein
Was wird geprüft?
Prüft, ob eine IP-Adresse auf gängigen Spam-Sperrlisten (RBLs) gelistet ist.
Wie funktioniert es?
Die IP-Adresse wird in reversed Form gegen ca. 30 bekannte DNS-basierte Blacklists (RBLs) abgefragt. Eine DNS-Antwort bedeutet, dass die IP gelistet ist.
Beispiel-Ergebnis
203.0.113.5 → Gelistet auf: Spamhaus ZEN, SORBS – Nicht gelistet auf: 28 weiteren RBLs
Hinweise
Nur IPv4-Adressen. Ergebnisse können je nach RBL-Aktualisierung leicht verzögert sein.
Was wird geprüft?
Prüft, ob DNS-Änderungen bei wichtigen öffentlichen Nameservern bereits angekommen sind.
Wie funktioniert es?
Der angegebene DNS-Record wird bei 10 großen öffentlichen DNS-Servern abgefragt: Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), Quad9 (9.9.9.9), OpenDNS (208.67.222.222, 208.67.220.220), Level3 (4.2.2.1), Comodo (8.26.56.26) und Neustar (64.6.64.6). Die Ergebnisse werden verglichen und der Propagation-Status in Prozent angezeigt.
Beispiel-Ergebnis
example.com (A-Record) → Google: 93.184.216.34, Cloudflare: 93.184.216.34, ... → Propagation: 100%
Hinweise
Es werden keine autoritativen Nameserver der Domain abgefragt, sondern öffentliche Resolver. Das Ergebnis zeigt, ob die Änderung bei den meistgenutzten DNS-Diensten angekommen ist.
Was wird geprüft?
Findet unsichere HTTP-Ressourcen auf HTTPS-Seiten, die Browser-Warnungen auslösen.
Wie funktioniert es?
Der HTML-Quellcode der Seite wird geladen und alle src- und href-Attribute analysiert. Ressourcen, die über http:// statt https:// geladen werden, werden als Mixed Content gemeldet.
Beispiel-Ergebnis
https://example.com → 2 Probleme: http://cdn.example.com/style.css (Stylesheet), http://example.com/logo.png (Bild)
Was wird geprüft?
Entdeckt Subdomains einer Domain über öffentliche Quellen.
Wie funktioniert es?
Abfrage der Certificate Transparency Logs über crt.sh. Zusätzlich DNS-Bruteforce-Prüfung gängiger Subdomain-Namen.
Beispiel-Ergebnis
example.com → www.example.com, mail.example.com, shop.example.com, api.example.com (4 gefunden)
Hinweise
Es werden nur öffentlich bekannte Subdomains gefunden. Interne oder nicht in CT-Logs veröffentlichte Subdomains werden nicht erkannt.
Was wird geprüft?
Analysiert die unterstützten TLS-Protokollversionen und Verschlüsselungs-Suiten eines Servers.
Wie funktioniert es?
Für jede TLS-Version (1.0, 1.1, 1.2, 1.3) wird ein separater Handshake-Versuch durchgeführt. Die ausgehandelten Cipher-Suiten werden nach Sicherheitsstufe bewertet.
Beispiel-Ergebnis
example.com → TLS 1.3: TLS_AES_256_GCM_SHA384 (stark), TLS 1.2: ECDHE-RSA-AES128-GCM-SHA256 (stark), TLS 1.1: nicht unterstützt
Hinweise
TLS 1.0 und 1.1 gelten als veraltet. Ein gutes Ergebnis zeigt nur TLS 1.2+ mit starken Ciphern.
Was wird geprüft?
Ermittelt den Hosting-Provider und ein eventuell vorgeschaltetes CDN einer Website.
Wie funktioniert es?
Die Domain wird per DNS aufgelöst, dann werden ASN-Lookup (Team Cymru), Reverse-DNS und ein HTTP-HEAD-Request parallel durchgeführt. Aus ASN-Organisation, Reverse-DNS-Hostname und HTTP-Headern (z.B. cf-ray, x-served-by) werden Hosting-Provider und CDN abgeleitet.
Beispiel-Ergebnis
example.com → IP: 104.21.5.123, CDN: Cloudflare, ASN: AS13335 (Cloudflare Inc.), Server: cloudflare
Hinweise
Hinter einem CDN wie Cloudflare ist der tatsächliche Origin-Hoster nicht ermittelbar, da alle Anfragen über das CDN geroutet werden.
E-Mail & DNS20
Was wird geprüft?
Umfassende Mail-Infrastruktur-Analyse: MX-Topologie (alle Prio-Stufen mit IPv4/IPv6/PTR/Reachability), echter STARTTLS-Handshake auf Port 25 mit Zertifikat-Parsing und Hostname-Matching, Implicit-TLS-Probe auf Port 465, Submission-Port 587 mit AUTH-Mechanism-Audit, DANE/TLSA-Lookup + Verification, VRFY/EXPN-User-Enumeration-Test, Open-Relay-Check, kompletter Mail-DNS-Stack (SPF/DMARC/DKIM/MTA-STS/TLS-RPT/CAA/BIMI), MX-Blacklist-Check und priorisierte Handlungsempfehlungen.
Wie funktioniert es?
Zuerst MX-Auflösung + Reverse-DNS, dann parallel: (1) klassische SMTP-Session für Banner/EHLO/Open-Relay/Transaction-Time. (2) Ausgehende STARTTLS-Verhandlung mit TLS-Upgrade und Zertifikat-Extraktion (Subject/Issuer/SAN/Wildcard/Ablauf/SPKI-Hash). (3) Implicit-TLS auf Port 465. (4) EHLO+STARTTLS auf Port 587 mit AUTH-Mechanism-Parse. (5) DANE-TLSA-Lookup und Vergleich gegen SHA-256-Hash des Live-Certs (usage=3, matching=1). (6) VRFY/EXPN-Test für User-Enumeration. (7) DNS-Stack über 13 häufige DKIM-Selektoren, SPF-Qualifier-Parse, DMARC-Breakdown, MTA-STS DNS + .well-known-Policy-Fetch, MTA-STS-vs-actual-MX-Match. (8) Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL. (9) Regelbasierte Recommendation-Engine.
Beispiel-Ergebnis
example.com → 3 MX-Hosts · STARTTLS TLS 1.3 ECDHE-RSA-AES256-GCM · Cert *.example.com 84 Tage · SAN matcht ✓ · Submission 587 mit STARTTLS+AUTH PLAIN LOGIN · DANE verified · SPF -all · DMARC p=reject rua= ✓ · MTA-STS enforce · Blacklists clean · 4 Empfehlungen
Hinweise
Die Live-Handshake-Checks (TLS, STARTTLS, DANE, 465, 587) setzen eine ausgehende Verbindung auf Port 25/465/587 vom Scanner-Host voraus. Einige große Mailbox-Provider (u.a. Google/Gmail, GMX, T-Online, freenet, web.de) filtern eingehende Verbindungen von Cloud-/VPS-IP-Ranges besonders streng — insbesondere wenn der PTR-Record generisch ist. In solchen Fällen können TLS-Probes scheitern, obwohl die gescannte Domain technisch einwandfrei ist. Der Scanner meldet seine eigene Outbound-Erreichbarkeit (full/partial/none), damit echte Domain-Probleme von Scanner-seitigen Reputations-Limits unterschieden werden können. Die DNS-basierten Checks (SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, DANE-Lookup, Blacklists) funktionieren unabhängig davon zuverlässig. Das Tool sendet nie echte Mail; AUTH-Credentials werden nie übermittelt.
Was wird geprüft?
Analysiert den Zustellweg einer E-Mail, Verzögerungen und Authentifizierungsergebnisse (SPF, DKIM, DMARC).
Wie funktioniert es?
Die eingefügten E-Mail-Header werden geparst. Received-Header werden in chronologischer Reihenfolge dargestellt, Verzögerungen zwischen Hops berechnet und Authentication-Results ausgewertet.
Beispiel-Ergebnis
Hop 1 → Hop 2 (0.3s) → Hop 3 (1.2s, Verzögerung!), SPF: pass, DKIM: pass, DMARC: pass
Was wird geprüft?
Prüft, ob DKIM-Signaturen für eine Domain korrekt im DNS hinterlegt sind.
Wie funktioniert es?
DNS-TXT-Abfrage auf den _domainkey-Selektoren der Domain. Die gefundenen DKIM-Schlüssel werden auf Format, Schlüssellänge und Gültigkeit geprüft.
Beispiel-Ergebnis
example.com → Selektor "google": gefunden, RSA 2048-Bit, gültig. Selektor "default": nicht gefunden.
Hinweise
Ohne Kenntnis des genauen Selektors werden gängige Selektornamen durchprobiert (default, google, selector1, selector2, k1 etc.).
Was wird geprüft?
Prüft den SPF-Record einer Domain auf Vorhandensein, Mechanismen, kaputte Includes und das DNS-Lookup-Limit nach RFC 7208.
Wie funktioniert es?
Liest den v=spf1-Record aus dem TXT, parst alle Mechanismen (ip4, ip6, a, mx, include, exists, ptr, all, redirect) mit Qualifier (+, -, ~, ?) und löst include-/redirect-Ketten rekursiv auf. Jeder a/mx/include/exists/ptr/redirect-Mechanismus zählt als 1 DNS-Lookup; bei mehr als 10 werten Empfänger den Record als PERMERROR (RFC 7208 §4.6.4). Includes ohne eigenen SPF-Record, deprecated ptr-Mechanismen, "+all" (offen), "?all" (neutral) und mehrere SPF-Records nebeneinander werden als Issues gemeldet.
Beispiel-Ergebnis
salesforce.com → v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all (4 DNS-Lookups, softfail, keine kaputten Includes)
Hinweise
Die Lookup-Zählung deckt nicht nur die direkt im Record sichtbaren Mechanismen ab, sondern auch alle Lookups in rekursiv aufgelösten Include-Ziel-Records — das spiegelt wider, wie ein empfangender Mailserver SPF wirklich auswertet.
Was wird geprüft?
Prüft den DMARC-Record einer Domain auf Vorhandensein, Policy-Stufe und vollständige RFC-7489-Tags.
Wie funktioniert es?
Liest _dmarc.<domain> TXT, parst alle Tags (v, p, sp, rua, ruf, pct, adkim, aspf, fo, rf, ri). Meldet die häufigsten realen Pannen: p=none (reines Monitoring, kein Schutz), pct<100 (Policy nur teilweise aktiv), fehlende rua (keine Reports = blind), sp=none bei p=reject (Subdomains spoofbar), unbekannte Tags (Tippfehler), Mehrfach-Records (RFC-Verstoß). Bei externen rua/ruf-Adressen wird zusätzlich der Authorisierungs-Record <eigene-domain>._report._dmarc.<externe-domain> geprüft — fehlt der, verwerfen Google/Microsoft die Reports.
Beispiel-Ergebnis
google.com → v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com (Policy: reject, Reports: an Google selbst → keine externe Autorisierung nötig, 0 Issues)
Hinweise
rua-Reporting ist der Schlüssel: ohne Aggregate-Reports kann eine Policy nicht sicher von p=none auf p=quarantine/reject hochgestuft werden, weil unbekannt bleibt, welche legitimen Sender brechen würden.
Was wird geprüft?
Prüft die MTA-STS-Konfiguration (RFC 8461) einer Domain: TXT-Record + HTTPS-Policy + Validierung von mode, mx-Liste und max_age.
Wie funktioniert es?
Parallel: TXT-Lookup an _mta-sts.<domain> (v=STSv1; id=...) und HTTPS-Fetch auf mta-sts.<domain>/.well-known/mta-sts.txt. Policy-Datei wird zeilenweise geparst (version, mode, mx, max_age). Issues: TXT ohne id, fehlende HTTPS-Policy, mode=none oder testing, max_age unter 1 Tag, keine MX-Einträge.
Beispiel-Ergebnis
google.com → mode=enforce, max_age=86400, mx=[smtp.google.com, ...] (0 Issues)
Hinweise
Updates an der Policy werden über das id-Feld im TXT signalisiert — die HTTP-Policy enthält selbst keinen id-Wert. Vergisst man, id zu erhöhen, holen sich Empfänger die Policy nicht neu.
Was wird geprüft?
Prüft den TLS-Reporting-Record (RFC 8460) einer Domain: Sammlung von TLS-Fehler-Reports von sendenden MTAs.
Wie funktioniert es?
Liest _smtp._tls.<domain> TXT, parst v=TLSRPTv1 + rua-Ziele. Validiert: nur ein Record, mailto:/https: als Schema, mindestens ein rua-Ziel. Meldet unbekannte Tags und Mehrfach-Records.
Beispiel-Ergebnis
google.com → v=TLSRPTv1; rua=mailto:sts-reports@google.com (1 Ziel, 0 Issues)
Hinweise
Ohne TLS-RPT bleiben TLS-Verbindungsprobleme zu deinem MX unsichtbar — kritisch im Zusammenspiel mit MTA-STS und DANE.
Was wird geprüft?
Prüft, ob eine Domain DNSSEC-signiert ist und ob die Chain bis zum Root validiert werden kann.
Wie funktioniert es?
Über Google DoH (https://dns.google/resolve) werden parallel DNSKEY-, DS- und SOA-Records angefragt. AD-Bit auf der SOA-Response zeigt: validierender Resolver konnte die Chain bis Root verifizieren. DNSKEYs werden auf Algorithmen-Stärke geprüft (deprecated: SHA-1, RSA/MD5; empfohlen: ECDSA P-256 oder Ed25519), DS-Records auf Digest-Typ (SHA-256 oder SHA-384).
Beispiel-Ergebnis
kit.de → signed, validated (AD=1), DNSKEYs: KSK ECDSA P-256, ZSK ECDSA P-256, DS am Parent mit SHA-256 (0 Issues)
Hinweise
DNSSEC ist der Trust-Anchor für MTA-STS und DANE — ohne DNSSEC sind diese Schichten gegen DNS-Spoofing offen.
Was wird geprüft?
Prüft die Certificate Authority Authorization (RFC 8659) einer Domain: welche CAs dürfen Zertifikate ausstellen?
Wie funktioniert es?
CAA-Lookup mit Inheritance: gibt es am angefragten Hostname keinen Record, wird der Parent gesucht (api.example.com → example.com → root). Parst issue, issuewild, iodef, contactemail, contactphone. Kritisch: unbekannte Tags mit critical-Flag (= CA muss ablehnen). Meldet: kein CAA (jede CA darf), niemand-Mode (keine CA darf), fehlendes iodef.
Beispiel-Ergebnis
google.com → issue "pki.goog" (nur Google Trust Services darf, 0 Issues)
Hinweise
CAA verhindert Mis-Issuance durch kompromittierte oder versehentlich verwendete CAs. Let's Encrypt prüft CAA vor jeder Ausstellung — falscher Record blockiert Renewal.
Was wird geprüft?
Bewertet die HTTP-Security-Header einer URL und liefert ein Score (0-100) plus Grade (A+ bis F).
Wie funktioniert es?
HTTP-GET (mit Redirect-Follow) und Bewertung der wichtigsten Header: Strict-Transport-Security (max-age, includeSubDomains, preload), Content-Security-Policy (default-src, frame-ancestors, unsafe-inline/eval-Penalty), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener/Resource-Policy, Server-Disclosure. Score ist gewichtet (CSP=25, HSTS=20, XFO=10, …). Grade nach Schulnoten-Logik: 95+=A+, 85+=A, 75+=B, 65+=C, 50+=D, sonst F.
Beispiel-Ergebnis
https://google.com → Grade F (Score 13/100) — fehlende HSTS, CSP, X-Content-Type-Options
Hinweise
X-Frame-Options wird vergeben, wenn CSP frame-ancestors gesetzt ist (RFC-Übersteuerung). Server-Header ohne Versionsnummer = neutral, mit Version = Punkt-Abzug.
Was wird geprüft?
Erzeugt TXT-Record und Policy-Datei für MTA-STS aus Domain, mode, mx-Liste und max_age.
Wie funktioniert es?
Aus Eingaben werden der TXT-Wert für _mta-sts.<domain> (mit auto-generierter id) und der vollständige mta-sts.txt-Inhalt mit version/mode/mx/max_age zusammengebaut. Sanity-Warnungen bei mode=none/testing, zu kurzem max_age und leerer MX-Liste.
Beispiel-Ergebnis
domain=example.com, mode=enforce, mx=[mx01.example.com, mx02.example.com], max_age=604800 → "v=STSv1; id=…" + 5-zeilige Policy
Hinweise
Bei jeder zukünftigen Policy-Änderung muss die id im TXT-Record erhöht werden, sonst sehen Empfänger die alte Policy.
Was wird geprüft?
Erzeugt TXT-Record für SMTP TLS Reporting (RFC 8460) aus rua-Reporting-Zielen.
Wie funktioniert es?
Akzeptiert mehrere rua-Ziele (mailto: / https:), validiert Scheme und baut den TXT-Record-Wert. Warnt bei ungültigen Schemas.
Beispiel-Ergebnis
domain=example.com, rua=[mailto:tlsrpt@example.com] → "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
Hinweise
Externe rua-Mailboxen ggf. am Reporting-Anbieter authorisieren, sonst werden Reports verworfen.
Was wird geprüft?
Erzeugt BIMI-TXT-Record aus Domain, Selektor, Logo-URL und optionalem VMC.
Wie funktioniert es?
Baut den FQDN <selector>._bimi.<domain> und den TXT-Wert v=BIMI1; l=<logo>; a=<vmc>. Sanity-Checks auf HTTPS-URLs und .svg-/.pem-Endungen.
Beispiel-Ergebnis
domain=example.com, selector=default, logoUrl=https://example.com/logo.svg → "v=BIMI1; l=https://example.com/logo.svg"
Hinweise
BIMI-Anzeige greift nur bei DMARC p=quarantine/reject. Gmail verlangt zusätzlich ein VMC.
Was wird geprüft?
Prüft SVG-Logos auf Konformität zu SVG Tiny 1.2 PS (Portable/Secure) für BIMI.
Wie funktioniert es?
Lädt SVG per URL oder akzeptiert Inline-Code. Prüft baseProfile=tiny-ps, version=1.2, quadratischer viewBox, max 32 KB, vorhandener title, verbotene Elemente (script, animation, foreignObject, iframe, image, a, video, audio, set, animateMotion/Transform), externe Referenzen und Event-Handler.
Beispiel-Ergebnis
baseProfile=tiny-ps, viewBox=0 0 100 100, title=Logo, ohne <script> → valid
Hinweise
Tiny PS verbietet alles, was zur Laufzeit Code ausführen oder externe Ressourcen laden könnte. Animationen sind ausgeschlossen.
Was wird geprüft?
Bewertet eine URL anhand von 12+ Phishing-/Malware-Indikatoren und vergibt einen Risk-Score 0-100.
Wie funktioniert es?
Pattern-Analyse für: NO_HTTPS, IP_AS_HOST, lange URL, viele Subdomains, verdächtige TLDs (.zip/.click/.xyz/...), URL-Shortener, Brand-Impersonation (35 Top-Brands), IDN-Homograph (Latin+Cyrillic/Greek-Mix), Punycode, Phishing-Pfad-Keywords (login/verify/account/secure...), non-standard Ports. Plus Live-Lookup gegen URLhaus (abuse.ch, kostenlos).
Beispiel-Ergebnis
http://paypal-secure-login-update.click/verify → Score 75, level=critical (NO_HTTPS + SUSPICIOUS_TLD + BRAND_IMPERSONATION + PHISHING_KEYWORDS_PATH)
Hinweise
Brand-Impersonation kennt offizielle Apex-Domains der erkannten Marken — eine URL mit "paypal" im Host, die nicht auf paypal.com/paypal.de endet, gilt als verdächtig.
Was wird geprüft?
Analysiert hochgeladene DMARC-Aggregate-Reports (.xml oder .xml.gz) nach Source-IPs, Pass/Fail-Raten und Sender-Provider.
Wie funktioniert es?
Akzeptiert XML oder gzip-komprimierte Reports. Parst Meta-Daten (Reporter, Zeitraum, Policy), aggregiert alle Records nach Source-IP, berechnet Gesamt-Pass-Rate. Top-10 Source-IPs bekommen Reverse-DNS + Provider-Erkennung (Google/Microsoft/Amazon SES/SendGrid/Mailchimp/...).
Beispiel-Ergebnis
google.com_reporter.xml → Reporter: Google, Zeitraum 24h, 5.234 Mails von 12 Source-IPs, 96 % Pass-Rate
Hinweise
Stateless — Datei wird nur im Request verarbeitet, nicht gespeichert. Warnt bei niedriger Gesamt-Pass-Rate und vielen unbekannten Sendern.
Was wird geprüft?
Identifiziert anhand von SPF, MX und DKIM, welche externen Mail-Vendors für eine Domain mailen oder Mail empfangen.
Wie funktioniert es?
Liest SPF und parst alle include:-Targets, holt MX-Records und probt 19 gängige DKIM-Selektor-CNAMEs. Matcht gegen einen Katalog von 19 bekannten Vendors (Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailchimp, Mailgun, Postmark, Brevo, Salesforce, HubSpot, Klaviyo, Zendesk, Intercom, Hornetsecurity, IONOS, Strato, ConvertKit, ...).
Beispiel-Ergebnis
mt-computerservice.de → IONOS (alle Rollen) + Microsoft 365 (sending+DKIM)
Hinweise
Pro Vendor werden die Rollen (sending/receiving/authentication) gezeigt, plus alle DNS-Evidence-Snippets. Warnt, wenn ein Vendor sendet aber keinen DKIM-Selektor hat (Alignment-Risiko für DMARC).
Was wird geprüft?
Prüft, ob eine Domain ein BIMI-Logo für die Anzeige in E-Mail-Clients konfiguriert hat.
Wie funktioniert es?
DNS-TXT-Abfrage auf default._bimi.[domain]. Wenn vorhanden, wird das referenzierte SVG-Logo abgerufen und auf Gültigkeit (SVG Tiny 1.2 Profil) geprüft.
Beispiel-Ergebnis
example.com → BIMI-Record: v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem – Logo: gültig
Was wird geprüft?
Umfassende Exchange-Intelligence: erkennt Microsoft Exchange Server samt Version, Patch-Stand, bekannten CVEs und End-of-Life-Status und liefert zusätzlich Host-/TLS-Analyse, Port-Exposure, SMTP-Gateway-Fingerprint, den kompletten Mail-DNS-Stack sowie priorisierte Handlungsempfehlungen.
Wie funktioniert es?
Mehrstufige Analyse: (1) HTTP-Probes aller Exchange-Endpoints (Autodiscover, OWA, ECP, ActiveSync, EWS, OAB, MAPI/HTTP, RPC/HTTP, PowerShell, REST API) auf Haupt- und mail./autodiscover.-Subdomains mit Versionserkennung aus Response-Headern. (2) Autodiscover-POST mit echtem XML-Request. (3) TLS pro Host: Zertifikat (Subject, Issuer, SAN, Wildcard-Status, Ablauf) plus Versions-Matrix TLS 1.0/1.1/1.2/1.3. (4) Port-Exposure auf 25, 443, 465, 587, 993, 995. (5) SMTP-Handshake mit EHLO-Feature-Parse und STARTTLS-Verhandlung (Cipher/Protokoll). (6) Mail-DNS-Stack: SPF, DMARC-Breakdown (p/sp/rua/ruf/adkim/aspf), DKIM-Selector-Probe, MTA-STS (DNS + .well-known-Policy), TLS-RPT, CAA, BIMI, Nameserver. (7) MX-Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL. (8) Abgleich gegen CVE-Datenbank (Static + NVD-Feed) und endoflife.date. (9) Regelbasierte Recommendation-Engine priorisiert alle Findings nach kritisch/hoch/info.
Beispiel-Ergebnis
example.com → Exchange SE 15.2.2562.17 erkannt, 5 SUs hinten, 16 NVD-CVEs, Wildcard-Cert 165 Tage, TLS 1.3 fehlt, DMARC ohne rua, MTA-STS fehlt, 9 priorisierte Empfehlungen
Hinweise
Port 25 wird bei manchen Scans vom Hoster blockiert, sodass der SMTP-EHLO-Block leer bleibt - alle anderen Intelligence-Daten werden trotzdem sauber geliefert. Das Tool arbeitet passiv, sendet nie echte Mail und meldet sich nur unauthentifiziert an Exchange-Endpoints.
Was wird geprüft?
Prüft, ob eine Domain DANE (DNS-Based Authentication of Named Entities) für die Absicherung von E-Mail-Transport einsetzt.
Wie funktioniert es?
Abfrage der TLSA-DNS-Records und Prüfung auf DNSSEC-Signierung. DANE erfordert DNSSEC, da die TLSA-Records sonst nicht vertrauenswürdig sind.
Beispiel-Ergebnis
example.com → TLSA-Record: 3 1 1 abc123..., DNSSEC: aktiv, DANE-Status: gültig
SEO & Website20
Was wird geprüft?
Analysiert die SEO-relevanten Meta-Tags einer Webseite: Title, Description, Open Graph und Twitter Cards.
Wie funktioniert es?
Der HTML-Quellcode wird geladen und die Meta-Tags per HTML-Parsing extrahiert. Geprüft werden Länge, Vorhandensein und Qualität der wichtigsten Tags.
Beispiel-Ergebnis
example.com → Title: "Beispiel GmbH" (12 Zeichen – zu kurz), Description: vorhanden (148 Zeichen – optimal), OG:Image: fehlt
Was wird geprüft?
Analysiert die robots.txt-Datei einer Website und zeigt die Crawler-Regeln übersichtlich an.
Wie funktioniert es?
Die robots.txt wird abgerufen und die Direktiven (Allow, Disallow, Sitemap, Crawl-delay) pro User-Agent geparst und ausgewertet.
Beispiel-Ergebnis
example.com/robots.txt → User-Agent: * – Disallow: /admin/, /tmp/ – Sitemap: https://example.com/sitemap.xml
Was wird geprüft?
Prüft die XML-Sitemap einer Website auf Gültigkeit und Vollständigkeit.
Wie funktioniert es?
Discovery folgt der sitemaps.org-Spec: zuerst wird die robots.txt nach einer Sitemap:-Direktive durchsucht (kanonische Methode, die auch Google und Bing nutzen). Erst wenn dort nichts steht, werden gängige Pfade als Fallback geprüft (/sitemap.xml, /sitemap_index.xml für Yoast, /sitemap-index.xml für Astro, /wp-sitemap.xml für WordPress-Core, /sitemap-0.xml). Anschließend wird das XML geparst und auf Pflichtfelder (loc, lastmod) geprüft. Sitemap-Indizes werden ebenfalls unterstützt.
Beispiel-Ergebnis
example.com → robots.txt verweist auf /sitemap-index.xml → 42 URLs gefunden, 3 ohne lastmod, 1 URL mit HTTP-Fehler 404
Hinweise
Sehr große Sitemaps (>50.000 URLs) werden nur teilweise analysiert. Wenn weder die robots.txt eine Sitemap deklariert noch einer der Standard-Pfade antwortet, gilt die Sitemap als nicht gefunden.
Was wird geprüft?
Zeigt eine Vorschau, wie eine URL auf Social-Media-Plattformen dargestellt wird.
Wie funktioniert es?
Open-Graph- und Twitter-Card-Tags werden ausgelesen und als Vorschau für Facebook, Twitter/X und LinkedIn simuliert.
Beispiel-Ergebnis
example.com → Facebook: Titel + Bild + Beschreibung, Twitter: Summary Card mit Bild, LinkedIn: Titel + Beschreibung
Was wird geprüft?
Prüft eine Webseite auf WCAG 2.1 Barrierefreiheits-Probleme (automatisierte Prüfung).
Wie funktioniert es?
Die Seite wird in einer jsdom-Umgebung geladen und mit der axe-core Engine analysiert. Gefundene Probleme werden nach Schweregrad (kritisch, schwerwiegend, moderat, gering) kategorisiert.
Beispiel-Ergebnis
3 kritisch: Bilder ohne Alt-Text, 5 schwerwiegend: fehlende Formular-Labels, 2 moderat: unzureichender Farbkontrast
Hinweise
Automatisierte Tests decken ca. 30-40% der WCAG-Kriterien ab. Eine vollständige Barrierefreiheits-Prüfung erfordert zusätzlich manuelle Tests.
Was wird geprüft?
Erkennt alle Cookies und Tracking-Technologien, die eine Website setzt.
Wie funktioniert es?
Die Seite wird in einem headless Puppeteer-Browser geladen. Über das Chrome DevTools Protocol (CDP) werden alle Cookies, Local-/SessionStorage-Einträge und Netzwerk-Requests analysiert. Optional wird ein Cookie-Consent simuliert (Deep Scan).
Beispiel-Ergebnis
8 Cookies gefunden: 2 notwendig (Session-ID, CSRF-Token), 4 Analytics (Google Analytics, Hotjar), 2 Marketing (Facebook Pixel)
Hinweise
Es können nicht alle Cookies erfasst werden – insbesondere Cookies, die erst nach Login gesetzt werden.
Was wird geprüft?
Erkennt die eingesetzten Technologien einer Website (CMS, Frameworks, Server, Analytics).
Wie funktioniert es?
HTTP-Response-Header (X-Powered-By, Server etc.) und HTML-Quellcode werden auf bekannte Muster geprüft. Pattern-Matching gegen eine Datenbank gängiger Technologie-Signaturen.
Beispiel-Ergebnis
example.com → Server: nginx, CMS: WordPress 6.4, PHP: 8.2, jQuery: 3.7, Google Analytics: GA4
Was wird geprüft?
Findet defekte Links (404, Timeout, etc.) auf einer Webseite.
Wie funktioniert es?
Alle Links im HTML-Quellcode werden extrahiert und per HTTP HEAD-Request auf Erreichbarkeit geprüft. Fehlerhafte Antworten (4xx, 5xx, Timeout) werden gemeldet.
Beispiel-Ergebnis
47 Links geprüft → 2 defekt: /alte-seite (404), https://extern.example.com/api (Timeout)
Hinweise
Es werden nur Links auf der angegebenen Seite geprüft, kein Crawling der gesamten Website.
Was wird geprüft?
Prüft Schema.org Structured Data (JSON-LD) einer Seite auf Vorhandensein und Korrektheit.
Wie funktioniert es?
JSON-LD-Blöcke im HTML werden extrahiert und geparst. Pflichtfelder je Schema-Typ werden validiert und fehlende Eigenschaften gemeldet.
Beispiel-Ergebnis
example.com → 1 Schema gefunden: Organization (name: ja, url: ja, logo: fehlt, contactPoint: fehlt)
Was wird geprüft?
Analysiert die Ladezeit und Performance-Kennzahlen einer Webseite.
Wie funktioniert es?
Gemessen werden Time-to-First-Byte (TTFB), Gesamtladezeit, Anzahl und Größe der Ressourcen (CSS, JS, Bilder) sowie Optimierungspotenziale.
Beispiel-Ergebnis
example.com → TTFB: 180ms, Ladezeit: 1.8s, 23 Requests, 1.2 MB Gesamt, 4 Bilder ohne Kompression
Was wird geprüft?
Findet doppelte oder widersprüchliche Meta-Tags über mehrere Seiten einer Website hinweg.
Wie funktioniert es?
Die Sitemap wird gecrawlt und die Meta-Tags (Title, Description) jeder Seite extrahiert und verglichen. Duplikate und zu ähnliche Einträge werden markiert.
Beispiel-Ergebnis
35 Seiten geprüft → 3 doppelte Titles ("/about" und "/über-uns"), 5 Seiten ohne Description
Hinweise
Maximal 100 Seiten aus der Sitemap werden geprüft.
Was wird geprüft?
Analysiert Bilder einer Webseite auf Optimierungspotenzial: Format, Größe, Alt-Texte und Lazy Loading.
Wie funktioniert es?
Alle Bild-Tags im HTML werden extrahiert. Geprüft werden: Dateiformat (WebP/AVIF-Empfehlung), Dateigröße, Vorhandensein von Alt-Texten und Lazy-Loading-Attributen.
Beispiel-Ergebnis
12 Bilder gefunden → 3 ohne Alt-Text, 5 als PNG statt WebP (Einsparung: ~60%), 2 ohne Lazy Loading
Was wird geprüft?
Bewertet die Inhaltsqualität einer Webseite: Lesbarkeit, Wortanzahl und Keyword-Dichte.
Wie funktioniert es?
Der Textinhalt wird extrahiert und analysiert. Berechnet werden Flesch-Reading-Ease (angepasst für Deutsch), Wortanzahl, Satzlänge und Keyword-Verteilung.
Beispiel-Ergebnis
example.com → 820 Wörter, Lesbarkeit: 58 (mittelschwer), Durchschn. Satzlänge: 16 Wörter, Top-Keywords: "service" (2.1%), "beratung" (1.8%)
Was wird geprüft?
Zeigt eine Vorschau, wie eine Seite in den Google-Suchergebnissen dargestellt wird.
Wie funktioniert es?
Title und Meta-Description werden mit Pixel-genauer Berechnung dargestellt. Zu lange Texte werden an der gleichen Stelle abgeschnitten wie bei Google.
Beispiel-Ergebnis
Title: "Beispiel GmbH – Ihr Partner für..." (56 Zeichen, 480px – passt), Description: "Wir bieten..." (142 Zeichen, 890px – wird abgeschnitten bei 920px)
Was wird geprüft?
Prüft, wie gut eine Seite für Generative Engine Optimization (KI-Suchen wie Google AI Overviews, ChatGPT, Perplexity, Bing Copilot) aufgestellt ist.
Wie funktioniert es?
Geladen wird die Seite mit Headless-Chromium. Geprüft werden: AI-Crawler in robots.txt (GPTBot, ClaudeBot, PerplexityBot, Google-Extended), llms.txt-Vorhandensein, FAQ/HowTo/Article-Schema, Autor-Markup, Datumsangaben, Passage-Citability (kurze, faktische Aussagen) sowie E-E-A-T-Signale.
Beispiel-Ergebnis
example.com -> GPTBot erlaubt, llms.txt vorhanden, 12 zitierbare Passagen, FAQ-Schema (5 Q&A), Score 78/100
Hinweise
Unterscheidet sich von klassischem SEO: Es geht nicht um Ranking-Position, sondern um die Wahrscheinlichkeit, in KI-generierten Antworten zitiert zu werden. AI-Crawler-Blockierung kann gewollt sein, daher als Info-Hinweis und nicht als Fehler ausgegeben.
Was wird geprüft?
Prüft ob sensible Dateien (.env, .git, wp-config.php, SQL-Dumps, docker-compose.yml etc.) öffentlich erreichbar sind.
Wie funktioniert es?
Ca. 30 bekannte sensible Pfade werden per HTTP GET abgefragt. Bei Status 200 wird der Inhalt mit dateitypspezifischen Validatoren geprüft (z.B. ".env" muss "=" enthalten, ".git/HEAD" muss "ref:" enthalten), um Custom-404-Seiten auszuschließen. Die Prüfung läuft in Batches von 10 parallelen Requests mit je 5 Sekunden Timeout.
Beispiel-Ergebnis
example.com → .env: exponiert (kritisch), .git/HEAD: nicht erreichbar, wp-config.php: nicht erreichbar, .well-known/security.txt: vorhanden (info)
Hinweise
security.txt (.well-known/security.txt) wird als positive Sicherheitspraxis gemeldet, nicht als Schwachstelle. Inhalt wird nur teilweise gelesen (max. 4 KB) und sensible Werte werden im Snippet maskiert.
Was wird geprüft?
Prüft ob die vier wichtigsten rechtlichen Pflichtseiten vorhanden und verlinkt sind: Impressum, Datenschutzerklärung, Cookie-Consent und Barrierefreiheitserklärung.
Wie funktioniert es?
Die Startseite wird geladen und das HTML nach Links mit relevanten Texten durchsucht (z.B. "Impressum", "Datenschutz", "Privacy"). Bei Treffern wird die Zielseite geladen und auf Inhalts-Muster geprüft (z.B. PLZ+Ort für Impressum). Fallback-Prüfung gängiger Standard-URLs (/impressum, /datenschutz etc.). Cookie-Consent wird über bekannte CMP-Signaturen im HTML erkannt (Cookiebot, OneTrust, Usercentrics, Borlabs, Klaro u.a.).
Beispiel-Ergebnis
example.com → Impressum: gefunden (pass), Datenschutz: gefunden (pass), Cookie-Consent: Cookiebot erkannt (pass), Barrierefreiheit: nicht gefunden (warn) → Score: 85/100
Hinweise
Die Prüfung ist eine Heuristik und ersetzt keine juristische Bewertung. Inhalte von Impressum und Datenschutzerklärung werden nur auf Muster geprüft, nicht inhaltlich validiert.
Was wird geprüft?
Durchsucht Schwachstellen-Datenbanken (NVD und OSV) nach bekannten CVEs für Software, Bibliotheken und Produkte.
Wie funktioniert es?
Der Suchbegriff (Software-Name, Bibliothek, Produkt oder CVE-ID) wird parallel bei der NVD (National Vulnerability Database, NIST) und OSV (Open Source Vulnerabilities, Google) abgefragt. Ergebnisse werden nach CVSS-Score bewertet, dedupliziert und nach Schweregrad sortiert.
Beispiel-Ergebnis
Suche "WordPress" → CVE-2024-31210 (kritisch, CVSS 9.8): Remote Code Execution, CVE-2024-28890 (hoch, CVSS 7.5): SQL Injection, ...
Hinweise
Maximal 30 Ergebnisse werden angezeigt. Die NVD-API hat Rate-Limits, daher können bei vielen Anfragen Verzögerungen auftreten. OSV deckt hauptsächlich Open-Source-Software ab.
Was wird geprüft?
Analysiert den CO2-Fußabdruck einer Webseite, Green Hosting, HTTP-Kompression, Bildformate und Font-Loading.
Wie funktioniert es?
Die Startseite wird geladen und die Transfer-Größe gemessen. CO2 wird nach dem Sustainable Web Design Model berechnet (0.81 kWh/GB × 442g CO2/kWh). Green Hosting wird über die Green Web Foundation API geprüft. Zusätzlich werden Content-Encoding (Kompression), Bildformate (Legacy vs. WebP/AVIF), Font-Dateien (@font-face, font-display, externe Fonts) und die Gesamtzahl externer Ressourcen analysiert.
Beispiel-Ergebnis
example.com → 0.12g CO2 (Exzellent), Green Hosting: ja (Hetzner), Brotli-Kompression: aktiv, 3 Legacy-Bilder, 4 Font-Dateien → Score: 78/100
Hinweise
Die CO2-Berechnung basiert auf der HTML-Transfergröße der Startseite. Nachgeladene Ressourcen (JS, CSS, Bilder) werden gezählt aber nicht separat gewogen. Durchschnitt liegt bei ca. 0.5g CO2 pro Pageview.
Was wird geprüft?
Erkennt alle externen Dienste und Drittanbieter, die eine Website lädt, und prüft die DSGVO-Konformität.
Wie funktioniert es?
Bis zu 30 Seiten werden per Sitemap oder Homepage-Crawl gesammelt. Für jede Seite werden alle extern geladenen Ressourcen (Scripts, Stylesheets, Fonts, iFrames, Bilder) extrahiert und gegen eine Datenbank von über 80 bekannten Diensten abgeglichen. Zusätzlich werden Inline-Script-Patterns (z.B. GTM-Container, Facebook Pixel) erkannt. Die Datenschutzerklärung wird per Link-Text-Suche oder Standard-URL-Fallback gefunden und textbasiert auf Erwähnung der erkannten Dienste geprüft.
Beispiel-Ergebnis
example.com → 12 externe Dienste: Google Analytics (Consent: ja, in DSE: ja), Google Fonts (Consent: ja, in DSE: nein – Warnung!), Cloudflare CDN (Consent: nein), DSGVO-Score: 67/100
Hinweise
Nur im HTML deklarierte Ressourcen werden erkannt. Dienste, die erst nach JavaScript-Ausführung oder nach Consent dynamisch geladen werden, können nur über Inline-Script-Pattern-Matching teilweise erkannt werden. Der Datenschutz-Abgleich ist eine Heuristik und ersetzt keine juristische Prüfung.
Generatoren7
Was wird geprüft?
Erstellt einen korrekten SPF-Record (Sender Policy Framework) für Ihre Domain.
Wie funktioniert es?
Über ein Konfigurationsformular wählen Sie erlaubte Mailserver, IP-Adressen und Include-Einträge. Daraus wird die korrekte TXT-Record-Syntax generiert.
Beispiel-Ergebnis
Eingabe: Google Workspace + eigener Server 203.0.113.5 → Ergebnis: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all
Hinweise
Ein SPF-Record darf maximal 10 DNS-Lookups auslösen. Der Generator warnt bei Überschreitung.
Was wird geprüft?
Erstellt einen DMARC-Record (Domain-based Message Authentication) für Ihre Domain.
Wie funktioniert es?
Sie wählen die DMARC-Policy (none, quarantine, reject), Berichts-Adressen und Prozentsatz. Daraus wird der TXT-Record für _dmarc.[domain] generiert.
Beispiel-Ergebnis
Policy: reject, Report: admin@example.com → Ergebnis: v=DMARC1; p=reject; rua=mailto:admin@example.com; pct=100
Was wird geprüft?
Erstellt eine robots.txt-Datei mit Crawler-Regeln für Ihre Website.
Wie funktioniert es?
Über einen Regel-Builder definieren Sie Allow/Disallow-Direktiven pro User-Agent und fügen Sitemap-Verweise hinzu. Das Ergebnis wird im robots.txt-Format ausgegeben.
Beispiel-Ergebnis
Ergebnis: User-agent: * Disallow: /admin/ Disallow: /private/ Sitemap: https://example.com/sitemap.xml
Was wird geprüft?
Erstellt einen Content Security Policy (CSP) Header für Ihre Website.
Wie funktioniert es?
Über einen Direktiven-Builder konfigurieren Sie erlaubte Quellen für Scripts, Styles, Bilder und weitere Ressourcentypen. Daraus wird die CSP-Header-Syntax generiert.
Beispiel-Ergebnis
Ergebnis: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *
Was wird geprüft?
Erstellt HTML-Meta-Tags für SEO, Open Graph und Twitter Cards.
Wie funktioniert es?
Über ein Formular geben Sie Title, Description, Keywords und Social-Media-Informationen ein. Daraus werden die entsprechenden HTML-Meta-Tag-Snippets generiert.
Beispiel-Ergebnis
Eingabe: Title "Meine Seite", Desc "Beschreibung" → <title>Meine Seite</title>, <meta name="description" content="Beschreibung">, <meta property="og:title" ...>
Was wird geprüft?
Erstellt Apache .htaccess-Konfigurationen für gängige Anwendungsfälle.
Wie funktioniert es?
Sie wählen aus Modulen wie Redirects, Caching, Kompression, Sicherheitsheader und URL-Rewriting. Daraus werden die entsprechenden Apache-Direktiven generiert.
Beispiel-Ergebnis
HTTPS-Redirect + Caching → RewriteEngine On, RewriteCond %{HTTPS} off, RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] + ExpiresByType ...
Was wird geprüft?
Generiert ein DKIM-Schlüsselpaar (RSA) für die E-Mail-Authentifizierung einer Domain.
Wie funktioniert es?
Im Browser wird über die Web Crypto API ein RSA-Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird als DNS-TXT-Record im DKIM-Format ausgegeben, der private Schlüssel im PEM-Format zum Download angeboten.
Beispiel-Ergebnis
Domain: example.com, Selektor: default → DNS: default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..." + Private Key als .pem Download
Hinweise
Die Schlüssel werden ausschließlich im Browser generiert – es werden keine Daten an den Server übertragen.