Handbuch

Checks

Jede Domain bekommt bis zu 21 Monitore, einen je freigeschaltetem Check-Typ (SMTP und IPv6 nur, wenn der Betreiber sie freigibt). Dieses Kapitel erklärt je Typ, was geprüft wird, welche Befunde entstehen können und wann daraus ein Incident wird. Am Ende steht das Punktesystem des öffentlichen Domain-Checks.

Auf dieser Seite

Wie ein Check arbeitet

Ein Monitor ist ein Check-Typ auf einem Ziel (Domain, Hostname oder URL) mit eigenem Intervall. Jeder Lauf endet mit einem Ergebnis: ok, warning, critical oder error. Ein Fehler bedeutet, dass DomainWarn selbst nicht prüfen konnte (Resolver-Timeout, Zeitbudget überschritten); er verändert nie einen Incident. Befunde tragen eine Schwere: Hinweis (info), Warnung oder kritisch, jeder mit Text und Empfehlung in Deutsch und Englisch.

Nur Zustandsbefunde eröffnen Incidents, und erst nach ihrer Schwelle: einer festen Zahl aufeinanderfolgender Läufe (1, 2 oder 3) oder, bei Verfügbarkeitschecks, nach der eingestellten Fehlerdauer (Standard 5 Minuten, umgerechnet in Läufe). Hinweise erzeugen nie einen Incident. Änderungen (ein Record ist anders als beim letzten Lauf) sind Ereignisse mit Vorher und Nachher, werden einmal gemeldet und laufen nicht als Incident weiter; Einzelheiten in „Alarme“.

Ein Lauf hat 30 Sekunden Zeit. HTTP-Abrufe folgen höchstens fünf Weiterleitungen und lesen höchstens 512 KB. DNS wird bevorzugt am autoritativen Nameserver abgefragt; jede erkannte Änderung wird nach 45 Sekunden an einem zweiten Nameserver der Zone bestätigt.

Siehe auch: Incidents, Schwellen und Erinnerungen

Website

Die Website-Checks laufen auf jedem Hostnamen mit Website-Monitor, also mindestens auf Apex und www.

  • http Website: Erreichbarkeit, Statuscode, Antwortzeit, Weiterleitungskette, Seiteninhalt und Sicherheits-Header. Verbindungsfehler, Timeouts und 5xx sind kritisch und eröffnen http_down nach der Fehlerdauer; ein anderer als der erwartete Statuscode ist eine Warnung (http_status); Antworten über der Langsam-Schwelle (Standard 5 s) eröffnen http_slow nach drei Läufen; eine HTTPS-Adresse, die auf http:// weiterleitet, sofort http_no_https. Fehlt ein Pflichttext oder taucht ein verbotener auf, entsteht http_content. Header-Befunde (HSTS, CSP, nosniff, Framing, Referrer- und Permissions-Policy, verratene Server-Versionen) sind Hinweise ohne Incident.
  • tls Zertifikat: Handshake, Kette, Hostname, Gültigkeit, Signaturalgorithmus und Protokoll auf Port 443 oder einem Mailport mit STARTTLS. Abgelaufen ist kritisch (tls_expired, sofort); unter 14 Tagen Restlaufzeit eine Warnung (tls_expiring), unter 30 Tagen ein Hinweis. Kettenfehler, falscher Hostname, selbstsigniert und noch nicht gültig eröffnen tls_invalid nach zwei Läufen; nicht erreichbar tls_unreachable. SHA-1 und TLS 1.0/1.1 sind Warnungen ohne Incident. Eine Erneuerung wird als Ereignis gemeldet, ein neuer Aussteller als Warnung.
  • redirects Weiterleitungen: http://, http://www., https:// und https://www. müssen bei derselben kanonischen HTTPS-Adresse landen. Unerreichbare Varianten, fehlende Weiterleitung auf https, Fehlerstatus am Ende und uneinheitliche Ziele eröffnen redirects_broken; lange Ketten und temporäre Redirects (302/307) sind Hinweise. Ändert sich die kanonische Adresse, wird das als Warnung gemeldet.
  • ipv6 IPv6: Hat der Hostname AAAA-Records, wird jede IPv6-Adresse per HTTP angesprochen. Keine Antwort oder 5xx eröffnet ipv6_broken nach der Fehlerdauer; fehlende AAAA-Records sind ein Hinweis. Vor jedem Befund prüft DomainWarn den eigenen IPv6-Pfad gegen Referenzziele; ohne IPv6-Route endet der Lauf als Fehler. Der Monitor entsteht nur, wenn der Betreiber IPv6 freigeschaltet hat.
  • ct_log Certificate Transparency: Alle Zertifikate der letzten 30 Tage für die Domain und ihre Subdomains aus den CT-Logs. Ein bisher unbekannter Aussteller ist eine Warnung ohne Incident; jedes neu ausgestellte Zertifikat ein Ereignis. Fällt es in die 24 Stunden nach einem Nameserver- oder MX-Wechsel, wird es als kritisch gemeldet. Hostnamen aus Zertifikaten ohne Website-Monitor werden als Vorschlag an der Domain gesammelt (bis 50 offene), die du per Klick übernimmst oder ausblendest.

Siehe auch: Website-Monitoring · SSL-Monitoring

E-Mail

Die E-Mail-Checks laufen auf der Domain. Werden beim Anlegen weder MX noch SPF gefunden, ist der Bereich zunächst abgeschaltet.

  • mx Mailserver-Records: Vorhandensein, Null-MX und Auflösbarkeit jedes MX-Hosts. Kein MX ist kritisch (mx_missing), kein auflösbarer MX kritisch (mx_unresolvable), teilweise auflösbar eine Warnung; jeweils nach zwei Läufen. Ein MX-Wechsel ist eine Warnung, ein entfernter MX kritisch.
  • spf SPF: Syntax, Mechanismen, Includes mit Schleifen, Lookup-Zahl und all-Qualifier. Fehlender Record (spf_missing), mehrere Records (spf_multiple, kritisch, weil Empfänger permerror werten), Syntaxfehler und kaputte Includes (spf_invalid), mehr als 10 DNS-Lookups (spf_lookups) und +all, ?all oder fehlendes all (spf_permissive) eröffnen nach einem Lauf; 9 Lookups sind ein Hinweis, ~all ebenfalls, ptr eine Warnung ohne Incident. Ein entfernter SPF-Record ist eine kritische Änderung.
  • dkim DKIM: Die eingetragenen Selektoren, ohne Eintrag eine Suche über 39 gängige Selektoren (google, selector1, k1, default, mail, brevo, mailgun, ionos, strato, amazonses und weitere). Fehlende konfigurierte Selektoren eröffnen dkim_missing nach zwei Läufen; widerrufene, ungültige und zu kurze Schlüssel dkim_invalid, unter 1024 Bit kritisch. Unter 2048 Bit und Testmodus (t=y) sind Hinweise. Wird nichts gefunden, ist das nur ein Hinweis, deine Selektoren einzutragen.
  • dmarc DMARC: Record unter _dmarc, Syntax, Policy, pct, rua, Subdomain-Policy. Fehlender Record eröffnet dmarc_missing nach einem Lauf, mehrere Records ebenfalls (kritisch). p=none, p=quarantine, pct unter 100, fehlende Berichtsadresse und eine schwächere Subdomain-Policy sind Hinweise. Eine abgeschwächte Policy ist eine kritische Änderung.
  • mta_sts MTA-STS: TXT-Record, Policy-Datei unter https://mta-sts.<domain>/.well-known/mta-sts.txt, Modus, max_age und ob alle MX-Hosts abgedeckt sind. Fehlende Policy ist ein Hinweis; fehlerhafte Records, unerreichbare Policy und fehlende Felder eröffnen mta_sts_invalid nach zwei Läufen. Nicht abgedeckte MX-Hosts im enforce-Modus sind kritisch, weil Absender die Zustellung verweigern.
  • tls_rpt TLS-RPT: Record unter _smtp._tls mit plausibler Berichtsadresse. Fehlender Record ist ein Hinweis mit Empfehlung, ein fehlerhafter eine Warnung ohne Incident.
  • bimi BIMI: Record unter default._bimi, Logo-URL (https, SVG Tiny PS), VMC-URL und die Voraussetzung DMARC mit quarantine oder reject. Fehlender Record ist ein Hinweis; fehlerhafte oder unerreichbare Logo- und VMC-Adressen sowie BIMI ohne durchgesetzte DMARC-Policy eröffnen bimi_invalid nach zwei Läufen.
  • smtp Mailserver: Verbindung auf Port 25 zu bis zu fünf MX-Hosts, Banner, STARTTLS, TLS-Version und Zertifikat; nie wird eine Mail eingeliefert. Kein erreichbarer Mailserver ist kritisch (smtp_unreachable), fehlendes oder scheiterndes STARTTLS, ungültiges Zertifikat und TLS 1.0/1.1 sind Warnungen mit Incident, ein einzelner toter MX eine Warnung ohne. Der Monitor entsteht nur, wenn der Betreiber Port 25 freigeschaltet hat.
  • reverse_dns Reverse DNS: Jede Adresse der MX-Hosts braucht einen PTR-Record, der auf die Adresse zurückzeigt. Fehlender PTR (reverse_dns_missing) und nicht passender PTR (reverse_dns_mismatch) eröffnen nach zwei Läufen; den PTR setzt der Betreiber des IP-Netzes.
  • dane DANE: TLSA-Records unter _25._tcp.<mx>, DNSSEC-Signierung, brauchbare Usage (2 oder 3) und, wenn Port 25 freigeschaltet ist, der Abgleich mit dem per STARTTLS ausgelieferten Zertifikat. Kein TLSA ist ein Hinweis; unsignierte, ungültige oder unprüfbare Records eröffnen dane_broken nach zwei Läufen; ein Zertifikat, zu dem kein TLSA-Record passt, ist sofort kritisch (dane_mismatch).

Siehe auch: E-Mail-Monitoring

Domain und DNS

Diese Checks laufen auf der Domain; CAA zusätzlich je Hostname mit Zertifikat.

  • dns DNS-Records: A, AAAA, CNAME, MX, TXT, NS und CAA, bevorzugt am autoritativen Nameserver, kanonisiert als Snapshot für die Änderungserkennung. NXDOMAIN und SERVFAIL sind kritisch (dns_failed), eine Zone ohne A, AAAA, CNAME und MX eine Warnung (dns_empty), jeweils nach zwei Läufen. Ein CNAME neben anderen Records ist eine Warnung ohne Incident. Einzelne Record-Änderungen sind Ereignisse, Nameserver- und MX-Wechsel Warnungen.
  • dnssec DNSSEC: DS-Record in der Elternzone und Validierung über einen validierenden Resolver, Ablauf der Signaturen, abgekündigte Algorithmen. Eine scheiternde Validierung ist kritisch (dnssec_bogus, zwei Läufe), denn Google, Cloudflare und Quad9 erreichen die Domain dann nicht. Signaturen, die in unter 7 Tagen ablaufen, sind eine Warnung, unter 2 Tagen kritisch (dnssec_expiring); die Warnung greift nur, wenn auch weniger als ein Drittel der Gültigkeitsdauer übrig ist, damit kurz signierende Anbieter keine Fehlalarme erzeugen. Ohne DNSSEC gibt es einen Hinweis.
  • domain Registrierung: Ablaufdatum, Registrar, EPP-Status und Nameserver laut Registry per RDAP, einmal täglich. Ablauf in unter 30 Tagen ist eine Warnung (domain_expiring), unter 60 Tagen ein Hinweis; abgelaufen oder nicht registriert kritisch (domain_expired); clientHold/serverHold kritisch (domain_hold). Fehlende Transfersperre ist ein Hinweis. Registries ohne Ablaufdatum (DENIC für .de) liefern nur Status und Nameserver. Ein Registrarwechsel wird als Warnung gemeldet.
  • blacklist Blacklists: Die IPv4-Adressen der Website und der ersten fünf MX-Hosts gegen Spamhaus ZEN, Spamcop, Barracuda und PSBL, der Domainname gegen Spamhaus DBL und SURBL. Eine gelistete Mailserver-IP oder Domain ist kritisch, eine gelistete Website-IP eine Warnung (blacklist_listed, ein Lauf). Nur eindeutige Listungsantworten zählen; die Streichung wird als Entwarnung gemeldet.
  • caa CAA: CAA-Records samt Eltern- und Wildcard-Regeln, verglichen mit der Zertifizierungsstelle des aktuellen Zertifikats auf Port 443 (rund 30 CAs bekannt). Kein CAA-Record ist ein Hinweis; ein Record, der die eigene CA aussperrt, eine Warnung (caa_blocks_issuer), weil die nächste Verlängerung scheitern würde; ungültige Records caa_invalid, jeweils nach zwei Läufen.
  • nameservers Nameserver: Jeder NS der Zone braucht eine Adresse, muss antworten, autoritativ sein und dieselbe SOA-Serial liefern. Tote, lame und adresslose Server sowie abweichende Serials eröffnen nameservers_broken nach zwei Läufen, antwortet keiner ist es kritisch. Ein einzelner Nameserver, alle im selben /24-Netz oder bei mehreren Anbietern sind Hinweise. Der Lauf hat 20 Sekunden Budget und beginnt an wechselnder Stelle; unvollständige Läufe werden markiert.

Siehe auch: DNS-Monitoring · Domain-Monitoring

Intervalle je Tarif

Jeder Monitor hat ein Intervall zwischen einer Minute und sieben Tagen, das du in den Einstellungen der Domain änderst. Der Tarif setzt die Untergrenze je Check-Typ; beim Tarifwechsel werden zu kurze Intervalle angehoben. Die wichtigsten Untergrenzen:

  • Website (http): Free 15 Minuten, Freelancer 5 Minuten, Agency und Agency Pro 1 Minute.
  • DNS-Records: Free 60 Minuten, Freelancer 30 Minuten, Agency 15 Minuten. DNSSEC: Free 6 Stunden, Freelancer 1 Stunde, Agency 15 Minuten.
  • SPF und DMARC: Free 6 Stunden, Freelancer 3 Stunden, Agency 1 Stunde. DKIM und MTA-STS: Free 12 Stunden, Freelancer 6 Stunden, Agency 1 Stunde. MX: Free 6 Stunden, Freelancer 1 Stunde, Agency 30 Minuten.
  • Zertifikat: Free 12 Stunden, sonst 6 Stunden. Blacklists: Free 24 Stunden, Freelancer 12, Agency 6 Stunden. Nameserver: Free 24 Stunden, Freelancer 12, Agency 6 Stunden.
  • Registrierung, CT-Logs, Weiterleitungen, CAA, BIMI und DANE: 24 Stunden in jedem Tarif. IPv6: 6 Stunden im Free-Tarif, sonst 1 Stunde (Agency Pro 30 Minuten).

Siehe auch: Tarifvergleich

Der Domain-Check mit Punktesystem

Der öffentliche Domain-Check auf der Startseite fasst 13 Einzelprüfungen in vier Bereiche mit je einer Punktzahl von 0 bis 100 zusammen und gewichtet sie zur Gesamtpunktzahl. Er nutzt dieselben Prüfungen wie die Monitore, aber einmalig und ohne Verlauf; im Dashboard gibt es die Punktzahl nicht, dort zählt der Zustand aus den offenen Incidents.

  • Bereiche und Gewichte: Website 30 % (Zertifikat, Weiterleitungen, Sicherheits-Header), E-Mail 35 % (MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT), DNS 20 % (Records, DNSSEC), Domain 15 % (Registrierung, Blacklists).
  • Punktzahl je Bereich: 100 minus Abzüge seiner Prüfungen. Je Prüfung kosten kritische Befunde 20 Punkte, Warnungen 7 Punkte (höchstens 20), Hinweise 1 Punkt (höchstens 3). Wegen des Zeitbudgets von 22 Sekunden ausgelassene Prüfungen fallen aus der Rechnung; konnte ein Teil wegen eines Fehlers nicht prüfen, gibt es keine Punktzahl.
  • Gesamtpunktzahl: gewichtetes Mittel der Bereiche. Stufen: ab 90 sehr gut, ab 70 gut, ab 50 mittel, darunter dringender Handlungsbedarf.
  • Empfehlungen: bis zu fünf Befunde, sortiert nach dem Punktgewinn ihrer Behebung. Der Gewinn ergibt sich aus dem Anteil des Befunds am Abzug seiner Prüfung, dem Gewicht des Bereichs und der Empfehlung aus dem Befundtext; bei Gleichstand stehen kritische vor Warnungen.
  • Grenzen: 20 Abfragen je Stunde und IP, Ergebnisse fünf Minuten zwischengespeichert, Ergebnisseite ohne Indexierung, aber teilbar.

Siehe auch: Domain-Check ausprobieren

Häufige Fragen

Warum sehe ich einen Befund, aber keinen Incident?
Hinweise erzeugen nie einen Incident, Warnungen nur bei Zustandsbefunden nach ihrer Schwelle. Manche Warnungen sind bewusst ohne Incident, etwa ein SPF-Record mit ptr, ein SHA-1-Zertifikat oder ein einzelner nicht erreichbarer MX-Host: Sie stehen im Ergebnis und in der Zeitleiste, wecken aber niemanden.
Kann ich einzelne Checks abschalten?
Ja, je Domain die Bereiche Website, E-Mail sowie Domain und DNS, und jeden Monitor einzeln. Ein abgeschalteter Monitor schließt seine offenen Incidents ohne Entwarnung.
Welche Checks brauchen etwas vom Kunden?
Keiner. Alle Prüfungen lesen öffentlich abfragbare Daten: DNS, HTTP, TLS, RDAP, CT-Logs und Blacklist-Antworten. Nichts wird beim Kunden installiert; nur die Records per Klick brauchen eine Integration mit dem DNS-Anbieter.
Warum fehlt der IPv6- oder der SMTP-Monitor?
Beide entstehen nur, wenn der Betreiber sie freigeschaltet hat: IPv6 braucht einen Prüfserver mit IPv6-Ausgang, der Mailserver-Check eine Freigabe von Port 25. Ohne Port-25-Freigabe prüft DANE nur Form und Signierung der TLSA-Records.