SPF, DKIM und DMARC: was jeder Eintrag prüft und wie man ihn setzt

SPF, DKIM und DMARC sind drei TXT-Einträge im DNS Ihrer Domain, mit denen ein empfangender Mailserver entscheiden kann, ob eine Nachricht, die angeblich von Ihnen kommt, das auch wirklich tut. Es sind getrennte Verfahren, sie beantworten getrennte Fragen, sie scheitern auf unterschiedliche Weise — und die Reihenfolge, in der Sie sie einrichten, ist wichtiger, als die meisten Anleitungen zugeben.

Was belegen SPF, DKIM und DMARC eigentlich?

Drei verschiedene Behauptungen, unabhängig voneinander geprüft.

SPF ist eine Liste der Server, die für Ihre Domain senden dürfen. Der Empfänger nimmt die IP-Adresse des sendenden Servers und fragt, ob Ihre Domain sie autorisiert hat.

DKIM ist eine kryptografische Signatur über die Nachricht. Der sendende Server signiert eine Auswahl von Headern und den Nachrichtenkörper mit einem privaten Schlüssel; der Empfänger holt den passenden öffentlichen Schlüssel aus Ihrem DNS und prüft, ob sich an dem Signierten unterwegs etwas geändert hat.

DMARC ist die Richtlinie obendrauf. Sie sagt Empfängern, was bei einem Fehlschlag der beiden ersten Prüfungen zu tun ist, und stellt eine Anforderung, die keine der beiden für sich stellt: Die von SPF oder DKIM geprüfte Domain muss zu der Domain passen, die ein Mensch im From:-Header sieht. Genau darum geht es. Ohne diesen Abgleich kann jeder SPF für eine Domain bestehen, die ihm gehört, und trotzdem Ihre Adresse in die From:-Zeile schreiben.

Was steht in einem SPF-Eintrag?

Ein einzelner TXT-Eintrag auf der Domain-Wurzel, beginnend mit v=spf1 und endend mit einem all-Mechanismus:

example.com.  IN  TXT  "v=spf1 include:_spf.provider.net -all"

In der Praxis scheitert SPF an vier Dingen.

Zwei Einträge. Eine Domain darf genau einen v=spf1-Eintrag veröffentlichen. Bei zweien liefert die Auswertung permerror, was als Fehlschlag zählt. Zwei Anbieter bedeuten einen Eintrag mit zwei include:-Termen.

Das Zehn-Lookup-Limit. Jeder include:-, a-, mx-, ptr- und exists-Term kostet einen DNS-Lookup, verschachtelte Includes zählen mit. Über zehn hinaus lautet das Ergebnis permerror. Lange Ketten von Anbieter-Includes reißen diese Grenze unbemerkt.

Das falsche all. -all weist Empfänger an, alles von einem nicht gelisteten Server abzulehnen. ~all ist ein Softfail, den die meisten Empfänger annehmen und markieren. Beginnen Sie mit ~all und ziehen Sie an, sobald die Reports sauber sind.

Weiterleitungen. SPF prüft den Envelope-Absender im Return-Path, nicht den From:-Header. Eine weitergeleitete Nachricht kommt vom Server des Weiterleitenden, den Ihr Eintrag nicht führt — SPF scheitert also, ohne dass am Eintrag etwas falsch wäre.

Wie funktioniert die DKIM-Signatur?

Der sendende Server erzeugt ein Schlüsselpaar. Die private Hälfte bleibt auf dem Server, die öffentliche kommt unter einem Selector Ihrer Wahl ins DNS:

sel1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Beim Versand bildet der Server einen Hash über den Nachrichtenkörper und eine gewählte Menge von Headern, signiert ihn und hängt einen DKIM-Signature-Header an, der die Domain in d= und den Selector in s= nennt. Der Empfänger liest diese beiden Felder, holt <selector>._domainkey.<domain> und prüft.

Den Selector gibt es, damit Sie mehr als einen Schlüssel gleichzeitig vorhalten können — genau das macht Rotation möglich: neuen Schlüssel veröffentlichen, Signierung umstellen, alten Eintrag entfernen, sobald nichts mehr damit signiert wird.

DKIM übersteht Weiterleitungen, SPF nicht, weil die Signatur mit der Nachricht reist. Es bricht, wenn unterwegs etwas an den signierten Teilen umgeschrieben wird — Mailinglisten, die eine Fußzeile anhängen oder den Betreff ändern, sind der häufige Fall.

Was entscheidet eine DMARC-Richtlinie?

Ein TXT-Eintrag auf der Subdomain _dmarc:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

p ist die Anweisung an Empfänger: none heißt nichts tun außer berichten, quarantine heißt Fehlschläge als verdächtig behandeln, reject heißt rundweg ablehnen. rua ist die Adresse für aggregierte Reports und der Grund, den Eintrag lange vor jeder Durchsetzung zu veröffentlichen.

DMARC besteht, wenn SPF besteht und seine Domain zur From:-Domain passt, oder wenn DKIM besteht und sein d= passt. Eines von beiden genügt. Alignment ist standardmäßig relaxed: Es müssen die organisatorischen Domains übereinstimmen, mail.example.com passt also zu example.com. Strict verlangt Gleichheit.

In welcher Reihenfolge richtet man sie ein?

Erst MX, dann SPF und DKIM, dann DMARC auf p=none, dann Durchsetzung — und der Abstand zwischen den letzten beiden bemisst sich in Wochen, nicht in Minuten.

1. MX. Mail muss ankommen, bevor es etwas bedeutet, sie zu authentifizieren.
2. SPF und DKIM gemeinsam. Beide ergänzen nur und lehnen für sich keine Mail ab.
3. DMARC auf p=none mit einer rua-Adresse. Für Empfänger ändert sich nichts, die Reports beginnen zu laufen.
4. Die Reports lesen. Sie nennen Absender, die Sie vergessen hatten: das Rechnungssystem, das CRM, die Monitoring-Alarme, wozu auch immer sich das Marketing angemeldet hat. Jeder davon kommt entweder in SPF, signiert künftig mit DKIM, oder hört auf, Ihre Domain zu benutzen.
5. p=quarantine, dann p=reject. Umstellen, sobald die Reports nur noch Fehlschläge zeigen, die Sie als Fälschung erkennen.

p=reject zu veröffentlichen, bevor man Reports gelesen hat, ist der übliche Weg, legitime Mail verschwinden zu lassen. Die Fehlschläge sind für Sie still und für den Absender unsichtbar.

Wie prüft man, ob die Einträge stimmen?

Fragen Sie sie so ab, wie ein Empfänger es tut:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT sel1._domainkey.example.com
dig +short TXT _dmarc.example.com

Schicken Sie dann eine echte Nachricht an ein Konto anderswo und lesen Sie den Authentication-Results-Header, mit dem sie ankommt. Dieser Header ist das Urteil des Empfängers über alle drei Prüfungen, Alignment eingeschlossen — und das verrät Ihnen kein noch so gründlicher Blick ins eigene DNS:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Achten Sie besonders auf header.d und header.from. Wenn die beiden nicht übereinstimmen, scheitert DMARC, wie grün die anderen Zeilen auch aussehen.

Was leisten diese Einträge nicht?

Sie authentifizieren eine Domain. Über den Inhalt einer Nachricht sagen sie nichts, über Verschlüsselung ebenfalls nichts.

Eine Nachricht kann alle drei Prüfungen bestehen und trotzdem Betrug sein, solange sie ehrlich darüber ist, welche Domain gesendet hat — Angreifer registrieren ähnlich aussehende Domains und veröffentlichen dafür tadellose Einträge. Verschlüsselt wird durch diese Einträge auch nichts: Transportsicherheit ist TLS zwischen den Stationen, und ob die Nachricht dort verschlüsselt liegt, wo sie zur Ruhe kommt, ist eine eigene Frage mit einer eigenen Antwort.

Was sie beheben, ist die Art von Fälschung, die genau Ihre Domain in die From:-Zeile setzt. Das war vorher kostenlos, und nach p=reject ist es das nicht mehr.