DomainKeys Identified Mail (DKIM) ist ein Verfahren zur automatischen Signatur von Mails bzw. zur Überprüfung der Signatur. DKIM-signierte E-Mails können zweifelsfrei ihrem Absender zugeordnet werden. Obwohl DKIM kein Kriterium zur Spam-Erkennung ist, betrachten manche Mail-Provider DKIM-signierte Mails als vertrauenswürdiger. Die Konfiguration von DKIM kann somit (manchmal) vermeiden, dass eigene Mails vom Empfänger als Spam betrachtet werden.

Dieser Artikel erläutert die Hintergründe von DKIM und zeigt, wie der eigene Mail-Server konfiguriert werden kann, um ausgehende Mails DKIM-konform zu signieren. Ich gehe davon aus, dass bereits ein funktionierender Mail-Server mit Postfix eingerichtet wurde und dass das ganze System unter Ubuntu läuft. Bei anderen Distributionen wird es vermutlich kleinere Abweichungen geben, das Prinzip bleibt aber natürlich unverändert.

Funktionsweise

Die Idee von DomainKeys Identified Mail (DKIM, Wikipedia) sieht so aus: Wenn ein DKIM-konfigurierter Mail-Server eine Mail versendet, verwendet er einen auf dem Mail-Server gespeicherten privaten Schlüssel und fügt der Mail eine Signatur hinzu.

Der Empfänger-Mail-Server kann nun zur Kontrolle den DNS-TXT-Eintrag des Senders auslesen. Dieser enthält den öffentlichen Teil des Schlüssels. Damit kann überprüft werden, ob die Mail und die Signatur zusammenpassen.

Mit DKIM kann also überprüft werden, ob die Mail tatsächlich von der in der Mail angegebenen Adresse stammt — und das ist schon viel wert. (Nur der legitime Mail Server verfügt über den privaten Schlüssel und kann damit eine korrekte Signatur durchführen.)

DKIM und SPF: DKIM wird oft zusammen mit SPF beschrieben. Das Sender Policy Framework (SPF, Wikipedia) ist ein wesentlich einfacheres Verfahren, das das Fälschen der Absenderadresse vermeiden soll. Die Gemeinsamkeit zu DKIM besteht darin, dass auch SPF einen DNS-Eintrag nutzt. Anders als bei DKIM enthält dieser Eintrag aber nur die IP-Adressen der Mail-Server, die für einen bestimmten Domainnamen Mails versenden dürfen. Beim Generieren eines geeigneten DNS-Eintrags hilft z.B. die Seite http://www.spf-record.de/generator. Außer dem Einrichten des korrekten DNS-TXT-Eintrags ist keine weitere Konfigurationsarbeit notwendig. Ähnlich minimal ist aber auch der Nutzen: Besonders ungnädig ist der Postfix-Experte Peer Heinlein, der SPF als Bullshit und Broken by Design bezeichnet (Quelle).

DKIM/SPF als Spam-Schutz?

Niemand kann Spammer daran hindern, ebenfalls DKIM und SPF zu nutzen. Insofern sind DKIM und SPF kein eindeutiges Kriterium zur Spam-Erkennung. Welchen Grund gibt es dann, sich überhaupt damit auseinanderzusetzen?

Die Hauptmotivation besteht normalerweise darin, dass man als kleiner Mail-Server-Betreiber ständig das Problem hat, dass große Mail-Provider vom eigenen Mail-Server versandte Mails als Spam betrachten. Anders formuliert: Zum Ärger darüber, selbst ständig mit Spam überschüttet zu werden, kommt das Problem hinzu, dass Google, GMX, Microsoft, Yahoo etc. eigene Mails fälschlich als Spams identifizieren. Immer wieder muss man Kunden, Geschäftspartner etc. darauf hinweisen: »Werfen Sie bitte auch einen Blick in Ihren Spam-Ordner!« oder »Fügen Sie kofler.info zur Liste der vertrauenswürdigen Empfänger (= Whitelist) hinzu.«

Um die Schmach zu vermeiden, dass die Mails der eigenen Firma als unseriös betrachtet werden, versucht man seinen Mail-Server so regelkonform wie möglich zu betreiben und implementiert selbst Verfahren, von deren Wertlosigkeit man eigentlich überzeugt ist. (Wobei hinzuzufügen ist: DKIM ist an sich keine schlechte Idee. Es ermöglicht die Authentizität der Absenderadresse zu verifizieren. Das ist durchaus lobenswert, aber es ändert eben nichts daran, dass auch Spammer DKIM verwenden können.)

OpenDKIM installieren und einrichten

OpenDKIM ist eine Open-Source-Implementierung von DKIM. Das Programm kann gleichermaßen ausgehende Mails mit einem eigenen Schlüssel signieren als auch die Signatur eintreffender Mails überprüfen. OpenDKIM ist mit diversen MTAs kompatibel. Diese Anleitung zeigt das Zusammenspiel von DKIM mit Postfix, wobei das Hauptaugenmerk des Artikels beim korrekten Signieren liegt. Das Ziel ist es also, Postfix so zu konfigurieren, dass es ausgehende Mails DKIM-konform signiert und so die Wahrscheinlichkeit mindert, dass die Mail vom Empfänger als Spam betrachtet wird.

Zuerst installieren Sie OpenDKIM:

apt-get install opendkim opendkim-tools 

Dann richten Sie ein Verzeichnis für die DKIM-Schlüssel ein:

mkdir /etc/opendkim
mkdir /etc/opendkim/keys
chown -R opendkim:opendkim /etc/opendkim
chmod go-rw /etc/opendkim/keys

Konfigurationsdatei opendkim.conf

Die zentrale Konfigurationsdatei von OpenDKIM ist /etc/opendkim.conf. Erstellen Sie opendkim.confwie im folgenden Muster. Details zu den Dateien trusted, key.table und signing.table, auf die die Konfiguration verweist, folgen gleich. Einzelheiten zu den diversen opendkim.conf-Optionen können Sie mit man opendkim.conf nachlesen.

# Datei /etc/opendkim.conf

# OpenDKIM agiert als Mail Filter (= Milter) in den
# Modi signer (s) und verifier (v) und verwendet eine
# Socket-Datei zur Kommunikation (alternativ: lokaler Port)
Mode                    sv
# Socket                  local:/var/run/opendkim/opendkim.sock
Socket                inet:12345@localhost

# OpenDKIM verwendet diesen Benutzer bzw.
# diese Gruppe
UserID                  opendkim:opendkim
UMask                   002
PidFile                 /var/run/opendkim/opendkim.pid

# OpenDKIM bei Problemen neustarten,
# aber max. 10 mal pro Stunde
AutoRestart             yes
AutoRestartRate         10/1h

# Logging (wenn alles funktioniert eventuell reduzieren)  
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

# Verfahren, wie Header und Body durch
# OpenDKIM verarbeitet werden sollen.
Canonicalization        relaxed/simple

# interne Mails (signieren, nicht verifizieren)
InternalHosts           refile:/etc/opendkim/trusted

# Hosts, denen vertraut wird (vermeidet Warnungen beim Logging)
ExternalIgnoreList      refile:/etc/opendkim/trusted

# welche Verschlüsselungs-Keys sollen für welche
# Domains verwendet werden        
# (refile: für Dateien mit regulären Ausdrücke)        
SigningTable            refile:/etc/opendkim/signing.table
KeyTable                /etc/opendkim/key.table       

# diesen Signatur-Algorithmus verwenden
SignatureAlgorithm      rsa-sha256

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier.  From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders         From

/etc/default/opendkim: Bitte beachten Sie, dass unter Debian und Ubuntu beim Start von OpenDKIM auch die Datei /etc/default/opendkim ausgewertet wird. Dort durchgeführte Einstellungen haben Vorrang gegenüber opendkim.conf. Ich gehe in dieser Anleitung davon aus, dass Sie die dort vorgesehenen Defaulteinstellungen durch das Einfügen von Kommentarzeichen deaktivieren. (Einzig RUNDIR sollten Sie belassen.)

Keine Signatur für interne Mails

Die Datei trusted gibt an, welchen Hosts der Mail-Server vertraut, d.h., für welche Hosts auf die DKIM-Signatur verzichtet wird. Ersetzen Sie die drei kofler.info-Einträge durch entsprechende Einträge mit dem Hostnamen Ihres Mail-Servers!

# Datei /etc/opendkim/trusted
127.0.0.1
::1
localhost
kofler
kofler.info
host1.kofler.info

Welcher Schlüssel für welchen Hostnamen?

Als nächstes richten Sie mit einem Editor die Dateien signing.table und key.table gemäß dem folgenden Muster ein. signing.table gibt an, für welche From-Adressen welcher Schlüssel verwendet werden soll. Die zweite Spalte in signing.table bezieht sich dabei auf die erste Spalte in key.table. Natürlich müssen Sie kofler.info und kofler durch eigene Namen ersetzen!

# Datei /etc/opendkim/signing.table
# für E-Mails von xxx@kofler.info den Schlüssel 'kofler' 
# zum Signieren verwenden
*@kofler.info kofler

key.table gibt dann den tatsächlichen Ort der Schlüsseldateien an. Die zweite Spalte besteht dabei aus drei Teilen: Dem Hostnamen (hier kofler.info), dem Selektor (hier 201611) und dem eigentlichen Dateinamen. Die Verwendung einer Zeitangabe für den Selektor hilft dabei einen Überblick zu behalten, wann die Schlüssel erzeugt wurden — hier also im Nov. 2016.

# Datei /etc/opendkim/key.table
# der Schlüssel 'kofler' befindet sich in 
# des Datei /etc/opendkim/keys/kofler.private
kofler kofler.info:201611:/etc/opendkim/keys/kofler.private

Wenn Ihr Mail-Server für mehrere Hosts zuständig ist, ergänzen Sie key.table und signing.table um entsprechende Einträge für alle weiteren Hosts.

Schlüssel generieren

Das Kommando opendkim-genkey erzeugt einen privaten Schlüssel (name.private) und einen öffentlichen Schlüssel (name.txt). Der private Schlüssel verbleibt am Server und darf nicht in falsche Hände geraten! Der öffentliche Schlüssel wird später im DNS-TXT-Record des Mail-Servers gespeichert. Die wichtigsten Optionen des Kommandos lauten:

• -d domain gibt an, für welche Domain die Schlüssel gelten sollen. Die Option wird aktuell nur dazu verwendet, um einen Kommentar in name.txt einzubauen. Ohne die Option verwendet opendkim-genkey die Zeichenkette example.com.

• -b 2048 gibt an, dass ein Schlüssel in der Länge von 2048 Bits generiert werden soll. Größere Schlüssel sind momentan mit der gängigen Mail-Server-Infrastruktur inkompatibel. Standardmäßig verwendet opendkim-genkey 1024 Bits, was aber vielfach als nicht mehr als ausreichend sicher erachtet wird.

• -r gibt an, dass der Schlüssel ausschließlich zur Signatur von E-Mails verwendet werden darf (restricted).

• -s selector gibt eine Selektor-Zeichenkette an, um das Schlüsselpaar zu identifizieren (standardmäßig: default). Die Selektor-Zeichenkette bestimmt die Namen der Schlüsseldateien. -s 201611 bewirkt also, dass die Dateien 201611.txt und „201611.private` erzeugt werden. Vorsicht. Eventuell schon vorhandene Schlüsseldateien werden ohne Rückfrage überschrieben.

Um also Schlüssel zu erzeugen, die zum obigen Beispiel passen, führen Sie das folgende Kommando aus:

cd /etc/opendkim
opendkim-genkey -d kofler.info -b 2048 -r -s 201611

Die resultierenden Dateien sehen so aus:

cat 201611.private

  -----BEGIN RSA PRIVATE KEY-----
  totalGeheimBlaBla123
  ...
  -----END RSA PRIVATE KEY-----

cat 201611.txt 

  201611._domainkey IN TXT ( 
    "v=DKIM1; k=rsa; s=email; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCA...73Qzl5Czna79"
    "7955/zX7Bp10e/lATZbVtP6Qu6eC2TMpWx06bEDRZ...oAtNNuhQIDAQAB" 
  ) ; ----- DKIM key 201611 for kofler.info

Die Dateien müssen nun noch entsprechend der Angaben in key.table platziert werden. Zuletzt stellen Sie sicher, dass nur der Benutzer opendkim auf die Dateien und Verzeichnisse zugreifen darf:

cd /etc/opendkim
mv 201611.private keys/kofler.private
mv 201611.txt     keys/kofler.txt
chown -R opendkim:opendkim /etc/opendkim
chmod -R go-rwx /etc/opendkim/keys

DNS-TXT-Eintrag hinzufügen

Der nächste Schritt besteht darin, den öffentlichen Teil der DKIM-Schlüssels, also in der Logik dieses Beispiels den Inhalt von kofler.txt in einem TXT-Eintrag in der DNS-Konfiguration Ihres Hostnamens zu speichern. Dabei verwenden Sie die Zeichenkette vor dem Schlüsselwort IN für das Feld Hostname des DNS-Eintrags und den gesamten Text zwischen den runden Klammern für das Feld Destination. In der Weboberfläche meines Hosters sieht der Dialog zum Einrichten eines neuen DNS-Eintrags vom Typ TXT so aus:

Bis die Änderung der DNS-Daten im Internet allgemein verfügbar ist, dauert es möglicherweise mehrere Stunden. Die TXT-Einträge eines Hosts können Sie mit dem Kommando host -t TXT auslesen, wobei Sie Ihrem Domainnamen die Bezeichnung <selector>._domainkey voranstellen müssen, hier also 201611._domainkey.

host -t TXT 201611._domainkey.kofler.info

201611._domainkey.kofler.info descriptive text "v=DKIM1\; k=rsa\; s=email\; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2iAMG1lvjfnXmJKFsfLDCt+PYFc16Q4aQz/dKnpQXSuSvejqb9qGidz0XXItRHXvnzsD7yOly3iconl+kCfY1JbONPKXaObWep7GIXNPIW4tL/jbd886oUd/wTonK50ScCuejelWAQTHs25Q6zH6/ZWWy1vCVIet/+dsqkeJpZ1NFoQrk2uEcx8Yz7NAHcvSt/73Qzl5Czna79" "7955/zX7Bp10e/lATZbVtP6Qu6eC2TMpWx06bEDRZwE4mK0T1iCSHb0wnjLurvKouSnbXAoT+q/dLApTAohIqsmhK0O6z/2Gmo+f8g9JH+PVtyzY4zfvjxsXgWn6kmhdoAtNNuhQIDAQAB"

OpenDKIM testen

Die geänderten Einstellungen erfordern einen Neustart von OpenDKIM:

service opendkim restart

Sobald der auf dem Nameserver gespeicherte öffentliche Schlüssel verfügbar ist (das testen Sie mit dem Kommando host -t TXT, siehe oben), können Sie mit dem Kommando opendkim-testkey lokal überprüfen, ob alles korrekt eingerichtet ist. Sofern das Kommando keine Fehlermeldungen liefert, ist alles OK. Die Option -vvv bewirkt, dass das Kommando zumindest einige Debugging-Daten liefert.

opendkim-testkey -d kofler.info -s 201611 -vvv
  opendkim-testkey: using default configfile /etc/opendkim.conf
  opendkim-testkey: checking key '201611._domainkey.kofler.info'
  opendkim-testkey: key not secure
  opendkim-testkey: key OK

Key not secure weist darauf hin, dass kein DNSSEC verwendet wird. Das hat aber nichts mit DKIM zu tun. Sollte hingegen die Meldung record not found erscheinen, kann OpenDKIM den erforderlichen Schlüssel nicht finden — dann liegt wirklich ein Konfigurationsproblem vor.

Bevor Sie die Postfix-Konfiguration ändern

Ich gehe hier davon aus, dass Postfix schon läuft und als MTA aktiv ist. Änderungen im laufenden Betrieb sind natürlich immer heikel. Wenn Sie etwas falsch machen, kann es passieren, dass eintreffende E-Mails abgewiesen werden. Diese sind dann endgültig verloren sind.

Deswegen ist es besser, vor Beginn der Umbauten soft_bounce=yes in main.cf einzubauen (und natürlich ständig ein scharfes Auge auf die Logging-Dateien zu werfen). Mit soft_bounce=yes wandelt Postfix alle 5xx-Fehlern (Permanent Failure) in 4xx-Fehler (Persistent Transient Failure) um. Der Sender wird daher nach einiger Zeit einen neuerlichen Zustellversuch unternehmen, die E-Mail ist nicht verloren.

Vergessen Sie nicht, nach Fertigstellung und Test der geänderten Konfiguration wieder soft_bounce=no einzustellen!

Postfix-Konfiguration für OpenDKIM erweitern

Damit Postfix ausgehende E-Mails mit OpenDKIM signiert, muss OpenDKIM als Mail Filter (= Milter) eingerichtet werden. Dazu sind in der Postfix-Konfiguration die Parameter smtpd_milters und non_smtpd_milters vorgesehen. Wenn OpenDKIM der einzige Milter ist, sieht die korrekte Konfiguration so aus:

# in /etc/postfix/main.cf
milter_default_action = accept   
milter_protocol   = 6              
smtpd_milters     = inet:localhost:12345
non_smtpd_milters = inet:localhost:12345

Vielleicht gab es bisher schon Milter — dann kommt der OpenDKIM-Milter (getrennt durch ein Komma) eben dazu. Bei meinem Mail-Server ist z.B. zusätzlich auch SpamAssasin aktiv:

# in /etc/postfix/main.cf
milter_default_action = accept   
milter_protocol   = 6              
smtpd_milters     = unix:spamass/spamass.sock, inet:localhost:12345
non_smtpd_milters = inet:localhost:12345

Einige Anmerkungen zu den Parametern:

• milter_default_action = accept bedeutet, dass Postfix auch dann Mails akzeptieren soll, wenn ein Milter defekt ist, nicht reagiert, falsch konfiguriert ist etc.

• In vielen Anleitungen ist von milter_protocol = 2 die Rede. Das gilt aber nur für alte Postfix-Versionen (älter als 2.6). Bei aktuellen Postfix-Versionen gilt standardmäßig milter_protocol = 6. Die Konfiguration funktioniert also auch, wenn Sie die Einstellung ganz weglassen.

• Vielleicht fragen Sie sich, was der Unterschied zwischen smtpd_milters und non_smtpd_milters ist: Die smtpd_milters gelten für E-Mails, die über das SMTP-Protokoll geliefert werden. non_smtpd_milters gilt dagegen für lokale E-Mails, die z.B. durch sendmail oder durch ein PHP-Script erzeugt und versendet werden. In der obigen Konfiguration wird für solche Mails auf den Spam-Test verzichtet.

DKIM im Zusammenspiel Postfix/OpenDKIM testen

Als erstes senden Sie sich selbst eine Mail und werfen dann einen Blick in den Header. Dieser sollte eine Zeile enthalten, die mit DKIM-Signatur beginnt, z.B. wie im folgenden Beispiel:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kofler.info;
    s=201611; t=1479644038;
    bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
    h=To:From:Subject:Date:From;
    b=VI6TIDLrzG8nAUYWwt5QasKJkkgU+Sv8sPGC1fynSEGo0GSULGgCjVN6KXPfx1rgm
     1uX2sWET/oMCpxjBFBVUbM7yHGdllhbADa2SarzYhkoEuNhmo+yxGpXkuh0ttn4z7n
     OmkLwjrdLafMOaqSBrXcTMg/593b/EQXtouEvHqOG59d0fubIGCJBF6DG5gcITS9CP
     q9tiVwIDVuQqynL9Crodl+2IObcvl15MeK2ej322qrjrTij6vZOru9SeVno4LNTkQ7
     tOT4s14BGLx8aRe5YXZj38AWsR6DxkT6OzM+3TnOhIfX3ZdkufMz8AUnTNuLhViZ1M
     betE0x1iOi/HQ==

Senden Sie nun eine E-Mail von Ihrem eigenen Mail-Server an einen Mail-Server, von dem Sie wissen, dass er DKIM unterstützt und verwendet. Eine gute Wahl ist Google (also Gmail). In der Gmail-Weboberfläche öffnen Sie die E-Mail und führen Original anzeigen aus. Das Ergebnis sollte analog wie beim folgenden Screenshot aussehen:

Key Rotation

Aus Sicherheitsgründen wird empfohlen, die DKIM-Schlüssel zumindest vierteljährlich zu wechseln. Das ist allerdings mit hohem Aufwand verbunden: neue Schlüssel generieren, Konfigurationsdateien anpassen, DNS-TXT-Einträge anpassen etc. Zudem müssen bei jedem Wechsel für einige Tage beide Schlüssel in der DNS-Konfiguration bleiben, einerseits, weil sich DNS-Änderungen nur relativ langsam im Internet verbreiten, andererseits, weil E-Mails mitunter erst nach Tagen zugestellt werden (z.B. wenn ein Empfänger-Server vorübergehend nicht erreichbar ist) .

Für große Mail-Provider lässt sich der regelmäßige DKIM-Schlüsselwechsel sicher gut automatisieren. Entsprechende Scripts für den Schlüsselwechsel lassen sich natürlich auch für den privaten Mail-Server zusammenbasteln, aber solche Scripts stoßen bei den DNS-Daten an ihre Grenzen: Wer keinen eigenen Nameserver betreibt, wird die DNS-Konfiguration für die eigene Domain zumeist über die Weboberfläche seines Hosters ändern (und da man muss schon dankbar sein, wenn dort überhaupt die Möglichkeit besteht, TXT-Einträge zu verwalten). Das automatisierte Verändern der DNS-TXT-Einträge wird aber kaum möglich sein.

Ganz so zwingend wie von manchen Autoren angegeben scheint die Key Rotation nicht zu sein. Wenn Sie eine E-Mail via Gmail versenden, fügt Google die folgenden Zeilen in den Mail-Header ein:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=subject:to:references:from:message-id:date:user-agent:mime-version
         :in-reply-to:content-transfer-encoding;
        bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=;
        b=FGSZV2FXjjed0+ByOySbvQMcDM4v+MWXtLDBNU8pgnV6I2k2V0vd6dOpINS+F2e9fl
         k1sH/EJFeqhit5l8MxhhfCCkP0BNZi3PCQ22i75CPh3ghLz8sjk1W4N03ls/+k3kcPrI
         VcRoCN5LYlgxSGn4wCSfGFI+ctYiDMw3gGLJoRgTCGA9wLzNEZCSo1Y2agaDDpkgSr3P
         4BmcGBE/PzTD8TCWgLw+cRiLDkfA9YvK2A/kR7aQ6292wHkO1S2z6V4jYOir+YWJHQZh
         fPxWAZLeazJ7DvWoQXpI1W+nMgU84xgdAEGPHOXzEzJ33l8Hgq5jNrw6+M0aXhLrVj5k
         8Y9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:to:references:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-transfer-encoding;
        bh=wPz35cXFAjOtHhgvJJVlP3LVP7on2SV5azh+UjTRZMM=;
        b=X8pFM/V1hDFQL6oBOoDaYHl9xxUgCZvUmEa4AUjcWe7I9ZTX27wuTH6U926gHVUyY3
         fS4K9Iji+K9xFvcSVSU2wY8SDFcy1VlabECONlKX78nhZdWUFuX33C8uiI/Az+ATku9A
         SDo6yy8xi6jGxPuBQhbQ9lir6jlpakWUV52bnk6GDBvumVfn4rC+N/UMUn4SJo69wTV1
         6/Y436G01VkTMoec+yGpm4XFqksWSsoipLfBHQAiVFnGa1l7yDdbpuvnbNZxGvGj2u6G
         YjU2p3S9P3HcyclvWzDpS7KEU7NjRWXoWzUuGs/yJpOUyS9eXBwn39mzUsiXb2Ds/JTa
         wHYw==

Werfen Sie einen Blick auf die Selektoren der beiden DKIM-Signaturen: Der eine wurde offensichtlich 2012 eingerichtet, der andere 2013 :-)

DMARC

Wenn bei Ihrem Mail-Server sowohl SPF als als auch DKIM funktioniert, können Sie sich noch überlegen, Domain-based Message Authentication, Reporting and Conformance (DMARC, Wikipedia) zu aktivieren. Dazu geben Sie mit einem weiteren DNS-TXT-Eintrag öffentlich bekannt, dass Ihr Mail-Server SPF und DKIM unterstützt, und wie mit Mails verfahren werden soll, die Ihren Hostnamen in der Absenderadresse enthalten, die aber von anderen Mail-Servern versandt wurden bzw. die nicht korrekt mit DKIM signiert sind.

Das Einrichten von DMARC ist mit wenig Arbeit verbunden. Sie müssen lediglich einen weiteren DNS-TXT-Eintrag definieren, der als Hostname _dmarc verwendet und einen Eintrag gemäß der DMARC-Syntax aufweist. Dabei können Sie sich an den DMARC-Einstellungen andere Mail-Provider orientieren:

host -t TXT _dmarc.yahoo.com
  _dmarc.yahoo.com descriptive text 
  "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;"

host -t TXT _dmarc.gmail.com
  _dmarc.gmail.com descriptive text 
  "v=DMARC1\; p=none\; rua=mailto:mailauth-reports@google.com"

host -t TXT _dmarc.hotmail.com
  _dmarc.hotmail.com descriptive text 
  "v=DMARC1\; p=none\; pct=100\; rua=mailto:d@rua.agari.com\;
   ruf=mailto:d@ruf.agari.com\; fo=1"

• Am radikalsten ist Yahoo. (Diese Firma hat DMARC ursprünglich entwickelt.) Mails, die SPF und DKIM nicht einhalten, sollen ganz einfach verworfen werden. Fehlerberichte können an dmarc_y_rua@yahoo.com gesendet werden.

• Deutlich entspannter sehen Gmail und Hotmail die Sache: p=none schlägt vor, nicht korrekt signierte Mails dennoch zu akzeptieren (»Monitor-Modus«). Aber auch diese Mail-Provider sind an Fehlermeldungen interessiert und geben entsprechende Mail-Adressen an.

• GMX hat aktuell keinen DMARC-Eintrag.

Wie alle anderen Techniken ist auch DMARC umstritten. Wird DMARC wie bei Yahoo streng exekutiert, dann verursachen durch Mailing-Listen weitergeleitete Mails oft Probleme. Die meisten Programme für Mailing-Listen verändern die From-Zeile nämlich nicht, wodurch es beim Weiterleiten zu einer Diskrepanz zwischen dem angegebenen Absender und dem Mail-Server der Mailing-Liste kommt — siehe z.B. Yahoo killt Mailinglisten-Mitgliedschaften (heise.de). Eine Diskussion über SPF, DKIM und DMARC können Sie auch im Anschluss an den Blog-Beitrag gmx.de und web.de haben Mail-Rejects durch SPF (heinlein.de) lesen.

Wenn Sie also einen DMARC-Eintrag einrichten möchten, sollten Sie sich meiner Ansicht nach Gmail als Vorbild nehmen und DMARC ohne Reject-Regel nur im Monitoring-Modus aktivieren.

An die mit dem rua-Schlüsselwort angegebene Feedback-Adresse erhalten Sie nun von manchen Mail-Providern, die DKIM nutzen und an die Ihr Server Mails sendet, regelmäßig (zumeist täglich) Feedback in Form einer komprimierten XML-Datei. Die folgenden Zeilen zeigen einen derartigen Report, den Gmail an mich versandt hat. Demnach gibt es aktuell keine Probleme mit der Konfiguration:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>11979167709934618081</report_id>
    <date_range>
      <begin>1479686400</begin>
      <end>1479772799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>kofler.info</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>138.201.20.187</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>kofler.info</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>kofler.info</domain>
        <result>pass</result>
        <selector>201611</selector>
      </dkim>
      <spf>
        <domain>kofler.info</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Ein letzter Test

Auf Seiten wie http://isnotspam.com oder https://www.mail-tester.com können Sie Ihre Mail-Konfiguration testen. Wenn Sie diese Seite besuchen, erhalten Sie eine zufällige Mail-Adresse, an die Sie eine Test-Mail senden können. (Die Mail sollte allerdings einen »richtigen« Inhalt enthalten, nicht nur ‚Test‘ — sonst fällt sie beim Spam-Test durch.) Die E-Mail wird dann überprüft, und Sie erhalten einen Report, der z.B. so aussehen kann:

Quellen

Grundlagen

• https://de.wikipedia.org/wiki/DomainKeys
• https://de.wikipedia.org/wiki/Sender_Policy_Framework
• http://www.opendkim.org/
• https://www.heinlein-support.de/vortrag/spf-dkim-greylisting-der-neue-spamschutz
• https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf/
• https://de.wikipedia.org/wiki/DMARC
• https://en.wikipedia.org/wiki/DMARC (ausführlicher)
• https://support.google.com/a/answer/2466580
• Das Postfix-Buch von Peer Heinlein (leider seit 2007 nicht mehr aktualisiert und nicht als eBook verfügbar)
• Golem.de-Artikel über DKIM, SPF und DMARC

Konfigurationsanleitungen

• https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy
• https://www.linode.com/docs/email/postfix/configure-spf-and-dkim-in-postfix-on-debian-8
• https://thomas-leister.de/voraussetzungen-fuer-den-e-mail-versand-zu-grossen-providern/
• https://thomas-leister.de/sicherer-mailserver-dovecot-postfix-virtuellen-benutzern-mysql-ubuntu-server-xenial/
• https://help.ubuntu.com/community/Postfix/DKIM
• https://www.debinux.de/2014/11/dkim-verstaendnis-konfiguration-und-installation-von-opendkim/
• https://wiki.archlinux.org/index.php/OpenDKIM
• https://wordtothewise.com/2014/05/dkim-key-rotation

Konfiguration unter Ubuntu 24.04

• https://www.christopher-kunz.de/postfix-opendkim-ubuntu-signaturen-reparieren.html

Mail-Tester

• https://www.mail-tester.com
• http://isnotspam.com
• http://mxtoolbox.com