Email checks

What the email checks cover: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, mail server, reverse DNS and DANE, with findings and thresholds.

On this page

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. On a subdomain a missing MX is only a hint (subdomains usually receive no mail).
  • 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. On a subdomain a missing record is only a hint: it is needed only if the subdomain sends mail itself.
  • 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. If a subdomain has no record of its own, RFC 7489 applies the record of the main domain with sp= (or p= without sp=): no dmarc_missing, but a hint naming the inherited policy.
  • 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).
  • autodiscover Mail-Autokonfiguration: Wie Outlook, Thunderbird und Smartphones Server und Ports finden. Geprüft werden Outlook Autodiscover (SRV _autodiscover._tcp mit Port 443, Host autodiscover.<domain> mit HTTPS-Endpunkt und Zertifikat auf genau diesen Namen, ersatzweise die Weiterleitung von http://autodiscover.<domain>), Thunderbird Autoconfig (autoconfig.<domain>/mail/config-v1.1.xml und /.well-known/autoconfig/ der Domain, mit grober Prüfung der XML-Datei) und SRV-Records nach RFC 6186 (_imaps, _imap, _submission, _submissions, _pop3s, das Ziel muss auflösen). Ist gar kein Weg eingerichtet, ist das nur ein Hinweis – viele Anbieter brauchen keinen. Ein eingerichteter, aber kaputter Weg eröffnet autodiscover_broken nach zwei Läufen (nie kritisch), am häufigsten ein Zertifikat, das nicht auf autodiscover.<domain> lautet, weil ein Wildcard-Record auf den Webserver zeigt: Outlook zeigt dann immer wieder eine Zertifikatswarnung. Der CNAME von Microsoft 365 auf autodiscover.outlook.com ist der gesunde Standardfall. Ohne Mailbetrieb wird nichts geprüft. Täglich.

See also: Email monitoring