Verhindern von Spoofing durch eMailServer-Authentifizierung

Wenn du in deinem eMail-Postfach schaust, findest du bestimmte eine ganze Menge SPAM. Die Flut an SPAM-eMails, die weltweit versendet werden wächst von Jahr zu Jahr und füllt unsere eMail-Postfächer. Aber es muss doch auch was geben, dass dagegen hilft! Ja, gibt es. SPF, DKIM und DMARC wurden zum Verhindern von Spoofing durch eMailServer-Authentifizierung entworfen. Deshab setzen die großen eMail-Provider wie Microsoft und Google voraus, dass SPF, DKIM und DMARC aktiviert ist, damit eMails von der eigenen Domain beim Empfänger zugestellt werden.

Um DMARC nutzen zu können, muss zuvor SPF und DKIM richtig konfiguriert werden. SPF ist wiederum die Vorraussetzung für DKIM und für den Einstieg in die Thematik leichter verständlich. Daher möchte ich mit der Erklärung zu SPF beginnen.

SPF – Sender Policy Framework

SPF steht für Sender Policy Framework – damit regelt man, welche eMail-Server berechtigt sein sollen, eMails im Namen einer bestimmten Domain zu senden. Ebenso legt man fest, wie mit eMails von Servern umgegangen werden soll, die nicht im Kreis der erlaubten Server anthalten sind. Dazu gibt es vier Möglichkeiten.

Möglichkeiten im Umgang mit SPF-Fehlern

Bezeichnung	Zeichenfolge	Auswirkung
Positiv	+all	alle Server sind berechtigt, keine eMail wird abgelehnt (als hätte man alle Server der Welt berechtigt). Jeder SPAM ist zugelassen.
Neutral	?all	alle Server sind berechtigt, eignet sich um zu erkunden, welche Server im Namen der eigenen Domain versenden. Jeder SPAM ist zugelassen, daher ist hier noch großer Rechercheaufwand notwendig, um herauszufinden, ob ein Server im Nachgang in den SPF-Eintrag aufgenommen werden sollte oder nicht.
SoftFail	~all	eMails von Servern außerhalb der festgelegten Werte werden weiterhin angenommen aber markiert und ggf. als als Junk einsortiert. Dies eignet sich, wenn man bereits die meisten legitimen Server identifiziert hat und lediglich unsicher ist, ob man vergessen hat, einen in den Berechtigungskreis aufzunehmen. Jeder SPAM ist zugelassen, wird aber beim Empfänger als SPAM/Junk angezeigt.
Fail	-all	nur die festgelegten Server dürfen eMails im Namen der Domain versenden. eMails von allen anderen Servern werden kommentarlos abgeleht. Dies sollte man erst verwenden, nachdem man sichergestellt hat, dass alle berechtigten Server identifiert und im SPF-Record eingetragen sind und es keine technischen Hürden gibt. (Stand 07.2025: Unter bestimmten Umständen tragen sich die Server von hornetsecurity nicht richtig in den eMailHeader ein, sodass eine Prüfung fehlschlägt, obwohl der Server im SPF richtig authentisiert ist, ein Ticket zur Behebung ist eröffnet.) SPAM wird vom Empfänger ohne Hinweis abgelehnt.

Erstellung des SPF-Records

Um einen Server per SPF zu authentisieren gibt es viele Möglichkeiten. Per MX-Record, per IP, per A/AAA-Record, per inkludieren einer Liste, die Möglichkeiten sind vielfältig, finden aber alle innerhalb eines DNS-Records statt. Um sich inspirieren zu lassen, empfehle ich die Verwendung eines Online-Generators, wie zum Beispiel: den von SPF-Record.com.

Der SPF-Eintrag wird als TXT-Ressource-Record im Root-Teil der Domain festgelegt. Der Hostname bleibt also leer. Für das Feld, dass den Wert des TXT-Eintrages enthält, gibt es eine Vielzahl an Gestaltungsmöglichkeiten.

Ein SPF-Record, der alle Server im MX-Record authentisiert und alle anderen ablehnt, könnte zum Beispiel so aussehen:

v=spf1 mx -all

Das „v=spf1“ ist Pflicht, da es festlegt, dass es sich hierbei um einen SPF-Eintrag handeln soll.

Ein SPF-Eintrag, der alle Server von M365 importiert, sieht bspw. so aus

v=spf1 include:spf.protection.outlook.com -all

Der Eintrag von Microsoft ist mit folgendem Inhalt bestückt

v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all

Als Erkenntnis daraus ergibt sich also, dass man mehrere Einträge ineinander verschachteln kann. Jedoch hat man nur 10 Lookups frei, bevor ein SPF-Eintrag als ungültig markiert wird. Man sollte den SPF also möglichst flach und allgemein gestalten, jedoch auch möglichst engmaschig, um nur die richtigen Server zum Versenden von eMails zu berechtigen und ein Versand von SPAM über die eigene Domain zu verhindern.

DKIM – DomainKeys Identified Mail

Der DKIM-Eintrag verifiziert mithilfe eines PublicKey, der im DNS-Record veröffentlicht wird, dass die eMail tatsächlich von dem Server stand, der in der QuellAdresse hinterlegt ist. Somit stellt man sicher, dass der SPF-Eintrag nicht durch manipulieren der IP-Adresse umgangen wurde. Den Key bekommt man von seinem eMail-Provider, beziehungsweise kann man von seinem eMail-Server generieren lassen. Daher muss man einen DKIM-Eintrag pro Domain und pro Anwendung/ Servercluster erstellen und dies im DNS per TXT hinterlegen. Ein DKIM-Eintrag erkennt man an folgendem Namensschema, wobei der Inhalt in den eckigen Klammern wählbar ist.

[selector]._domainkey.[domain.tld]

Der Selector ist frei wählbar oder wird vom eMail-Provider vorgegeben. Er könnte aber bspw. nach dem Servercluster/ Anwendung benannt sein, für die er gilt. Also bspw für das Tool zur Personalverwaltung:

HRsystem._domainkey.firma.de

und für das Haupt-eMail-Servercluster bspw.

eMailCluster-RZKoeln._domainkey.firma.de

Der Inhalt oder Wert lautet dann bspw. wie folgt:

v=DKIM1; p=76E629F05F709EF665853333EEC3F5ADE

v=DKIM1 legt fest, dass es sich um einen DKIM-Eintrag handeln soll und p= enthält dann den PublicKey.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Mittels des DMARC-Eintrages regelt man, wie mit eMails umgegangen werden soll, bei denen der DKIM-Eintrag nicht so ausfällt, wie erwartet. Bei der Erstellung empfehle ich ebenfalls wieder einen Generator, diesmal den von MXToolbox

Möglichkeiten im Umgang mit Fehlern

Es gibt 3 Möglichkeiten, wie mit den eMails umgegangen werden soll.

Regel	Beschreibung
none	es wird nichts unternommen, nicht konforme eMails werden trotzdem zugestellt
quarantine	eMails werden zugestellt, aber im SPAM/Junk-Ordner des Empfängers
reject	eMails werden beim Empfängerserver ohne Benachritigung abgelehnt

Gestaltung eines DMARC-Records

Des Weiteren kann ich mittels DMARC einen Bericht zusenden lassen, von welchen IP-Adressen eMails für meine Domain versendet wurden und ob diese legitim waren oder durch die Prüfung bei SPF/DKIM durchgefallen sind. Einen DMARC-Eintrag muss ich nicht wie die anderen beiden Einträge explizit pro Domäne neu erstellen, ich kann auch per CNAME auf einen bereits bestehenden Eintrag verweisen. Voraussetzung, um über einen CNAME-Eintrag die Reports zu bekommen ist, dass die Domain, die die Berichte bekommen soll die QuellDomain berechtigt hat. Dies geschieht bspw. über einen TXT-Eintrag.

Wenn ich also möchte, dass mein Bericht von Firma.de an ITLDemo.de gesendet wird, dann muss bei ITLDemo folgender DNS-Eintrag erstellt werden:

firma.de._report._dmarc.itldemo.de

dieser enhält dann den Wert

v=DMARC1

Alternativ kann ich wieder jede beliebige Domain berechtigen, durch einen Eintrag mit dem gleichen Wert „v=DMARC1“ aber diesmal mit dem Namen:

*._report._dmarc.itldemo.de

Bestandteile des DMARC-Records

Bestandteil	Erklärung	Kommentar
RUA	Aggreated Reports – Zusammenfassung aller IP-Adressen an eine bestimmte Domain und ob bei der Prüfung von SPF/DKIM Fehler aufgetreten sind oder ob diese erfolgreich waren.	Enthält immer eine Übersicht über alle fehlgeschlagenen aber auch erfolgreichen IP-Adressen. Dies lässt sich leider nicht auf „nur fehlgeschlagene“ eingrenzen.
RUF	Failure Report for Forensic Analysis – wird direkt erstellt, wenn eine eMail von einer nicht legitimierten Adresse versendet wird und enhält die eMail im Anhang.	Durch das Anhängen der eMail ist dies nicht DSGVO-Konform. siehe: https://certified-senders.org/wp-content/uploads/2018/08/Gutachten_DMARC_und_DSGVO.pdf
FO	Failure Options – Bezieht sich nur auf RUF-Report, dieser sollte jedoch für die DSGVO-Konformität gänzlich deaktiviert sein.

Ein DMARC-Eintrag für die Domain ITLDemo.de wird als neuer DNS-Eintrag erstellt, mit dem Namen _dmarc, im ganzen lautet dieser daher

_dmarc.itldemo.de

Zusammenfassung

SPF, DKIM und DMARC sind drei Einträge, die im DNS der jeweiligen Domain gesetz werden zur Verhinderung von Spoofing der eigenen eMail-Domain.
SPF übernimmt dabei die Einschränkung, dass eMails von nur ausgewählten Servern versendet werden.
DKIM bestätigt, dass die eMail nur von einem Server versendet wurde, der im SPF berechtigt wurde.
DMARC beinhaltet dann die Steuerung, was mit eMails passieren soll, bei denen die Prüfung zu SPF/DKIM fehlgeschlagen ist und erstellt darüber hinaus noch einen Bericht, damit der Administrator der eMailDomain und der eMailServer weitere Handlungsschritte daraus ableiten können.