Was sind SPF, DKIM und DMARC? Warum sind diese Verfahren wichtig, wenn man einen eigenen Mailserver betreibt? Warum sollte man SPF auch eintragen, wenn man keinen E-Mailservice über seine Domäne betreibt? Auf diese Fragen werde ich in diesem Beitrag etwas näher eingehen.
SPF – Sender Policy Framework
Der SPF Eintrag in der Domäne zeigt einem Empfänger Server, von welchen Servern eigentlich für diese Domäne gesendet werden darf. Stimmt der Eintrag nicht mit dem gesendeten Server überein, wird die Mail als Spam markiert, bzw. komplett verworfen.
SPF ist also auch ein wichtiger Eintrag, wenn man keinen Mailservice für seine Domäne verwendet. Somit verhindert man, dass überhaupt E-Mails als authentisch ausgegeben werden, egal von wo Sie kommen. Nun fragt man sich, “Aber wie soll den überhaupt eine Mail von meiner Domain aus gesendet werden, wenn kein Mailservice aktiv ist?”
Das Problem liegt im Mailprotokoll. Das ist mittlerweile sehr alt und damals in den 1980er Jahren hat noch niemand daran gedacht, dass das Protokoll Sicherheitsfunktionen benötigen würde. Jeder, welcher einen Mailserver aufbauen kann, kann theoretisch eine Mail im Namen von Jemanden anderen senden. Das nennt man Mail Spoofing. SPF kann dem Empfänger Server zumindest mitteilen, dass der Absender Server nicht befugt ist, Mails im Namen der Domäne zu senden, solange der Empfänger Mailserver diesen Eintrag in der Domain prüft und er auch in der Domain hinterlegt ist.
Ein SPF Eintrag für Liersch.it sieht beispielsweise so aus und wird als TXT in der Domain hinterlegt:
TXT v=spf1 include:spf.infomaniak.ch -all| TXT | Ist ein TXT Resource Record im DNS Verzeichnis der Domäne. |
| v=spf1 | Gibt die Version an. Es gibt momentan nur Version 1. |
| include:spf.infomaniak.ch | Weißt auf einen Mailserver hin, welcher nicht teil der Domain ist. |
| -all | Weist den Empfänger an, alle nicht autorisierten Absender abzuweisen. |
Wenn also eine Domain ohne Mailservice vorhanden ist, sollte immer folgender SPF Eintrag als TXT beim DNS Provider hinterlegt sein:
TXT v=spf1 -allFür interne Mailserver sollte natürlich statt include, welcher eher für externe Services verwendet wird, mx oder ip: angegeben werden. mx bezieht sich generell auf alle MX Einträge im DNS für diese Domäne.
TXT v=spf1 mx -allIhr merkt vielleicht, dass alle -all Einträge mit einem Bindestrich (-) voran geschrieben sind. Diese Präfixe entscheiden das Verhalten. Eine Tilde (~) beispielweise stellt nur einen Softfail dar. Mails von Servern die nicht autorisiert werden, kommen an, werden aber dann meist vom Empfänger-Server als Spam behandelt. Wobei ein Empfänger bei -all die Mail meistens direkt komplett ablehnt.
Daher ist meine Empfehlung auch immer -all zu hinterlegen und alle Server einzeln an zugegeben, welche Mails senden dürfen, am Besten mit IP Adresse der zusendenden Mailserver.
Quellen:
https://www.spf-record.de/generator
https://www.spf-record.de/syntax
https://de.wikipedia.org/wiki/Sender_Policy_Framework
DKIM – DomainKeys Identified Mail
Der DKIM Eintrag ist ein wichtiges Element um Spoofing zu verhindern und die Authentizität vom Absender zu erhöhen. Es fügt eine Signatur in dem Mailheader hinzu, welcher der Empfänger mit dem öffentlichen Schlüssel gegenprüfen kann. Der private Schlüssel verbleibt beim verifizierten Absender, womit die Signatur im Header erstellt wird.
Ein DKIM Eintrag kann direkt beim Mail Provider angefragt werden, welcher euch dann den öffentlichen Schlüssel zum Eintragen beim DNS Provider zur Verfügung stellt. Sollte er diesen Schlüssel nicht generieren können, muss man sich Gedanken um einen neuen Provider machen.
Beim Betreiben eines eigenen Mailservers kann dieser bei Exchange Installationen oder anderen Groupware Installationen wie Mailcow generiert werden und dann im DNS Verzeichnis der Domain eingetragen werden.
Man kann bspw. in Mailcow auch zuvor erstellte DKIM Keys exportieren und importieren. Somit kann ein privater Key für mehrere eigene Server verwendet werden.
Der öffentliche DKIM Schlüssel für Liersch.it könnte beispielsweise so aus:
20210506._domainkey TXT v=DKIM1; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCw/AbvP5Cmc9/4GFnNgCgeziQyhckeYGrqkEoeFFnfN/PnnMnYJs/QLJU+KoOtGArtL| 20210506._domainkey | Wird als Hostname in der Domain hinterlegt und 20210506 wird als Separator verwendet, auf den sich der Absender beziehen muss. |
| TXT | Ist ein TXT Resource Record im DNS Verzeichnis der Domäne. |
| v=DKIM1; | Die Version von DKIM. Version 1 ist Standard. |
| t=s; | Gibt mehr oder weniger an, dass die Domäne hinter @ mit der Domäne des Senders übereinstimmen muss. |
| p=… | Der Öffentliche Schlüssel |
Und wie folgend sieht dann ein signierter Header aus:
Wichtig ist hier vor allem:
| s=20210506 | Der zu verwendende Selektor im DNS Verzeichnis |
| t=1644159627 | Der Timestamp in Sekunden |
| bh= | Body Hash in Base64 |
| h= | Welche Attribute zur Signaturerstellung verwendet wurden. Wird die Signatur entschlüsselt, muss das Ergebnis mit diesem Eintrag übereinstimmen. |
| b= | Die Signatur, welche mit dem privaten Schlüssel und h= generiert wurde, und mit dem öffentlichen Schlüssel im DNS Verzeichnis der Domain entschlüsselt werden muss. Ebenfalls in Base64. |
Sollte diese Authentizitätsprüfung nicht übereinstimmen, ist die Mail erstmal suspekt. In den meisten Fällen kommt sie allerhöchstens nur in den Spam. Mit DMARC kann man genauer definieren, was damit wirklich auf Empfängerseite passieren soll.
Quellen:
https://www.heinlein-support.de/upload/mk4/3-02_DKIM-fuer-Profis.pdf
https://help.returnpath.com/hc/en-us/articles/222438487-DKIM-signature-header-detail
https://dmarcian.com/what-is-dkim/
https://help.returnpath.com/hc/en-us/articles/222481088-DKIM-DNS-record-overview
DMARC – Domain-based Message Authentication, Reporting and Conformance
DMARC wird hauptsächlich verwendet, um dem Empfänger Server mitzuteilen, wie er mit den verwendeten Protokollen umzugehen hat und wohin er seine Erkenntnisse als Report mitteilen soll. Das Verfahren sollte als essentiell angesehen werden, wenn man DKIM eingerichtet hat.
Der Eintrag für Liersch.it sieht beispielsweise so aus:
_dmarc TXT v=DMARC1; p=reject; fo=1; rua=mailto:spam@liersch.it| _dmarc | Wird als Hostname in der Domain hinterlegt und wird zum Auffinden des DMARC Eintrags verwendet. |
| TXT | Ist ein TXT Resource Record im DNS Verzeichnis der Domäne. |
| v=DMARC1; | Die Version von DMARC. Version 1 ist Standard. |
| p=reject; | Setzt die Policy fest – hier alles was nicht authentisch aussieht wird zurückgewiesen. Das ist die Holzhammer Methode. Es ist auch p=quarantine und p=none möglich. p=none wird für die Testphase verwendet, um zu prüfen, ob alle Einstellungen korrekt sind. |
| fo=1; | Gibt an wie und wann ein Fehlerbericht vom Empfänger Server gesendet werden soll. 1 bedeutet, dass ein Bericht gesendet wird, sobald SPF oder DKIM nicht authentifiziert werden konnten. Standardwert ist 0 und bedeutet, das ein Bericht gesendet wird, wenn SPF und DKIM nicht authentifiziert werden konnten. |
| rua=mailto: | Versendet vom Empfänger Server einen aufbereiteten Report an die benannte E-Mailadresse über Mails mit fehlerhafter Authentizität. |
Man könnte noch adkim= und aspf= definieren. Der Standardwert ist hier auf r für relaxed angegeben, was heißt, dass auch über Subdomains gesendet werden darf. Möchte oder plant man das nicht, wäre ein s für strict sinnvoller, um nur die Hauptdomain als Authentisch zu deklarieren.
Der Bericht erfolgt im XML Format, könnte also auch von Anwendungen aufbereitet werden. Mailcow kann diese beispielsweise über ihr Spam Tool auswerten und aufbereiten.
Quellen:
https://dmarc.org/overview/
https://www.ionos.de/digitalguide/e-mail/e-mail-sicherheit/dmarc-erklaert/
https://de.wikipedia.org/wiki/DMARC
Testseiten
Um die Einstellungen zu prüfen, gibt es viele Testseiten, die ich hier mal in eine Liste zusammen geschrieben habe.
| Webseite | URL | Beschreibung |
|---|---|---|
| MXToolbox | https://mxtoolbox.com/ | Eine Prüfseite, welche nicht nur DNS Einträge prüft, sondern auch, ob die Domain auf einer Sperrliste draufsteht. Sehr mächtiges Tool. |
| Learn DMARC | https://www.learndmarc.com/# | Wird anschaulich dargestellt, welche Prüfungen der Empfänger Mailserver unternimmt und wie SPF, DKIM und DMARC da zusammenspielen. |
| My Email Communications Security Assessment (MECSA) | https://mecsa.jrc.ec.europa.eu/de/ | Eine von der Europäischen Union bereitgestellte Testseite um die allgemeine E-Mailserversicherheit zu prüfen. |
| Internet.nl | https://internet.nl/test-mail/ | Eine niederländische Seite, welche Domains auf die aktuellsten und sichersten Standards prüft. |
Fazit
Als Fazit kann man ziehen, dass das Thema zwar erstmal kompliziert aussieht, aber wichtig für die Authentizität und Reputation einer Domain ist und es nach etwas Übung ziemlich leicht ist, diese Standards einzuführen.
Es muss euch bewusst werden, dass auch eure Domäne einen wirtschaftlichen Wert und Ruf hat. Und wenn dieser einmal ruiniert ist, ist es sehr schwer diesen Ruf wieder gerade zu biegen. Wenn die Domäne berüchtigt für Spam-Mails ist und auf verschiedensten Spamlisten landet, ist die Domäne wertlos geworden und es kann sehr aufwendig und teuer werden, wieder einen angesehenen Ruf zu bekommen.
Deshalb ist es auch wichtig für Domains ohne Mailservice zumindest den SPF-Record im DNS zu hinterlegen.
Alle hier gezeigten Methoden funktionieren natürlich nur für Spoofing Versuche. Ein Angreifer, welcher sich bereits auf dem authentisierten Mailserver befindet und dort Mails versendet, hebt dies natürlich nicht auf. Ebenso angegriffene Clients, welche massenhaft Spam Mails versenden. Da hilft nur gute IT Sicherheit, so dass ein Einbruch gar nicht erst stattfindet.
Außerdem sollte man das alles nicht mit Verschlüsselung verwechseln! Es geht hier hauptsächlich darum den Spam-Score der Domäne so niedrig wie möglich zu halten und nur definierte Server als authentische und erlaubte Absender zu deklarieren.
