SPF, DKIM und DMARC
Photo generated by DALL·E 3
Ab dem 1. Februar 2024 erfordern die E-Mail-Server von Google und Yahoo, dass alle E-Mails, die an ihre Benutzer gesendet werden, die Standards SPF, DKIM und DMARC erfüllen. SPF definiert, welche Server E-Mails für eine bestimmte Domain senden dürfen. DKIM signiert ausgehende E-Mails für eine Domain. Eine DMARC-Richtlinie definiert, wie der empfangende E-Mail-Server eingehende E-Mails von einer Domain authentisieren soll. Dieser Artikel erklärt, was diese Standards sind und wie Du sie auf Deinem eigenen E-Mail-Server implementieren kannst.
In dem Blog von Google und in dem Blog von Yahoo haben die beiden Internetplatzhirsche am 3. Oktober 2023 zeitgleich angekündigt, dass sie ab dem 1. Februar 2024 neue Sicherheitsstandards verlangen, um E-Mails an ihre Benutzer zuzustellen. Die beiden Unternehmen haben die Standards SPF, DKIM und DMARC bereits seit Jahren unterstützt, aber ab dem 1. Februar 2024 ist es erforderlich, dass alle E-Mails, die an ihre Benutzer gesendet werden, diese Standards erfüllen.
Die drei Standards sind in folgenden RFCs definiert:
- RFC 7208 : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
- RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Wenn Du also einen eigenen E-Mail-Server betreibst, musst Du diese Standards implementieren, um sicherzustellen, dass Deine E-Mails an die Benutzer von Google und Yahoo zugestellt werden und nicht etwa im Spamordner verschwinden.
SPF: Sender Policy Framework aktivieren und überprüfen
Das Sender Policy Framework (SPF) ist ein Standard, der es einem E-Mail-Server ermöglicht, zu überprüfen, ob eine E-Mail von einem autorisierten Server gesendet wurde. Dazu wird ein DNS-Eintrag verwendet, der die IP-Adressen der autorisierten Server enthält. Wenn eine E-Mail von einem Server gesendet wird, der nicht in diesem DNS-Eintrag aufgeführt ist, wird die E-Mail als Spam markiert oder abgelehnt.
Der SPF-Eintrag wird als TXT-Eintrag im DNS gespeichert. Der Eintrag für die Domain abshoff.dev sieht wie folgt aus:
v=spf1 redirect=_spf.abshoff.it
Dieser Eintrag leitet die SPF-Abfrage an den Eintrag _spf.abshoff.it weiter. Dieser Eintrag enthält die IP-Adressen der Server, die autorisiert sind, E-Mails von abshoff.dev zu senden:
v=spf1 ip4:148.251.51.30 ip4:148.251.51.27 ip6:2a01:4f8:202:110f:0:0:0:3 ip6:2a01:4f8:202:110f:0:0:0:4 -all
Eingehende E-Mails überprüfen
Um auf dem eigenen E-Mail-Server zu prüfen und zu verhindern, dass E-Mails von nicht autorisierten Servern angenommen werden, muss ein SPF-Checker installiert werden. Auf Debian-Systemen kann dies mit dem Paket postfix-policyd-spf-python erreicht werden:
apt-get install postfix-policyd-spf-python
Die Konfiguration erfolgt in der Datei /etc/postfix-policyd-spf-python/policyd-spf.conf und kann z. B. wie folgt aussehen:
debugLevel = 1
TestOnly = 1
HELO_reject = SPF_Not_Pass
Mail_From_reject = Fail
PermError_reject = False
TempError_Defer = False
skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1
Nun kann der SPF-Checker mit dem Postfix-Mailserver verbunden werden, indem die folgenden Zeilen in der Datei /etc/postfix/main.cf hinzugefügt werden:
smtpd_recipient_restrictions =
...
check_policy_service unix:private/policyd-spf
Der Service wird in der Datei /etc/postfix/master.cf konfiguriert:
policyd-spf unix - n n - 0 spawn
user=policyd-spf argv=/usr/bin/policyd-spf
Die eingehenden E-Mails erhalten von nun an einen zusätzlichen Header, der den SPF-Status der E-Mail enthält:
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::b2d; helo=mail-yb1-xb2d.google.com; envelope-from=someone@gmail.com; receiver=example.com
DKIM: DomainKeys Identified Mail aktivieren und überprüfen
Das DomainKeys Identified Mail (DKIM) ist ein Standard, der es einem E-Mail-Server ermöglicht, zu überprüfen, ob eine E-Mail von einem autorisierten Server gesendet wurde. Dazu wird jede ausgehende E-Mail mit einem privaten Schlüssel signiert und kann mit einem öffentlichen Schlüssel überprüft werden. Der öffentliche Schlüssel wird wiederum als TXT-Eintrag im DNS gespeichert.
Unter Debian kann DKIM mit dem Paket opendkim aktiviert werden:
apt-get install opendkim opendkim-tools
Wie im Debian-Wiki
beschrieben, muss für die Integration mit dem Postfix-Mailserver über einen Unix-Socket der postfix-Benutzer zur Gruppe opendkim hinzugefügt werden:
sudo adduser postfix opendkim
Die Konfiguration erfolgt in der Datei /etc/opendkim.conf und sieht ohne Anpassungen wie folgt aus:
# This is a basic configuration for signing and verifying. It can easily be
# adapted to suit a basic installation. See opendkim.conf(5) and
# /usr/share/doc/opendkim/examples/opendkim.conf.sample for complete
# documentation of available configuration parameters.
Syslog yes
SyslogSuccess yes
#LogWhy no
# Common signing and verification parameters. In Debian, the "From" header is
# oversigned, because it is often the identity key used by reputation systems
# and thus somewhat security sensitive.
Canonicalization relaxed/simple
#Mode sv
#SubDomains no
OversignHeaders From
# Signing domain, selector, and key (required). For example, perform signing
# for domain "example.com" with selector "2020" (2020._domainkey.example.com),
# using the private key stored in /etc/dkimkeys/example.private. More granular
# setup options can be found in /usr/share/doc/opendkim/README.opendkim.
#Domain example.com
#Selector 2020
#KeyFile /etc/dkimkeys/example.private
# In Debian, opendkim runs as user "opendkim". A umask of 007 is required when
# using a local socket with MTAs that access the socket as a non-privileged
# user (for example, Postfix). You may need to add user "postfix" to group
# "opendkim" in that case.
UserID opendkim
UMask 007
# Socket for the MTA connection (required). If the MTA is inside a chroot jail,
# it must be ensured that the socket is accessible. In Debian, Postfix runs in
# a chroot in /var/spool/postfix, therefore a Unix socket would have to be
# configured as shown on the last line below.
#Socket local:/run/opendkim/opendkim.sock
#Socket inet:8891@localhost
#Socket inet:8891
Socket local:/var/spool/postfix/opendkim/opendkim.sock
PidFile /run/opendkim/opendkim.pid
# Hosts for which to sign rather than verify, default is 127.0.0.1. See the
# OPERATION section of opendkim(8) for more information.
#InternalHosts 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
# The trust anchor enables DNSSEC. In Debian, the trust anchor file is provided
# by the package dns-root-data.
TrustAnchorFile /usr/share/dns/root.key
#Nameservers 127.0.0.1
Die Generierung eines Schlüsselpaares erfolgt mit dem Befehl opendkim-genkey. Der folgende Befehl erstellt ein Schlüsselpaar für die Domain example.com mit dem Selektor 20240130 und speichert die Schlüssel in dem Verzeichnis /etc/dkimkeys. Der Selektor ist eine Art Version des Schlüssels, damit dieser rotiert werden kann. Die weiteren Optionen geben die Schlüssellänge von 2048 Bit an und beschränken den Schlüssel auf die Signatur von E-Mails (nicht zum Verschlüsseln). Der Parameter -v gibt zusätzliche Informationen aus:
sudo --user opendkim opendkim-genkey \
--domain example.com \
--selector 20240130 \
--directory /etc/dkimkeys \
-b 2048 -r -v
Es wurden zwei Dateien erstellt: /etc/dkimkeys/20240130.private und /etc/dkimkeys/20240130.txt. Die Datei 20240130.private enthält den privaten Schlüssel, der auf dem E-Mail-Server verbleibt. Die Datei 20240130.txt enthält den öffentlichen Schlüssel, der als TXT-Eintrag im DNS gespeichert werden muss. Der Inhalt der Datei 20240130.txt sieht wie folgt aus:
20240130._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; s=email; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxBDx+285OwAOt0LCMBUeyL+XjhK5oS1Gmn+urvkklF1wms3Wv1U1qaVs4k0fOC764mLmzZISzg5ltCh0vih/tdFnPrZQdVPMwROJgnA9awL4ceY96HEbaxHifY5KLmgsxfza4fk/OtKLptJDDOS7jTI1v+3ugRZRLmFrKgZiwpDGGy/rduJg+YlshapNGTWGdMtjEEOrCpcC4s"
"U3VDqwUV54LOOIwTBKfk+PtAvsOQo+4HAJUhSU0OD1vGtb1F0p6h3osTLGKpxPaxXoEqYe6NnS+jrU/aOtoljTkDA5JpwL6ZfBUCQEHNYI2Z6/BGeY8CtiBXarkDhZu72EtU41UwIDAQAB" ) ; ----- DKIM key 20240130 for example.com
Der TXT-Eintrag für 20240130._domainkey.example.com soll nun also so aussehen:
v=DKIM1; h=sha256; k=rsa; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxBDx+285OwAOt0LCMBUeyL+XjhK5oS1Gmn+urvkklF1wms3Wv1U1qaVs4k0fOC764mLmzZISzg5ltCh0vih/tdFnPrZQdVPMwROJgnA9awL4ceY96HEbaxHifY5KLmgsxfza4fk/OtKLptJDDOS7jTI1v+3ugRZRLmFrKgZiwpDGGy/rduJg+YlshapNGTWGdMtjEEOrCpcC4sU3VDqwUV54LOOIwTBKfk+PtAvsOQo+4HAJUhSU0OD1vGtb1F0p6h3osTLGKpxPaxXoEqYe6NnS+jrU/aOtoljTkDA5JpwL6ZfBUCQEHNYI2Z6/BGeY8CtiBXarkDhZu72EtU41UwIDAQAB
Nun muss der DKIM-Checker mit dem Postfix-Mailserver verbunden werden, indem die folgenden Zeilen in der Datei /etc/postfix/main.cf hinzugefügt werden:
smtpd_milters = unix:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters
Eingehende E-Mails erhalten von nun an einen zusätzlichen Header, der den DKIM-Status der E-Mail enthält:
Authentication-Results: mx.abshoff.it;
dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=H0mG+B2C;
dkim-atps=neutral
DMARC: Domain-based Message Authentication, Reporting and Conformance aktivieren
Das Domain-based Message Authentication, Reporting and Conformance (DMARC) baut auf SPF und DKIM auf und definiert eine Richtlinie, wie der empfangende E-Mail-Server eingehende E-Mails von einer Domain authentisieren soll. Dazu wird ein erneut DNS-Eintrag verwendet, der die Richtlinie enthält.
Der nachfolgende TXT-Eintrag für _dmarc.example.com ist ein Beispiel für eine DMARC-Richtlinie, mit der DMARC im Monitormodus betrieben wird. Die übergebenen rua- und ruf-E-Mail-Adressen erhalten fortan Berichte über die Authentifizierung der E-Mails (in aggregierter Form oder als forensischer Einzelbericht). Die E-Mails werden nicht abgelehnt, wenn die Authentifizierung fehlschlägt.
v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=0:1:d:s;
Fazit
Wenn alles richtig konfiguriert wurde, kann man in Gmail in der Originalansicht einer E-Mail die Authentifizierungsinformationen einsehen:
Die Konfiguration bringt leider relativ viel Aufwand mit sich, aber es lohnt sich, da die E-Mails nicht mehr im Spamordner landen und die Empfänger sicher sein können, dass eine E-Mail tatsächlich von der angegebenen Domain stammt.
Es wird spannend zu sehen, ob Google und Yahoo durch die Umsetzung dieser Maßnahmen die Spam-Flut eindämmen können. Erstmal ermöglichen diese Maßnahmen den beiden Unternehmen andere E-Mail-Server besser zu bewerten und ggf. zu sanktionieren. Es bleibt abzuwarten, ob restriktive DMARC-Richtlinien sich bei der breiten Masse durchsetzen werden.
Tags: