Erzwungene TLS-Richtlinie für eingehende Mails
DNS & Einträge
DNS-Abfrage Alle DNS-Einträge für jede Domain A-Eintrag-Abfrage IPv4-Adressen für eine Domain AAAA-Eintrag-Abfrage IPv6-Adressen für eine Domain MX-Abfrage Mailserver für eine Domain NS-Abfrage Autoritative Nameserver TXT-Abfrage TXT-Einträge, SPF, Verifizierung CNAME-Abfrage Kanonische Namen (Alias)-Einträge SOA-Abfrage Start-of-Authority-Eintrag SRV-Abfrage Dienst-Standort-Einträge CAA-Abfrage Welche CAs Zertifikate ausstellen dürfen Reverse DNS (PTR) IP-Adresse zu Hostname DNSSEC-Prüfung Ist die Domain signiert und validiert? DNS-Gesundheitscheck Ein vollständiger Bericht zu Delegierung & DNSE-Mail-Zustellbarkeit
SPF-Prüfung Validieren Sie Ihren Sender-Policy-Framework-Eintrag DMARC-Prüfung Untersuchen und bewerten Sie Ihre DMARC-Richtlinie DKIM-Prüfung Finden und validieren Sie Ihren öffentlichen DKIM-Schlüssel Blacklist-Prüfung Prüfen Sie eine IP gegen E-Mail-Sperrlisten (DNSBLs) SMTP-Test Mit einem Mailserver verbinden und STARTTLS prüfen MTA-STS-Prüfung Erzwungene TLS-Richtlinie für eingehende Mails BIMI-Prüfung Markenlogo-Eintrag für E-Mail TLS-RPT-Prüfung SMTP-TLS-BerichtsrichtlinieNetzwerk & Web
SSL-Zertifikat-Prüfung TLS-Zertifikat und Ablauf einer Website untersuchen HTTP-Header-Prüfung Antwort-Header, Weiterleitungen und Sicherheit untersuchen Ping (TCP) Erreichbarkeit und Latenz über TCP Port-Prüfung Welche gängigen Ports offen sindDomain
WHOIS-Abfrage Registrierungsdaten für Domains, IPs und ASNsMTA-STS erlaubt einer Domain zu verlangen, dass eingehende Mail über authentifiziertes TLS zugestellt wird, und schützt so vor Downgrade- und Man-in-the-Middle-Angriffen. IPeek liest den _mta-sts-TXT-Record und ruft die unter mta-sts.ihre-domain veröffentlichte Policy-Datei ab. Es schließt die Lücke, die das opportunistische STARTTLS lässt, das ein Angreifer stillschweigend entfernen kann.
MTA-STS besteht aus zwei Teilen. Ein TXT-Record unter _mta-sts.ihre-domain enthält eine Version und eine Policy-ID, die sendenden Servern mitteilt, dass eine Richtlinie existiert, und sich ändert, wenn Sie sie aktualisieren. Die Richtlinie selbst liegt in einer Klartextdatei, die über HTTPS unter https://mta-sts.ihre-domain/.well-known/mta-sts.txt ausgeliefert wird. Diese Datei listet die Version, den Modus, die zulässigen MX-Hostnamen und eine max_age-Cache-Lebensdauer auf. Ein Sender, der MTA-STS unterstützt, ruft die Richtlinie ab und cached sie, und verweigert dann die Zustellung an jeden MX, dessen Zertifikat nicht dagegen validiert.
IPeek zeigt, ob der _mta-sts-TXT-Record existiert und ob die Policy-Datei über HTTPS erreichbar ist. Der Modus-Wert ist am wichtigsten. none bedeutet, dass keine Richtlinie in Kraft ist, testing bedeutet, dass Fehler gemeldet werden, aber Mail weiter fließt, und enforce bedeutet, dass ein Sender die Zustellung abbrechen muss, wenn die TLS-Authentifizierung fehlschlägt. Prüfen Sie, dass die mx-Einträge in der Richtlinie mit Ihren echten MX-Records übereinstimmen und dass das HTTPS-Zertifikat auf dem Policy-Host gültig ist. Ein hoher max_age-Wert, oft 604800 Sekunden, verbessert den Schutz, weil gecachte Richtlinien Live-Manipulationen widerstehen.
Der häufigste Fehler ist ein TXT-Record, der existiert, während die Policy-Datei einen 404 oder eine Weiterleitung zurückgibt, was die Richtlinie unbrauchbar macht. Der Policy-Host muss gültiges HTTPS ausliefern, sodass ein abgelaufenes oder nicht passendes Zertifikat auf mta-sts.ihre-domain die Durchsetzung vollständig bricht. MX-Einträge, die mit Ihrem DNS außer Takt geraten, verursachen Zustellfehler, sobald Sie auf enforce wechseln. Rollen Sie zuerst im testing-Modus aus, überwachen Sie TLS-RPT-Berichte auf Fehler und wechseln Sie erst zu enforce, nachdem Sie bestätigt haben, dass jeder MX ein gültiges, passendes Zertifikat präsentiert.
Im testing-Modus stellen Sender, die einen TLS-Fehler erkennen, die Mail dennoch zu, melden aber das Problem, sodass Sie Probleme finden, ohne Verkehr zu blockieren. Im enforce-Modus muss ein Sender die Zustellung an jeden MX abbrechen, dessen Zertifikat die Validierung nicht besteht. Beginnen Sie mit testing, beobachten Sie Ihre TLS-RPT-Berichte und wechseln Sie erst zu enforce, sobald keine Fehler mehr auftreten.
Die Policy-Datei wird über HTTPS unter https://mta-sts.ihre-domain/.well-known/mta-sts.txt ausgeliefert, auf einer Subdomain namens mta-sts. Der DNS-TXT-Record unter _mta-sts.ihre-domain kündigt nur an, dass eine Richtlinie existiert, und trägt eine ID; die eigentlichen Regeln, einschließlich Modus und zulässiger MX-Hosts, liegen in dieser HTTPS-Datei. Beide müssen vorhanden und gültig sein, damit MTA-STS funktioniert.
STARTTLS ist opportunistisch: Es bietet Verschlüsselung an, aber ein Netzwerkangreifer kann die STARTTLS-Ankündigung entfernen und unbemerkt eine Klartextzustellung erzwingen. MTA-STS fügt eine veröffentlichte Richtlinie hinzu, die Sendern mitteilt, dass TLS erforderlich ist und welchen MX-Zertifikaten zu vertrauen ist, sodass eine entfernte oder ungültige TLS-Verbindung die Zustellung scheitern lässt, statt stillschweigend herabzustufen. Es härtet STARTTLS gegen Downgrade-Angriffe ab.
Nein. MTA-STS stützt sein Vertrauen bewusst auf HTTPS und die Web-PKI, nicht auf DNSSEC, was es einfacher einsetzbar macht als DANE. Das HTTPS-Zertifikat der Policy-Datei liefert die Authentifizierung. Wenn Ihre Domain bereits DNSSEC hat, können Sie DANE neben MTA-STS betreiben, da sich die beiden Mechanismen ergänzen und nicht widersprechen.
Veröffentlichen Sie den TXT-Record und die Policy-Datei zuerst im testing-Modus und aktivieren Sie dann TLS-RPT, damit sendende Server Ihnen Berichte über etwaige TLS-Fehler mailen. Bestätigen Sie, dass Ihre MX-Hostnamen in der Richtlinie mit dem DNS übereinstimmen und dass jeder MX ein gültiges Zertifikat präsentiert. Sobald Berichte über einen normalen Berichtszyklus keine Fehler zeigen, ändern Sie den Modus auf enforce und aktualisieren die Policy-ID.