Kurz gesagt
Mailserver verschlüsseln die Übertragung meist per STARTTLS, aber nur freiwillig: Ein Angreifer im Netz kann die Verschlüsselung unterdrücken, und die Mail geht im Klartext durch. MTA-STS und DANE schließen diese Lücke. Beide teilen sendenden Servern mit, dass Ihr Mailserver Verschlüsselung erwartet und welches Zertifikat gültig ist. MTA-STS arbeitet mit einer Datei auf einer Website, DANE mit DNSSEC-gesicherten DNS-Einträgen.
Das Problem mit STARTTLS
Wenn ein Mailserver einem anderen eine Mail zustellt, fragt er, ob dieser Verschlüsselung kann. Antwortet der Empfänger mit „ja“, wird verschlüsselt. Antwortet er nicht oder scheinbar mit „nein“, geht die Mail im Klartext. Genau hier setzt ein Angreifer an, der sich in die Verbindung einklinkt: Er unterdrückt das Angebot zur Verschlüsselung, und beide Server sprechen unverschlüsselt weiter. Außerdem prüfen viele Server das Zertifikat der Gegenseite gar nicht.
MTA-STS: Die Regel steht auf einer Website
Mit MTA-STS (RFC 8461) veröffentlichen Sie eine kleine Richtliniendatei unter https://mta-sts.ihre-domain.de. Darin steht, welche Mailserver zu Ihrer Domain gehören und dass sie nur verschlüsselt mit gültigem Zertifikat beliefert werden dürfen. Ein DNS-Eintrag weist auf die Richtlinie hin.
- Modus testing: Sendende Server melden Probleme, stellen aber trotzdem zu. Gut zum Einstieg.
- Modus enforce: Ohne gültige Verschlüsselung wird nicht zugestellt. Das ist das Ziel.
- Vorteil: Funktioniert ohne DNSSEC.
- Nachteil: Braucht eine Website mit gültigem Zertifikat für die Subdomain mta-sts.
DANE: Das Zertifikat steht im DNS
Bei DANE für SMTP (RFC 7672) steht im DNS, welches Zertifikat Ihr Mailserver verwendet, in einem sogenannten TLSA-Eintrag. Weil der DNS-Eintrag per DNSSEC unterschrieben ist, kann ihn niemand unterwegs fälschen. Ein sendender Server, der DANE beherrscht, verschlüsselt dann nur mit genau diesem Zertifikat.
- Vorteil: Sehr robust, keine zusätzliche Website nötig.
- Voraussetzung: DNSSEC für die Domain des Mailservers. Nicht jeder DNS-Anbieter unterstützt das.
- Pflege: Beim Zertifikatswechsel muss der TLSA-Eintrag mitgezogen werden, sonst kommt keine Mail mehr an.
TLS-RPT: Berichte über Probleme
Mit TLS-RPT (RFC 8460) bitten Sie sendende Server, Ihnen täglich zu berichten, ob die verschlüsselte Zustellung geklappt hat. So merken Sie, wenn etwas mit Zertifikat oder Richtlinie nicht stimmt, bevor Mails verloren gehen.
In welcher Reihenfolge einrichten?
- Erst SPF, DKIM und DMARC sauber einrichten, damit Ihre eigenen Mails ankommen. Siehe DMARC einrichten.
- TLS-RPT-Eintrag anlegen, um Berichte zu bekommen.
- MTA-STS im Modus testing einrichten und die Berichte ein paar Wochen beobachten.
- Auf enforce umstellen.
- DANE ergänzen, wenn DNSSEC für den Mailserver verfügbar ist.
Ob Ihre Domain diese Einträge schon hat, zeigt unser Mail-Check. Bei Shield Mail berechnen wir alle Einträge für Ihre Domain, liefern die Richtlinie für MTA-STS im Modus enforce aus und prüfen ausgehend selbst MTA-STS und DANE der Empfänger.
Häufige Fragen
- Brauche ich beides, MTA-STS und DANE?
- Nicht zwingend. Manche sendenden Server unterstützen nur das eine, manche nur das andere. Wer beides einrichtet, deckt mehr Absender ab.
- Was passiert, wenn mein Zertifikat abläuft und MTA-STS auf enforce steht?
- Dann stellen Server, die MTA-STS beachten, keine Mails mehr zu, bis das Zertifikat erneuert ist. Automatisch erneuerte Zertifikate und TLS-RPT-Berichte schützen davor.
- Verschlüsselt MTA-STS auch meine ausgehenden Mails?
- MTA-STS schützt Mails, die an Ihre Domain gehen. Für ausgehende Mails muss Ihr eigener Mailserver die MTA-STS-Richtlinien und DANE-Einträge der Empfänger beachten.