DMARC einrichten: legitime E-Mail vor Fehlern schützen

Wer wissen möchte, wie man DMARC einrichtet, sollte nicht sofort zu p=reject springen. Beginnen Sie mit Beobachtung, prüfen Sie für jeden tatsächlichen Sender erfolgreiches ausgerichtetes SPF oder DKIM und verschärfen Sie die Richtlinie erst nach Tests. So lässt sich Domain-Spoofing begrenzen, ohne vergessene Rechnungs-, Passwort- oder SaaS-Versandwege unnötig zu beeinträchtigen.

Die Praxis ist selten übersichtlich: Microsoft 365 versendet die Postfachmail, eine externe Anwendung Rechnungen, ein anderes System Marketingmail, und ein Kopierer verschickt Scans. Ein übersehener Sender kann eine strengere Richtlinie zum Betriebsproblem machen. Für die Domainkonfiguration helfen ergänzend E-Mail auf meiner Domain einrichten und der Überblick zu geschäftlicher E-Mail.

Dieser Leitfaden beschreibt den Betriebsablauf: beobachten, belastbare Ergebnisse sammeln, Ausrichtung korrigieren und erst dann Durchsetzung anfordern. Eine veröffentlichte Richtlinie allein ersetzt diese Prüfung nicht.

Was DMARC tatsächlich leistet

DMARC ist eine DNS-Richtlinie, die Empfängern die gewünschte Behandlung von Nachrichten mitteilt, deren Domainauthentifizierung nicht zur sichtbaren From-Domain passt. Sie baut auf SPF und DKIM auf. Mindestens eines muss erfolgreich sein und die erforderliche From-Ausrichtung erfüllen.

DMARC steht für Domain-based Message Authentication, Reporting, and Conformance. Damit veröffentlichen Sie eine Richtlinie für fehlgeschlagene Prüfungen und fordern Berichte an. Die Basisspezifikation ist RFC 7489. Das Verfahren bestätigt weder unbedenklichen Inhalt noch eine bestimmte Zustellung.

Für die Einrichtung sind diese Zusammenhänge entscheidend:

• SPF kann bestehen, ohne zur From-Domain ausgerichtet zu sein. DMARC scheitert dann nur, wenn kein erfolgreiches ausgerichtetes DKIM vorliegt.
• Auch erfolgreiches DKIM reicht ohne Ausrichtung nicht aus. Erfolgreiches ausgerichtetes SPF kann DMARC dennoch bestehen lassen.
• DMARC besteht, sobald SPF oder DKIM gleichzeitig erfolgreich und ausgerichtet ist.

Googles beschriebene Anforderungen für Massenversender verlangen SPF, DKIM und mindestens einen DMARC-Eintrag mit p=none. Für die entsprechenden Sender ist außerdem From-Ausrichtung über SPF oder DKIM erforderlich. Prüfen Sie die jeweils geltenden Bedingungen in Googles FAQ zu den Absenderrichtlinien.

Voraussetzungen vor der DMARC-Einrichtung

Prüfen Sie zuerst Ihre Versandkonfiguration. Fehlerhaftes SPF, fehlendes DKIM oder Signaturen mit einer fremden Domain können unter einer einschränkenden Richtlinie legitime Mail treffen. Eine Beobachtungsrichtlinie verursacht solche Authentifizierungsfehler nicht selbst, kann sie aber sichtbar machen.

Prüfen Sie zunächst drei Bereiche.

1. SPF: Genau einen passenden SPF-Eintrag je tatsächlicher Envelope-Domain verwenden. Die Grenze von 10 betrifft DNS-auslösende Mechanismen und Modifikatoren einschließlich verschachtelter Auswertung, nicht sämtliche DNS-Abfragen.
2. DKIM: Soweit unterstützt aktivieren und testen. Verwenden Sie bei geeigneter Anbieterunterstützung Schlüssel mit 2048 Bit.
3. Inventar: Alle Systeme mit Ihrer From-Domain erfassen, einschließlich Mailplattform, CRM, Abrechnung, Support, Formularen, Scannern und Marketing.

Für TrekMail-Domains erläutern Erforderliche DNS-Einträge und Domain hinzufügen die Grundlagen. DNS-Prüfungen können fehlende oder doppelte Einträge erkennen; tatsächliche Nachrichten müssen anschließend separat geprüft werden.

Eine Rechnungsanwendung sendet mit billing@yourdomain.com, signiert aber mit der Anbieterdomain und verwendet deren Return-Path. SPF und DKIM können für diesen Anbieter bestehen, ohne Ihre From-Domain auszurichten. Fehlt ein anderer ausgerichteter erfolgreicher Pfad, scheitert DMARC.

Solche Ausrichtungsfehler erklären manche Probleme, die erst bei der Durchsetzung auffallen.

Schritt 1: Einen DMARC-Eintrag zur Beobachtung veröffentlichen

Bei noch ungeprüften Versandwegen bietet sich Beobachtung an. Mit p=none fordern Sie keine Quarantäne oder Ablehnung durch DMARC an. Verfügbare Berichte helfen bei der Analyse, sind aber nicht garantiert; lokale Empfängerfilter gelten weiterhin.

Erstellen Sie einen TXT-Eintrag unter _dmarc.yourdomain.com mit diesem Wert:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Dieselbe Konfiguration in Zonendateischreibweise, nicht als zusätzlicher Eintrag:

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

Das entspricht dem Beispielprinzip in RFC 7489. Verwenden Sie eine betreute Berichtsadresse oder einen Alias statt eines persönlichen Postfachs. Aggregierte Berichte enthalten XML und können sich rasch ansammeln. Prüfen Sie Zugriffsrechte und bei externen Zielen eine gegebenenfalls erforderliche DNS-Autorisierung.

Veröffentlichen Sie den Eintrag bei Ihrem tatsächlichen DNS-Verwalter und prüfen Sie anschließend die übrigen Authentifizierungswege. TrekMails FAQ Meine E-Mails landen im Spam unterstützt die Unterscheidung zwischen Weiterleitungseffekten und Problemen, die weitere Tests benötigen.

Schritt 2: Berichte lesen und tatsächliche Sender ermitteln

Überspringen Sie die Auswertung nicht. Berichte liefern Hinweise auf Versandquellen und Fehler, können aber weder sämtliche Sender erfassen noch legitime Mail und Missbrauch allein zuverlässig unterscheiden.

Berichte können insbesondere Folgendes zeigen:

• Vom berichtenden Empfänger beobachtete Quell-IP-Adressen
• SPF-Authentifizierungsergebnisse
• DKIM-Authentifizierungsergebnisse
• Ergebnisse der Ausrichtung zur From-Domain
• Die vom Empfänger gemeldete Behandlung

Für die Untersuchung sind zwei Gruppen hilfreich.

Bekannte legitime Sender mit Ausrichtungsfehlern benötigen Korrekturen. Unbekannte Quellen müssen erst zugeordnet werden: Sie können auf Missbrauch, aber auch auf Weiterleitung oder gemeinsam genutzte Versanddienste hinweisen. Authentifizierungserfolg allein beweist keine sichere Nachricht.

Die folgende Tabelle zeigt Beispiele, keine unveränderlichen Anbieterstandards:

Bei vielen Domains wird jede neue SaaS-Anwendung zu einer weiteren Versandkonfiguration. Ein gemeinsames Betriebskonzept kann helfen; dazu erläutert Mehrdomain-E-Mail-Hosting mögliche Organisationsmodelle, ohne eine bestimmte Ticketreduktion zu garantieren.

Schritt 3: Ausrichtung statt nur Authentifizierung korrigieren

Entscheidend ist ein erfolgreicher ausgerichteter SPF- oder DKIM-Pfad. Bloßer Authentifizierungserfolg reicht nicht. Bei gelockerter Ausrichtung müssen authentifizierte Domain und sichtbare From-Domain dieselbe Organisationsdomain haben; bei strikter Ausrichtung ist exakte Übereinstimmung erforderlich.

RFC 7489 beschreibt gelockerte Ausrichtung gegenüber der Domain von RFC5322.From. Googles Absender-FAQ erläutert, dass für DMARC ein ausgerichteter erfolgreicher SPF- oder DKIM-Pfad genügt. Beide Authentifizierungsverfahren sollten nach den jeweils geltenden Anforderungen eingerichtet werden.

Typische Korrekturen:

• Marketingplattformen: DKIM-Signierung mit der eigenen Domain konfigurieren und prüfen.
• Rückläufer: Einen eigenen Return-Path oder eine passende Bounce-Domain einrichten, soweit unterstützt.
• Microsoft 365: DKIM für die eigene Domain vor der Durchsetzung aktivieren und testen.
• Verwalteter TrekMail-Versand: Die für den tatsächlichen Versandweg angezeigten SPF- und DKIM-Einträge exakt veröffentlichen.

Auch bei zentraler Verwaltung bleibt die korrekte DNS-Konfiguration wichtig. TrekMail kann die erforderlichen Einträge anzeigen und je nach Tarif verwalteten SMTP oder eigenen SMTP mit Nano ermöglichen. Postfachbetrieb und Versanddienst müssen dabei getrennt geprüft werden.

Bei Nano erfolgt der Versand über Ihren SMTP-Anbieter; entsprechende bezahlte Tarife bieten verwalteten SMTP. Als Preisorientierung nennt TrekMail ab $3.50/Monat und eine angebotene 14-tägige Testphase für bezahlte Tarife. Nano hat eine kostenlose Option ohne Karte. Prüfen Sie aktuelle Funktionen und Bedingungen bei TrekMail-Tarife.

Schritt 4: Quarantine als möglichen Zwischenschritt prüfen

Nach Beobachtung und Tests kann Quarantine ein Zwischenschritt sein. Es ist bereits eine Durchsetzungsanforderung: Empfänger sollen fehlgeschlagene Nachrichten verdächtig behandeln. Weder ein bestimmter Spamordner noch spätere Wiederherstellung sind garantiert. Entscheidend sind auch seltene legitime Versandwege.

Ersetzen Sie den bisherigen Eintrag bei entsprechender Bereitschaft durch:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Warum kann Quarantine vor Reject sinnvoll sein?

• Sie fordert Einschränkungen für fehlgeschlagene Domainauthentifizierung an.
• Bei manchen Empfängern ist die Behandlung weniger endgültig als eine Ablehnung.
• Sie erlaubt eine weitere Beobachtungsphase, bleibt aber für legitime Mail risikobehaftet.

Die Dauer hängt von den Versandzyklen ab. Ein paar Wochen können zur Planung dienen; 30 Tage sind ebenfalls nur ein Beispiel. Seltene oder quartalsweise wichtige Nachrichten erfordern gezielte Tests oder längere Beobachtung.

Dabei tauchen oft undokumentierte WordPress-Plugins, CRM-Testumgebungen, alte Kopierer oder monatlich sendende Anbieter auf. Quarantine ersetzt deren Prüfung nicht und garantiert keinen verlustfreien Puffer.

Schritt 5: Reject nach Prüfung der Ergebnisse erwägen

Mit p=reject fordern Sie die Ablehnung fehlgeschlagener Nachrichten an, statt nur deren verdächtige Behandlung. Das kann direkte Domainfälschungen begrenzen, wird aber durch lokale Empfängerentscheidungen beeinflusst.

Der folgende Eintrag ersetzt die vorherige Richtlinie, statt sie zu ergänzen:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

RFC 7489 beschreibt für p=reject die angeforderte Ablehnung bei DMARC-Fehlern. Empfänger können lokale Ausnahmen anwenden; die Richtlinie verhindert nicht jeden Betrug und bestätigt keinen sicheren Inhalt.

Vor diesem Schritt prüfen Sie mindestens:

• Erfolgreiche ausgerichtete Authentifizierung beim primären Postfachversand
• Erfolgreiche ausgerichtete Authentifizierung bei Marketing und Transaktionsmail
• Mehrere Wochen verfügbarer Berichte sowie Tests seltener kritischer Abläufe
• Eine nachvollziehbare Erklärung für verbleibende Fehler

Beobachten Sie Berichte und tatsächliche Mail auch anschließend. Neue Dienste oder Versandänderungen gehören in denselben Prüfprozess.

Häufige Fehler mit Auswirkungen auf Mail

Übersehene Sender, doppelte SPF-Einträge, fehlendes DKIM und nicht angepasste Anbieter-Domains können unter einer strengeren Richtlinie zu Problemen führen. Untersuchen Sie die Versandkonfiguration statt nur die DMARC-Anforderung zu ändern.

• Durchsetzung anfordern, bevor DKIM aktiviert und getestet ist
• Mehrere SPF-Einträge statt eines korrekt abgestimmten Eintrags erstellen
• SPF-Erfolg mit DMARC-Erfolg gleichsetzen
• Selten sendende Anbieter übersehen
• Ohne Versandprüfung unmittelbar zu p=reject wechseln
• Berichte an eine nicht betreute Adresse senden

Bei Weiterleitung kann SPF scheitern, während eine weiterhin gültige ausgerichtete DKIM-Signatur DMARC bestehen lässt. Voraussetzung ist die Erhaltung signierter Daten unter den Kanonisierungsregeln. Weitere Hinweise geben Weiterleitung mit E-Mail-Alias und sichere geschäftliche E-Mail.

Kurze Checkliste zur DMARC-Einrichtung

Diese Checkliste fasst den schrittweisen Ablauf zusammen. Sie muss an Ihre tatsächlichen Sender und Geschäftszyklen angepasst werden.

1. Alle Systeme mit Ihrer From-Domain erfassen.
2. SPF je tatsächlicher Envelope-Domain auf einen gültigen Eintrag abstimmen.
3. DKIM bei unterstützenden Versandplattformen aktivieren und prüfen.
4. v=DMARC1; p=none; rua=mailto:... veröffentlichen.
5. Berichte mit bekannten Sendern abgleichen und unbekannten Verkehr untersuchen.
6. Für jeden legitimen Sender erfolgreichen ausgerichteten Versand sicherstellen.
7. Nach Tests p=quarantine erwägen.
8. Berichte und wichtige Nachrichten erneut prüfen.
9. Nach Klärung der Ergebnisse p=reject erwägen.

Fazit: DMARC kontrolliert einrichten

Ein praktikabler Ablauf beginnt mit p=none, gleicht Berichte mit dem Senderinventar ab und korrigiert SPF- und DKIM-Ausrichtung. Nach Tests können p=quarantine und später p=reject folgen. Diese Schritte reduzieren Fehlkonfigurationsrisiken, garantieren aber weder Zustellung noch vollständigen Spoofing-Schutz.

Bei zahlreichen Domains helfen konsistente Werkzeuge. TrekMail kann je nach Tarif eigene Domains, IMAP-Postfächer, Catch-all, Weiterleitung, Migration und eigenen oder verwalteten SMTP bereitstellen. IMAP-Migration kopiert vorhandene Nachrichten und ersetzt keinen vollständigen MX-, Anwendungs- oder Versandwechsel. Auch Pauschaltarife haben Grenzen; DMARC muss weiterhin korrekt eingerichtet werden.

Das ist der betriebliche Ansatz für die DMARC-Einrichtung: zuerst prüfen, danach gezielt verschärfen und verfügbare Berichte laufend mit tatsächlichen Tests abgleichen.