Vom Layer 8.

Layer 8 ist unter Tekkies der höfliche Fachausdruck für das, was im Störungsfall fast immer wirklich passiert: Die sieben Schichten der OSI-Welt sind sauber, formal, deterministisch. Dann kommt der Mensch. Und plötzlich wird aus Protokolltechnik Sozialdynamik, aus Kryptographie Telefonarbeit, aus Zustellbarkeit Reputationsschaden. Layer 8 meint nicht bloss „Bedienfehler“, sondern die ganze weiche Materie über der Applikationsschicht: Erwartungshaltungen, Kommunikationskultur, Prozesshygiene, Fehlanreize, und ja, manchmal auch schlichte intellektuelle Bequemlichkeit.¹

Genau dort spielt E-Mail-Sicherheit ihren unerquicklichsten Sport. SMTP² ist alt, robust, opportunistisch, und darum gnadenlos missbrauchsfreundlich. Wer meint, „wir haben doch Passwörter“, verwechselt Postfachzugriff mit Absenderautorität. Wer meint, „wir haben doch TLS³„, verwechselt opportunistische⁴ Verschlüsselung mit erzwungener Transportintegrität. Und wer meint, „wir haben doch DMARC⁵„, der verwechselt eine Policy mit einer Therapie gegen menschliche Gutgläubigkeit.

Spoofing⁶ ist als Mechanik unerquicklich simpel: Eine fremde Infrastruktur versendet Nachrichten mit gefäschte Absenderdomain im sichtbaren From, häufig kombiniert mit psychologischem Druck (Rechnung, Mahnung, „dringend“, „heute noch“). Das Sicherheitsrisiko für die Endgeräte ist dadurch nicht automatisch gegeben. Der Kollateralschaden kommt nicht über Exploitcode, sondern über Telefone, Supportpostfächer, verunsicherte Kundschaft, manchmal über Dritte, die „zur Sicherheit“ Zahlungen an die falsche Stelle leisten. Layer 8, in Reinform.

Der erste Schritt ist deshalb immer eine saubere Trennung der Tatbestände: Wurde tatsächlich ein Postfach kompromittiert, oder wird lediglich die Absenderdomain gefälscht? Passwortwechsel hilft nur beim ersten Fall. Beim zweiten Fall hilft Disziplin in der Authentisierung, plus Kommunikationsarbeit nach aussen. Diese Unterscheidung wirkt trivial, sie wird aber in der Realität erstaunlich oft nicht gemacht, weil Menschen „E-Mail“ als monolithisches Ding betrachten, nicht als Kette aus Identitäten, Headerfeldern, Zustellwegen und Policies.

Ich halte es gern nüchtern: Jedes Tool ist ein Messinstrument. Messinstrumente sind wertvoll, solange man nicht vergisst, was sie nicht messen.

Mailhardener

Mailhardener positioniert sich als „E-Mail Hardening Suite“ und bündelt mehrere Baustellen in einem Dashboard: DMARC-Reporting, SMTP TLS Reporting (TLS-RPT),⁷ MTA-STS Policy Hosting,⁸ BIMI Asset Hosting,⁹ DANE^{10 11} / TLSA¹², DNSSEC¹³-Validierung¹⁴, DNS-Change-Monitoring. Das ist handwerklich sinnvoll, weil es die Administrationsrealität abbildet: Man publiziert DNS-Policies, man will Reports einsammeln, man will Regressionen sehen, man will nicht jeden Tag XML, JSON und Aggregate-Reports von Hand sortieren.¹⁵

Was Mailhardener „wirklich tun“ kann, ist damit ziemlich klar umrissen:

1. Es kann Sichtbarkeit geben. DMARC-Aggregate-Reports zeigen, wer in wessen Namen sendet, wie SPF¹⁶ und DKIM¹⁷ aus Sicht grosser Empfänger ausfallen, wie Alignment greift, und wo legitime Versender noch querstehen. DMARC ist genau dafür gebaut: Domain-level Policy und Reporting, skalierbar, empfängergetrieben.¹⁸
2. Es kann Transport-Telemetrie liefern. TLS-RPT, RFC8460¹⁹, ist ein Feedbackkanal für TLS-Zustellprobleme, inklusive potentieller Downgrades und Fehlkonfigurationen. Das ist wichtig, weil „STARTTLS²⁰ vorhanden“ allein nichts garantiert; ohne Policy bleibt es bestenfalls ein höflicher Vorschlag.
3. Es kann Arbeit abnehmen. MTA-STS ist nicht nur ein DNS-Record, sondern auch eine HTTPS-Policy, die korrekt gehostet, versioniert und erreichbar sein muss. Wer das sauber „hosten“ lässt, reduziert Fehlerflächen.

Was Mailhardener nicht kann, und das wird in Diskussionen gerne unter den Teppich gekehrt, ist ebenso simpel: Es kann ohne On-Path-Position nicht den gesamten Mailverkehr „sehen“, schon gar nicht den Inhalt. Es kann auch nicht mit magischer Hand den ausgehenden MTA²¹ zwingen, bei jedem Ziel korrekt und streng nach DANE oder MTA-STS zu handeln. Es kann prüfen, ob die DNS-Statements formal stimmen, ob Reports eintreffen, ob Empfänger etwas melden. Die operative Wahrheit „was der Server beim Senden wirklich tut“ ist ein anderes Messproblem.

Mailhardener ist also kein Sicherheitsprodukt, das Verantwortung abnimmt; es ist ein Instrumentenbrett, das schneller merken lässt, wenn man im Nebel fliegt.

Learndmarc

Learndmarc ist vom Charakter her das Gegenteil: kein dauerhaftes Monitoring, kein Policy Hosting, kein Flottenmanagement, sondern ein Lehr- und Testkonsolenansatz. Man sendet eine Mail an eine Testadresse, und das System visualisiert, wie ein empfangender Mailserver SPF, DKIM und DMARC prüft. Das ist didaktisch hervorragend, weil es den üblichen Nebel aus „müsste doch passen“ brutal auflöst: Header rein, Authresultate raus, inklusive Alignment-Logik.²²

Was Learndmarc damit für Admins und Firmeninhaber leistet, ist ein mentaler Kalibrierungsdienst: Man begreift, warum SPF ohne Alignment nicht DMARC ist; warum DKIM-Signaturen selektorabhängig sind; warum Mailinglisten und Weiterleitungen die Welt nicht besser machen; warum From und Return-Path zwei verschiedene Universen sind. Der Wert liegt nicht im Report, sondern im Lerneffekt, der anschliessend Entscheidungen beschleunigt.

Die Grenze ist ebenso klar: Learndmarc sieht den konkreten Testfall, nicht die Gesamtlage. Es ersetzt keine DMARC-Aggregation, keine TLS-RPT-Telemetrie, keine MTA-STS-Verfügbarkeit, keine DNS-Drift-Erkennung.

MECSA

MECSA ist ein strukturierter Sicherheitscheck entlang etablierter Standards: StartTLS, x509-Zertifikatsvalidierung, SPF, DKIM, DMARC, DANE, DNSSEC. Es misst also primär die Fähigkeit eines Mailanbieters beziehungsweise einer Domain, MTA-zu-MTA-Kommunikation technisch abzusichern und Spoofing über Standards einzudämmen.²³

Für Admins ist das nützlich, weil es zwei Dinge entkoppelt, die im Alltag oft vermischt werden: „Wir haben irgendwo eine Marketingfolie“ versus „der Backbone kann die Standards wirklich“. MECSA bleibt dabei bewusst auf der Transport- und Authentisierungsebene und tut nicht so, als könne es den Menschen aus der Gleichung entfernen.

Die Grenze: MECSA ist keine Auswerteplattform für DMARC-RUA-Rohdatenströme, keine TLS-RPT-Sammelstelle, kein MTA-STS-Hoster, kein Incident-Response-Playbook. Es sagt nicht, ob die Buchhaltung jeden PDF-Anhang doppelklickt, nur weil „Rechnung“ im Betreff steht. Layer 8 bleibt weiterhin ein Problem.

Lindenberg

Der spannende Unterschied, und hier wird es endlich praktisch, liegt bei aktiven Tests des Sendeverhaltens. Es gibt Testansätze, die nicht nur Records evaluieren, sondern das Verhalten des MTAs gegenüber bewusst präparierten Gegenstellen. In einer Diskussion wurde genau diese Differenzierung explizit gemacht: Ein externer Monitoringdienst prüft typischerweise DNS und Reports, aber sagt wenig darüber, wie ein System beim Senden unter realen Bedingungen reagiert; ein spezialisierter Testdienst kann hingegen Aussagen über das Senden treffen, weil er es provoziert und beobachtet.²⁴

Der Lindenberg-Test wird in diesem Umfeld als Beispiel genannt, das Schwerpunkte bei SMTP-DANE und MTA-STS „in beide Richtungen“ setzt, und für SPF, DKIM, DMARC ergänzende Tests anbietet.

Damit ist auch beantwortet, was MECSA und Learndmarc nicht können, was ein solcher Ansatz kann: MECSA bestätigt, dass DANE, DNSSEC, MTA-STS etc. publiziert sind und dass der Server StartTLS spricht. Learndmarc zeigt, wie eine konkrete Mail durch SPF / DKIM / DMARC fällt oder besteht. Ein aktiver Transporttest kann hingegen zeigen, ob der ausgehende MTA bei fehlendem DANE korrekt auf MTA-STS fällt, ob er bei fehlender Policy opportunistisch bleibt, ob er Downgrade-Situationen erkennt, ob er hart abbricht, wo er hart abbrechen sollte. Das ist Verhalten, nicht Konfigurationstext.

Das ist kein akademischer Unterschied. Spoofing-Abwehr besteht aus Signalen nach aussen und Reaktionen nach innen. Records sind Signale. Das Verhalten ist die Reaktion.

CenturionMail

Ich schaue gern auf harte Messwerte. Mein MECSA-Report für coresecret.eu zeigt jeweils 5.0 / 5 in den Kategorien „Confidential Delivery“, „Phishing and Identity Theft“ und „Integrity of Messages“, dazu 100 Punkte bei StartTLS, x509, SPF, DKIM, DMARC, DANE, DNSSEC, und ebenso 100 bei MTA-STS.²⁵

Der Report legt auch offen, wie die Policy tatsächlich aussieht, und genau dort erkennt man den Charakter des Setups: DMARC steht auf p=reject, mit striktem Alignment für DKIM und SPF adkim=s; aspf=s, und mit Reporting an definierte Adressen.

Ich betreibe zusätzlich TLS-Reports, weil ich nicht nur wissen will, ob eine Verbindung irgendwie TLS spricht, sondern ob Zustellpfade sauber bleiben, ob irgendwo Downgrades, Zertifikatsprobleme oder Policy-Mismatches auftreten. RFC8460 existiert nicht als Dekoration, sondern weil „opportunistisch“ ein Euphemismus für „angreifbar“ ist.

So weit die Technik. Selbst ein Setup, das in diesen standardisierten Checks Vollpunktzahl erreicht, verhindert nicht, dass irgendein Dritter meinen Domainnamen in ein From-Feld schreibt und damit Menschen erreicht, die Authresultate ignorieren oder deren Mailinfrastruktur DMARC nicht konsequent durchsetzt. DMARC ist Policy, keine Naturgewalt; es wirkt dort, wo Empfänger es respektieren.

Und selbst dort, wo es respektiert wird, bleibt der Trick mit Lookalike-Domains, Subdomains, Reply-To-Manipulation, kompromittierten legitimen Konten, oder schlicht mit überzeugendem Social Engineering. Wer E-Mail-Sicherheit als reine DNS-Aufgabe begreift, hat zwar einen Schraubenzieher, aber keinen Plan, wo die Schrauben sind.

Analyse von Sicherheitsvorfällen

Mich interessieren bei solchen Fällen weniger die „Tools“, als die Sequenz. Die Reihenfolge entscheidet, ob man sich selbst beschäftigt oder das Problem entschärft.

Zuerst kläre ich, ob ein Konto wirklich kompromittiert ist. Das ist ein forensischer Blick: Login-Historie, MFA-Logs, verdächtige Weiterleitungen, neue OAuth-Tokens, unübliche IMAP-Clients, auffällige Versandmuster. Kein Tool ersetzt diesen Blick, weil es sich um Innenansichten handelt.

Dann trenne ich „Absenderdomain“ von “Absenderinfrastruktur”. SPF, DKIM, DMARC sind Standards, die genau diese Trennung operationalisieren: SPF autorisiert Versandhosts für MAIL FROM; DKIM bindet eine Signatur an eine Domain und den Inhalt; DMARC erzwingt Alignment am sichtbaren From und definiert Disposition samt Reporting.

Parallel kommuniziere ich speditiv. Nicht in Panik, sondern in Klartext. „Es kursieren gefälschte Rechnungen, wir versenden solche Dokumente nicht so, prüfen Sie bitte die Authentizität, im Zweifel rufen Sie an.“ Das wirkt banal, ist aber die einzige Massnahme, die im Kopf des Empfängers greift, bevor irgendein Header gelesen wird.

Danach kommt die Optimierungsschleife: DMARC von none auf quarantine auf reject, Alignment konsequent, DKIM-Signing ohne Lücken, SPF ohne wildes include-Gestrüpp, Reporting angeschaltet und ausgewertet. Wer hier Mailhardener nutzt, kauft sich nicht „Sicherheit“, sondern Zeit und Übersicht, und das ist im Incident oft mehr wert als die zehnte Grundsatzdiskussion.

Und ja, dann kommen die Tests. Learndmarc für die schnelle, anschauliche Verifikation einer konkreten Mail. MECSA für die Standardabdeckung und die Aussenwirkung der Domain. Ein aktiver Transporttest, wenn ich wissen will, wie mein MTA sich im Grenzbereich verhält, nicht wie mein DNS-Text aussieht.

E-Mail-Sicherheit als Governance

Man kann E-Mail erstaunlich weit „abhärten“, ohne den Inhalt anzufassen. Das ist auch gut so, denn Transport- und Authentisierungssicherheit sind Voraussetzung, nicht Luxus: DANE, RFC7672²⁶, liefert downgrade-resistente Transportauthentisierung über DNSSEC-verankerte TLSA-Records; MTA-STS, RFC8461²⁷, liefert eine CA-basierte Policy-Schicht, die sendende Server zu TLS mit validiertem Zertifikat verpflichten kann; TLS-RPT, RFC8460²⁸, liefert Telemetrie, damit man nicht blind bleibt.

Trotzdem ist der härteste Teil nicht kryptographisch, sondern organisatorisch: Wer darf im Namen der Domain senden, wer verwaltet DNS, wer dreht Policies, wer liest Reports, wer entscheidet über Reject versus Quarantine, wer kennt die Abhängigkeiten zu Newsletter-Anbietern, Ticketing-Systemen, ERP, Multifunktionsdruckern, und wer ist bereit, bei einem echten Angriff den Betrieb kurz ungemütlich zu machen, statt ihn langfristig lächerlich zu lassen. Layer 8 ist Governance: Zuständigkeit, Mut zur Konsequenz, Abneigung gegen „wird schon“.

---

1. https://en.wikipedia.org/wiki/Layer_8 ↩︎
2. https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol ↩︎
3. https://de.wikipedia.org/wiki/Transport_Layer_Security ↩︎
4. https://en.wikipedia.org/wiki/Opportunistic_encryption#Email ↩︎
5. https://de.wikipedia.org/wiki/DMARC ↩︎
6. https://de.wikipedia.org/wiki/Spoofing ↩︎
7. https://www.msxfaq.de/signcrypt/tlsrpt.htm ↩︎
8. https://www.msxfaq.de/signcrypt/mta_sts.htm ↩︎
9. https://www.digicert.com/de/faq/email-trust/what-is-bimi-and-why-is-it-important ↩︎
10. https://de.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ↩︎
11. https://dane.sys4.de/ ↩︎
12. https://de.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_Resource_Record ↩︎
13. https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
14. https://dnsviz.net/ ↩︎
15. https://www.mailhardener.com/features ↩︎
16. https://en.wikipedia.org/wiki/Sender_Policy_Framework ↩︎
17. https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎
18. https://datatracker.ietf.org/doc/html/rfc7489 ↩︎
19. https://datatracker.ietf.org/doc/html/rfc8460 ↩︎
20. https://en.wikipedia.org/wiki/Opportunistic_TLS ↩︎
21. https://en.wikipedia.org/wiki/Message_transfer_agent ↩︎
22. https://www.learndmarc.com/ ↩︎
23. https://mecsa.jrc.ec.europa.eu/en/technical ↩︎
24. https://blog.lindenberg.one/EmailSicherheitsTest ↩︎
25. https://mecsa.jrc.ec.europa.eu/en/finderRequest/b754189b94fb4c28edc4b373424f2fe0 ↩︎
26. https://datatracker.ietf.org/doc/html/rfc7672 ↩︎
27. https://datatracker.ietf.org/doc/html/rfc8461 ↩︎
28. https://datatracker.ietf.org/doc/html/rfc8460 ↩︎

---