Documentation

Checks

Every domain gets up to 21 monitors, one per enabled check type (SMTP and IPv6 only if the operator enables them). This chapter explains per type what is checked, which findings can arise and when they become an incident. At the end is the scoring of the public domain check.

On this page

How a check works

A monitor is a check type on a target (domain, host name or URL) with its own interval. Every run ends with a result: ok, warning, critical or error. An error means DomainWarn itself could not check (resolver timeout, time budget exceeded); it never changes an incident. Findings carry a severity: info, warning or critical, each with a text and a recommendation in German and English.

Only state findings open incidents, and only after their threshold: a fixed number of consecutive runs (1, 2 or 3) or, for availability checks, after the configured failure duration (default 5 minutes, converted into runs). Info findings never create an incident. Changes (a record differs from the last run) are events with before and after, are reported once and do not continue as an incident; details in "Alerts".

A run has 30 seconds. HTTP fetches follow at most five redirects and read at most 512 KB. DNS is queried preferably at the authoritative name server; every detected change is confirmed after 45 seconds against a second name server of the zone.

See also: Incidents, thresholds and reminders

Website

The website checks run on every host name with a website monitor, i.e. at least on apex and www.

  • http Website: availability, status code, response time, redirect chain, page content and security headers. Connection errors, timeouts and 5xx are critical and open http_down after the failure duration; a status code other than the expected one is a warning (http_status); responses above the slow threshold (default 5 s) open http_slow after three runs; an HTTPS address redirecting to http:// immediately http_no_https. A missing required text or a forbidden one creates http_content. Header findings (HSTS, CSP, nosniff, framing, referrer and permissions policy, exposed server versions) are hints without an incident.
  • tls Certificate: handshake, chain, host name, validity, signature algorithm and protocol on port 443 or a mail port with STARTTLS. Expired is critical (tls_expired, immediately); under 14 days remaining a warning (tls_expiring), under 30 days a hint. Chain errors, wrong host name, self-signed and not yet valid open tls_invalid after two runs; unreachable tls_unreachable. SHA-1 and TLS 1.0/1.1 are warnings without an incident. A renewal is reported as an event, a new issuer as a warning.
  • redirects Redirects: http://, http://www., https:// and https://www. must end up at the same canonical HTTPS address. Unreachable variants, a missing redirect to https, an error status at the end and inconsistent targets open redirects_broken; long chains and temporary redirects (302/307) are hints. When the canonical address changes it is reported as a warning.
  • ipv6 IPv6: if the host name has AAAA records, every IPv6 address is requested over HTTP. No answer or 5xx opens ipv6_broken after the failure duration; missing AAAA records are a hint. Before every finding DomainWarn verifies its own IPv6 path against reference targets; without an IPv6 route the run ends as an error. The monitor only exists if the operator has enabled IPv6.
  • ct_log Certificate Transparency: all certificates of the last 30 days for the domain and its subdomains from the CT logs. A previously unknown issuer is a warning without an incident; every newly issued certificate an event. If it falls within 24 hours after a name server or MX change, it is reported as critical. Host names from certificates without a website monitor are collected as suggestions on the domain (up to 50 open) that you accept or dismiss with one click.

See also: Website monitoring · SSL monitoring

Email

The email checks run on the domain. If neither MX nor SPF is found when the domain is added, the area is switched off initially.

  • mx Mail server records: presence, null MX and resolvability of every MX host. No MX is critical (mx_missing), no resolvable MX critical (mx_unresolvable), partially resolvable a warning; each after two runs. An MX change is a warning, a removed MX critical.
  • spf SPF: syntax, mechanisms, includes with loops, lookup count and all qualifier. Missing record (spf_missing), several records (spf_multiple, critical because receivers evaluate permerror), syntax errors and broken includes (spf_invalid), more than 10 DNS lookups (spf_lookups) and +all, ?all or a missing all (spf_permissive) open after one run; 9 lookups are a hint, ~all as well, ptr a warning without an incident. A removed SPF record is a critical change.
  • dkim DKIM: the configured selectors, without configuration a search over 39 common selectors (google, selector1, k1, default, mail, brevo, mailgun, ionos, strato, amazonses and more). Missing configured selectors open dkim_missing after two runs; revoked, invalid and too short keys dkim_invalid, under 1024 bits critical. Under 2048 bits and testing mode (t=y) are hints. If nothing is found, that is only a hint to enter your selectors.
  • dmarc DMARC: record under _dmarc, syntax, policy, pct, rua, subdomain policy. A missing record opens dmarc_missing after one run, several records as well (critical). p=none, p=quarantine, pct below 100, a missing reporting address and a weaker subdomain policy are hints. A weakened policy is a critical change.
  • mta_sts MTA-STS: TXT record, policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, mode, max_age and whether all MX hosts are covered. A missing policy is a hint; broken records, an unreachable policy and missing fields open mta_sts_invalid after two runs. Uncovered MX hosts in enforce mode are critical because senders refuse delivery.
  • tls_rpt TLS-RPT: record under _smtp._tls with a plausible reporting address. A missing record is a hint with a recommendation, a broken one a warning without an incident.
  • bimi BIMI: record under default._bimi, logo URL (https, SVG Tiny PS), VMC URL and the prerequisite DMARC with quarantine or reject. A missing record is a hint; broken or unreachable logo and VMC addresses as well as BIMI without an enforced DMARC policy open bimi_invalid after two runs.
  • smtp Mail servers: connection on port 25 to up to five MX hosts, banner, STARTTLS, TLS version and certificate; no mail is ever submitted. No reachable mail server is critical (smtp_unreachable), missing or failing STARTTLS, an invalid certificate and TLS 1.0/1.1 are warnings with an incident, a single dead MX a warning without. The monitor only exists if the operator has enabled port 25.
  • reverse_dns Reverse DNS: every address of the MX hosts needs a PTR record that points back to the address. A missing PTR (reverse_dns_missing) and a non-matching PTR (reverse_dns_mismatch) open after two runs; the PTR is set by the operator of the IP network.
  • dane DANE: TLSA records under _25._tcp.<mx>, DNSSEC signing, usable usage (2 or 3) and, if port 25 is enabled, the comparison with the certificate served via STARTTLS. No TLSA is a hint; unsigned, invalid or unverifiable records open dane_broken after two runs; a certificate that no TLSA record matches is critical immediately (dane_mismatch).

See also: Email monitoring

Domain and DNS

These checks run on the domain; CAA additionally per host name with a certificate.

  • dns DNS records: A, AAAA, CNAME, MX, TXT, NS and CAA, preferably at the authoritative name server, canonicalised as a snapshot for change detection. NXDOMAIN and SERVFAIL are critical (dns_failed), a zone without A, AAAA, CNAME and MX a warning (dns_empty), each after two runs. A CNAME next to other records is a warning without an incident. Single record changes are events, name server and MX changes warnings.
  • dnssec DNSSEC: DS record in the parent zone and validation via a validating resolver, signature expiry, deprecated algorithms. A failing validation is critical (dnssec_bogus, two runs) because Google, Cloudflare and Quad9 then cannot reach the domain. Signatures expiring in under 7 days are a warning, under 2 days critical (dnssec_expiring); the warning only applies if less than a third of the validity period remains, so that providers with short signatures do not cause false alarms. Without DNSSEC there is a hint.
  • domain Registration: expiry date, registrar, EPP status and name servers according to the registry via RDAP, once a day. Expiry in under 30 days is a warning (domain_expiring), under 60 days a hint; expired or not registered critical (domain_expired); clientHold/serverHold critical (domain_hold). A missing transfer lock is a hint. Registries without an expiry date (DENIC for .de) only deliver status and name servers. A registrar change is reported as a warning.
  • blacklist Blacklists: the IPv4 addresses of the website and the first five MX hosts against Spamhaus ZEN, Spamcop, Barracuda and PSBL, the domain name against Spamhaus DBL and SURBL. A listed mail server IP or domain is critical, a listed website IP a warning (blacklist_listed, one run). Only unambiguous listing responses count; the removal is reported as an all-clear.
  • caa CAA: CAA records including parent and wildcard rules, compared with the certificate authority of the current certificate on port 443 (around 30 CAs known). No CAA record is a hint; a record that locks out your own CA a warning (caa_blocks_issuer) because the next renewal would fail; invalid records caa_invalid, each after two runs.
  • nameservers Name servers: every NS of the zone needs an address, must answer, be authoritative and serve the same SOA serial. Dead, lame and addressless servers as well as diverging serials open nameservers_broken after two runs; if none answers it is critical. A single name server, all in the same /24 network or spread over several providers are hints. The run has a 20-second budget and starts at a rotating position; incomplete runs are marked.

See also: DNS monitoring · Domain monitoring

Intervals per plan

Every monitor has an interval between one minute and seven days that you change in the settings of the domain. The plan sets the lower limit per check type; on a plan change intervals that are too short are raised. The most important lower limits:

  • Website (http): Free 15 minutes, Freelancer 5 minutes, Agency and Agency Pro 1 minute.
  • DNS records: Free 60 minutes, Freelancer 30 minutes, Agency 15 minutes. DNSSEC: Free 6 hours, Freelancer 1 hour, Agency 15 minutes.
  • SPF and DMARC: Free 6 hours, Freelancer 3 hours, Agency 1 hour. DKIM and MTA-STS: Free 12 hours, Freelancer 6 hours, Agency 1 hour. MX: Free 6 hours, Freelancer 1 hour, Agency 30 minutes.
  • Certificate: Free 12 hours, otherwise 6 hours. Blacklists: Free 24 hours, Freelancer 12, Agency 6 hours. Name servers: Free 24 hours, Freelancer 12, Agency 6 hours.
  • Registration, CT logs, redirects, CAA, BIMI and DANE: 24 hours on every plan. IPv6: 6 hours on Free, otherwise 1 hour (Agency Pro 30 minutes).

See also: Plan comparison

The domain check with its score

The public domain check on the home page bundles 13 individual checks into four areas, each with a score from 0 to 100, and weights them into the total score. It uses the same checks as the monitors, but once and without history; the dashboard has no score, there the state from the open incidents counts.

  • Areas and weights: Website 30% (certificate, redirects, security headers), Email 35% (MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT), DNS 20% (records, DNSSEC), Domain 15% (registration, blacklists).
  • Score per area: 100 minus the deductions of its checks. Per check, critical findings cost 20 points, warnings 7 points (at most 20), hints 1 point (at most 3). Checks skipped because of the 22-second time budget drop out of the calculation; if a part could not check because of an error, there is no score.
  • Total score: weighted average of the areas. Grades: 90 and above excellent, 70 and above good, 50 and above fair, below that urgent action needed.
  • Recommendations: up to five findings, sorted by the points gained by fixing them. The gain follows from the share of the finding in the deduction of its check, the weight of the area and the recommendation from the finding text; on a tie critical comes before warning.
  • Limits: 20 queries per hour and IP, results cached for five minutes, result page not indexed but shareable.

See also: Try the domain check

Frequently asked questions

Why do I see a finding but no incident?
Hints never create an incident, warnings only for state findings after their threshold. Some warnings deliberately have no incident, such as an SPF record with ptr, a SHA-1 certificate or a single unreachable MX host: they appear in the result and the timeline but wake nobody.
Can I switch off individual checks?
Yes, per domain the areas Website, Email and Domain & DNS, and every monitor individually. A switched-off monitor closes its open incidents without an all-clear.
Which checks need something from the client?
None. All checks read publicly queryable data: DNS, HTTP, TLS, RDAP, CT logs and blacklist responses. Nothing is installed at the client; only the records in one click need an integration with the DNS provider.
Why is the IPv6 or the SMTP monitor missing?
Both only exist if the operator has enabled them: IPv6 needs a checking server with IPv6 egress, the mail server check a release of port 25. Without port 25, DANE only checks form and signing of the TLSA records.