DMARC-Validation

SPF und DKIM erlauben beide die Prüfung einer eingehenden Mail, DMARC verbindet diese Tests mit einer Richtlinie und Reporting. Es gibt viele Seiten, die dazu was geschrieben haben aber wenn ich eine Unzustellbarkeit analysiere, dann stehe auch ich immer wieder vor der Frage, welche Quelle gültig und aktuell ist. Also pflege ich meinen eigenen Spickzettel und hier ist er öffentlich.

Ohne DMARC

Auch ohne dass eine Domain einen DMARC-Eintrag veröffentlicht hat, können SPF und DKIM funktionieren. Je nach Konfiguration des empfangenden Servers wird die Mail dann abgelehnt. Die Funktion ist schnell erklärt aber ist für das weitere Verständnis und insbesondere Abweichungen durch die Funktion "Alignment" wichtig. SPF und DKIM sind ohne DMARC zwei komplett unterschiedliche unabhängige Prüfungen und der der empfangende Mailserver entscheidet, wie er mit den Ergebnissen umgeht.

Methode

SPF

DKIM

Quelle

Die RFC 7208 beschreibt, dass ein Empfänger zwei Felder heranziehen sollte

  • RFC5321-MailFrom (Envelope)
  • HELO/EHLO

Beide Informationen sieht ein Endanwender normalerweise nicht. Einige Anbieter parsen aber auch den den "Return-Path" im Header, um eine Domain des Absenders zu ermitteln. 

DKIM möchte den Empfänger schützen und dieser sieht als Absender in seinem Mailclient das Feld "From" aus dem Header. DKIM liest hier die Domain aus

  • RFC5322-MailFrom (Header)

DNS-Eintrag

Damit der Empfänger einen SPF-Check machen kann, muss der Absender einen TXT-Record mit den IP-Adressen aller legitimen Mailserver als DNS-Name, IP-Adresse oder Include-Direktive veröffentlichen. Nach maximal 10 DNS-Abfragen stoppt eine Rekursion

Im DNS zur Absender-Domain muss es einen TXT-Eintrag geben, welcher den öffentlichen Schlüssel enthält. Der private Schlüssel wird auf dem absenden Mailserver hinterlegt.

Policy

Bei SPF kann der Administrator durch ein "-all" z.B. alle anderen IP-Adressen verbieten. Ein "~all" verrät genaugenommen, dass der Absender gar nicht sicher weiß, welche Server in seinem Namen was versenden.

DKIM sieht weder im Header noch per DNS eine Policy vor, wie mit einer Mail umgegangen wird, die den Test nicht besteht

Validierung

Der empfangende Server vergleicht, ob die einliefernde IP-Adresse in der Liste der erlaubten Adressen aufgeführt ist. Es ist nicht vorgeschrieben, wie er mit den Ergebnis umgeht. Die Prüfung kann schon mit dem Empfang des Envelope erfolgen. Wird aber DMARC genutzt, muss die Prüfung noch auf die Absenderdomain des FROM-Headers warten.

Die DKIM-Signatur wird im Header gespeichert und enthält die Domain, den Hinweis zum DNS-Eintrag, die Liste der berücksichtigten Felder und Hashwerte. Der Empfänger prüft die Signatur des DKIM-Eintrags anhand des öffentlichen Schlüssels und dann den Hashwert.

Ergebnis

Am Ende der Prüfung gibt es ein Ergebnis

  • PASS = Die Prüfung konnte per DNS einen SPF-Eintrag finden und die IP-Adresse ist gelistet.
  • None: Es konnte keine DNS-Domain ermittelt werden
  • Neutral: Es konnte nicht ermittelt werden, ob die IP-Adresse gültig ist
  • Fail: Die IP-Adresse ist nicht erlaubt und ein "-all" ist vorhanden
  • SoftFail: Die IP-Adresse ist nicht sicher erlaubt. Meist ist ein "~all" vorhanden
  • TemptError: Vermutlich gab es Fehler bei der DNS-Abfragen (Überlast, Timeout o.ä.)
  • PermError: Meist kann die Domain per DNS nicht aufgelöst werden

Wie der Mailserver damit umgeht, ist eine Frage der Konfiguration.

Eine Mail kann mehrere DKIM-Signaturen enthalten. Bewertet wird nur die Signatur, deren Domain (d=) zur Domain des Absenders im From-Header passt.

  • Pass: Es wurde mindestens eine Signatur gefunden, die gültig ist
  • Neutral: Schlechtes Format des DKIM-Eintrags
  • Fail: Die Signatur ist ungültig, d.h. die Mail wurde verändert
  • Fail: Es wurde kein öffentlicher Schlüssel per DNS gefunden

Wie der Mailserver damit umgeht, ist eine Frage der Konfiguration.

Mit DMARC

SPF hat mit dem "-all" ja schon eine Möglichkeit dem Empfänger einen Umgang mit Fail-Nachrichten zu empfehlen. Bei DKIM gibt es dies so nicht. Hier kommt DMARC als TXT-Record ins Spiel, über den Sie viele Details steuern können.

  • Policy (Reject, Quarantine, None)
    Der Inhaber der Absenderdomain kann mittels DMARC einstellen, wie die empfangene Seite die Mails hinsichtlich SPF und DKIM prüfen sollte. Empfangende Server "sollten" sich daran orientieren aber natürlich obliegt es jedem Administrator, seine Nutzer zu schützen.
  • Alignment (relaxed/strict)
    Sie können für SPF und DKIM separat vorgeben, wie der empfangende Server den Grade der Übereinstellung von der Domain im Envelope-From mit dem Mail-Header prüfen soll. Default ist "relaxed".
  • RUF/RUA
    Gerade bei der Einführung möchte man als Absender erst mal eine Simulation fahren. Dazu können Sie über die ruf= und rua=-Einträge einen Report per Mail verlangen und so einige Tage oder Wochen mal sehen, wer alles so mit ihrer Domain E-Mails versendet. So bauen sie langsam dann ihren SPF-Record auf und konfigurieren DKIM auf Servern, ehe sie die Richtlinie dann strenger machen.

Es gibt noch jede weitere Header und sie können mit "sp=" auch die Gültigkeit des DMARC-Eintrags für Subdomains steuern. Ich möchte mich hier aber auf eine einfache Domain wie msxfaq.de beschränken, um die Überprüfung einer eingehenden Mail zu demonstrieren. Beachten Sie dabei, dass DMARC die Ergebnisse von SPF und DKIM kombiniert und es reicht, wenn ein Ergebniss ein "Pass" hat.

SPF DKIM Gesamtergebnis

Pass

Pass

Pass

Pass

Fail

Pass

Fail

Pass

Pass

Fail

Fail

Fail

Es muss natürlich ein "Pass", damit DMARC zufrieden ist. Ein "TempFail" oder "Neutral" bei SPF ist als "Fail" zu werten.

DMARC Alignment

Während bei SPF nur die Domain des für den Empfänger unsichtbaren SMTP Envelope MAILFROM geprüft wird, nutzt DKIM die Domain aus dem "From"-Feld des SMTP-Headers ohne zu sagen, ob ein DKIM=FAIL schlimm ist. DMARC schreibt über die Policy aber vor, wie ein Empfänger sich bei einem SPF=FAIL und DKIM=FAIL verhalten soll. Allerdings schreibt DMARC auch vor, welche Domains maßgeblich sind und hier steht der vom Anwender "sichtbare" Empfänger im Vordergrund:

Ein Empfänger "sieht" in seinem Mailclient eigentlich nur den Absender aus dem SMTP-Header, d.h. das "From:"-Feld im Header und daher sind sowohl DKIM als auch DMARC darauf ausgerichtet.
SPF prüft den EnvelopeFrom, der vom Anwender nicht gesehen wird.
DKIM prüft den Header From und erwartet eine exakte Übereinstimmung
DMARC forderte eine Prüfung beider Felder. Strict bedeutet dabei "genau" und relaxed erlaubt auch Subdomains

Verkürzt kann ich daher schreiben, dass die Domain passen müssen. Das ist aber nicht ganz richtig, denn DMARC kennt schon noch den Unterschied zwischen "strict" und "relaxed" um z.B. Subdomains zuzulassen Dazu kennt DMARC die "Organizational Domain", anhand der Subdomains auf die Hauptdomäne zurückgeführt werden und dabei auch Besonderheiten einiger Länder versteht, z.B.

mail1.msxfaq.de       -> msxfaq.de
vertrieb.msxfaq.de    -> msxfaq.de
sales.example.co.uk   -> example.co.uk
sales.example.gov.uk  -> example.gov.uk

Mit der "Relaxed"-Einstellung können Sie Aufgabenstellungen entschärfen, bei denen sie z.B. mehrere Dienstleister und Server haben, die sich mit Subdomains im EHLO melden oder Absender eine Subdomain beim Versand nutzen. Ihr zentraler Server muss so nicht für jede Domain eine eigene DKIM-Konfiguration vorhalten. Das gilt natürlich nur mit einem "Relaxed" in der DMARC-Prolicy. Ein PASS erhalten die Verfahren also immer bei: 

Verfahren Ohne DMARC DMARC strict DMARC Relaxes
SPF

Envelope-From und IP-Adresse

 aspf=s
Envelope-From = HeaderFrom und IP-Adresse ist im SPF-Record aufgeführt		 aspf=s
OrgDomain von EnvelopeFrom entspricht Headerfrom
DKIM

Header-From und DKIM D=

 adkim=s
Envelope-From = HeaderFrom und DKIM-Signatur mit D=Domain ist gültig 		adkim=s
OrgDomain der d=Domain entspricht Headerfrom

Wie das "PASS" dann weiter verwendet wird ist nur definiert, wenn es eine DMARC-Policy gibt

Flussdiagramm

Es gibt mehrere Diagramme im Internet, wie DMARC, DKIM u.a. funktionieren. Microsoft hat dazu ein sehr umfangreiches Diagramm veröffentlicht, welches aber vermutlich den ein oder anderen Betrachter eher verwirrt, da es mehrere Startpunkte hat und dann die Ergebnisse zusammengeführt werden. Ich habe mir eine vereinfache Variante erstellt. Für die Analyse brauchen wie drei Informationen aus einer Mail:

  • A = MailFrom-Domain  oder EHLO
    Das ist die Domain, die der MTA aus dem MAIL FROM oder EHLO ermittelt.
  • B = HeaderFrom-Domain
    Diese Adresse ist die From-Domain, die der Absender vorgibt zu sein.
  • C = DKIM-Domain
    Das ist die Domain einer vorhandenen DKIM-Signatur, die für die DKIM-Prüfung herangezogen wurde. Is ist entweder mit HeaderFrom-Domain identisch oder hat zumindest die gleiche OrganizationDomain

Da DMARC ein "SPF-Alignment" fordert, kann ein Empfänger die Mail nicht mehr direkt nach dem Envelope ablehnen, wenn die MAIL-FROM und IP-Adressen bei SPF fehlschlagen. Er muss schon das DATA mit dem Header zulassen, um die DMARC-Prüfung zu starten.

Nachdem die Mail komplett empfangen wurde, können SPF und DKIM parallel starten. Dies bedeutet nicht, dass der Empfänger dem einliefernden Mailserver schon ein "200 OK" gesendet hat.

Idealerweise erfolgt der SPF/DKIM/DMARC-Check noch vorher, damit der prüfende Server die Mail bei Unstimmigkeiten mit einem Fehler ablehnen kann und der einliefernde Server sich um den NDR kümmern muss

Ich bin nicht sicher, ob diese Flussdiagramm alle Fälle abdeckt. Es gibt doch noch viele Sonderfälle und es unterscheidet sich auch deutlich von dem Diagramm, was Microsoft angeblich implementiert hat.

Weitere Links