Was ist denn nun schon wieder dieses SPF, DKIM und DMARC?

DIE DREI MUSKETIERE IM E-MAIL MARKETING

Sichere Mailzustellung ist in der digitalen Welt entscheidend. DKIM, SPF und DMARC sind dabei sozusagen die Drei Musketiere und wichtige Technologien, um vor Spam, Phishing und Betrugsversuchen zu schützen. DKIM bestätigt die Authentizität von E-Mails, SPF prüft den erlaubten Absender und DMARC überwacht und bewertet DKIM und SPF. In diesem Artikel erklären wir, warum es heute wichtiger denn je ist, diese Einstellungen perfekt zu konfigurieren, um eine optimale Mailzustellung (Deliverability) im E-Mail Marketing und Mail-Verkehr zu erreichen.

WAS IST ALSO SPF?

Einfach ausgedrückt, sind Sender Policy Frameworks (SPF) Sicherheits-Mechanismen, welche erstellt wurden, um Bösewichte davon abzuhalten, E-Mails fälschlicherweise in Ihrem Namen zu versenden.

Während der Kommunikation der verschiedenen DNS-Server wird überprüft, ob anhand von SPF die Authentizität des Senders geprüft werden kann. Hört sich kompliziert an, ist es aber gar nicht.

Hier die Erklärung:
Angenommen Sie schicken eine E-Mail an Tim. Woher soll Tims Server nun wissen, dass die E-Mail auch wirklich von Ihnen ist? Hier sind wir beim Thema. Das kann der Server nicht wissen, außer Sie nutzen den SPF-Eintrag auf Ihrem DNS-Server.
Der SPF-Eintrag auf Ihrem DNS-Server legt also fest, welche IP-Adressen benutzt werden dürfen, um E-Mails unter Ihrem Namen zu senden.
Um das Ganze bildlich darzustellen, haben wir uns zwei mögliche „Konversationen“ zwischen den DNS-Servern, am Beispiel SPF überlegt. Nachdem wir mit Tim schon einen Namen für den Empfänger haben, brauchen wir nun noch einen für Sie. Sagen wir einfach Sie heißen Alex.

SPF EINFACH ERKLÄRT

Szenario 1: Sie haben keinen SPF-Eintrag auf Ihrer Domain hinterlegt

Server Alex: Hey Server Tim. Ich habe eine neue Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Super! Ich prüfe nur noch Deinen SPF! Denn wir lassen nur Mails zu, deren Identität nachweisbar ist.
Server Alex: Ach so ja wegen SPF… Wen interessiert das schon. Ich hab keinen, aber du kannst mir glauben, die Nachricht ist ganz sicher von Alex. Wirklich!
Server Tim: Schade. Wenn du mir seine erlaubten IPs zur Überprüfung nicht gibst, kann ich sie mit dem SPF-Eintrag an Alex´ DNS-Server auch nicht vergleichen.
Server Alex: Ich habe die Liste von Alex´ erlaubten IPs nicht.
Server Tim: Ok, dann will ich deine Nachricht nicht. Zustellung abgelehnt, tut mir leid Kumpel.

Szenario 2: Sie haben den SPF-Eintrag auf Ihrer Domain hinterlegt

Server Alex: Hey Server Tim. Ich habe eine neue Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Ich überprüfe noch kurz die Echtheit der Herkunft mittelst SPF? Gibst Du mir bitte Deinen SPF Schlüssel?
Server Alex: Da schau her, hier ist mein SPF mit der kompletten Liste aller IPs, die Alex zum Versenden erlaubt hat.
Server Tim: Okay, lass mich mal nachschauen… Die Nachricht welche du für mich hast, wurde von IP 80.190.129.145 versendet. Perfekt sie steht auf meiner Liste. So gefällt mir das. Gib mir die Nachricht und ich zeige sie Tim. Vielen Dank und bis zum nächsten Mal!

AHA - UND WAS IST DANN DKIM?

Ähnlich wie SPF sorgt auch DKIM (DomainKey Identified Mail) dafür, Absender zu identifizieren und es Bösewichten zu erschweren, unter falschem Namen nicht erwünschte Mailings zu senden.

Anders als im vorherigen Beispiel, werden beim DKIM-Verfahren allerdings zwei miteinander korrespondierende digitale Schlüssel erstellt. Der erste Schlüssel wird auf Ihrem DNS-Server hinterlegt und veröffentlicht (Public Key). Der zweite Schlüssel ist nur dem Versender bekannt (Private Key).

Mit dem Private Key wird die Mail digital signiert, das heißt aus dem Mail-Inhalt wird eine Signatur erstellt. Dies ist genau genommen ein zweistufiger Prozess. Zuerst wird ein Hashwert des Contents erstellt, der anschließend mit dem Private Key zur eigentlichen digitalen Signatur verschlüsselt wird. Diese kann dann beim Empfänger mit dem Public Key wieder entschlüsselt werden.

Um auch hier ein bisschen weg von Tech-Talk zu kommen und das Szenario bildlich darzustellen, haben wir uns zwei mögliche „Konversationen“ zwischen den DNS-Servern, am Beispiel DKIM überlegt.

Zur Erinnerung: Unser Empfänger der E-Mail-Nachricht ist Tim, der Versender heißt Alex.

DKIM EINFACH ERKLÄRT

Szenario 1: Sie haben keinen DKIM-Eintrag hinterlegt, aber das Mailing wurde DKIM-verschlüsselt gesendet.

Server Alex: Hey Server Tim. Ich habe eine neue Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Ah, in Deiner Mail ist ein privater DKIM-Schlüssel enthalten. Lass mich mal Deinen öffentlichen Schlüssel am DNS-Server sehen.
Server Alex: Ach so ja wegen DKIM… Wen interessiert das schon. Ich hab keinen zweiten Schlüssel, aber du kannst mir glauben, die Nachricht ist von Alex. Wirklich!
Server Tim: Wenn du nur einen Teil des DKIM-Schlüssels hast, wirst Du mir wahrscheinlich etwas vorgaukeln. Ich kann nicht sicher sein, dass die Nachricht wirklich von Alex ist. Wenn du mir Alex’ öffentlichen Schlüssel gibst, kann ich das überprüfen.
Server Alex: Ich habe keinen DKIM-Schlüssel von Alex.
Server Tim: Ok, dann will ich deine Nachricht nicht. Zu gefährlich! Zustellung abgelehnt, tut mir leid Kumpel.

Szenario 2: Sie haben Ihren DKIM-Eintrag hinterlegt und das Mailing wurde DKIM-verschlüsselt gesendet.

Server Alex: Hey Server Tim. Ich habe eine neue Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Ah, in Deiner Mail ist ein privater DKIM-Schlüssel enthalten. Lass mich mal Deinen öffentlichen Schlüssel am DNS-Server sehen.
Server Alex: Da schau her, hier ist mein öffentlicher DKIM-Schlüssel.
Server Tim: Okay, lass mich mal die beiden Schlüssel überprüfen und den Hashwert zurück rechnen. Perfekt, das Ergebnis stimmt überein. So gefällt mir das. Gib mir die Nachricht und ich zeige sie Tim. Vielen Dank und bis zum nächsten Mal!

SORRY!

An dieser Stelle eine kleine Entschuldigung an alle technisch affinen Leser für diese stark simplifizierte und primitive Darstellung der Situation.

Bitte vergebt uns Dummies und habt im Hinterkopf, dass wir Euch nur um Eure superanalytischen Köpfe beneiden

ZWISCHEN FAZIT:

Wie auch immer Sie mit der Essenz dieser Geschichte umgehen, Fakt ist:
Benutzen Sie DKIM und/oder SPF! Denn tun Sie das nicht, könnte es sein, dass Ihr DNS-Server als Bösewicht dargestellt wird und nicht alle Ihre E-Mail Nachrichten ankommen. Und das wollen wir schließlich alle nicht!

Sollten Sie jetzt keine Lust mehr haben sich weiter mit diesem Thema zu beschäftigen, sind aber auf der Suche nach einer sicheren Versandlösung mittels eines professionellen E-Mail-Marketing Systems? Dann steht Ihnen Unser erfahrenes Team aus E-Mail-Marketing-Spezialisten gerne zur Verfügung.

Nehmen Sie mit uns Kontakt auf!

UND WAS IST DENN DANN DMARC?

Nein, DMARC hat nichts mit der guten Alten D Mark (Deutsche Mark) zu tun! Die DMARC-Spezifikation entstand unter anderem auf Initiative von Google, Yahoo, Microsoft, Facebook, AOL, PayPal und LinkedIn, um ein besseres Server-Management bei den empfangenden Mail-Servern zu ermöglichen. 

DMARC (Domain-based Message Authentication, Reporting and Conformance) wurde entwickelt, um den Missbrauch von E-Mails zu reduzieren. Sie versucht beim E-Mail-Versand die Unzulänglichkeiten bei Authentifizierungsproblemen zu beheben und kann ergänzend zu DKIM und/oder SPF-Einträgen angelegt werden. Mit einem DMARC-Eintrag lassen sich zusätzliche Empfehlungen definieren, wie der empfangende Mail-Server mit einer E-Mail umgehen sollte, die nicht den Regeln entspricht.

Während bei den beiden vorab genannten Szenarien beschrieben wird, wer eine Mail versenden darf (SPF), bzw. dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender mit der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art und Weise der Empfänger mit seiner E-Mail umgehen soll, die in einem oder beiden Fällen nicht den Anforderungen entspricht.

Sofern der E-Mail-Empfänger die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Echtheit dieser E-Mail gesichert und ein besseres Anti-SPAM-Management ist möglich.

Für die Einrichtung von DMARC ist beim Absender keine Einstellung im System nötig, da bereits alle Informationen in den Einträgen für SPF und DKIM beinhaltet sind. DMARC regelt die Behandlung des Mail beim Empfänger-Server.

Wenn jemand Ihre Identität fälscht, SPF- und DKIM-Überprüfungen nicht besteht und versucht, Spam zu senden, funktionieren die Policies wie folgt:

> Mit einer quarantine-Policy können die E-Mails entweder:

• direkt in den Spam-Ordner der Empfänger gelangen,
• eine vorübergehende Quarantäneperiode durchlaufen, bevor sie geliefert, ignoriert oder gelöscht werden, oder
• einem tiefergehenden Anti-Spam-Filtering unterzogen werden, bevor sie möglicherweise im Spam-Ordner der Empfänger landen.

> Mit einer reject-Policy werden die E-Mails überhaupt nicht zugestellt, wenn die Validierung fehlschlägt

WICHTIG: DMARC ist ab 2024 Pflichtanforderung von Google und Yahoo!

Eine detailliertere Übersicht über die neuen Absenderanforderungen von Google und Yahoo finden Sie in den Richtlinien für E-Mail-Absender von Google und in den Best Practices für Absender von Yahoo.

DMARC EINFACH ERKLÄRT

Szenario 1: Sie haben keinen SPF- und DKIM-Eintrag auf Ihrer Domain hinterlegt

Server Alex: Hey Server Tim. Ich habe eine super tolle Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Gibst du mir bitte deine Daten, also DKIM und SPF?
Server Alex: Ähm, ach so ja, DKIM, SPF… Wen interessiert das denn? Ich bin aber eine wichtige Nachricht und kein SPAM.
Server Tim: Wenn du mir weder die erlaubten Absender IPs, noch den dazugehörigen Schlüssel geben kannst, werde ich Deine Nachricht nicht direkt an Tim weiterleiten.
Server Alex: Ich habe die Liste von Tims erlaubten IPs und den Private-Key nicht als SPF und DKIM.
Server Tim: Ok, dann will ich deine Nachricht nicht direkt zustellen, sondern laut hinterlegtem DMARC-Protokoll prüfen und intern bearbeiten oder weiterleiten. Vielleicht geht dein Mail dann doch noch an Tim.

Szenario 2: Sie haben den SPF- und DKIM-Eintrag auf Ihrer Domain hinterlegt

Server Alex: Hey Server Tim. Ich habe eine neue Nachricht von Alex für Tim.
Server Tim: Hallo Server Alex. Was ist dein SPF und DKIM?
Server Alex: Hier ist mein SPF mit der kompletten Liste aller IPs, die Alex zum Versenden erlaubt hat und mein Private-Key des DKIM mit dem du die Richtigkeit prüfen kannst.
Server Tim: Okay, lass mich mal nachschauen… Die Nachricht, welche du für mich hast, wurde von IP 80.190.129.145 versendet. Perfekt sie steht auf meiner Liste. Jetzt prüfe ich noch den DKIM Public-Key... Aja, der Hash des Mails passt zum Public-Key von Tim. So gefällt mir das. Gib mir die Nachricht und ich schiebe sie direkt in das Postfach von Tim. Vielen Dank und bis zum nächsten Mal!

 

PROFITIEREN SIE VON 20 JAHREN
E-MAIL-MARKETING ERFAHRUNG

Sie möchten die Zustellbarkeit Ihrer E-Mail-Marketing und Marketing-Automation-Kampagnen optimieren? Sie suchen einen erfahrenen Partner der Sie bei der Konzeptionierung und Umsetzung unterstützt? Sie suchen Expertise bei der Systemauswahl und der technischen Implementierung? Dann nehmen Sie mit uns Kontakt auf!

WIR BERATEN SIE GERNE.  

TIPPS & TEST-TOOLS

Sie suchen nach geeigneten Lösungen, Tipps und Tools, um Ihre DKIM, SPF und DMARC Einträge zu prüfen? Glück gehabt! Hier verraten wir Ihnen unsere Lieblings-Tools für Ihr perfektes E-Mail Marketing.

LERN- UND TEST-TOOL FÜR EINE VISUELLE AUFSCHLÜSSELUNG DER KOMMUNIKATION VON E-MAIL-SERVERN, DIE IHNEN EIN BESSERES VERSTÄNDNIS VON SPF, DKIM UND DMARC UND DEREN ZUSAMMENSPIEL VERMITTELT

TEST-TOOL FÜR DKIM & SPF (MAIL-TESTER.COM)
TEST-TOOL FÜR DMARC (DMARCIAN.COM)
GMAIL RICHTLINIEN FÜR E-MAIL-ABSENDER