E-Mail-Checks

Was die E-Mail-Checks prüfen: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, Mailserver, Reverse DNS und DANE, mit Befunden und Schwellen.

Auf dieser Seite

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. Auf einer Subdomain ist ein fehlender MX nur ein Hinweis (Subdomains empfangen üblicherweise keine Mails).
  • 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. Auf einer Subdomain ist ein fehlender Record nur ein Hinweis: nötig ist er nur, wenn sie selbst als Absender auftritt.
  • 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. Hat eine Subdomain keinen eigenen Record, gilt nach RFC 7489 der Record der Hauptdomain mit sp= (ohne sp= mit p=): kein dmarc_missing, sondern ein Hinweis mit der geerbten Policy.
  • 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).
  • 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.

Siehe auch: E-Mail-Monitoring