Das zum Transport von E-Mails verwendete SMTP-Protokoll sieht keine Möglichkeit vor, die Absenderadresse einer E-Mail zu verifizieren. Grundsätzlich können also Absenderadressen beliebig gefälscht werden und man kann als Empfänger nicht wissen von wem eine E-Mail wirklich stammt. Dies erleichtert Betrugsversuche, Spam, Phishing und ähnliches.
DKIM wurde entwickelt um prüfen zu können, ob eine E-Mail wirklich vom angegebenen
Absender (From:-Kopfzeile) stammt. Das Protokoll sieht
dabei eine Prüfung auf Domain-Ebene vor, es ist also jeder Absenderdomain selbst überlassen,
ob und welche Mechanismen sie vorsieht, um Fälschungen innerhalb der Absenderdomain zu
verhindern. Als Empfänger kann man sich daher bei DKIM nur darauf verlassen, dass die Domain
stimmt, nicht aber auf die Adresse innerhalb der Domain.
Bei DKIM versieht der E-Mail-Server des Absenders jede versendete E-Mail mit einer
digitalen Signatur und fügt diese in eine zusätzliche Kopfzeile ein
(DKIM-Signature:). Gleichzeitig wird im DNS-Eintrag der
Domain der öffentliche Schlüssel, mit dem die Signaturen erstellt werden, publiziert. Jeder
Empfänger kann nun prüfen, ob die E-Mail wirklich mit dem richtigen Schlüssel signiert
wurde. Dies funktioniert unabhängig vom Server des Absenders. Die E-Mail kann daher über
beliebige Server verschickt oder weitergeleitet werden ohne die Prüfung zu
beeinträchtigen.
Grundsätzlich kann jeder Absender selbst entscheiden, ob er seine E-Mails mit DKIM signiert oder nicht. Dies erlaubt eine graduelle Einführung. Einige Empfänger oder deren E-Mail-Dienstleister haben sich aber entschieden, nicht signierte E-Mails generell abzulehnen. Dies übt Druck auf alle Absender aus, ihre E-Mails auch zu signieren, da sie sonst mit diesen Empfängern nicht mehr per E-Mail kommunizieren können.
Der Absender entscheidet bei DKIM welche Teile einer E-Mail er signiert und welche
nicht. Die Liste der in der Signatur enthaltenen Teile wird dabei zusammen mit der Signatur
im DKIM-Signature:-Header abgelegt und nicht zentral im DNS
gespeichert. Damit ist es möglich, jede E-Mail unterschiedlich zu signieren und z.B. für
einige Empfänger eine andere Konfiguration zu verwenden.
Grundsätzlich muss der From:-Header immer signiert
werden. Es wird aber dringend empfohlen zusätzlich auch
Date:, Subject:,
Reply-To:, Sender:, alle
MIME-Header, alle Content-Header und den eigentlichen Inhalt der E-Mail
(Body) zu signieren. Denn falls einem Angreifer eine E-Mail
mit gültiger Signatur in die Hand fallen sollte, kann er alle nicht signierten Teile
verändern, ohne dass die Signatur ungültig wird. Eine E-Mail bei der nur
From: signiert ist, entspäche dann einem Blanko-Scheck
und sollte daher vermieden werden. Im Intra2et System stehen mehrere Listen mit zu
signierenden Kopfzeilen vordefiniert im Menü
""
zur Verfügung.
Außer der Liste der signierten Teile enthält der
DKIM-Signature:-Header auch den sog.
Selector. Der Selector ist der Name des Eintrags des
öffentlichen Schlüssels im DNS und kann frei gewählt werden. Anhand des Selectors weiß der
Empfänger, woher er den Schlüssel zur Prüfung der Signatur bekommt. Es können mehrere
Selectoren für eine Domain gleichzeitig genutzt werden. Dies macht z.B. während einer
Umstellung oder bei Nutzung mehrerer E-Mail-Server Sinn.
SPF. ist ein alternativer Standard um Absender einer E-Mail zu verifizieren. Dabei wird eine Liste der IP-Adressen im DNS hinterlegt, die E-Mails für eine Domain versenden dürfen. Dies führt aber zu mehreren Problemen:
E-Mails können nicht mehr normal weitergeleitet werden, da der weiterleitende Server nicht auf der Liste der erlaubten IPs steht. Als Workaround ist das Sender Rewriting Scheme (SRS) vorgesehen, welches das Problem aber nur teilweise löst und neue Probleme mit sich bringt.
SPF prüft nur den auf SMTP-Ebene übertragenen Envelope Sender, nicht den
From:-Header der vom E-Mail-Programm des Empfängers angezeigt wird. Der Envelope Sender ist für den Empfänger nur über Umwege wie z.B. die Quelltext-Anzeige einsehbar.
Intra2net rät auf Grund dieser Nachteile von der Nutzung von SPF ab und empfiehlt DKIM zu verwenden.
DMARC. ist ein Standard, über den der Administrator einer Domain kommunizieren kann, dass alle von dieser Domain legitim versendeten E-Mails mit DKIM signiert sind oder die SPF-Anforderungen erfüllen müssen. Dies kann vom Empfänger genutzt werden, um alle E-Mails, die das nicht erfüllen abzulehnen. DMARC baut daher auf DKIM und/oder SPF auf.
Ein wichtiger Teil bei der Umsetzung von DKIM ist sicherzustellen, dass Außenstehende nicht in der Lage sind, sich gültige DKIM-Signaturen zu erschleichen. Dies ist vor allem denkbar im Zusammenhang mit E-Mail-Weiterleitungen, Sortierregeln, Verteilern, Webformularen und ähnlichem. Um dies zu verhindern, blockiert das Intra2net System automatisch alle von nicht vertrauenswürdigen Systemen eingehenden E-Mails ohne gültige DKIM-Signatur mit der eigenen Domain als Absender. Dadurch wird auch gleichzeitig die Fälschung der Absenderadresse für die eigene Domain verhindert.
Dies bedeutet aber, dass vor der Einführung von DKIM für alle legitimen E-Mail-Pfade die korrekte Signierung bedacht werden muss. Bedenken Sie hier vor allem externe Nutzer, die direkt auf den E-Mail-Provider zugreifen, Geräte wie Scanner und Drucker im lokalen Netz, E-Mails mit Status- oder Fehlerinformationen von Diensten wie Backupservern, NAS, USVs, Gebäudeautomatisierung und ähnlichem, automatisierte Reports wie z.B. von Arbeitszeiterfassung, Warenwirtschaft, Buchhaltung etc., sowie E-Mails von externen Webservern, wie z.B. Webshop, Kontaktformular und ähnlichem.
Über folgende Wege können E-Mails signiert werden:
Einlieferung der E-Mail am Intra2net System aus dem lokalen Netz per SMTP, Verschlüsselung der Verbindung mit TLS, Authentifizierung mit einem gültigen Benutzer. Der Benutzer muss Mitglied einer Gruppe sein, die das Recht zur SMTP-Authentifzierung aus dem lokalen Netz hat.
Einlieferung der E-Mail am Intra2net System aus dem lokalen Netz per SMTP, die IP des SMTP-Clients hat das Recht "" (siehe z.B. ""). TLS und Authentifizierung sind dann optional.
Einlieferung der E-Mail an einem anderen E-Mail-Server im lokalen Netz. Dieser Server macht zwar selbst keine DKIM-Signierung, leitet ausgehende E-Mails aber an das Intra2net System weiter.
Einlieferung der E-Mail am Intra2net System aus dem Internet per SMTP, Verschlüsselung der Verbindung mit TLS, Authentifizierung mit einem gültigen Benutzer. Der Benutzer muss Mitglied einer Gruppe sein, die das Recht zur SMTP-Authentifzierung aus dem Internet hat.
Einlieferung der E-Mail am Intra2net System per Activesync. Der Benutzer muss Mitglied einer Gruppe sein, die das Recht zur Nutzung von Activesync hat.
Einlieferung der E-Mail an einem anderen Server oder Dienst der auch E-Mails per DKIM signiert. Solche Dienste werden von einigen Webhosting- oder E-Mail-Providern angeboten. Dieser kann einen anderen gültigen DKIM-Selector verwenden als das Intra2net System. Ein solcher Dienst muss zwingend per DKIM signieren, die Nutzung von SPF ist nicht ausreichend, damit die E-Mails vom Intra2net System akzeptiert werden.
Stellen Sie sicher, dass jede E-Mail, die die eigene Domain im Absender verwendet, immer über einen der genannten Wege versendet wird.
Gehen Sie wie folgt vor um E-Mails mit DKIM zu signieren:
Stellen Sie sicher, dass die Voraussetzungen aus Abschnitt 15.8.4, „Voraussetzungen zur Nutzung“ erfülllt sind und prüfen dazu alle legitimen E-Mail-Pfade für die eigene Domain.
Legen Sie im Menü "" einen neuen Schlüssel vom Typ "" an. Wählen Sie einen beliebigen Namen bei "", beschränken sich aber auf Kleinbuchstaben und verwenden keine Leer- oder Sonderzeichen außer dem Bindestrich. Als Schlüssellänge wird 2048 Bit als guter Kompromiss zwischen Sicherheit, Rechenzeit und Datengröße im DNS empfohlen.
Legen Sie im Menü "" ein neues Profil an. Wählen Sie die eigene Domain als Absenderdomain aus und verwenden den eben erstellten DKIM-Schlüssel. Als Liste der zu signierenden Header wird empfohlen mit der Standardliste zu beginnen.
Lassen Sie das Profil unbedingt zuerst deaktiviert und speichern die Einstellungen. Nach dem Speichern wird im unteren Bereich des Menüs der nötige DNS-Eintrag für den Selector angezeigt.
Gehen Sie in das Verwaltungsportal des für die Domain zuständigen Providers. Meist ist dies der Provider, der auch für das Webhosting zuständig ist. Öffnen Sie dort die DNS-Verwaltung für die gewählte Absenderdomain.
Fügen Sie einen neuen Eintrag, Hostname oder Record vom Typ
TXThinzu. Der Name für den Eintrag ist dabei der Selector mit._domainkeyangehängt, so wie es im Menü des Intra2net Systems unter "" vorne angezeigt wird.Den Inhalt des Eintrags kopieren Sie auch aus der Anzeige des Intra2net Systems. Das genau geforderte Format unterscheidet sich hierbei zwischen den DNS-Providern. Denn der nötige Eintrag ist länger als 255 Zeichen und muss daher nach dem DNS-Standard aufgetrennt werden. Einige DNS-Provider nehmen diese Auftrennung selbst vor, bei anderen muss der Nutzer dies übernehmen. Über die Schaltfläche "" können Sie sich beide Varianten im Intra2net System anzeigen lassen. Auch ob die Anführungszeichen mit angegeben werden müssen oder nicht unterscheidet sich zwischen den DNS-Providern.
Menü eines DNS-Providers als Beispiel. Die Gestaltung variiert je nach DNS-Provider.
Wenn der DNS-Provider Ihnen die Möglichkeit dazu gibt, dann verwenden Sie zuerst eine kurze TTL (Time-to-Live, Gültigkeitsdauer) für den DNS-Eintrag aus, z.B. 5 Minuten bzw. 300 Sekunden. Dies ermöglicht Ihnen im Fall eines Konfigurationsfehlers diesen sofort zu korrigieren, ohne zuerst die lange Gültigkeitsdauer des falschen Eintrags abwarten zu müssen.
Speichern Sie den neuen DNS-Eintrag in der Oberfläche des DNS-Providers und warten bis der neue Eintrag auf den DNS-Servern publiziert ist. In den meisten Fällen ist dies nach wenigen Minuten abgeschlossen, die genaue Dauer variiert aber je nach DNS-Provider.
Klicken Sie im Intra2net System auf "" und starten die DKIM-Diagnose. Damit prüft das Intra2net System, ob der DKIM-Eintrag korrekt im DNS abrufbar ist. Im Fall eines Fehlers siehe Abschnitt 15.8.5.1, „Lösen von DKIM-Konfigurationsfehlern“.
Wenn die Diagnose erfolgreich durchgelaufen ist, können Sie das neue DKIM-Profil im Menü "" aktivieren. Ab dann werden alle E-Mails mit der eingestellten Absenderdomain signiert und unsignierte Mails von dieser Domain blockiert wenn Sie nicht von einem vertrauenswürdigen System kommen.
Sollte die Diagnose fehlschlagen, dann prüfen Sie abhängig von der genau angezeigten Fehlermeldung folgende Punkte.
Der DNS-Eintrag wurde nicht gefunden:
Prüfen Sie als erstes, ob der Eintrag evtl. vom DNS-Provider noch nicht aktualisiert wurde. Abhängig vom DNS-Provider kann dies zwischen wenigen Sekunden bis zu mehreren Stunden dauern. Dies sollte in der Dokumentation oder Verwaltungsoberfläche des DNS-Providers beschrieben sein.
Kontrollieren Sie als nächstes, ob die Absenderdomain auch lokal genutzt wird oder dorthin eine Weiterleitung besteht. In diesem Fall wird Ihnen der zuständige lokale DNS-Server in der Diagnoseausgabe mit angezeigt. Es empfielt sich den DKIM-Eintrag dann in diesem lokalen DNS-Server zusätzlich zu hinterlegen. Die Diagnose kann aber in diesem Fall ausschließlich den Eintrag im lokalen DNS-Server überprüfen und nicht den für andere im Internet sichtbaren.
Vergleichen Sie als nächstes die genaue Schreibweise des Eintrags / Hostnamens und den korrekten Typ "TXT" zwischen der Anzeige im Intra2net System und den Daten beim DNS-Provider.
Syntaxfehler oder falscher öffentlicher Schlüssel:
Vergleichen Sie den Inhalt des DNS-Eintrags zwischen den im Intra2net System angezeigten Daten und denen beim DNS-Provider. Die Daten dort müssen identisch sein. Achten Sie vor allem auf den Anfang und das Ende sowie auf Leerzeichen.
Wenn die Verwaltungsoberfläche des DNS-Providers mehrere Zeilen vorsieht, dann verwenden Sie Darstellung mit aufgetrennten Zeilen, wenn sie nur eine Zeile vorsieht dann ohne.
Probieren Sie Anführungszeichen am Anfang und Ende wegzulassen oder hinzuzufügen.
Evtl. bietet die Verwaltungsoberfläche des DNS-Providers die Möglichkeit zur Diagnose die komplette DNS-Zonendatei anzeigen zu lassen oder herunterzuladen. Dies kann hilfreich sein um Übertragungsfehler zu erkennen. Eine standardkonforme Zonendatei sollte den Eintrag exakt in der Form enthalten, wie sie im Intra2net System mit aktiviertem "" angezeigt wird.
Beachten Sie, dass wenn Sie einen einmal beim DNS-Provider erstellten Eintrag abrufen und danach dort wieder ändern, der alte Wert normalerweise noch im DNS-Cache für die hinterlegte TTL / Gültigkeitsdauer zwischengespeichert bleibt. Warten Sie daher erst den Ablauf der TTL ab, bevor Sie die Diagnose erneut starten.
Abhängig von den verwendeten DNS-Servern können Sie diese Wartezeit umgehen, indem Sie den DNS-Cache des Intra2net Systems im Menü "" leeren. Das ist aber nur möglich wenn das Intra2net System als eigentständiger DNS-Resolver die Root Nameserver befragt und nicht andere DNS-Resolver verwendet.
Nach der Aktivierung von DKIM für eine Absenderdomain muss das Intra2net System alle E-Mails, die vorgeben von dieser Domain zu kommen, aber nicht DKIM-signiert sind oder von einem vertrauenswürdigen System stammen, blockieren. Dies ist notwendig, um das Erschleichen von Signaturen zu verhindern, siehe Abschnitt 15.8.4, „Voraussetzungen zur Nutzung“.
Auf diese Weise blockierte E-Mails landen standardmäßig in der DKIM/DMARC-Quarantäne. Diese Quarantäne ist unter "" zu finden. Dort können die E-Mails eingesehen, untersucht und fälschlicherweise gefilterte E-Mails wieder freigegeben werden.
Unter "" können Sie das Verhalten des Filters steuern. Es wird empfohlen, diese E-Mails für einige Wochen nach Einführung von DKIM zuerst unter Quarantäne stellen zu lassen. Während dieser Zeit kann der Administrator sicherstellen, dass tatsächlich alle E-Mail-Pfade der eigenen Domain korrekt konfiguriert sind, ohne dass E-Mails versehentlich abgelehnt und gelöscht werden. Im Fehlerfall können diese E-Mails dann über einen der in Abschnitt 15.8.4, „Voraussetzungen zur Nutzung“ beschriebenen Wege umgeleitet werden.
Ruft das Intra2net System von außen eingehende E-Mails per POP von einem E-Mail-Provider ab (siehe Menü ""), dann muss die Quarantäne dauerhaft genutzt werden, da die zu blockierenden E-Mails schon durch den E-Mail-Provider angenommen wurden wenn sie am Intra2net System ankommen. Um sie auf SMTP-Ebene abzulehnen ist es dann schon zu spät.
Werden von extern eingehende E-Mails dagegen per SMTP empfangen und zeigt der MX-Eintrag der E-Mail-Domain auf das Intra2net System, dann empfiehlt es sich, nach einer Einführungzeit von einigen Wochen die Aktion für unsignierte E-Mails auf Ablehnen umzustellen. Dann fallen die Benachrichtigungsemails für unter Quarantäne gestellte E-Mails an den Administrator weg.
Unter "" können Listen mit den zu signierenden E-Mail-Kopfzeilen konfiguriert werden. Normalerweise empfiehlt es sich das vordefinierte Standardprofil zu verwenden, da dort alle relevanten Header enthalten sind und es damit einem potentiellen Angreifer sehr schwer gemacht wird, E-Mails zu verfälschen oder bestehende Signaturen zu missbrauchen.
Allerdings kann es vorkommen, dass ein Server zwischen Absender und bestimmten Empfängern E-Mails legitim verändert und dadurch die Prüfung der DKIM-Signatur dann beim endgültigen Empfänger der E-Mail fehlschlägt. Dies passiert z.B. wenn Kennzeichnungen wie "[extern]" in den Betreff eingefügt werden oder eine Mailingliste genutzt wird, die ihren Namen in den Betreff einfügt oder eine Kurzanleitung zur Nutzung an den E-Mail-Text anhängt. Für diese Fälle bietet das Intra2net System die Möglichkeit für bestimmte Empfänger Ausnahmereglen zu definieren und dort weniger Header zu signieren.
Wählen Sie dafür zuerst unter "" eine passende Liste von Headern aus oder legen eine neue an. Gehen Sie danach ins Menü "" und legen ein neues Empfänger-Profil an. Tragen Sie entweder eine gesamte Empfänger-Domain ein oder eine einzelne Empfänger-E-Mail-Adresse. Wählen Sie die gewünschte Header-Liste aus und speichern.
Dann wird für alle E-Mails, die an die eingestellte Empfänger-E-Mail-Adresse oder -Domain gehen sollen und deren Absenderadresse in einer Domains liegt, für die ein DKIM-Profil aktiv ist, die im Empfänger-Profil hinterlegte Einstellung übernommen. Diese hat also Vorrang vor den Einstellungen für die Absenderdomain.
Da der Absenderserver die Liste der zu signierenden Header frei auswählen kann, ist hierfür keine Änderung im DNS oder dem Selector nötig.
Der zu einem DKIM-Selector gehörende Schlüssel kann prinzipiell zeitlich unbegrenzt verwendet werden. In einigen Fällen sollte der Schlüssel aber unverzüglich durch einen neuen ersetzt werden:
Es wird Missbrauch des Schlüssels durch andere eindeutig erkannt oder vermutet
Ein Server, auf dem der private Schlüssel gespeichert war, wurde von nicht autorisierten Personen infiltriert oder dies zumindest vermutet
Ein Mitarbeiter, der Zugriff auf den privaten Schlüssel hatte, hat das Unternehmen verlassen
Einem Dienstleister, wie z.B. IT-Dienstleiser, Webhosting-Provider oder E-Mail-Provider, bei dem der private Schlüssel gespeichert war, wurde gekündigt
Über diese Ereignisse hinaus empfiehlt es sich die Schlüssel alle 1 bis 5 Jahre zu rotieren, um ein Brechen des Schlüssels mit viel Rechenleistung zu verhindern und die Schlüssellänge an den jeweiligen Stand von Wissenschaft und Technik anzupassen.
Gehen Sie zum Rotieren des Schlüssels wie folgt vor:
Legen Sie im Menü "" einen neuen Schlüssel vom Typ "" an. Verwenden Sie einen anderen Selector als beim bisherigen Schlüssel.
Legen Sie im Menü "" ein neues Profil an. Tragen Sie die selbe Absenderdomain ein, verwenden Sie den neuen Schlüssel und lassen das neue Profil unbedingt zuerst deaktiviert.
Konfigurieren Sie den neuen DNS-Eintrag zusätzlich beim DNS-Provider, lassen dort den bisherigen DNS-Eintrag bestehen und starten danach die DKIM-Diagnose. Siehe Abschnitt 15.8.5, „Konfiguration“ für eine detaillierte Beschreibung.
Wenn die Diagnose erfolgreich war, aktivieren Sie die Warteschlange im Menü "".
Deaktivieren Sie das bisherige DKIM-Profil und aktivieren das neue. Lassen Sie das bisherige Profil weiterhin bestehen und löschen es noch nicht. Beide Änderungen werden zuerst in der Warteschlange vorgemerkt und noch nicht sofort wirksam.
Führen Sie jetzt die Warteschlange aus, um nahtlos vom alten auf das neue Profil umzuschalten.
Da noch mit dem alten Profil signierte E-Mails unterwegs sein können und später vom Empfänger geprüft werden können müssen, muss das Profil und der zugehörige DNS-Eintrag weiterhin bestehen bleiben. Im Menü "" wird das frühestmögliche Löschdatum angezeigt.