DMARC.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein Kontrollsystem und kann, im Gegensatz zu SPF und DKIM, dem Empfänger-E-Mail-Server sagen, ob er die E-Mail bei fehlerhafter Prüfung auf SPF und/ oder DKIM annehmen oder ablehnen soll. Hier gilt es zusammen mit den Sicherheitsbeauftragten die Einstellungen für die eigene Domain zu treffen.

Entsprechende E-Mails, die durch die SPF- bzw. DKIM-Prüfung gefallen sind, werden entsprechend der Anweisung des DMARC gelöscht, zurückgewiesen oder in den Spam-Ordner verschoben. In diesem Zusammenhang besteht zusätzlich die Möglichkeit, dass der E-Mail Empfänger dem Domaininhaber über den Missbrauch und den Problemen mit der Authentifizierung durch den Versand eines Berichtes informiert. Der entsprechende Bericht wird dann an eine im DMARC Eintrag festgelegte E-Mailadresse versendet.

Domaininhaber erlangen durch die Nutzung eines DMARC Eintrages in deren DNS-Zone wichtige, zusätzliche Informationen. So erhalten Domaininhaber beispielsweise eine Auskunft darüber, wer versucht E-Mails im Namen des Domaininhabers zu versenden.

Doch wie erstellen Sie nun einen DMARC-Eintrag? Um einen DMARC-Eintrag zu konfigurieren, muss SPF und DKIM vorhanden sein. Um die Konfiguration von DMARC abzuschließen, müssen Sie den DNS-Einträgen Domain Richtlinien hinzufügen. Dies erfolgt in Form von TXT-Einträgen.

Für die Konfiguration der DMARC-Einträge werden nur die Tags v (Version)und p (Richtlinie) zwingend benötigt. Für den Tag p stehen folgende drei Einstellungen zur Verfügung:

• None policy: Bei dieser Einstellung werden keine Maßnahmen ergriffen. Die betroffenen Meldungen werden nur im Tagesbericht protokoliert.
• Quarantine policy: Nachrichten, die in diese Kategorie fallen, werden als Spam markiert.
• Reject policy: Wenn E-Mails in diese Richtlinie fallen, gelangen diese auf das SMTP-Schicht (Simple Mail Transfer Protocol).

Optional sind folgende Tags:

• pct: „pct“ gibt die Prozentzahl der nicht authentifizierten Nachrichten an, die der DMARC-Richtlinie unterliegen. Beim hinterlegten Prozentsatz muss es sich um eine ganze Zahl zwischen 1 und 100 sein. Wenn im DMARC-Eintrag diese Option nicht verwendet wird, gilt die DMARC-Richtlinie für alle Nachrichten, die von der Domain versendet werden.
• rua: „rua“ ist die E-Mail-Adresse, an die Berichte zu DMARC-Aktivitäten für die Domain gesendet werden. Die E-Mail-Adresse muss „mailto:“ enthalten. Es besteht auch die Möglichkeit, den Bericht an mehrere Adressen zu versenden. -
• ruf: Das Tag „ruf“ ist für den Versand von Fehlerberichten notwendig und wird auch forensische Bericht genannt.
• asdf: Das „asdf“ legt die Abgleichsrichtlinie für SPF fest. In dieser Option wird definiert, wie genau Nachrichteninformationen mit SPF-Signaturen übereinstimmen müssen.
• adkim: Das „adkim“ legt die Abgleichrichtlinie für DKIM fest. In dieser Option wird definiert, wie genau Nachrichteninformationen mit DKIM-Signaturen übereinstimmen müssen.
• sp: Die „sp“ legt die Richtlinie für Nachrichten fest, die über Subdomains der primären Domain gesendet werden. Wenn diese Option nicht verwendet wird, wird für die Subdomains die für die übergeordnete Domain festgelegte Richtlinie der DMARC übernommen.

Um DMARC möglichst genau auf Ihr Unternehmen anzupassen empfiehlt es sich, auch die optionalen Tags zu definieren. Gerne stehen unsere Experten Ihnen in diesem Zusammenhang zur Verfügung.

DKIM.

Hinter DKIM (DomainKeys Identified Mail) verbirgt sich eine erweiterte Methode zur Sender-Authentifizierung. Ähnlich wie SPF, hierzu kommen wir noch, soll DKIM helfen, unerwünschte E-Mails von den erwünschten zu unterscheiden. Die Methode ist vergleichbar mit einem Fingerabdruck: Der private Schlüssel auf dem Server des Absenders signiert jede E-Mail im Header. Diese digitalen Signaturen sind kryptografisch verschlüsselt und benötigen daher zum Entschlüsseln denselben Hashwert in der Prüfsumme, wie vor dem Versand errechnet wurde. Bereits kleine Änderungen der Signaturdaten verändert die Prüfsumme und lässt daher auf eine mögliche Fälschung schließen.

DKIM geht dabei wie folgt vor: Der empfangende Server ruft beim Nachrichteneingang zunächst den öffentlichen Schlüssel ab. Dieser befindet sich als TXT-Resource Record in der DNS-Zone der Absenderdomain. Im Anschluss wird mit dem öffentlichen Schlüssel vom empfangenden Server überprüft, ob die Signatur korrekt ist. Wenn die Schlüssel übereinstimmen, muss anhand des DMARC Eintrages vom System des Empfängers abgefragt werden, welche weiteren Verarbeitungsschritte im weiteren Verlauf erfolgen sollen.

SPF.

Mit dem Sender Policy Framework, kurz SPF, können Sie Absenderadress-Fälschungen vermeiden und ist ein Verfahren zur Sender-Authentifizierung. Das Verfahren hilft dem Empfänger-Server eine E-Mail, die von einem nicht zum Versand autorisierten E-Mail-Server gesendet wurde, zu erkennen. E-Mails, die gefälschte Internetadressen nutzen, können beispielsweise Spam- oder Phishing-Mails sein. SPF erkennt E-Mail Server, die nicht zum Versand im Namen einer Domain berechtigt sind.

Die Funktionsweise von SPF ist simpel: In der DNS-Zone einer Domäne wird ein spezieller TXT Ressource Record angelegt. Dieser legt fest, welche E-Mail Server im Namen der Domäne versenden dürfen. Der Empfänger kann prüfen, inwieweit der versendete Server die Versandrechte für die Absenderdomain besitzt. Hier muss beim Eingehen der E-Mail jedoch eine SPF-Prüfung durchgeführt werden. Wird ein E-Mail-Server nicht im Domain SPF Eintrag genannt, versendet jedoch E-Mails in deren Namen, so kann der empfangende E-Mail-Server diese ablehnen.

DANE.

Im Bereich der E-Mail-Sicherheit wird auch DANE, kurz für: DNS-based Authentication of Named Entities, genutzt. Bei DANE handelt es sich um ein in verschiedenen RFCs (kurz für Request for Comments) spezifiziertes Verfahren zur Prüfung von Serverzertifikaten mithilfe des Domain Name Systems. Gleichzeitig ist es durch DANE möglich, den per TLS (Transport Layer Security) und Zertifikate zum verschlüsselnden Verkehr so abzusichern, dass die Prüfung der Zertifikate nicht mehr von einer vertrauenswürdigen Zertifizierungsstelle abhängig ist. Bestehende Zertifikate können so nicht einfach ausgetauscht werden und erhöht somit die Sicherheit in Unternehmen gravierend. Klassischerweise wird DNS-based Authentification of Named Entitites (kurz: DANE) für den verschlüsselten Zugriff auf Webseiten oder dem verschlüsselten Austausch von E-Mails über SMTP eingesetzt.

DANE funktioniert wie folgt: DANE arbeitet mit sogenannten TLSA-Einträgen in der jeweiligen DNS-Zone. Im Eintrag sind Informationen zum Zertifikat in Form eines Hashwerts hinterlegt. Dadurch ist nur der Inhaber der Domain autorisiert Einträge zu verwalten. Eine entsprechende Manipulation der Einträge ist dadurch ausgeschlossen. Durch einen TLSA-Eintrag ist es möglich unter der entsprechenden Domain eine verschlüsselte Domain anzunehmen . Um nun ein Zertifikat zu überprüfen, kontaktiert der Client nicht mehr die CA, also die Certificate Authority, sondern den TLSA-Eintrag ab, in der die Domain mit dem Hashwert des Zertifikats hinterlegt ist. Dieser Austausch an DNS-Informationen wird mit DNSSEC gesichert. Zuletzt kann die per TLS verschlüsselte Verbindung aufgebaut werden.