SPF, DKIM und DMARC einrichten: Spätestens seit Emotet und den fast täglich ankommenden Rechnungen die angeblich von Amazon stammen, ist es sinnvoll sich dem Thema Email Authentifizierung zu widmen. In diesem Artikel versuche ich etwas Licht in die Zusammenhänge zu bringen.
Wie können Absender/ Empfänger überhaupt gefälscht werden?
Dazu müssen wir kurz einen Schritt zurück gehen und eine theoretische Situation betrachten:
Stell dir vor du schreibst eine Postkarte. Dort schreibst du als Absender „Angela Merkel“ drauf, als Empfänger „Max Mustermann„.
Diese Postkarte legst du nun in einen Briefumschlag und klebst ihn zu. Was musst du nun auf diesen Briefumschlag schreiben, damit du ihn verschicken kannst? Richtig: Einen Absender und einen Empfänger.
In meinem Beispiel adressieren wir den Brief an Bob in der Musterstraße 17. Damit der Briefumschlag nun auch bei Bob ankommt, musst du logischerweise auch die richtige Adresse angeben. Wie soll die Post ihn sonst richtig abgeben? Den Absender dagegen, kontrolliert beim Absenden niemand. Selbst wenn du dort als Absender Luke Skywalker in der Sternenstraße 42 drauf schreibst, ist die Wahrscheinlichkeit groß, dass der Brief an Bob zugestellt wird.
Der Brief kommt nun bei Bobs Briefkasten an. Sein Sekretär packt den Brief für ihn aus und schmeißt den Briefumschlag weg. Bob erhält also nur die Postkarte, schaut sie sich an und wundert sich:
Auf der Postkarte stehen seltsame Empfänger und Absender. Der Empfänger der auf dieser Postkarte zu sehen ist, ist doch überhaupt nicht Bob. Warum ist diese Postkarte nun bei Bob angekommen? Und warum schickt Angela Merkel diese Postkarte ab?
Jetzt hast du einen Überblick darüber, wie E-Mails aufgebaut sind und wo das Problem liegt.
Die verschiedenen Absender- und Empfänger-Felder
Bei E-Mails haben wir das gleiche Prinzip. Eine E-Mail hat einen Envelope (Briefumschlag) mit Empfänger und Absender. Der Envelope wird zum Zustellen von den Mailservern genutzt (in unserem Beispiel die Post). Dein E-Mail Programm (Sekretär) blendet diesen Teil dann für dich aus. Die Empfänger und Absender die du nun in deinem Mail-Programm siehst, sind diejenigen des Mail-Headers (Postkarte).
Hier findest du nun die Namen der Felder, wie du sie oft vorfinden wirst:
| Name aus Beispiel | SMTP-Name |
| Envelope Absender | MAIL FROM: (Envelope-From, Return-Path, …) |
| Envelope Empfänger | RCPT TO: |
| Header Empfänger | To |
| Header Absender | From |
Du siehst also, es gibt nur eine einzige Adresse, die man nicht fälschen kann: die Envelope Empfänger Adresse (Die Empfänger-Adresse des Briefumschlag). Denn wenn man diese falsch angeben würde, kommt die Mail nicht beim gewünschten Empfänger an. Alle anderen Adressen könnte man theoretisch beliebig fälschen!
Um nun sicher zu stellen, dass beide Absender-Adressen (Envelope und Header) meiner Domain nicht gefälscht werden können, brauche ich zwei verschiedene Werkzeuge.
SPF (Sender Policy Framework)
SPF schützt die Envelope (Briefumschlag) Absender Adresse. Das ist also die Adresse, die der Mailserver betrachtet. Die Idee hinter SPF ist relativ einfach: Ich nenne bestimmte Server denen ich erlaube unter meiner Domain Mails zu versenden. Das mache ich, indem ich einen DNS-Eintrag für meine Domain veröffentliche. Ich erzeuge einen sogenannten TXT-Record und gebe dort beispielhaft folgendes an:
v=spf1 ip4:81.169.146.128/25 ip4:85.215.255.0/24 include:spf.protection.outlook.com -all| Symbol | Bedeutung |
| v=spf1 | SPF-Version |
| ip4: | IPv4 Adresse (bzw. Bereich, wenn ein Bereich nach dem / folgt) |
| include: | Ich inkludiere einen weiteren SPF-Eintrag In diesem Beispiel dürfen also alle Outlook-Server ebenfalls Mails für diese Domain versenden |
| -all | Was soll passieren wenn die Mail nicht von einem erlaubten Server kam -all = Ablehnen ~all = Softfail ?all = Nichts unternehmen |
Gerade Include: Einträge machen es leicht SPF einzurichten, da ich so einem E-Mail Dienstleister die Verwaltung meines SPF-Eintrags übertragen kann. So kann ich z.B. sagen „Outlook Online verwaltetet meinen SPF-Eintrag, schaut dort nach“. In einem SPF-Eintrag dürfen allerdings maximal 10 DNS-Anfragen vorkommen. In meinem Eintrag oben ist nur eine DNS-Anfrage enthalten, nämlich auf spf.protection.outlook.com. Würden aber hinter diesem Outlook-DNS-Eintrag nochmal 2 include Einträge stecken, wäre mein SPF-Eintrag schon bei insgesamt 3 DNS-Anfragen.
Eine super Seite um sich das im Detail anzeigen zu lassen, ist emailstuff.org. Dort kann man unter Authentication/SPF den eigenen Domainnamen eingeben. Anschließend überprüft die Seite, ob der Record gültig ist.
Du kannst aber natürlich auch jederzeit selbst eine DNS-Anfrage machen. Eine sehr einfache Seite dazu ist http://kloth.net/ . Dort musst du oben auf TXT umstellen und findest anschließend den SPF-Eintrag:
DKIM (Domain Key Identified Mail)
DKIM schützt ebenfalls die Envelope (Briefumschlag) Absender Adresse. Dazu wird ein kleines Programm auf deinem Mail Server installiert, welches ausgehende Mails signiert. Das kannst du dir so vorstellen:
Als erstes wird die Mail generiert. In dem Header der Mail stehen jetzt schon viele verschiedene Dinge, wie die beiden Absender-Adressen, welches E-Mail Programm du nutzt, wie groß die Mail ist, … viele Informationen halt 🙂
All diese Informationen werden jetzt mit einem privaten Schlüssel eines Zertifikats signiert. Diese Signatur wird ebenfalls in den Header der Mail eingefügt. Der öffentliche Schlüssel dieses Zertifikats wird nun ebenfalls als DNS-Eintrag in deiner Domain veröffentlicht. Wenn du also jetzt eine Mail versendest, wird diese im Header automatisch mit deinem eigenen privaten Schlüssel signiert.
Der Empfänger sieht jetzt diese Mail und bemerkt den signierten Header-Teil. Er schaut in deinem DNS nach, ob er dort den öffentlichen Schlüssel dazu finden kann. Wenn er den signierten Teil mit dem öffentlichen Schlüssel entschlüsseln kann, weiß er, dass diese Mail wirklich von deinem Mailserver kam.
DKIM baut dabei auf sogenannte „Selectors“. So kannst du beispielsweise auf deinem Mailserver im DKIM-Programm mehrere Selectors anlegen, die unterschiedliche Namen haben und unterschiedliche Zertifikate benutzen.
Falls du dich fragst warum: Wir benutzen hierbei Zertifikate, die natürlich irgendwann mal ablaufen. Wenn das Zertifikat von Selector1 getauscht werden soll, kann ich in der Zeit einfach auf Selector2 umstellen. Ab dann werden alle Mails mit dem Selector2 signiert und ich kann in der Zwischenzeit in aller Ruhe Selector1 austauschen. Würde ich diesen Schwenk auf Selector2 nicht vorher machen, würde in der Zeit, in der ich das Zertifikat von Selector1 tausche, die Mails nicht signiert werden. Somit würde die Mail für meine Empfänger gefälscht aussehen!
In dem Mail-Header siehst du aber sofort, welcher Selector zum Signieren genutzt wurde. Deshalb brauchst du auch den Selector und den Domain-Namen, um einen DKIM-Record zu kontrollieren. Im Header sieht das dann wie folgt aus:
| Header Name | Header Wert |
|---|---|
| DKIM-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; t=1585063963; s=strato-dkim-0002; d=lukaslange.de; h=Message-ID:Date:Subject:In-Reply-To:References:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=7xGG84A |
Hinter dem s= siehst du den Namen des DKIM Selectors. Hinter d= siehst du diejenige Domain, die im Header-FROM (Postkarte, die sichtbare E-Mailadresse) Teil angegeben wurde. Somit kannst du selbst diesen Record überprüfen, indem du z.B. bei Emailstuff.org unter Authentication DKIM auswählst und dann dort nach dem Selector strato-dkim-0002 und der Domain lukaslange.de suchst. Präsentiert wird dir der öffentliche Schlüssel, den Strato veröffentlicht hat und mit dem diese Mail signiert wurde 🙂 Genau das macht dein E-Mail Server dann automatisch für dich und schreibt es anschließend in den Authentication-Results Teil des Headers.
Ein DKIM Record im DNS ist wie folgt aufgebaut:
SELECTORNAME._domainkey.domainname.deIn meinem Beispiel von oben findest du den Record also unter:
strato-dkim-0002._domainkey.lukaslange.de
Super! Nun könnte man meinen, dass alles sicher ist! Aber was soll ein Empfänger machen, wenn SPF nicht stimmt, aber DKIM? Oder was soll er machen, wenn DKIM stimmt, aber SPF nicht?
DMARC (Domain-based Message Authentication, Reporting and Conformance)
Mit DMARC kommt nun das letzte wichtige Konzept ins Spiel: Das sogenannte „Domain Alignment“. DMARC erfordert eine Domain-Übereinstimmung über SPF oder DKIM.
Damit SPF übereinstimmt, muss die versteckte Envelope-From (Briefumschlag) und die sichtbare Header-From (Postkarte) Domain übereinstimmen.
Damit DKIM übereinstimmt, muss die sichtbare Header-From (Postkarte) und die DKIM d= Domain übereinstimmen.
Wie SPF und DKIM baut auch DMARC auf einem DNS-Eintrag auf. Ein DMARC Record sieht dabei wie folgt aus:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@lukaslange.de; ruf=mailto:dmarc@lukaslange.de; fo=1; sp=no
ne; aspf=r;| Symbol | Bedeutung |
| v=DMARC1 | DMARC Version |
| p=reject | Policy – Was soll passieren? none = Nichts unternehmen reject = Ablehnen quarantine = In die Quarantäne verschieben |
| pct=100 | Auf wie viel Prozent der Emails soll das angewandt werden? |
| rua | Eine Adresse an die aggregierte Berichte gesendet werden sollen |
| ruf | Eine Adresse an die forensische Berichte gesendet werden sollen |
| fo=1 | Failure reporting 1 = Generiere einen Fehler-Report wenn irgendeine Authentifizierungs-Methode fehlschlägt |
| sp=none | Subdomain Policy Ist relevant wenn auch von Subdomains gesendet wird (z.B. blog.lukaslange.de oder shop.lukaslange.de). Hier kann angegeben werden ob die Policy für die Subdomains gleich gilt |
| aspf=r | SPF Regelwerk r= relaxed |
Über die DMARC Regeln kannst du also ganz genau sagen, was dein Empfänger machen soll, wenn etwas fehlschlägt.
Praktisch ist dabei, wenn man p=none für den Anfang aktiviert. Dadurch nimmt der Empfänger trotzdem jede E-Mail von dir an, selbst wenn SPF oder DKIM nicht stimmt. Durch die Adressen die bei rua und ruf angegeben sind, wird jedesmal eine Email mit einem kleinen Report an diese Adressen gesendet. Auf diesem Weg kannst du also kontrollieren, ob es vielleicht noch andere Adressen oder Anbieter gibt, die unter deiner Domain E-Mails verschicken. Je nachdem kann es sich dabei um Fälscher handeln, oder natürlich auch echten Dienst-Anbietern (Z.B. Ein Newsletter-Anbieter der in deinem Namen Mails versendet!)
Bei den Forensichen Reports solltest du aber unbedingt auf die Vereinbarkeit mit der DSGVO achten. Hierbei werden teilweise die Mails als Anhang an die Adresse gesendet. Da momentan sowieso viele Report-Sender nur die zusammengefassten Reports (Aggregate Reports) versenden, empfehle ich deshalb gerne, die ruf-Adresse nicht zu setzen.
DMARC DNS-Records sind immer wie folgt aufgebaut:
_dmarc.domainname.deIn meinem Beispiel also:
_dmarc.lukaslange.de
Die Reports, die an diese Adressen gesendet werden, enthalten dabei immer XML-Dokumente. In diesen XML-Dokumenten findest du dann die Authentication-Stati einzelner Mails.
Lesbarkeit der DMARC XML-Reports
Die XML-Dateien werden teilweise doppelt gezippt und so an die Empfänger-Adresse gesendet. Somit ist die Lesbarkeit und Analyse dieser Sender wirklich sehr schwierig. Glücklicherweise gibt es aber diverse Anbieter, die dir die Reports automatisch aufbereiten. In meinem DMARC-Record siehst du oben schon angedeutet, dass ich dmarc.postmarkapp.com nutze. Der Dienst ist völlig kostenlos und kann einfach auf der Seite angefordert werden.
Dazu musst du deinen Domainnamen dort angeben und anschließend die angezeigte E-Mail Adresse mit in deine rua Adressen aufnehmen. Anschließend werden dir wöchentlich leicht lesbare Reports zugesandt, die dir auf einen Blick alles verraten.
Für Office 365 Kunden gibt es sogar ein kostenloses Angebot mit einem eigenen Dashboard, von der Firma Valimail. Das Prinzip ist das gleiche, man muss ebenfalls Domains einrichten und dann im eigenen Record die rua Adresse von Valimail hinzufügen.
Empfangen von Reports anderer Domains
Gerade wenn du mehrere Domains hast, kann es gut sein, dass du gerne eine zentrale Mailadresse verwenden möchtest, um alle Reports zu erhalten. Damit das aber möglich ist, musst du von der empfangenden Domain aus dein Okay dazu geben.
Nehmen wir als Beispiel den Dienst-Anbieter postmarkapp.com. Wenn ich in meinem DMARC-Record angebe, dass die Mails an die Adresse in dieser Domain gesendet werden sollen, würde das nicht ohne weiteres funktionieren. Damit das aber doch möglich ist, muss dmarc.postmarkapp.com nochmal einen DNS-Record für meine Domain veröffentlichen. Der ist dabei wie folgt aufgebaut:
meinedomain.de._report._dmarc.reportdomain.deIn diesem Beispiel also:
lukaslange.de._report._dmarc.postmarkapp.comDiejenige Domain, die Reports von meiner Domain erhalten soll, erlaubt das also durch einen DNS-Eintrag in der meine Domain angegeben ist.
SPF, DKIM und DMARC zusammen
Wir haben nun erfolgreich alle Authentisierungs-Verfahren eingerichtet. Was passiert nun, wenn jemand meine Domain als Absender fälscht?
Fälscht der Angreifer den Absender im Envelope-Absender (der Briefumschlag, also die Adresse die hauptsächlich vom Server genutzt wird) mit meiner Domain, überprüft der Empfänger im SPF Record, ob dieser Server überhaupt unter dieser Domain senden darf. Da der Angreifer das natürlich nicht darf und sein Email Server nicht in meinem SPF Record steht, wird SPF=Fail registriert. Ist kein Record vorhanden, wird SPF=none registriert.
Fälscht er den Absender in der Header-Absender (die Postkarte, also die Adresse die der User im Programm direkt sieht), gibt es drei Möglichkeiten. DKIM=pass, DKIM=fail und DKIM=none
Der Empfänger prüft, ob eine DKIM Signatur vorhanden ist. Wenn ja, wird geprüft ob der passende Record auch vorhanden ist. Ist er vorhanden und die Signatur passt, wird DKIM=pass angegeben. Ist er vorhanden, aber die Signatur stimmt nicht überein, wird es DKIM=fail. Wird aber überhaupt keine DKIM Signatur mitgesendet, wird es DKIM=none.
Jetzt wird der DMARC Record wichtig. Wie du dir sicher schon denken kannst, gäbe es ohne DMARC ein Problem. Denn dann könnte der Angreifer die Mail einfach wie folgt aufbauen:
| Absender-Adresse | Wert |
|---|---|
| Envelope-From | Angreifer@AngreiferDomainMitSPF.de |
| Header-From | Chef@meinedomain.de |
Was passiert nun? Der Empfänger schaut im Envelope-From (Briefumschlag) und findet dort die Domain AngreiferDomainMitSPF.de. Er schaut also bei AngreiferDomainMitSPF.de nach, ob es einen SPF-Record dafür gibt. In diesem Fall gibt es den und unter dieser Domain darf der Angreifer auch von diesem Server aus senden. Somit wird SPF=Pass!
Der Header-From ist hierbei also die gefälschte Adresse. Dort steht jetzt meine Domain drin, aber es wird keine DKIM Signatur gemacht. Somit wird DKIM=None
Der Angreifer hat also SPF=PASS und DKIM=NONE. Ohne DMARC weiß der Empfänger aber nicht, dass das ein Problem ist!
Nur wenn mein DMARC-Record jetzt vorhanden ist, gilt die Mail als richtig wenn SPF ODER DKIM auf Pass stehen, damit DMARC=Pass wird.
Ich hoffe der Beitrag hat dir geholfen die Thematik besser zu verstehen. Schreibe mir gerne einen Kommentar wenn du Fragen oder Anregungen hast!