SPF, DKIM und DMARC – Einstellungen für den Mailversand

Seit einiger Zeit stellen Anbieter für E-Mail Postfächer wie Google neue Anforderungen an Versender, damit E-Mails nicht im Spam landen oder zurückgewiesen werden¹. Wer also E-Mails an einen Empfänger mit einer Google-Mail-Adresse senden möchte, muss zumindest die Techniken SPF oder DKIM eingerichtet haben. Wer Massen-E-Mails versenden möchte (beispielsweise Newsletter), muss SPF, DKIM und DMARC eingerichtet haben. Was diese Techniken genau sind und wie man die Einrichtung vornimmt, soll hier kurz erklärt werden.

Zwar finden sich in den erwähnten Richtlinien noch weitere Punkte, die beachtet werden sollten, jedoch sind diese meist nur für größere Infrastrukturen oder Newsletter relevant und oft bereits vorkonfiguriert. Ein Blick in die Richtlinien lohnt sich daher, geht aber über den Inhalt dieses Beitrags hinaus.

SPF (Sender Policy Framework) – Ein Schutzschild gegen E-Mail-Spoofing

Das Sender Policy Framework² (früher Sender Permitted From) soll dabei helfen, das Fälschen von Absenderadressen (E-Mail-Spoofing) zu erschweren. Beim E-Mail-Spoofing nutzen Angreifer gefälschte Absenderadressen, um Phishing-Angriffe oder Spam zu verbreiten.

Wie funktioniert SPF

Einfach gesagt listet der Domaininhaber mit einem SPF-Record im Domain Name System (DNS) die autorisierten Mailserver auf, die E-Mails im Namen der Domain versenden dürfen. Wenn ein E-Mail-Server eine Nachricht empfängt, überprüft er diesen SPF-Record und vergleicht die IP-Adresse des absendenden Servers mit den autorisierten Servern. Stimmt die Adresse überein, wird die E-Mail als legitim eingestuft. Andernfalls kann sie als verdächtig markiert oder abgelehnt werden.

Obwohl SPF eine wirksame Schutzmaßnahme ist, gibt es auch Einschränkungen:

• SPF schützt nur vor gefälschten Absenderadressen, nicht vor Phishing-Inhalten in legitimen E-Mails.
• SPF funktioniert nicht, wenn eine E-Mail weitergeleitet wird, da sich die Absender-IP ändert.
• SPF sollte idealerweise mit DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting & Conformance) kombiniert werden, um einen umfassenderen Schutz zu gewährleisten.

Beispieleintrag

Um einen entsprechenden SPF-Record anzulegen, kann der Inhaber einer Domain im DNS einen TXT-Eintrag setzen, der die Adressen der zum Versand von E-Mails berechtigten Mail Transfer Agents (MTA) auflistet. Ein typischer Eintrag könnte folgendermaßen aussehen:

v=spf1 ip4:192.168.1.1 include:mailserver.com -all

• Ein SPF-Record beginnt zunächst mit einer Versionsnummer. Für die aktuelle SPF-Version ist dies v=spf1
• Der Eintrag ip4 gibt an, dass eine nachfolgende IPv4-Adresse dazu berechtigt ist E-Mails zu versenden, in diesem Falle die Adresse 192.168.1.1. Dieser Teil des Eintrags heißt Mechanismus. Eine Übersicht der Mechanismen findet sich beispielsweise unter http://www.open-spf.org/SPF_Record_Syntax/. Bei dem Teil include:mailserver.com handelt es sich ebenfalls um einen Mechanismus. Dieser gibt an, dass zusätzlich die Mailserver, die in den SPF-Einträgen der Domain mailserver.com definiert sind, als berechtigte Absender gelten.
• Wenn ein Mechanismus ein positives Ergebnis zurück gibt, wird dessen Qualifikator genutzt (Standard: +/Pass), wobei die Mechanismen der Reihe nach abgearbeitet werden. Falls es keine Übereinstimmungen gibt ist der Standard Neutral. Damit nun alle nicht explizit autorisierten Server als nicht legitim betrachtet werden wird entsprechend der Eintrag -all gesetzt (Fail).

SPF Einrichten

Über die entsprechenden DNS-Einträge kann SPF konfiguriert werden. Die Einstellungsmöglichkeiten lassen sich in Kurzform der folgenden Übersicht entnehmen. Oftmals unterstützen Webhoster, die managed Webhosting anbieten, die automatische Einrichtung.

Übersicht Mechanismen

Mechanismus	Bedeutung
all	Gilt für alle Absender, die nicht von vorherigen Mechanismen erfasst wurden. Wird fast immer am Ende des SPF-Records genutzt.
ip4	Erlaubt eine bestimmte IPv4-Adresse oder ein ganzes Subnetz.
ip6	Funktioniert wie ip4, aber für IPv6-Adressen.
a	Erlaubt alle IP-Adressen, die mit dem A- oder AAAA-Record der Domain übereinstimmen.
mx	Erlaubt alle IP-Adressen, die im MX-Record der Domain definiert sind.
ptr	Prüft, ob die IP-Adresse zu einem Hostnamen der angegebenen Domain aufgelöst wird. Wird nicht empfohlen, da es ineffizient und unsicher ist.
exists	Falls der angegebene Hostname existiert, gilt die Prüfung als erfolgreich.
include	Bindet den SPF-Record einer anderen Domain ein. Falls die enthaltene Domain keinen passenden SPF-Eintrag hat, schlägt der Check fehl. include gilt nur als erfolgreich, wenn einer der Mechanismen innerhalb des enthaltenen SPF-Records matcht.

Übersicht Qualifikatoren

Qualifikator	Bedeutung
+	Pass
-	Fail
~	SoftFail
?	Neutral

Übersicht Modifikatoren

Zusätzlich gibt es noch die Modifikatoren redirect (leitet die SPF-Prüfung an einen anderen SPF-Record weiter) und exp (gibt eine benutzerdefinierte Fehlermeldung zurück, wenn die SPF-Prüfung fehlschlägt); diese sind optional.

SPF-Einträge prüfen

Es gibt diverse Onlinetools, mit denen SPF-Einträge geprüft werden können, biespielsweise https://mxtoolbox.com/spf.aspx.

DKIM (DomainKeys Identified Mail) – Eine zusätzliche Schutzschicht

Während SPF sicherstellt, dass E-Mails von autorisierten Servern stammen, geht DKIM³ noch einen Schritt weiter, indem es die Integrität der Nachricht überprüft. DKIM verwendet digitale Signaturen, die im Header einer E-Mail hinterlegt sind, um zu bestätigen, dass die Nachricht während der Übertragung nicht manipuliert wurde. Das Verfahren basiert auf asymmetrischer Kryptographie⁴.

Wie funktioniert DKIM

1. Der absendende Mailserver signiert ausgehende E-Mails mit einem privaten Schlüssel.
2. Die Signatur wird im Header der E-Mail gespeichert.
3. Der empfangende Mailserver überprüft die Signatur, indem er den dazugehörigen öffentlichen Schlüssel aus dem DNS der absendenden Domain abruft und damit die Signatur prüft.
4. Wenn die Signatur gültig ist, wird die E-Mail als authentisch eingestuft.

Einschub assymetrische Kryptographie

DKIM basiert, wie zuvor erwähnt, auf asymmetrischer Kryptographie, einem Verfahren, bei dem verschiedene Schlüssel verwendet werden: private und öffentliche Schlüssel. Hierbei ist es wichtig, dass der private Schlüssel privat bleibt, also nur dem Absender bekannt ist, und der öffentliche Schlüssel entsprechend öffentlich – in diesem Fall über DNS – abgerufen werden kann. Üblicherweise läuft asymmetrische Kryptographie wie folgt ab:

1. Ein Sender erstellt ein Schlüsselpaar: einen privaten und einen öffentlichen Schlüssel.
2. Mit dem privaten Schlüssel kann eine Nachricht signiert werden. Alternativ kann mit dem öffentlichen Schlüssel eines Empfängers eine Nachricht verschlüsselt werden.
3. Der öffentliche Schlüssel wird an den Empfänger weitergegeben oder öffentlich zugänglich gemacht. Beispielsweise indem dieser in einer signierten oder verschlüsselten Nachricht enthalten oder öffentlich zugänglich ist.
4. Der Empfänger kann die Signatur der Nachricht mit dem öffentlichen Schlüssel des Senders überprüfen, oder mit seinem privaten Schlüssel entschlüsseln.

Der große Vorteil asymmetrischer Kryptographie liegt darin, dass der öffentliche Schlüssel frei verteilt werden kann, ohne die Sicherheit zu gefährden, solange der private Schlüssel geheim bleibt. Bei der symmetrischen Kryptographie (bei der beide Partner dasselbe geheime Passwort kennen) müssen die Kommunikationspartner zunächst ein Passwort austauschen. Dafür ist bereits ein sicherer Kanal notwendig, denn ein Angreifer könnte mit dem geheimen Passwort direkt den Inhalt der Nachrichten entschlüsseln.

Dieses Verfahren wird in verschiedenen Sicherheitsanwendungen genutzt, darunter TLS/SSL (zur sicheren Internetkommunikation), digitale Signaturen und Verschlüsselungstechnologien wie PGP oder RSA.

Beispieleintrag

Ein DKIM-Eintrag im DNS sieht typischerweise so aus:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq…"

• default._domainkey – Der spezifische Selector für den DKIM-Schlüssel.
• v=DKIM1 – Gibt an, dass es sich um einen DKIM-Eintrag handelt.
• k=rsa – Gibt an, dass RSA als Verschlüsselungsverfahren verwendet wird.
• p=MIGfMA0GCSq... – Der öffentliche Schlüssel, der zur Überprüfung der Signatur dient.

Die meisten detailierteren Informationen zu den möglichen Tags setzt ein wenig Wissen im Ablauf von assymetrischer Kryptographie vorraus. Die Details zu dem Aufbau eines Eintrags lassen sich unter anderem RFC6376 entnehmen.

DKIM einrichten

Um DKIM einzurichten, ist es entsprechend notwendig die beschriebenen zwei Schlüssel zu generieren, einen privaten und einen öffentlichen. Der öffentliche Schlüssel muss über das DNS hinterlegt sein, der private Schlüssel im Mailprogramm eingebunden werden. Es gibt online diverse Anleitungen zur Einrichtung, beispielsweise unter https://www.mailhardener.com/kb/how-to-create-a-dkim-record-with-openssl. Es ist dabei nicht zwingend notwendig einen kostenpflichtigen Dienst zu nutzen, eine kostenlose Alternative sind beispielsweise (wie dort beschrieben) selbsterstellte OpenSSL-Schlüsselpaare. Oftmals unterstützen Webhoster, die managed Webhosting anbieten, die automatische Einrichtung.

DKIM-Einträge prüfen

Wie bei SPF gibt es auch hier diverse Onlinetools, beispielsweise https://www.mailhardener.com/tools/dkim-validator.

DMARC – Die Kombination aus SPF und DKIM

Domain-based Message Authentication, Reporting and Conformance⁵ (DMARC) kombiniert diese beiden Techniken, indem es die Ergebnisse der SPF- und DKIM-Überprüfung nutzt und eine Richtlinie definiert, die bestimmt, wie mit E-Mails umgegangen werden soll, die diese Prüfungen nicht bestehen.

Um DMARC für eine Domain zu implementieren, muss der Domaininhaber einen speziellen DNS-Eintrag erstellen, der die DMARC-Richtlinien definiert. Dieser Eintrag gibt an, wie die E-Mails der Domain überprüft werden sollen und welche Maßnahmen bei fehlerhaften Authentifizierungen ergriffen werden sollen. Hierfür ist es zunächst notwendig, dass SPF und DKIM korrekt konfiguriert wurden. Der DMARC-Eintrag enthält auch eine Adresse für die Berichterstattung, sodass Domaininhaber regelmäßig Berichte über die E-Mail-Authentifizierung ihrer Domain erhalten. Diese Richtlinie kann eine der folgenden Optionen umfassen:

• None (keine Maßnahme): Die E-Mail wird einfach überprüft, aber es werden keine Maßnahmen ergriffen, wenn sie die Prüfungen nicht besteht. Diese Option wird oft zu Testzwecken verwendet.
• Quarantine (in Quarantäne stellen): E-Mails, die die Prüfungen nicht bestehen, werden als verdächtig eingestuft und in den Spam-Ordner des Empfängers verschoben.
• Reject (ablehnen): E-Mails, die die Prüfungen nicht bestehen, werden komplett abgelehnt und erreichen den Empfänger nicht.

Es ist wichtig, DMARC richtig zu konfigurieren, da eine falsche Implementierung dazu führen kann, dass legitime E-Mails blockiert oder fälschlicherweise als Spam markiert werden.

Beispieleintrag

v=DMARC1; p=reject; rua=mailto:dmarc-reports@meinedomain.com; ruf=mailto:dmarc-forensic@meinedomain.com; sp=none; adkim=s; aspf=s; pct=100

• v=DMARC1 – Dies gibt die Version des DMARC-Protokolls an. In diesem Fall ist es DMARC1, was die aktuelle Version ist. Dieser Teil ist notwendig, damit der DMARC-Eintrag korrekt interpretiert wird.
• p=reject – Hier wird die Richtlinie für den Umgang mit E-Mails festgelegt, die die DMARC-Authentifizierung nicht bestehen. In diesem Fall bedeutet reject, dass E-Mails, die die SPF- und/oder DKIM-Authentifizierung nicht bestehen, komplett abgelehnt werden und nicht zugestellt werden.
• rua=mailto:dmarc-reports@meinedomain.com – Dies gibt an, wohin Aggregierte Berichte gesendet werden sollen. Diese Berichte liefern statistische Informationen zu den E-Mails, die für die Domain gesendet wurden, und zeigen an, wie viele dieser E-Mails die DMARC-Authentifizierung bestanden haben oder nicht.
• ruf=mailto:dmarc-forensic@meinedomain.com – Dies gibt an, wohin Forensische Berichte gesendet werden sollen. Diese Berichte sind detaillierter und enthalten Informationen zu spezifischen E-Mails, die die DMARC-Authentifizierung nicht bestanden haben. Sie werden in der Regel nur gesendet, wenn eine E-Mail ernsthaft gegen die Richtlinie verstößt.
• sp=none – Dies gibt an, wie strikt die DKIM-Authentifizierung geprüft wird. adkim=s bedeutet strict, was bedeutet, dass die DKIM-Signatur mit der Domain exakt übereinstimmen muss. Bei einer relaxed-Einstellung (adkim=r) kann die Subdomain auch die Signatur durchgehen, solange der Domainname übereinstimmt.
• aspf=s – Ähnlich wie bei DKIM gibt dieser Wert die Striktheit der SPF-Authentifizierung an. aspf=s bedeutet strict, was bedeutet, dass die Absenderdomain exakt mit der SPF-Einstellung übereinstimmen muss. Bei relaxed (aspf=r) könnte auch eine Subdomain erlaubt sein.
• pct=100 – Dieser Wert gibt an, wie viel Prozent der E-Mails einer Domain überprüft werden sollen. pct=100 bedeutet, dass 100 % der E-Mails auf DMARC-Richtlinien geprüft werden, was normalerweise die bevorzugte Option ist. Es könnte auch eine Zahl wie pct=50 geben, die bedeutet, dass nur 50 % der E-Mails überprüft werden (oft zu Testzwecken).

DMARC einrichten

Nachdem SPF und DKIM korrekt konfiguriert wurden muss ein entsprechender DNS Eintrag gesetzt werden, der die Konfiguration festlegt. Dazu können verschiedene Tags verwendet werden. Mögliche Werte für die Tags finden sich beispielsweise im Wikipedia Artikel oder auch im RFC7489.

Übersicht der Tags

Tag	Bedeutung
adkim	Legt fest, wie strikt die DKIM-Authentifizierung überprüft wird. Es bestimmt, ob die Domain in der DKIM-Signatur genau übereinstimmen muss.
aspf	Legt fest, wie strikt die SPF-Authentifizierung überprüft wird. Es bestimmt, ob die Absenderdomain in der SPF-Überprüfung genau übereinstimmen muss.
fo	Dieser Tag gibt an, unter welchen Bedingungen ein forensischer Bericht erstellt werden soll, wenn eine E-Mail die DMARC-Überprüfung nicht besteht.
p	Legt die Richtlinie fest, wie mit E-Mails umgegangen werden soll, die die DMARC-Überprüfung (SPF und/oder DKIM) nicht bestehen.
pct	Gibt den Prozentsatz der E-Mails an, die von der DMARC-Richtlinie betroffen sein sollen. Dies kann verwendet werden, um die DMARC-Überprüfung schrittweise einzuführen.
rf	Legt das Format für die forensischen Berichte fest.
ri	Gibt das Intervall in Sekunden an, wie oft die aggregierten DMARC-Berichte gesendet werden sollen.
rua	Gibt die Adresse(n) an, an die aggregierte DMARC-Berichte gesendet werden sollen. Diese Berichte enthalten zusammengefasste Daten zur E-Mail-Authentifizierung.
ruf	Gibt die Adresse(n) an, an die forensische DMARC-Berichte gesendet werden sollen. Diese Berichte sind detaillierter und bieten spezifische Informationen zu E-Mails, die die DMARC-Überprüfung nicht bestanden haben.
sp	Legt die DMARC-Richtlinie für Subdomains fest. Wenn nicht angegeben, erbt die Subdomain die Richtlinie der Hauptdomain.
v	Dieser Tag muss immer vorhanden sein und gibt an, dass es sich um einen DMARC-Eintrag der Version 1 handelt (derzeit die einzige Version): v=DMARC1

Zwingend erforderlich sind mindestens die Tags p und v, alle anderen sind optional und haben Standardwerte, wenn nicht anders angegeben.

DMARC-Einträge prüfen

Auch hier gibt es wieder verschiedene Onlinetools wie https://mxtoolbox.com/dmarc.aspx.

Zusammenfassung

SPF definiert, welche Server E-Mails für eine bestimmte Domain versenden dürfen. DKIM ermöglicht das digitale Signieren von E-Mails. DMARC baut auf SPF und DKIM auf und legt fest, wie E-Mails behandelt werden sollen, die diese Prüfungen nicht bestehen. Die wichtigsten Eigenschaften der Standards werden an der folgenden Tabelle aufgezeigt:

Standard	Vertraulichkeit (Schutz vor unbefugtem Zugriff auf den Nachrichteninhalt)	Integrität (Schutz vor Manipulation der Nachricht)	Authentizität (Echtheitsprüfung des Absenders)*	Verbindlichkeit (Nachweisbarkeit des Absenders)**
SPF	❌ Keine Verschlüsselung – SPF definiert nur erlaubte Absender-Server, schützt aber nicht den Inhalt der E-Mail.	❌ Keine Sicherung des Nachrichtentextes – SPF überprüft nur, ob ein Server E-Mails für eine Domain senden darf, aber nicht, ob der Inhalt verändert wurde.	✅ Überprüfung der IP-Adresse des sendenden Servers anhand eines DNS-Eintrags, um festzustellen, ob der Server berechtigt ist, E-Mails für die Domain zu versenden.	❌ SPF überprüft nur, ob eine IP-Adresse berechtigt ist, E-Mails für eine Domain zu senden. Es gibt keine digitale Signatur oder kryptografische Sicherung, die beweisen könnte, dass eine bestimmte E-Mail von einer bestimmten Person stammt.
DKIM	❌ Keine Verschlüsselung – DKIM signiert die Nachricht, schützt aber nicht davor, dass der Inhalt von Dritten gelesen wird.	✅ Digitale Signatur sichert, dass der Inhalt der Nachricht nicht verändert wurde, solange sie sich zwischen Sender und Empfänger bewegt.	✅ DKIM verwendet eine kryptografische Signatur, um nachzuweisen, dass die E-Mail von einer bestimmten Domain stammt. Der öffentliche Schlüssel zur Verifikation wird per DNS veröffentlicht.	❌ DKIM beweist nur, dass die E-Mail von einer autorisierten Quelle signiert wurde – es bestätigt nicht, dass eine bestimmte Person sie tatsächlich versendet hat. Zudem können DKIM-Schlüssel rotiert oder aus dem DNS entfernt werden.
DMARC	❌ Keine Verschlüsselung – DMARC baut auf SPF und DKIM auf, bietet aber selbst keine Schutzmechanismen für den Nachrichteninhalt.	✅ DMARC setzt auf SPF und DKIM, um sicherzustellen, dass die E-Mail während der Übertragung nicht verändert wurde.	✅ DMARC prüft, ob die Absenderadresse (From-Header) mit SPF und/oder DKIM übereinstimmt, um Spoofing zu verhindern.	❌ DMARC selbst führt keine neuen kryptografischen Mechanismen ein, sondern setzt auf SPF und DKIM. DMARC bietet keine Möglichkeit, den Absender kryptografisch zweifelsfrei zu identifizieren oder einen langfristigen Beweis zu liefern.

* Bezogen auf einen beliebigen Absender mit einer E-Mail, die Teil der Domain ist.
** Bezogen auf eine eindeutige Person.

Zwar helfen SPF, DKIM und DMARC dabei, dass die E-Mails korrekt zugestellt werden und häufige Angriffe wie Mail-Spoofing verhindert werden, jedoch gibt es keine Vertraulichkeit und keine Verbindlichkeit in Bezug auf den tatsächlichen Absender. Es wird zwar sichergestellt, dass nur berechtigte Sender E-Mails versenden dürfen und diese E-Mails auch nicht beim Transport verändert werden, allerdings können Dritte den Inhalt der E-Mail auf dem Transportweg weiterhin mitlesen, und es ist nicht eindeutig klar, welcher berechtigte Sender letztendlich eine E-Mail über den Mailserver versendet hat. Hier können jedoch weitere Techniken wie E-Mail-Verschlüsselung (z.B. S/MIME⁶ oder PGP⁷) weiterhelfen, da so der Inhalt der Nachricht verschlüsselt wird und der Absender eindeutig als Inhaber einer Mailadresse identifiziert werden kann.

Weitere Informationen

1. https://support.google.com/a/answer/81126?hl=de ↩︎
2. https://de.wikipedia.org/wiki/Sender_Policy_Framework ↩︎
3. https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎
4. https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem ↩︎
5. https://en.wikipedia.org/wiki/DMARC ↩︎
6. https://de.wikipedia.org/wiki/S/MIME ↩︎
7. https://de.wikipedia.org/wiki/Pretty_Good_Privacy ↩︎