MX, SPF, DKIM und DMARC erklärt: So greifen sie ineinander

Vier Arten von DNS-Einträgen entscheiden darüber, wie E-Mails für Ihre Domain zugestellt werden und ob Empfänger glauben, dass eine Nachricht wirklich von Ihnen stammt. Meist werden sie einzeln erklärt, und dabei geht der wichtigste Punkt unter: Jeder Eintrag schließt eine Lücke, die die anderen offen lassen.

Dieser Leitfaden geht alle vier durch, dazu die Fehler, die in echten Zonen am häufigsten auftauchen, und eine Reihenfolge für die Einführung, die Ihre legitimen E-Mails nicht gefährdet.

Die Kurzfassung

MX sagt, wohin E-Mails an Ihre Domain zugestellt werden.
SPF sagt, welche Server E-Mails mit Ihrer Domain im Envelope-Absender versenden dürfen.
DKIM hängt eine kryptografische Signatur an, die belegt, dass eine Nachricht von einer Domain autorisiert und unterwegs nicht verändert wurde.
DMARC verknüpft SPF und DKIM mit der From-Adresse, die Menschen tatsächlich sehen, sagt Empfängern, was zu tun ist, wenn beides scheitert, und schickt Ihnen Berichte.

Bei MX geht es um den Empfang. Bei den anderen dreien geht es um den Versand.

MX: wohin die E-Mail geht

$ dig +short MX example.com
10 mx1.mail.example.net.
20 mx2.mail.example.net.

Absender versuchen es zuerst mit der niedrigsten Präferenzzahl und weichen bei Fehlern auf höhere Zahlen aus. Gleiche Zahlen teilen sich die Last.

Die Regeln, auf die es beim MX-Record ankommt:

Das Ziel muss ein Hostname mit A- oder AAAA-Record sein. Es darf keine IP-Adresse und kein CNAME sein.
Gibt es keinen MX-Record, weichen Absender auf den A/AAAA-Record der Domain selbst aus. Das ist fast nie gewollt.
Eine Domain, die niemals E-Mails empfangen soll, kann einen Null-MX veröffentlichen: 0 . (Präferenz null, Ziel ein einzelner Punkt). Absender scheitern dann sofort, statt es tagelang erneut zu versuchen.

SPF: welche Server versenden dürfen

SPF ist ein einzelner TXT-Record an der Domain:

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ip4:192.0.2.10 -all"

Der empfangende Server nimmt die Domain aus dem Envelope-Absender (dem Return-Path, nicht dem sichtbaren From-Header), holt deren SPF-Record und prüft, ob die IP-Adresse der eingehenden Verbindung dazu passt. Das all am Ende entscheidet, was mit allen anderen geschieht: -all bedeutet Fail, ~all Softfail, ?all keine Aussage.

Zwei Einschränkungen sind eingebaut:

SPF prüft eine Domain, die der Empfänger nie zu Gesicht bekommt. Für sich genommen hindert es niemanden daran, Ihre sichtbare From-Adresse zu fälschen.
SPF scheitert bei Weiterleitungen. Wird eine Nachricht weitergeleitet, verbindet sich die IP-Adresse des Weiterleitenden mit dem endgültigen Empfänger, und diese Adresse steht nicht in Ihrem Record.

DKIM: eine Signatur, die mit der Nachricht reist

Bei DKIM signiert der sendende Server ausgewählte Header und den Nachrichtentext mit einem privaten Schlüssel und fügt einen DKIM-Signature-Header hinzu. Der öffentliche Schlüssel liegt im DNS:

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

s2026 ist der Selektor: eine beliebige Bezeichnung, die das sendende System wählt. Im Signatur-Header erscheint er als s=s2026 neben der signierenden Domain d=example.com. Eine Domain kann beliebig viele Selektoren haben, einen je Versanddienst und einen je Schlüsselwechsel.

Daraus folgt etwas, worüber viele stolpern: „Den DKIM-Record“ einer Domain kann man nicht nachschlagen. Das DNS kennt keine Möglichkeit, die Namen unter _domainkey aufzulisten. Sie brauchen den Selektor, und der verlässliche Weg dorthin führt über die Header einer Nachricht, die die Domain wirklich versendet hat.

Eine einfache Weiterleitung übersteht DKIM, weil die Signatur mit der Nachricht reist. Sie bricht, wenn eine Zwischenstation signierte Inhalte ändert, und genau das tun viele Mailinglisten, wenn sie eine Fußzeile oder ein Betreff-Kürzel einfügen.

DMARC: Alignment, Richtlinie und Berichte

DMARC ist ein TXT-Record unter _dmarc:

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

Er bringt drei Dinge mit.

Alignment. Eine Nachricht besteht DMARC, wenn SPF besteht und die Envelope-Domain zur From-Domain passt, oder wenn DKIM besteht und die d=-Domain zur From-Domain passt. Ein einziges bestandenes Verfahren mit Alignment genügt. Standardmäßig ist das Alignment „relaxed“, mail.example.com passt also zu example.com.

Richtlinie. p=none bittet Empfänger, nichts zu unternehmen. p=quarantine bittet sie, Fehlschläge als verdächtig zu behandeln (meist: Spam-Ordner), und p=reject bittet sie, die Nachricht abzulehnen. sp= legt eine eigene Richtlinie für Subdomains fest.

Berichte. Empfänger schicken täglich aggregierte XML-Berichte an die rua-Adresse: welche IP-Adressen E-Mails in Ihrem Namen versendet haben, wie viele Nachrichten es waren und ob SPF und DKIM bestanden haben und das Alignment stimmte. Über diese Berichte finden Sie die Absender, die Sie vergessen hatten.

Das Alignment ist der Grund, warum eine Nachricht „SPF bestehen“ und trotzdem an DMARC scheitern kann. Eine Newsletter-Plattform, die ihre eigene Bounce-Domain verwendet, besteht SPF für ihre Domain, und die passt nicht zu Ihrer. Abhilfe schafft normalerweise ein eigener Return-Path oder, besser, die DKIM-Signatur mit Ihrer eigenen Domain bei dieser Plattform.

Die häufigsten Fehler

Mehrere SPF-Records

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ~all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

Zwei Records, die mit v=spf1 beginnen, sind ein permanenter Fehler (permerror). SPF scheitert dann für jede Nachricht. Meist passiert das, wenn jemand die Einrichtungsanleitung eines neuen Dienstleisters wörtlich befolgt. Führen Sie beide zu einem Record mit beiden Includes zusammen.

Das Limit von 10 DNS-Abfragen

Ein Empfänger darf bei der Auswertung von SPF höchstens zehn DNS-Abfragen durchführen. include, a, mx, exists, redirect und ptr zählen jeweils, und Includes sind verschachtelt: Ein einziges Include eines Dienstleisters kann allein drei oder vier Abfragen kosten. ip4, ip6 und all kosten nichts. Wer über zehn kommt, erhält wieder permerror.

Abhilfe, in der Reihenfolge der Präferenz: Dienste entfernen, die Sie nicht mehr nutzen. Massenversender auf eine Subdomain mit eigenem SPF-Record verlegen. Bei Diensten, die es unterstützen, auf DKIM mit Alignment setzen und deren Include streichen. Vorsicht bei „SPF-Flattening“, das die IP-Adressen des Dienstleisters in Ihren Record kopiert: Es veraltet ohne Vorwarnung, sobald der Dienstleister seine Adressbereiche ändert.

`+all`

v=spf1 +all autorisiert jeden Server im Internet. Das ist schlimmer als gar kein Record, weil es aktiv behauptet, gefälschte E-Mails seien legitim. ?all ist kaum besser.

Der Mechanismus `ptr`

Langsam, unzuverlässig, und die SPF-Spezifikation selbst rät davon ab. Entfernen Sie ihn.

`p=none` für immer

p=none ist ein Beobachtungsmodus. Er liefert Berichte und keinen Schutz: Jeder kann weiterhin Ihre Domain in die From-Zeile setzen, und Empfänger stellen die Nachricht so zu, wie sie es ohnehin getan hätten. Viele Domains veröffentlichen p=none, um die Checkliste für Massenversender abzuhaken, und bleiben dann dort stehen. Sind die Berichte seit Wochen sauber, gibt es keinen Grund zu verharren.

Domains vergessen, die nichts versenden

Geparkte Domains und Domains, die nur für Websites dienen, werden gerade deshalb gefälscht, weil niemand auf sie achtet. Riegeln Sie sie ab:

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         MX   0 .

DMARC sicher einführen

Absender erfassen. Postfachanbieter, Website- und Anwendungs-E-Mails, CRM, Newsletter-Tool, Rechnungsstellung, Helpdesk, Monitoring-Alarme. Was Sie vergessen, fällt später aus.
SPF in Ordnung bringen. Ein Record, weniger als zehn Abfragen, am Ende ~all oder -all.
DKIM überall einschalten. Aktivieren Sie bei jedem Dienst die Signatur mit Ihrer Domain in d=. Das ist der wichtigste Schritt, denn DKIM sorgt dafür, dass DMARC auch nach einer Weiterleitung besteht.
p=none mit rua-Adresse veröffentlichen. Nutzen Sie ein Postfach oder einen Dienst zur Berichtsauswertung. Rohes XML von Hand zu lesen ist mühsam.
Zwei bis vier Wochen lang Berichte lesen. Suchen Sie nach legitimen Quellen, deren Alignment scheitert. Beheben Sie jede an der Quelle.
Auf p=quarantine wechseln. Bei großem Volumen gehen Sie mit pct= schrittweise vor, zum Beispiel 10, dann 50, dann 100. Lesen Sie weiter die Berichte.
Auf p=reject wechseln. Entscheiden Sie gesondert, ob Subdomains eine eigene sp=-Richtlinie brauchen.
Weiter beobachten. Neue Tools werden eingeführt, ohne dass jemand der Person Bescheid gibt, die das DNS verantwortet. Aus den Berichten erfahren Sie es.

Rechnen Sie mit einem kleinen Rest an Fehlschlägen, die Sie nicht beheben können, vor allem von Mailinglisten und eigenwilligen Weiterleitungen. Viele Empfänger fangen diese mit ARC oder eigenen Heuristiken ab. Das ist ein Grund, behutsam vorzugehen, aber kein Grund, bei p=none zu bleiben.

Was DNS-Einträge nicht leisten

Korrekte MX-, SPF-, DKIM- und DMARC-Records bedeuten, dass Empfänger überprüfen können, ob eine E-Mail von Ihrer Domain autorisiert ist. Sie bedeuten nicht, dass Ihre E-Mail im Posteingang landet. Postfachanbieter gewichten außerdem die Reputation Ihrer Domain und Ihrer sendenden IP-Adressen, Beschwerderaten, Listenqualität, Inhalt und die Art, wie Empfänger mit Ihren E-Mails umgehen. Nichts davon steht im DNS.

Authentifizierung ist die Eintrittskarte. Große Anbieter verlangen sie inzwischen von Massenversendern, und ohne sie werden Sie aussortiert, bevor irgendetwas anderes betrachtet wird. Mit ihr werden Sie danach beurteilt, wie Sie tatsächlich versenden.

Eine DNS-Prüfung kann auch nicht beweisen, dass E-Mails fließen. Sie kann zeigen, dass Ihre veröffentlichte Richtlinie in sich stimmig ist, und das ist der Teil, den Sie von der Zone aus steuern.

Mit OrbitProbe prüfen

Die MX-Abfrage von OrbitProbe liest die MX-, SPF- und DMARC-Records einer Domain und weist auf die oben beschriebenen Probleme hin: mehrere SPF-Records, zu viele Abfragen, +all, ein fehlender DMARC-Record oder eine Richtlinie, die bei p=none stehen geblieben ist. Für DKIM suchen Sie Ihren Selektor in den Headern einer versendeten Nachricht und fragen selector._domainkey.ihredomain als TXT-Record ab. Wenn Sie wissen möchten, wann sich diese Einträge ändern, führt eine DNS-Änderungsüberwachung im Workspace eine Historie.

Zum Weiterlesen: Wenn Nachrichten trotz allem im Spam-Ordner landen, arbeiten Sie die DNS-Checkliste für E-Mails im Spam ab. Die Grundlagen zu MX- und TXT-Records stehen in DNS-Einträge erklärt.