SPF, DKIM und DMARC jetzt!

Die drei Begriffe SPF, DKIM und DMARC und vielleicht auch noch ARC werden immer wieder falsch verstanden und ich möchte eine Lanze für den Einsatz dieser Konfigurationen brechen. Sie helfen nicht ihrem eigenen Spamschutz aber dem ihrer Partner und verhindern Phishing in ihrem Namen.

SPF, DKIM und DMARC jetzt!
https://youtu.be/M09swCqVh_Y

Warum

Frage an ihren Geschäftsführer: "Ich besorge mir eine Rechnung von ihnen oder das Briefpapier und sende ihre Rechnung an ihren Kunden und verändere nur die Bankverbindung". Sie glauben das geht nicht? Dann haben sie sich getäuscht und ich bin sicher, dass viele ihrer Kunden dann die Rechnung an die neue Bankverbindung überweisen. Das fällt erst auf, wenn der Kunde erbost auf ihre Mahnung reagiert.

So funktioniert Mail

Aber schauen wir uns noch mal an, wie die Zustellung einer Mail vom Absender an den Empfänger funktioniert. Die internen Stationen lasse ich weg, denn letztlich interessiert nur das System des Absenders oder Spam-Dienstleisters, bei dem die Mail den Einflussbereich des Absenders verlässt und über das Internet an das mittels MX-Record aufgelöste Eingangssystem übermittelt wird.

Der Absender A sendet eine Mail von der Domain "msxfaq.de" an einen Empfänger B der Domain "uclabor.de". Dazu löst er im Internet den MX-Record auf, der ihn zum Server 198.51.100.3 verweist. Der empfangende Server sieht einmal die IP-Adresse des einliefernden Servers, die bei TCP nicht gefälscht werden kann, den HELO/EHLO-Namen, der stimmen kann aber nicht muss und den gelben Envelope mit dem MAIL FROM und RCPT TO. Sobald die eigentliche Mail übertragen wird, kommt zuerst der Header mit Datum, Betreff und dem vorgeblichen Absender "From" und Empfänger "To". Die Daten im Header sind aber nicht für das Routing relevant. Dazu dient nur der Umschlag (Envelope). Aber der Empfänger sieht nur die Informationen aus dem Header. Bei Spam und Phishing sind die Unterschiede zu beachten.

Was kann ich als Absender tun?

Ohne besondere Vorkehrungen ist es auch für einen Angreifer sehr einfach, eine Mails an ihre Firma zuzustellen und sich dabei als Kunde auszugeben.

Das funktioniert übrigens genauso einfach mit einem Postbrief. Das Briefpapier des Absenders kann ich heute einfach drucken. Das Problem ist hier nur, dass der Absender zumindest das Porto bezahlen muss und viel mehr Arbeit anfällt.

Natürlich "sollte" der Rechnungseingang des Kunden jedes Schreiben besonders gut prüfen, speziell wenn es eine Rechnung ist aber sie könne auch etwas dafür tun: Helfen Sie ihren Kommunikationspartnern bei der Erkennung von Fälschungen, indem sie:

  • Die legitimen Mailserver zum Versand mit ihrem guten Namen veröffentlichen (SPF)
  • Ihr Mails gegen Veränderungen durch eine Signatur schützen (DKIM)
  • Dem Empfänger die Prüfung empfehlen (DMARC)
  • Die Empfänger um Rückmeldungen bei Fehlern bitten (DMARC)

Das ist auch der Grund, warum gedruckte Bahnfahrkarten z.B. einen Silberrand oder QR-Code als Kopierschutz und Geldscheine sogar mehrere Sicherheitsmerkmale haben und die COVID-Zertifikate auch gezeigt haben, wie einfache sich digitale Signaturen prüfen lassen.

Die nächsten Abschnitte beschreiben, wie sie als Inhaber einer SMTP-Domäne der Empfängerseite dabei helfen können, authentische Mails von Fälschungen zu unterscheiden. Das gilt natürlich auch in der Gegenrichtung: Prüfen sie ihren eigenen empfangenden Systeme, ob sie die von ihren Kommunikationspartnern bereitgestellten Informationen auswerten, damit sie selbst nicht zu einfach Opfer eine Phishing-Mail werden.

Schritt 1: SPF veröffentlichen

In ihren Briefkasten ab der Firmenadresse kann nicht nur die deutsche Post sondern jede Person einen Brief einwerfen. Auch Mailserver nehmen von jedem anderen Computer im Internet E-Mails an. Zu ihrem Schutz gibt es natürlich Spamfilter anhand des Inhalts, Viren in Anlagen und weniger vertrauenswürdiger IP-Adressen der Absender. Hier ist der erste Hebel, indem Sie per DNS im Internet veröffentlichen, überwelche Systeme ihre Mail-Domain ausgehende Nachrichten versendet.

Dann kann ein entsprechend konfigurierter Empfänger alle Mails von anderen IP-Adressen als Fälschung direkt ablehnen. Ein SPF-Eintrag können Sie per DNS für jede Domain einfach in Erfahrung bringen, z.B.:

C:\>nslookup -q=TXT msxfaq.de
msxfaq.de text = "v=spf1 a mx include:spf.protection.outlook.com include:spf.server-he.de -all"

Ich veröffentliche damit, dass alle Server, auf die mein MX-Records verweist, die Mailserver von Microsoft und von HostEurope zum Versand als "*@msxfaq.de" legitimiert sind und durch das "-all" am Ende verbiete ich alle anderen Server.

Der empfangende Server kann damit schon einmal dummer Spammer ablehnen, die im Envelope eine so geschützte Domain verwenden. Allerdinge wissen Sie natürlich, dass das einfache SPF nicht den Header prüft und daher eine Fälschung immer noch möglich ist. Erst durch DMARC kann ein Absender den Empfänger anweisen, auch dies zu prüfen. Dazu sind aber noch ein paar Schritt erforderlich.

Das Risiko einer solche strengen Einstellung besteht darin, dass neue Server oder ihnen unbekannte aber dennoch legitime Dienste wie Newsletter-Versender etc. natürlich dann auch geblockt werden. Es ist daher ratsam,. vorab möglichst zu erfassen, wer alles mit ihrem Namen sendet. Ein guter Weg dazu ist z.B. DMARC, was ich weiter unten beschreibe.

Ich rate gerade bei Massenversand durch andere Dienstleister dazu, eine eigen Domain oder Subdomain zu verwenden, um ihre primäre Maildomäne, die von Mitarbeitern genutzt wird, zu schützen.

Schritt 2: DKIM aufbringen

Der Schutz anhand der einliefernden IP-Adresse wir schon lange genutzt aber ist mit Einschränkungen verbunden. Die reine SPF-Definition prüft nur den Absender des "Umschlags", den aber der Anwender nie zu sehen bekommt. Eine Prüfung des Absender im Header findet erst einmal nicht statt und wenn eine Mail von einem System z.B. im Rahmen einer Migration oder Newsletters unter Beibehaltung des Absenders umgeleitet wird, dann kann SPF die Zustellung unterbinden.

Einen Schritt weiter geht hier DKIM, bei dem Sie als Absender eine kryptografischen Schlüssel veröffentlichen und Elemente wie Absender, Empfänger, Datum. Betreff, Body u.a. der Mail damit signieren. Im Header wird dann für den Empfänger auch hinterlegt, wie er die signierte Mail prüfen kann.

Der Absender signiert einen Hashwert über die Header angegeben Felder und sendet all das im Header der Mail mit. Der Empfänger kann nach dem Empfang der Mail die gleiche Rechnung durchführen und mit dem im Header angegeben "Selector" per DNS den öffentlichen Schlüssel abrufen und die Signatur prüfen. Damit kann eine Mail sogar über Weiterleitungen/Umleitungen wie bei Newslettern und Mailinglisten durch fremde Systeme versendet werden, solange die Mail selbst nicht verändert wird.

Hier ein Beispiel einer von Exchange Online versendeten Mail:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=msxfaq.onmicrosoft.com;
 s=selector2-msxfaq-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JENyHM4RpZyX/voSRrUL9hy2YoYbWV0GE3PZI1Dpvzg=;
 b=whYefHLGuC0DdfsX7CB270aNX......ixN4=

Der Header sagt dem Empfänger, dass er sich das Schlüsselmaterial per DNS vom Selector (s=) holen soll. Das können Sie auch manuell machen:

C:\>nslookup -q=TXT selector2-msxfaq-onmicrosoft-com._domainkey.msxfaq.onmicrosoft.com

selector2-msxfaq-onmicrosoft-com._domainkey.msxfaq.onmicrosoft.com text = "v=DKIM1; k=rsa; p=MIGfM........DAQAB; n=1024,1450894445,1"

Über den DNS-Eintrag veröffentlich der Sender einen "öffentlichen Schlüssel", damit der Empfänger aus den hinter "h=" angegebenen Feldern einen Hashwert bildet und die digitale Signatur prüfen kann. Diese Methode hat jede Menge Vorteile gegenüber SPF:

  • IP-Adresse nicht mehr relevant
    Das erleichtert den Wechsel von Providern oder Failover-Szenarien und Datacentern mit dynamischen Adressen für absendende Server
  • Absender im Header statt des Envelope ist relevant
    Diesen Eintrag sieht der Anwender und wird bei einfachen SPF-Checks nicht erkannt
  • Eine Veränderung der Mail oder Anlagen bricht die Signatur
    Das erschwert deutlich eine Mail auf dem Weg zu verändern und zu ersetzen. Allerdings ist dies nicht mit einer SMIME-Signatur zu vergleichen.
  • Unterschiedliche Mailserver können eigene Keys und Selectoren nutzen
    Damit muss man nicht einen privaten Key auf mehreren Servern nutzen oder sogar an Dienstleister abgeben, sondern kann jedem Server einen Key generieren lassen und im DNS einfach mehrere Keys hinterlegen. Der Empfänger holt sich anhand des Selectors, den der Absender vorgibt, immer den passenden Schlüsseln

DKIM hat aber auch das große Problem, dass es immer noch viele Empfänger gibt, die DKIM nicht nutzen und sich nur auf SPF stützen. Das sind zwar nicht die großen Provider aber leider immer noch sehr viele Mittelständler mit eigenen On-Premises Servern.

Da leider nicht alle Absender schon DKIM nutzen, gibt es mit ARC einen weiteren ähnlichen Standard, bei dem aber ein Provider oder Relay die Mails mit einem eigenen Schlüssel signiert. Der Empfänger kann dann z.B. dem Provider einen " Vertrauensstatus" einräumen, so dass diese Mails dennoch ankommen. Sie finden ARC z.B. schon bei Yahoo, Hotmail u.a., denn gerade diese Provider gehen davon aus, dass ihre Wettbewerber dennoch für eine gewisse Hygiene sorgen und keiner der Provider möchte, das zu viele Mails in Warteschlangen steckenbleiben und die NDRs letztlich Support-Tickets verursachen. Auf ARC gehe ich hier aber nicht weiter ein.

Schritt 3: DMARC Feedback + Enforcement

Bei SPF kann ich mit dem Eintrag "-all" jeden anderen Server als ungültig kennzeichnen. Bei DKIM fehlt diese Option per DNS. Aber wenn Sie über SPF/DKIM nachdenken, dann wünschen Sie sich vielleicht sowieso erst einmal einen Report aller ausgehenden Server und welche Prüfungen denn fehlschlagen. Zumindest die größeren Provider unterstützen dazu ein Reporting mittels DMARC. Addieren Sie einfach einen DMARC-Eintrag in der folgenden Form in ihrer DNS-Domäne:

C:\>nslookup -q=TXT _dmarc.msxfaq.de

_dmarc.msxfaq.de text = "v=DMARC1; p=ignore; rua=mailto:dmarcin@carius.de"

Damit teilen Sie Microsoft, Google, Yahoo und vielen anderen DMARC-kompatiblen Servern mit, dass die per SPF und DKIM bereitstellten Informationen erst einmal nicht eine Mail ablehnen sondern ignoriert werden sollen. Das bedeutet zwar nicht, dass sich die Empfänger auch daran halten, aber interessanter ist der "rua="-Eintrag, an den diese Server dann Berichte über bei ihnen eingegangene Mails senden. So bekommen Sie recht schnell mit, welche anderen Server noch Mails mit ihrer Domain senden. Das können Spammer u.a. sein aber eben auch ein Kontakt-Webformular auf einer Homepage, von der Sie bislang nichts wussten. Nach einigen Tagen oder Wochen können Sie dann die Absender entweder im SPF-Record eintragen, für DKIM aktivieren oder auf eine andere Domain umstellen.

Das Ziel ist aber, dass Sie irgendwann ihren DMARC-Eintrag aber auf "Quarantine" oder "Reject" umstellen, damit der Missbrauch ihrer Domain unterbunden wird.

REM Beispiel eines Eintrags mit Quarantine
C:\>nslookup -q=TXT _dmarc.msxfaq.de

_dmarc.msxfaq.de text = "v=DMARC1; p=quarantine; rua=mailto:dmarcin@carius.de"


REM Beispiel eines Eintrags mit Reject
C:\>nslookup -q=TXT _dmarc.msxfaq.de

_dmarc.msxfaq.de text = "v=DMARC1; p=reject; rua=mailto:dmarcin@carius.de"

In allen Fällen bleibt es aber dem Empfänger überlassen, wie er damit umgeht. Der Inhaber einer Domain veröffentlicht damit nur seine Empfehlung, wie damit umgegangen werden soll. Ein guter Spamfilter wird nicht alleine diesen Informationen vertrauen, denn auch Spammer können Domains kaufen und mit gültigen SPF/DKIM/DMARC-Einträgen versehen und das kann sogar absichtlich mit sehr ähnlich geschriebenen Domains passieren.

Aber niemand sollte die SPF/DKIM/DMARC-Einträge ihrer Firmen-Domain verändern können, wenn wir mal von DNS-Spoofing und anderen Angriffen auf die meist ungesicherte DNS-Abfrage absehen.

Schritt 4: Eingehend prüfen

Wenn Sie für den Versand alle Vorkehrungen getroffen haben, damit die Empfänger ihre Mails als legitim ansehen, ist natürlich immer noch nicht sichergestellt, dass ihre Mail auch sicher zugestellt wird. SPF, DKIM, DMARC sind keine Methoden eine Zustellung zu sicher oder sogar zu erzwingen, denn letztlich ist jeder Empfänger immer noch selbst berechtigt eine Mail auch abzulehnen. Aber sie haben damit den Empfängern zumindest alle Möglichkeiten angeboten, eine Fälschung ihrer Adresse zu erkennen und zu blockieren. Das ist schon mal ein großer Schritt ihren Namen zu schützen. Sie können aber davon ausgehen, dass auch die Spammer entweder Firmenserver missbrauchen oder eine eigene Domain vergleichbar gut konfigurieren.

Damit das aber alles besser funktioniert, muss natürlich der Empfänger die von ihnen bereitgestellte Informationen auch auswerten und entsprechend befolgen. Leider leider gibt es immer noch zu viele Provider, die noch keine korrekte SPF/DKIM-Prüfung und DMARC-Konfiguration auswerten und damit ihre Kunden nicht vor Fälschungen schützen. Wenn Sie ihren Spamfilter als Firma selbst konfigurieren, dann sollten Sie jetzt die Chance nutzen, die Konfiguration zu prüfen. Wenn ihr Spamfilter DMARC unterstützt, dann nutzen Sie die Informationen der Absender und prüfen Sie vor allem das "Alignment" zwischen dem "Mail From" und dem "Envelope-From". Der Anwender sieht nur die Absenderadresse im Header während ein einfacher SPF-Check nur die Absenderadresse des Umschlags bewertet. Ein Spammer kann die problemlos unterschiedlich setzen. Erst ein DMARC-Eintrag stellt sicher, dass die beiden Adressen von der gleichen Domain kommen müssen.

FAQ

  • Q: Ich habe einen SPF-Eintrag mit "-all". Damit habe ich doch genug getan?
    A: Leider nein, denn ohne DMARC prüfen die meisten Empfänger nur, dass der "MAIL FROM", auch Envelope-From genannt) passt aber nicht die Absenderadresse im Header. Beispiel: Ich sende ihnen einen Postbrief und schreibe auf den Umschlag einen Absender, der zum Stempel der Post auf der Briefmarke passt. Auf dem drinnen liegenden Brief schreibe ich einen ganz anderen Absender. Ihre Poststelle schaut auf den Umschlag und sagt, dass alles OK aussieht, öffnet den Brief, wirft den Umschlag weg und legt ihnen das Anschreiben mit einer ganz anderen Absenderadresse auf den Tisch.
    Sie sollten zumindest per DMARC-Eintrag sicherstellen, dass auch auf dem Briefpapier selbst die Adresse zum Umschlag passt.
  • Q: Ok ich habe SPF und DMARC eingestellt, brauch ich dann DKIM
    A: Ja, wenn es kann ja passieren, dass eine Mail z.B. bei einer Migration, einer Mailingliste o.ä. "umgeleitet" wird. Dann kommt die Mail bei ihnen über eine Zwischenstation an, von der der Absender aber nichts wei. Daher sollte der Absender die Mail auch per DKIM signieren, damit solche Situationen auch weiter funktionieren
  • Q: Ich würde gerne "SPF -all" nutzen aber traue mich nicht
    A: Dann sollten sie DMARC so einstellen, dass die Empfänger ihre Mails noch nicht streng prüfen aber ihnen einen Bericht senden. Wenn eines ihrer Systeme dann eine Mail an Yahoo, Google, Hotmail und einig andere Provider senden, dann bekommen Sie einen Report. Parallel sollten Sie natürlich schon ihre Mailsystem kennen und Versanddienstleister für Massenmails in ihrem Namen vielleicht auf Subdomains umstellen.
  • Q: Das schützt doch alles nicht vor Spam an meine Domain
    A: Korrekt. Sie helfen damit aber ihren Geschäftspartnern, Fälschungen mit ihrer Domain zu blockieren und indirekt bekommen Sie dann weniger Beschwerden oder Unzustellbarkeiten. Aber sie können schon sehr einfach Fälschungen von Domains ihrer regulären Partner ablehnen und Phishing damit deutlich erschweren, wenn die andere Seite entsprechend SPF, DKIM, DMARC konfiguriert hat.
  • Q: Warum können meine Empfänger keine Mails mehr Umleiten?
    A: Wenn A an B sendet und B die Mail an C umleitet, dann prüft C natürlich woher die Mail komm. Da B aber nicht für A zugelassen ist, werden solche Mails abgelehnt. Siehe auch Umleitung/Weiterleitung mit SPF/DKIM/DMARC/SRS
  • Q: Welche Frage haben Sie noch?
    A:

Sie haben immer noch Fragen zu SPF, DKIM und DMARC und wie sie was am besten Einsetzen, dann fragen Sie einfach meine Kollegen von NoSpamProxy oder mich. Ich werde gerne ihre Fragen hier als FAQ-Bereich erweitern.

Provider

Nicht jeder den den Vorteil seinen eigenen Mailserver zu betreiben. Damit stellt sich die Frage, welche Provider wie weit schon die Optionen unterstützen.

Hinweis: Einige Provider beschreiben in ihren Hilfeseiten z.B. DKIM aber bietet es selbst nicht an. Sie können natürlich ihre Mails dann selbst mit einem eigenen Key signieren und den DKIM-Selector im DNS eintragen. Das ist aber kein "Support" für die Liste

Wenn Sie bei ihrer Domain einen SPF-Eintrag setzen wollen, müssen sie vom Provider nur die Liste der ausgehenden Mailserver referenzieren. Das sollte jeder Provider anbieten und ist nur ein DNS-Eintrag. Bei DKIM muss der Mailserver des Providers aber Schlüssel vorhalten und den Header der Mail erweitern und den DNS-Eintrag vornehmen oder ihnen mitteilen. Bei eingehenden Verbindungen muss der empfangende Mailserver die entsprechenden Prüfungen durchführen.

Beachten Sie, dass Provider nur dann eine DKIM-Signatur anbringen können, wenn Sie die Mail über den Provider als Smarthost versenden.

Provider Ausgehend Eingehend
DKIM
signieren
RNDS SPF
Prüfung
DKIM
Prüfen
DMARC
Prüfung
DMARC
Reporting

Outlook.com

Ja

Nein

Ja

Ja

Always On

Ja

Exchange Online/EOP

Konfigurieren

Nein

Ja

Ja

Konfigurierbar

 

GMail

Ja

Ja!

Ja

Ja

Ja

Ja

IONOS

Ja

Nein

?

?

?

?

Hetzner

Ja

?

?

?

?

?

HostEurope

Ja

?

?

?

?

?

All-Inkl.com

Ja

Ja

?

?

?

?

Ich prüfe immer mal wieder Provider aber freue mich über entsprechende Meldungen von Lesern

Eine weiter Übersicht wird von Tino Hager auf seiner Webseite bereitgestellt

Sie können auch einfach eine Mail von ihrem Postfach über ihren Provider an einen der beiden Dienste senden um die DKIM-Konfiguration zu prüfen:

Hier die weiterführenden Link zu den verschiedenen Providern

Einschätzung

SPF ist einfach, schnell und sollten sie unbedingt konfigurieren. DKIM sichert ihre Mail weiter ab, aber ein Server in ihrer SMTP-Routing-Kette zum Internet muss dann DKIM signieren können. Exchange Online kann es aber für Exchange On-Premises gibt es nur 3rd Party Module. Zum Glück können aber die meisten Spamfilter, wie z.B. NoSpamProxy und andere die DKIM-Signatur anfügen. In die Empfangsrichtung sollten Sie heute keinem Spamfilter mehr einsetzen, der nicht SPF/DKIM/DMARC prüfen kann. Diese Funktion ist mit dem Geldschein-Prüfgerät vergleichbar, welches an vielen Supermarktkassen steht.

Die Veröffentlichung von SPF und DMARC ist zwar keine Pflicht, aber aus meiner Sicht notwendig. DKIM sollten Sie aktivieren, wenn ihr Mailsystem eine DKIM-Signatur addieren kann. Eingehende Spamfilter ohne SPF/DKIM/DMARC-Support sollten Sie ebenfalls nicht länger einsetzen. Phishing unter ihrer eigenen Domain wird so unmöglich. Es schützt aber nicht gegen "Vertipperdomains".

Weitere Links