SPF, DKIM, DMARC und MX erklärt

Vier Familien von DNS-Einträgen tragen einen großen Teil der Betriebsregeln einer eigenen E-Mail-Domain. MX leitet eingehende E-Mails weiter. SPF autorisiert die Versandinfrastruktur. DKIM fügt Nachrichten eine überprüfbare Domain-Signatur hinzu. DMARC prüft, ob SPF oder DKIM mit der für den Empfänger sichtbaren Domain übereinstimmt, und veröffentlicht eine Durchsetzungsrichtlinie.

Sie arbeiten zusammen, lösen jedoch jeweils ein eigenes Problem. Ein Domain-Administrator sollte diese Grenzen verstehen, bevor er einen Anbieter verbindet oder E-Mails migriert.

Der private E-Mail-Dienst für eigene Domains von Thelemail erzeugt und prüft die erforderlichen Einträge. Dieser Leitfaden erläutert die Bedeutung der Einträge, damit Sie die resultierende Konfiguration sicher prüfen können.

MX wählt die Server für eingehende E-Mails aus

Ein MX-Eintrag gibt an, welcher Host E-Mails für eine Domain annimmt. Jeder Eintrag hat einen Präferenzwert und einen Ziel-Hostnamen. Niedrigere Präferenzwerte werden zuerst versucht. Mehrere Einträge mit derselben Präferenz können Versuche auf gleichwertige Server verteilen, während Einträge mit höheren Zahlen häufig alternative Zustellwege bereitstellen.

Das Ziel ist ein Hostname, der zu einer Adresse aufgelöst wird. Geben Sie die Werte exakt so ein, wie der E-Mail-Anbieter sie bereitstellt. DNS-Oberflächen behandeln den Zonennamen und den abschließenden Punkt unterschiedlich. Betrachten Sie daher das veröffentlichte Ergebnis als maßgebliche Fassung.

MX wirkt sich auf die eingehende Weiterleitung aus. Es sagt nichts darüber aus, welche Systeme im Namen der Domain versenden dürfen. Diese Autorisierung erfolgt durch SPF und DKIM, während DMARC die Übereinstimmung der Identitäten bewertet.

Bereiten Sie bei einer Anbietermigration den neuen Dienst vor, bevor Sie MX ersetzen. Erstellen Sie zuerst jedes Postfach, jeden Alias und jede gemeinsame Adresse. Der Leitfaden zur stufenweisen MX-Umstellung behandelt TTL-Planung, Überwachung der Überschneidung und Rückkehr zum vorherigen Zustand.

SPF autorisiert den Umschlagabsender

Sender Policy Framework, kurz SPF, veröffentlicht eine TXT-Richtlinie, die Systeme benennt, die unter Verwendung einer Domain im SMTP-Umschlag versenden dürfen. Empfangende Server vergleichen die verbindende IP-Adresse mit den Mechanismen in dieser Richtlinie.

Die Umschlagidentität wird häufig als Return-Path oder MAIL-FROM-Adresse bezeichnet. Sie empfängt unzustellbare Nachrichten und kann sich von der in einem E-Mail-Client sichtbaren From-Adresse unterscheiden. Ein reines SPF-Pass-Ergebnis kann daher eine Domain verwenden, die nicht mit dem sichtbaren Absender zusammenhängt.

Eine SPF-Richtlinie kann direkte IP-Bereiche und vom Anbieter gepflegte Richtlinien autorisieren. Zu den häufigen Mechanismen gehören ip4, ip6, a, mx und include. Der abschließende Qualifizierer gilt für nicht übereinstimmende Quellen. Ihr Anbieter sollte die erforderlichen Elemente der Richtlinie bereitstellen.

Eine SPF-Richtlinie pro Domain beibehalten

Eine Domain sollte einen SPF-Eintrag veröffentlichen, der mit v=spf1 beginnt. Mehrere separate SPF-Einträge verursachen einen permanenten Auswertungsfehler. Wenn eine Website-Plattform, ein Abrechnungssystem und ein Postfachanbieter alle E-Mails für die Domain versenden, kombinieren Sie deren autorisierte Mechanismen in einer Richtlinie.

Die SPF-Auswertung erlaubt höchstens zehn Mechanismen und Modifikatoren, die DNS-Abfragen auslösen. Verschachtelte include-Richtlinien werden auf dieses Limit angerechnet. Eine Überschreitung führt zu einem permanenten Fehler. Entfernen Sie stillgelegte Absender und erwägen Sie eigene Subdomains für unterschiedliche E-Mail-Zwecke.

Weiterleitung kann SPF beeinflussen, weil der weiterleitende Server eine Verbindung von einer neuen IP-Adresse herstellt und dabei eine frühere Umschlagdomain beibehält. Sender Rewriting Scheme kann eine neue autorisierte Umschlagidentität bereitstellen. DKIM kann eine Weiterleitung überstehen, wenn der signierte Inhalt unverändert bleibt.

DKIM signiert die Nachricht mit einem Domain-Schlüssel

DomainKeys Identified Mail, kurz DKIM, gibt einem Versandsystem einen privaten Signaturschlüssel. Seine Kopfzeile DKIM-Signature enthält die signierende Domain, den Selektor, die signierten Kopfzeilen und einen Hash des Nachrichtentextes. Der Empfänger ruft den öffentlichen Schlüssel über DNS ab und überprüft die Signatur.

Der DNS-Name kombiniert den Selektor mit _domainkey und der signierenden Domain. Ein Anbieter stellt den Eintrag mit dem öffentlichen Schlüssel oder einen darauf verweisenden CNAME bereit. Für Schlüsselrotation und mehrere Versanddienste können mehrere Selektoren nebeneinander bestehen.

Eine erfolgreiche DKIM-Prüfung zeigt, dass der signierte Inhalt die Übertragung unverändert überstanden hat und ein Inhaber des privaten Schlüssels die Signatur erstellt hat. DMARC prüft anschließend die Übereinstimmung zwischen der signierenden Domain und der sichtbaren From-Domain.

Mailinglisten, Gateways und Sicherheitsprodukte können signierte Inhalte verändern und dadurch eine DKIM-Signatur ungültig machen. Prüfen Sie die Kopfzeile Authentication-Results und den Nachrichtenweg, bevor Sie den DNS-Schlüssel ändern.

Selektoren bewusst rotieren

Für eine sichere DKIM-Rotation veröffentlichen Sie den neuen Schlüssel, signieren mit dem neuen Selektor, prüfen die Ergebnisse und behalten den früheren öffentlichen Schlüssel während des Übergangszeitraums bei. Beschränken Sie private Schlüssel auf autorisierte Versandsysteme.

DMARC verbindet die Authentifizierung mit der sichtbaren From-Domain

Domain-based Message Authentication, Reporting and Conformance, kurz DMARC, wird unter _dmarc innerhalb der Domain veröffentlicht. Es bewertet die Domain in der sichtbaren From-Kopfzeile anhand der SPF- und DKIM-Ergebnisse.

DMARC besteht, wenn mindestens einer dieser Wege erfolgreich ist:

• SPF besteht, und seine authentifizierte Umschlagdomain stimmt mit der sichtbaren From-Domain überein.
• DKIM besteht, und seine signierende Domain stimmt mit der sichtbaren From-Domain überein.

Eine lockere Übereinstimmung erlaubt organisatorisch zusammengehörige Subdomains, während eine strenge Übereinstimmung eine exakte Domain-Übereinstimmung erfordert. Die lockere Übereinstimmung ist der Standard. Die Richtlinie beschreibt außerdem die gewünschte Behandlung von Fehlern.

Die wichtigsten Richtlinienmodi sind:

• p=none fordert Überwachung an, während Berichte gesammelt werden.
• p=quarantine fordert Empfänger auf, fehlgeschlagene E-Mails als verdächtig zu behandeln.
• p=reject fordert Empfänger auf, fehlgeschlagene E-Mails abzulehnen.

Empfänger behalten die abschließende Kontrolle über die lokale Behandlung, daher ist die Richtlinie eine veröffentlichte Anforderung. Aggregierte Berichte, die an rua-Ziele gesendet werden, fassen Ergebnisse nach Quelle zusammen und machen Übereinstimmungsprobleme sichtbar, bevor eine strengere Durchsetzung erfolgt.

Wechseln Sie erst von der Überwachung zur Durchsetzung, nachdem jeder legitime Absender berücksichtigt wurde. Ein vergessenes Rechnungssystem oder Website-Formular kann bei einer strengen Richtlinie die Zustellbarkeit verlieren, selbst wenn die E-Mails des Postfachanbieters korrekt konfiguriert sind.

Authentifizierung und Verschlüsselung schützen unterschiedliche Dinge

SPF, DKIM und DMARC helfen empfangenden Systemen dabei, Domain-Identität und Spoofing zu bewerten, während MX eingehende E-Mails weiterleitet. Die Verschlüsselung von Inhalten erfordert Kontrollen an anderen Stellen des Nachrichtenwegs.

TLS schützt SMTP-Verkehr zwischen unterstützenden Servern. Ende-zu-Ende-Verschlüsselung schützt lesbare Inhalte über den gesamten Weg, wenn beide Seiten kompatible Schlüssel verwenden. Speicherverschlüsselung schützt Postfachdaten, die der Dienst aufbewahrt.

Thelemail bietet Zero-Access-Verschlüsselung für gespeicherte Postfachinhalte und Ende-zu-Ende-Verschlüsselung zwischen Thelemail-Konten. Bei externen E-Mails verwendet der Webclient WKD/OpenPGP, wenn ein kompatibler Empfängerschlüssel verfügbar ist, und Thelemail veröffentlicht die Schlüssel der Nutzer über WKD für kompatible verschlüsselte eingehende E-Mails. Andere externe Zustellungen verwenden Standard-SMTP mit TLS, sofern unterstützt. Externe Betreffzeilen und Umschlagmetadaten bleiben für die Weiterleitung sichtbar. Das Sicherheits- und Bedrohungsmodell beschreibt diese Garantien genau.

Eine stufenweise Einrichtungsreihenfolge verwenden

Eine neue Konfiguration für eine eigene Domain lässt sich am einfachsten in dieser Reihenfolge prüfen:

1. Weisen Sie die Inhaberschaft der Domain mit dem TXT-Eintrag des Anbieters nach.
2. Veröffentlichen Sie DKIM für den neuen Versanddienst.
3. Erstellen Sie eine SPF-Richtlinie, die jeden legitimen Absender abdeckt.
4. Veröffentlichen Sie DMARC mit Berichten und einer geeigneten anfänglichen Richtlinie.
5. Erstellen Sie jedes Postfach, jeden Alias und jede gemeinsame Adresse.
6. Testen Sie die ausgehende Authentifizierung von jedem Versanddienst.
7. Ändern Sie MX, nachdem alle eingehenden Empfänger bereit sind.
8. Prüfen Sie Berichte und passen Sie die DMARC-Durchsetzung auf Grundlage der Nachweise an.

Diese Reihenfolge wird in der Anleitung zur Domain-Einrichtung von Thelemail verwendet. Die aktuellen Tarife und Kapazitäten bestimmen die Grenzen für Postfächer, Speicher und Domains. Kostenpflichtige Tarife bieten unbegrenzte Aliasse; pro Workspace gilt ein Schutzmechanismus gegen Missbrauch. Aliasse sind im Free-Tarif nicht enthalten.

Einzelpersonen können eine @temail.org-Adresse verwenden, ohne DNS zu verwalten. Ein Haushalt oder ein von Gründern geführtes Team erhält die Portabilität von Adressen auf einer eigenen Domain, wenn ein technischer Administrator diesen Einrichtungsprozess verantwortet.

Fehler anhand der Nachrichtenkopfzeile diagnostizieren

Beginnen Sie mit der Kopfzeile Authentication-Results des empfangenden Systems. Sie zeichnet üblicherweise die SPF-, DKIM- und DMARC-Ergebnisse zusammen mit den ausgewerteten Domains auf.

SPF besteht, während DMARC fehlschlägt

Vergleichen Sie die authentifizierte Umschlagdomain mit der sichtbaren From-Domain. Konfigurieren Sie einen übereinstimmenden Return-Path oder verwenden Sie eine übereinstimmende DKIM-Signatur.

DKIM meldet einen fehlenden Schlüssel

Fragen Sie den Selektor und die signierende Domain aus der Kopfzeile DKIM-Signature ab. Prüfen Sie kopierte Host-Felder, abgelaufene Anbietereinrichtungen und zu früh entfernte Schlüssel.

Die DKIM-Prüfung schlägt trotz veröffentlichtem Schlüssel fehl

Prüfen Sie den aktuellen DNS-Schlüssel und ob ein Weiterleitungsdienst, eine Mailingliste oder ein Gateway den signierten Inhalt verändert hat. Testen Sie einen direkten Weg, um die Veränderung einzugrenzen.

SPF gibt einen permanenten Fehler zurück

Prüfen Sie auf mehrere SPF-Einträge, Syntaxprobleme, rekursive Includes und mehr als zehn Begriffe, die DNS-Abfragen auslösen. Entfernen Sie nicht mehr genutzte Dienste oder trennen Sie E-Mail-Ströme.

Einige Absender erreichen weiterhin den früheren Hoster

Fragen Sie das autoritative DNS ab und prüfen Sie die MX-TTL. Halten Sie beide Anbieter während der geplanten Überschneidung verfügbar und gleichen Sie Nachrichten beim alten Hoster ab.

Die Einträge nach dem Start pflegen

E-Mail-DNS benötigt regelmäßige Prüfungen. Entfernen Sie Autorisierungen für stillgelegte Plattformen, rotieren Sie DKIM-Selektoren, lesen Sie aggregierte DMARC-Berichte und prüfen Sie MX nach Änderungen des DNS-Anbieters. Nehmen Sie jeden neuen Versanddienst in das Verzeichnis auf, bevor er produktive E-Mails versendet.

Verwenden Sie Anbieteroberflächen als ein Signal und unabhängige DNS-Abfragen als ein weiteres. Testnachrichten an externe Systeme zeigen die Authentifizierungsergebnisse, die Empfänger tatsächlich sehen. Dokumentieren Sie die Wiederherstellungswege für Domain-Registrar, DNS-Anbieter und E-Mail-Host außerhalb des Postfachs, das sie schützen.

Für Familien-Domains macht der Leitfaden zur Einrichtung von Familien-E-Mail aus diesen Einträgen einen vollständigen Haushaltsplan. Homelab-Administratoren können mit der Bewertung des Selbst-Hostings das Netzwerk, die Reputation und die Betriebsarbeit hinter dem DNS einschätzen.

Wenn die vier Eintragsfamilien getrennt voneinander verstanden werden, wird die Fehlerbehebung wesentlich direkter: MX beantwortet, wohin eingehende E-Mails gehen, SPF beantwortet, welche Infrastruktur versenden darf, DKIM weist eine Domain-Signatur nach, und DMARC prüft die Übereinstimmung mit der Identität, die ein Empfänger sieht.