E-Mail-DNS-Records: MX, SPF, DKIM und DMARC

E-Mail hängt von mehreren DNS-Records ab, die unterschiedliche Aufgaben erfüllen. MX-Records sagen sendenden Mailsystemen, wohin sie eingehende Nachrichten für eine Domain zustellen sollen. SPF veröffentlicht in TXT-Daten eine Richtlinie darüber, welche Absendersysteme autorisiert sind. DKIM nutzt einen im DNS veröffentlichten öffentlichen Schlüssel, damit Empfänger eine kryptografische Signatur überprüfen können, und DMARC teilt Empfängern mit, wie sie Nachrichten bewerten sollen, die die Alignment-Prüfung nicht bestehen, und wohin Berichte gesendet werden dürfen. Diese Mechanismen ergänzen einander; ein korrekter MX-Record authentifiziert ausgehende Mails nicht, und ein gültiger SPF-Record konfiguriert nicht die eingehende Zustellung.

Das eingehende Routing beginnt mit MX

Ein sendender Mailserver fragt die MX-Records der Empfängerdomain ab und erhält einen oder mehrere Mail-Exchanger-Hostnamen mit Präferenzwerten. Niedrigere Präferenzzahlen werden bevorzugt, wenn mehrere Ziele verfügbar sind, wobei Zustellsysteme eigene Wiederholungs- und Verfügbarkeitslogik anwenden können. Die Ziel-Hostnamen müssen anschließend selbst per Adressauflösung aufgelöst werden. Hat die Domain keinen MX-Record, kann das Mailverhalten auf andere DNS-Regeln zurückfallen, aber sich auf einen impliziten Fallback zu verlassen ist meist unklarer, als die beabsichtigte Konfiguration zu veröffentlichen. Prüfen Sie die MX-Werte anhand der aktuellen Einrichtungsanleitung des E-Mail-Anbieters und kontrollieren Sie die exakte Root-Domain, die für Mail verwendet wird.

SPF wird als TXT-Record an der betreffenden Domain veröffentlicht und gegen den verbindenden Absender ausgewertet. Es gibt Lookup-Limits und Syntaxregeln, sodass das Kopieren mehrerer unabhängiger SPF-Zeichenketten in getrennte TXT-Records einen Permerror verursachen kann. DKIM-Records werden meist unter selektorspezifischen Namen veröffentlicht, die der Absender vorgibt, und ein fehlender Selektor kann Signaturen unverifizierbar machen. DMARC verwendet einen festgelegten Namen unter _dmarc und kann in einem Überwachungsmodus beginnen, bevor eine strengere Richtlinie in Betracht kommt. Erfinden Sie keine Werte: Beziehen Sie sie von jeder Mail-Plattform, die im Namen der Domain senden darf.

Warum die Mail-Authentifizierung ein Alignment erfordert

DMARC prüft, ob die sichtbare From-Domain einer Nachricht mit einer per SPF oder DKIM authentifizierten Domain übereinstimmt (Alignment), entsprechend dem konfigurierten Alignment-Modus. Das hilft Empfängern, die autorisierte Nutzung einer Domain von Nachrichten zu unterscheiden, die lediglich vorgeben, von ihr zu stammen. Eine Domain kann SPF bestehen, aber DMARC nicht, wenn der authentifizierte Envelope-Absender nicht mit der sichtbaren From-Domain übereinstimmt, und eine DKIM-Signatur kann scheitern, wenn der veröffentlichte Schlüssel fehlt oder falsch ist. Mail-Plattformen nutzen oft mehrere Versanddienste, daher sollten alle legitimen Quellen erfasst werden, bevor eine Richtlinie verschärft wird.

• Listen Sie jedes System auf, das Mail für die Domain versendet, bevor Sie SPF bearbeiten.
• Veröffentlichen Sie die vom Anbieter ausgestellten DKIM-Selektoren und prüfen Sie den exakten Selektornamen.
• Starten Sie das DMARC-Reporting mit einer Richtlinie, die zu Ihrer Überwachungsbereitschaft passt.
• Prüfen Sie nach Anbieterwechseln die MX-Prioritäten und die Adressauflösung der Ziele.
• Werten Sie Aggregatberichte aus und untersuchen Sie unbekannte Absender, bevor Sie die Durchsetzung ändern.

Records nach einer Migration verifizieren

Wenn Sie den E-Mail-Anbieter wechseln, exportieren Sie die alte DNS-Konfiguration und vergleichen dann die neuen MX-, SPF-, DKIM- und DMARC-Records mit der Einrichtungs-Checkliste des neuen Anbieters. Manche Anbieter verlangen zusätzlich zu den Mail-Records einen TXT-Record zur Domain-Verifizierung. Lassen Sie alte Versandsysteme nur so lange autorisiert, wie sie noch legitimen Traffic senden, und entfernen Sie überholte Autorisierungen nach der Beobachtung sorgfältig. Wegen des TTL-Cachings sieht nicht jeder Empfänger eine Änderung sofort. Bestätigen Sie die öffentlichen Antworten und senden Sie Testnachrichten an repräsentative Empfängersysteme, bedenken Sie aber, dass Zustellergebnisse auch von Reputation, Inhalt und der Filterung beim Empfänger abhängen.

Ein DNS-Lookup kann zeigen, ob die Records öffentlich sichtbar sind; er kann für sich genommen nicht beweisen, dass eine Nachricht im Posteingang landet. Der Leitfaden zu MX-Records und die Erklärung zu SPF, DKIM und DMARC behandeln die einzelnen Mechanismen. Nutzen Sie einen DNS-Checker, um bestimmte Namen und Typen zu prüfen, und validieren Sie anschließend mit kontrollierten Testnachrichten und einem Blick in die Anbieterprotokolle. Wenn Sie Routing und Authentifizierung in Ihrer Checkliste getrennt halten, werden Mail-Änderungen deutlich sicherer.

Vor Änderungen am Mail-DNS ein Inventar anlegen

Viele Organisationen haben mehr als einen legitimen Absender: Ein Postfachanbieter, eine Marketing-Plattform, ein Ticketsystem, eine Buchhaltungsanwendung und ein Monitoring-Dienst können alle als dieselbe Domain senden. Legen Sie ein Inventar mit jedem Anbieter, der Versanddomain, der SPF-Anforderung, dem DKIM-Selektor und dem Verantwortlichen an. Klären Sie, ob jeder Anbieter die sichtbare From-Domain oder eine delegierte Subdomain verwendet. Dieses Inventar ist die Grundlage einer sicheren DMARC-Richtlinie, denn Berichte offenbaren oft Systeme, von deren Existenz der zuständige E-Mail-Administrator nichts wusste. Validieren Sie Anbieter anhand ihrer aktuellen Dokumentation und einer echten Testnachricht und entfernen Sie überholte Absender erst, wenn das Team bestätigt, dass ihr Traffic nicht mehr benötigt wird.