Was bedeuten die Begriffe SPF, DKIM und DMARC, die beim Mail-Versand eine Rolle spielen. Wir haben uns umgesehen, und versuchen eine möglichst verständliche Erklärung. Aber leicht ist das nicht, glauben Sie uns.
Im Oktober 1971 hatte Ray Tomlinson den ersten elektronischen Brief verschickt, das war die Geburtsstunde der E-Mail. Damals dachte man nicht daran, dass es in Zukunft auch Spam-Mails geben könnte, daher wurde das technische Konzept hinter dem Mailversand eher einfach gehalten. Jahrzehnte danach haben wir den Spam-Salat.
Nun gibt es nachträglich entwickelte Konzepte, die sich um wesentliche Anforderungen an die E-Mail kümmern, wie die Authentizität, der Datenschutz und die Integrität der E-Mail.
Mit der Authentizität einer E-Mail ist gemeint, dass sichergestellt ist, dass die E-Mail auch wirklich vom Absender stammt, also ein Original ist und keine betrügerische Fälschung. Datenschutz bezeichnet bei E-Mails im Wesentlichen den Schutz vor Mitlesen durch Dritte auf dem Übertragungsweg. Als Integrität bezeichnet man das Schutzziel, dass der E-Mail-Inhalt bei der Übertragung vollständig und unverändert bleibt.
Wikipedia, Stand 2021-07-03
In diesem Artikel geht es nicht darum, wie Sie selbst sich vor Spam-Mails schützen können, sondern was Sie unternehmen können, damit Ihre Mails, die hoffentlich keine Spam-Mails sind, bei dem Empfänger/innen mit hoher Wahrscheinlichkeit ankommen.
Einträge im Domain Name System
Bei allen Verfahren zur Gewährleistung der wesentlichen Kriterien handelt es sich um Einträge im Domain Name System (DNS), also die Domain-Einstellungen der Domain, für die diese Kriterien angewendet werden sollen.
Es existieren daher optimalerweise im DNS der Domain drei besondere (Text-)Einträge für die Absicherung des Mail Verkehrs mit Hilfe der drei Verfahren:
SPF
DKIM
DMARC
Für Eilige
Mit SPF geben Sie an, welche Mail-Server im Namen Ihrer Domain E-Mails versenden dürfen.
Mit DKIM kann man feststellen, ob eine E-Mail tatsächlich über die angegebene Domäne versendet wurde. Eine Verschlüsselung des Mail-Inhalts oder eine Wertung bezüglich Spam-Verdacht finden dabei ausdrücklich nicht statt.
Mit DMARC können Sie Empfehlungen geben, wie ein Empfänger-Server bei Verstößen gegen SPF und DKIM mit einer E-Mail verfahren soll.
Arbeiten im Domain Name System (DNS)
Die Einträge für SPF, DKIM und DMARC sind nicht für alle Mailserver und Domains einfach dieselben, sondern deren Inhalte hängen von den Umständen ab. Kopieren Sie daher keinesfalls etwaige Beispiele von weiter unten und fügen diese auf Ihrem Nameserver ohne individuelle Anpassungen ein!
Sie benötigen also Zugang zum DNS im Verwaltungsbereich Ihres Providers. Dort folgen Sie am besten einer Anleitung, die Ihr Provider zweifellos zur Verfügung stellt. Sollte das nicht der Fall sein, wenden Sie sich an den Support Ihres Providers.
Änderungen im DNS werden üblicherweise nicht sofort wirksam. Je nach Provider kann das einige Minuten bis einige Stunden dauern, bis Ihre Einträge wirksam – oder bei Fehlfunktion und Löschens des Eintrags – wieder unwirksam werden.
Seien Sie bitte auch unbedingt gewarnt: fehlerhafte DNS-Einträge können zu Nicht-Funktionieren von Website und/oder Mail-Versand führen. Konsultieren Sie daher auch die Anleitungen oder den Support Ihres Providers, bei dem die DNS-Einträge gemacht werden.
Am Ende des Beitrags finden Sie allgemeine hilfreiche Links zum Thema.
SPF
Was ist ein SPF Eintrag?
SPF steht für Sender Policy Framework. Mit SPF wird festgelegt, welche (Mail-)Server im Namen der Domain E-Mails versenden dürfen.
Mit einem SPF Eintrag im Domain Name System vom Typ »TXT(SPF)« geben Sie an, welche Mail-Server im Namen Ihrer Domain E-Mails versenden dürfen.
SPF kümmert sich also um die Authentizität (stammt die E-Mail tatsächlich vom Absender?).
Ablauf
Der Empfänger-Mailserver erhält eine E-Mail, und prüft erst einmal, ob der Absender zum Versand berechtigt ist. Dazu sieht sich der Empfänger an, welche Domain der Absender in bestimmten Mail-Feldern („MAIL FROM“ und „HELO“ im Mail-Header) angegeben hat.
Für diese angegebene Domain ruft der Empfänger nun die SPF-Information über das Domain Name System der Sender-Domain ab.
Stimmt die IP-Adresse überein (wird also der Sender-Mailserver in der Sender Domain angeführt), so ist der Absender authentisch, und die E-Mail wird in die Inbox zugestellt. Andernfalls kann die E-Mail verworfen werden; oder sie wird zwar zugestellt, aber direkt im Spam-Verzeichnis des Empfängers abgelegt.
Wie macht man einen SPF-Eintrag?
Wir wiederholen: mit Ihrem SPF Eintrag können Sie vorgeben, welche Mailserver (MTA – Mail Transfer Agent) überhaupt Mails aus Ihrer Domain zustellen dürfen, und wie Mails vom Empfänger-Mailserver behandelt werden sollen, die nicht über einen für Ihre Domain zugelassenen Mailserver versendet wurde.
ihre-domain.de. IN TXT "v=spf1 include:_spf.ihr-newsletter-mailserver.com a mx~all"
Das sieht wohl auf dem ersten Blick kompliziert aus, ist aber nicht so schlimm. Beachten Sie den Teil innerhalb der Anführungszeichen, und ganz besonders das Zeichen vor »all«. Mit dem Zeichen vor dem Wort »all« steuern Sie, inwieweit alle anderen Mailserver abgesehen von Ihrem eigenen Mailserver (der darf natürlich Mails für Sie versenden) klassifiziert werden:
-all: die »strenge Variante“ für die Domain (»hard fail«, definitive Abweisung)
~all: die tolerantere Variante (»soft fail«)
?all: alle anderen Mailserver gelten als neutral
+all: alle Mailserver sind zum Senden berechtigt (davon ist natürlich abzuraten)
Mit dem Eintrag aus Punkt 1 (-all) wird etwa nur solchen Mailservern die Zustellung von Mails erlaubt, die einen sogenannten MX Eintrag (mx) in Ihrer DNS Domain besitzen. Das gilt natürlich für Ihren eigenen Mailserver. Der Empfang Ihrer Mails, die über andere Mailserver gesendet wurden, wird abgewiesen.
Mit dem Eintrag aus Punkt 2 (~all) wird ebenfalls nur solchen Mailservern die Zustellung von Mails explizit erlaubt, die einen MX Eintrag (mx) in der DNS Domain besitzen. Alle anderen Mailserver werden aber nur als »verdächtig« markiert, und dennoch zugelassen. Die Mails dieser anderen Mailserver können dann je nach Empfängersystem durchaus im Posteingang landen oder zumindest im Spam-Verzeichnis der Empfänger. Die meisten Experten empfehlen die Nutzung dieser Variante, außer Ihre Mailadresse wird gerade in großem Stil für Spamversand mißbraucht.
Wenn Sie ?all aus Punkt 3 nutzen, dann wirkt das meist eher wie -all statt wie ~all.
Die Variante +all aus Punkt 4 nutzen Sie bitte keinesfalls.
Den für Ihren Fall konkreten Inhalt erhalten Sie entweder von Ihrem Provider, oder Sie nutzen dafür ein Tool (s.u.). Das werden Sie benötigen, wenn Sie beispielsweise auch über eine Newsletter-Plattform (CleverReach, mailworx, MailChimp, MailerLite, u.a.) Mails versenden wollen. Denn damit gestatten Sie auch dem Mailserver der Newsletter-Plattform Mails in Namen Ihrer Domain zu versenden. Sehen Sie dazu den o.a. Eintrag für den fiktiven Mailserver ihr-newsletter-mailserver.com. Die include Anweisung fügt einen oder mehrere weitere Mailserver zur Liste der erlaubten Mailserver hinzu.
Wenn Sie also einem zusätzlichen Mailserver die Erlaubnis geben möchten, Ihre Mails zu versenden, dann bringen Sie in Erfahrung, wie der Mailserver der jeweils verwendeten Plattform heißt, damit Sie den SPF Eintrag für Ihre Domain korrekt erstellen können. Suchen Sie am besten im Support-Bereich der Plattform nach Artikeln rund um den Begriff SPF.
Seit Sommer 2023 ist es vor allem nötig, einen SPF Eintrag zu nutzen, wenn man Mails an gmail.com-Mailadressen senden möchte. Andernfalls können die Mails eventuell nicht zugestellt werden, die Fehlermeldung beinhaltet:
Gmail requires all senders to authenticate with either SPF or DKIM.
Mit Domain Keys kann man feststellen, ob eine E-Mail tatsächlich über die angegebene Domäne versendet wurde. Eine Verschlüsselung des Mail-Inhalts oder eine Wertung bezüglich Spam-Verdacht finden dabei ausdrücklich nicht statt.
Um das zu bewirken, wird der E-Mail (dem »Header« der E-Mail) eine Signatur hinzugefügt, die der Domain zugeordnet ist. Damit soll das Fälschen des Absenders einer E-Mail erschwert werden. Das Verfahren basiert auf asymmetrischer Verschlüsselung. Der öffentliche Teil des Schlüsselpaars wird am Nameserver (im Domain Name System) hinterlegt, der private Teil des Schlüsselpaars am Mailserver implementiert.
Ablauf
Wenn eine E-Mail versendet wurde, fügt DKIM die sogenannte DKIM-Signatur zum Header der E-Mail hinzu.
Wenn die E-Mail empfangen wird, fragt der Empfänger-Mailserver den öffentlichen Schlüssel ab, der in der DNS-Zone der Sender-Domain veröffentlicht wurde. Mit diesem Schlüssel wird überprüft, ob die Signatur korrekt ist.
Wenn der öffentliche Schlüssel nicht zur Signatur passt, so kann dies folgende zwei Gründe haben:
Die E-Mail wurde nicht vom Mailserver gesendet, der im Mail-Header deklariert ist, sondern von einem anderen – betrügerischen – Server.
Die E-Mail wurde auf dem Weg vom „echten“ Mailserver zum Empfänger verändert.
DKIM kümmert sich also um die Integrität der E-Mail.
Wie macht man einen DKIM-Eintrag?
DKIM kann man bei guten Mailprovidern einfach aktivieren, vermutlich bei den Einstellungen zur Domain (konsultieren Sie bitte den Hilfe-Bereich Ihres Providers). Dabei wird das Schlüsselpaar erzeugt und der öffentliche Schlüssel in das DNS eingetragen. Der private Schlüssel wird bei Ihrem Mailserver (Abk: MTA) abgelegt.
Der Dateninhalt des öffentlichen Schlüssels sieht so ähnlich aus wie:
Bei DKIM kann man durchaus mehrere DKIM Einträge machen, die sich voneinander durch einen sogenannten Selector voneinander unterscheiden. Der Selector dient dazu, die öffentlichen DKIM-Schlüsseldetails der Domain für einen bestimmten Mailserver zu identifizieren. Er ist so etwas wie ein Name oder Namenszusatz des öffentlichen Schlüssels und wird ihm als Präfix vorangestellt.
Der Grund: Sie nutzen sowohl den Mailserver Ihres Hosting Providers für Ihre Mails, als auch gleichzeitig den Mailserver einer Newsletter-Plattform für Ihren Newsletter. Dann braucht es zwei DKIM Einträge im DNS für Ihre Domain. Mit dem Selector werden die beiden Einträge voneinander unterschieden.
Der DKIM Eintrag für CleverReach sieht üblicherweise etwa so aus: crsend._domainkey.IhreDomain.com
Das crsend ist der Selector dieses DKIM Eintrags.
Wie der vollständige TXT-Eintragname bei einem DMARC-Eintrag lautet, hängt also ganz von Ihrem (Mail-)Provider ab, bzw. vom Anbieter der Mailing-Plattform, für die Sie DKIM einrichten müssen (CleverReach, MailerLite, etc.).
MailerLite: litesrv._domainkey.[IhreDomain.com] (neue Version) oder ml._domainkey.[IhreDomain.com] (alte Version)
SendGrid: s1._domainkey.[IhreDomain.com]
MailChimp: k1._domainkey.[IhreDomain.com] und k2._domainkey.[IhreDomain.com]
Ersetzen Sie [IhreDomain.com] durch Ihren tatsächlichen Domain-Namen (oder Subdomain-Namen). Wenn es nur um den DKIM Eintrag für Ihren Hosting Provider geht (z.B. all-inkl, hostinger, hosttech, Strato, Hetzner, etc.), passiert der Eintrag auf Knopfdruck, das haben viele Provider so vorbereitet. Wenn Sie aber für einen Newsletter-Anbieter einen zusätzlichen DKIM Eintrag benötigen, dann erhalten Sie die komplette DKIM Information direkt bei diesem Newsletter-Anbieter.
Links zu DKIM-Anleitungen einiger gebräuchlicher Newsletter-Plattformen:
Es reicht also nicht, das Schlüsselpaar mit einem beliebigen Online Tool herzustellen, und dann nur den öffentlichen Schlüssel am Nameserver abzulegen. Es muss zwingend auch der private Schlüssel am Mailserver so hinterlegt werden, dass gemeinsam mit dem öffentlichen Schlüssel die DKIM Signatur erstellt werden kann. Das ist ganz klar eine Mailserver Einstellung Ihres Providers bzw. Newsletter-Anbieters.
Die Nutzung von Newsletter-Plattformen, wie MailChimp, mailerLite, CleverReach u.a. ist mittlerweile nur mehr möglich, wenn ein DKIM Eintrag für diese Plattform existiert.
Hinweis: der Inhalt des DKIM Abschnitts wurde aufgrund der Anmerkung eines Lesers (siehe Kommentar) überarbeitet. Vielen Dank für die korrigierende Info.
DMARC
Was ist ein DMARC Eintrag?
DMARC steht für Domain-based Message Authentication, Reporting and Conformance.
Mit DMARC können Sie Empfehlungen geben, wie ein Empfänger-Server bei Verstößen gegen SPF und DKIM mit einer E-Mail verfahren soll. Das lässt sich stufenweise regulieren mit bestimmten Parametern.
Wenn es weder einen SPF noch einen DKIM Eintrag gibt, dann ist ein DMARC-Eintrag für diese Domain nicht sinnvoll.
Sie haben die Möglichkeit sich bei Verstößen informieren zu lassen, wenn Sie den DMARC Eintrag entsprechend vornehmen.
Der Dateninhalt eines DMARC Eintrags im Domain Name System kann so aussehen:
v=DMARC1 ist fixer Bestandteil und darf nicht geändert werden.
p weist den Empfängerserver an, was mit Nachrichten passieren soll, die nicht authentifiziert werden konnten. Mögliche Werte sind none, quarantine und reject.
Mit rua nennen Sie die E-Mail-Adresse, an die Berichte zu DMARC-Aktivitäten für Ihre Domain gesendet werden. Tipp: legen Sie dafür eine eigene Mailbox an, etwa nach dem Schema dmarc-rua@ihre-domain.de
Mit ruf nennen Sie die E-Mail-Adresse, an die Fehlerberichte (auch forensische Berichte genannt) versendet werden sollen. Tipp: legen Sie dafür eine eigene Mailbox an, etwa nach dem Schema dmarc-ruf@ihre-domain.de
adkim und aspf legen die Abgleichrichtlinien für DKIM bzw. SPF fest. Darin ist definiert, wie genau Nachrichteninformationen mit DKIM-Signaturen bzw. SPF-Signaturen übereinstimmen müssen. s steht für »strenger Abgleich«, r für »lockeren Abgleich«.
Beispiel
Die folgende Konfiguration weist alle E-Mails zurück, die nicht mit Ergebnissen der DKIM- und SPF-Prüfung übereinstimmen. Darüber hinaus wird ein aggregierter Statusbericht an die E-Mail-Adresse postmaster@example.com gesendet.
Puh, das war jetzt doch ein wenig mehr Erklärung zur Technik, als ursprünglich vorgesehen. Verzeihen Sie mir bitte. Andererseits: so läuft es bei DMARC nun einmal ab.
Wie macht man einen DMARC-Eintrag?
Bei DMARC Einträgen gibt es, wie Sie eben gesehen haben, eine Reihe von Parametern (Wikipedia). Damit wird reguliert, auf welche Art der Empfänger mit einer Mail umgeht, die im Fall SPF und/oder DKIM nicht den Anforderungen entspricht.
Wenn Sie bereits SPF und DKIM eingerichtet haben, konfigurieren Sie DMARC, indem Sie den DNS-Einträgen Ihrer Domain die DMARC Richtlinien in Form von TXT-Einträgen hinzufügen (also genau so wie bei SPF oder DKIM).
Der TXT-Eintragname sollte bei einem DMARC-Eintrag lauten:
_dmarc.IhreDomain.com
Ersetzen Sie bitte “IhreDomain.com” durch Ihren tatsächlichen Domain-Namen (oder Subdomain-Namen).
Wie das daher in Ihrem konkreten Fall aussehen kann, das können Sie auch bei kompetenter Stelle nachfragen (bei Ihrem Domain/Mail-Provider), oder probieren es vorsichtig unter Zuhilfenahme von Anleitungen (s.o. unsere, bzw. s.u. bei Online-Tools) aus.
Sie werden dann an den angegebenen Mail-Adressen (rua, ruf) eher schwierig lesbare Berichte im XML-Format erhalten. Diese Berichte können Sie aber in ein Online DMARC-Berichtstool (Link weiter unten) hochladen, um eine verständliche Form des Berichts zu sehen.
DMARC-Bericht bei EASYDMARC
Ergebnis
Sind alle Einträge gemacht, kann das im Ergebnis so aussehen wie hier (Beispiel beim Provider Timme-Hosting):
Alle drei Einträge am Beispiel einer Domain bei Timme-Hosting
Wie das Bild zeigt, wird laut SPF Eintrag (erste Zeile) das Versenden über den Server crsend.com (CleverReach) ebenfalls zugelassen (der entsprechende CleverReach DKIM Eintrag ist hier nicht zu sehen).
Das default._domainkey in Zeile 2 für den DKIM-Eintrag gilt für den Provider im gezeigten Beispiel (Timme-Hosting). Bei Newsletter-Anbietern kommt hier sehr sicher ein weiterer Eintrag mit einem anderen Selector als default hinzu. Sehen Sie das bitte unbedingt in der Anleitung Ihres Newsletter-Anbieters nach.
Tools
Mit dem gewonnen Basis-Wissen können Sie auch diverse Tools und Generatoren bestens nutzen. Sehen Sie sich etwa die Tools der Plattform MX Toolbox an:
Das Thema Mail-Absicherung ist kein triviales Thema. Eine Standardvorgangsweise, bei der »blind« allgemein wirksame und gültige Einträge in irgendein Tool gemacht werden, gibt es hierfür leider nicht.
Wir freuen uns, wenn uns gelungen sein sollte, etwas Licht ins Dunkel zu bringen. Teilen Sie doch bitte Ihre Erfahrungen als Kommentar zum Beitrag mit.
Empfehlen Sie diesen Artikel weiter:
Heinz Duschanek
Heinz Duschanek hat 2003 die Online-Marketing Agentur E-Werkstatt gegründet. Da er vorher auch beim Radio gearbeitet hatte (Radio CD International, Ö1, Ö3), freut er sich jetzt ganz besonders über die Richtung, die das Online-Marketing nimmt. Denn das liefert einen Vorwand dafür, viele elektrischen Geräte und Gadgets rund um Audio und Video anzuschaffen.
Daneben interessiert sich Heinz auch für Tango Argentino, Lindy Hop, Wing-Tsun, Boxen, (Jazz-/Blues-)Gitarre. Und er betreibt den Podcast "Cabeceo - Gespräche über den Tango Argentino" (cabeceo.at) sowie den Onlineshop shop.cabeceo.at.
[…] haben uns über die Zustellbarkeit von Mail […]
Hallo Herr Duschanek,
Ihre Darstellung von DKIM ist leider sehr fehlerbehaftet. Ich glaube ja gerne, dass eine einfache Erklärung nicht ganz leicht ist – aber Ihre Behauptungen hier empfinde ich geradezu als gefährlich, da Sie Ihre Leser womöglich verleiten könnten auf wirksame Verschlüsselungsmethoden zu verzichten.
»[…] wird die E-Mail durch den Sender verschlüsselt, und durch den Empfänger entschlüsselt […]« ,
»DKIM kümmert sich also um Datenschutz (um das Nicht-mitlesen-können) […]«
Falsch!
Zwar wird für DKIM asymmetrische Kryptografie verwendet, jedoch *nur* um eine kryptografische Signatur der Email (genauer: eines Hashwertes derselben) zu erstellen.
Verschlüsselt wird da gar nichts, die Mail geht weiterhin im Klartext über die Leitung.
(Mal abgesehen von der -inzwischen glücklicherweise üblichen- Transportverschlüsselung (TLS), die aber eben auch nur die Verbindungen zwischen den beteiligten Computern, also z.B. vom PC zum Server, schützt.)
»Der private Schlüssel wird mit jeder Mail automatisch mit gesendet.« ,
»Es muss zwingend auch der private Schlüssel am Mailserver so hinterlegt werden, dass gemeinsam mit dem öffentlichen Schlüssel die ausgehenden Mails verschlüsselt werden können. Weiters muss der private Schlüssel mit den Mails mit gesendet werden, sodass ein Entschlüsseln der Mails beim Empfänger gemeinsam mit dem öffentlichen Schlüssel möglich ist.«
Auch dies ist falsch, *private* Schlüssel heißen nicht umsonst so: sie werden niemals weiter gegeben, denn nur sie ermöglichen das Signieren und ggf. (aber eben nicht hier bei DKIM) Entschlüsseln – eine Signatur ist aber nichts wert, wenn quasi Jeder über den privaten Schlüssel verfügt und somit Beliebiges signieren kann.
Der öffentliche Teil eines Schlüsselpaares dagegen erlaubt nun nur die Prüfung der Signatur, und wird in anderen Anwendungsfällen zur VERschlüsselung benutzt, aber niemals zum Signieren oder Entschlüsseln – daher kann er eben auch öffentlich sein.
Danke für die Info, ich habe berichtigt und verweise auf Ihren Kommentar.
Wir analysieren unsere Website zwecks Reichweitenmessung sowie Optimierung und Personalisierung von Inhalten und Werbung. Eingebundene Dritte führen diese Informationen ggf. mit weiteren Daten zusammen. Mehr dazu lesen Sie in der Datenschutzerklärung. Ihre vorgenommenen Einstellungen können Sie jederzeit über die Cookie-Richtlinie ändern. Mit der weiteren Nutzung dieser Website stimmen Sie – jederzeit widerruflich – dieser Datenverarbeitung durch den Seitenbetreiber und Dritte zu.
Einige Services verarbeiten personenbezogene Daten in den USA. Mit Ihrer Einwilligung zur Nutzung dieser Services stimmen Sie auch der Verarbeitung Ihrer Daten in den USA gemäß Art. 49 (1) lit. a DSGVO zu. Das EuGH stuft die USA als Land mit unzureichendem Datenschutz nach EU-Standards ein.
Hier können Sie ganzen Kategorien zustimmen oder diese ablehnen.
Funktional
Immer aktiv
Diese Cookies sind für die technische Funktion der Website unerläßlich. Diese dienen keinen Trackingzwecken.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Diese Cookies dienen der Erhebung von Daten zur statistischen Auswertung der Website-Besuche. Die Auswertung ermöglicht uns keine Rückführung auf konkrete Personen und deren Aktivitäten auf dieser Website.
Marketing
Diese Cookies ermöglichen das Führen anonymisierter Besucherprofile, damit wir den Besucher/innen personalisierte Werbung website-übergreifend zeigen können.
[…] haben uns über die Zustellbarkeit von Mail […]
Hallo Herr Duschanek,
Ihre Darstellung von DKIM ist leider sehr fehlerbehaftet. Ich glaube ja gerne, dass eine einfache Erklärung nicht ganz leicht ist – aber Ihre Behauptungen hier empfinde ich geradezu als gefährlich, da Sie Ihre Leser womöglich verleiten könnten auf wirksame Verschlüsselungsmethoden zu verzichten.
»[…] wird die E-Mail durch den Sender verschlüsselt, und durch den Empfänger entschlüsselt […]« ,
»DKIM kümmert sich also um Datenschutz (um das Nicht-mitlesen-können) […]«
Falsch!
Zwar wird für DKIM asymmetrische Kryptografie verwendet, jedoch *nur* um eine kryptografische Signatur der Email (genauer: eines Hashwertes derselben) zu erstellen.
Verschlüsselt wird da gar nichts, die Mail geht weiterhin im Klartext über die Leitung.
(Mal abgesehen von der -inzwischen glücklicherweise üblichen- Transportverschlüsselung (TLS), die aber eben auch nur die Verbindungen zwischen den beteiligten Computern, also z.B. vom PC zum Server, schützt.)
»Der private Schlüssel wird mit jeder Mail automatisch mit gesendet.« ,
»Es muss zwingend auch der private Schlüssel am Mailserver so hinterlegt werden, dass gemeinsam mit dem öffentlichen Schlüssel die ausgehenden Mails verschlüsselt werden können. Weiters muss der private Schlüssel mit den Mails mit gesendet werden, sodass ein Entschlüsseln der Mails beim Empfänger gemeinsam mit dem öffentlichen Schlüssel möglich ist.«
Auch dies ist falsch, *private* Schlüssel heißen nicht umsonst so: sie werden niemals weiter gegeben, denn nur sie ermöglichen das Signieren und ggf. (aber eben nicht hier bei DKIM) Entschlüsseln – eine Signatur ist aber nichts wert, wenn quasi Jeder über den privaten Schlüssel verfügt und somit Beliebiges signieren kann.
Der öffentliche Teil eines Schlüsselpaares dagegen erlaubt nun nur die Prüfung der Signatur, und wird in anderen Anwendungsfällen zur VERschlüsselung benutzt, aber niemals zum Signieren oder Entschlüsseln – daher kann er eben auch öffentlich sein.
Danke für die Info, ich habe berichtigt und verweise auf Ihren Kommentar.