DMARC einführen: In 6 Schritten von „p=none“ zu „p=reject“

Jemand schickt Rechnungen in deinem Namen an deine Kunden — du merkst es erst, wenn der Kunde anruft. Oder deine eigenen Angebote landen beim Empfänger im Spam. Beides hat dieselbe Ursache: Die Domain ist nicht dagegen abgesichert, dass fremde Server in ihrem Namen senden.

DMARC schließt diese Lücke. Was die drei Verfahren SPF, DKIM und DMARC grundsätzlich tun, steht in unserem Artikel DMARC erklärt. Hier geht es um die praktische Einführung: in welcher Reihenfolge, mit welchen Fallen und wie du vermeidest, dass dabei echte Mails verloren gehen.

Warum das heute kein „Nice to have“ mehr ist

Große Postfachanbieter haben ihre Regeln verschärft. Seit Februar 2024 verlangen Google und Yahoo von Absendern größerer Mailmengen unter anderem eine korrekt eingerichtete Authentifizierung mit SPF, DKIM und DMARC, Microsoft hat für Outlook.com nachgezogen. Auch kleine Absender merken das indirekt: Mails von Domains ohne saubere Authentifizierung werden schneller als verdächtig eingestuft. Die genauen Schwellen und Fristen ändern sich — prüfe im Zweifel die aktuellen Angaben der Anbieter.

Schritt 1: Alle Absender erfassen

Bevor du irgendetwas im DNS änderst, schreibe auf, wer in deinem Namen Mails verschickt. Typische Kandidaten:

• dein Mailserver oder Mail-Anbieter (Microsoft 365, Hosting-Postfächer)
• Newsletter-Tool
• CRM, Ticket- und Buchhaltungssystem
• Webformulare und Shop-Benachrichtigungen
• Drucker und Scanner, die „Scan to Mail“ nutzen
• Monitoring und Server (Benachrichtigungen, Backup-Berichte)

Diese Liste ist das Fundament. Alles, was fehlt, wird später blockiert.

Schritt 2: SPF prüfen und aufräumen

Der SPF-Eintrag nennt die erlaubten Absender-Server. Typische Probleme:

• Mehr als ein SPF-Eintrag pro Domain — das ist ungültig, es darf nur einen geben.
• Mehr als 10 DNS-Abfragen (include, a, mx …). Dann bricht SPF mit einem Fehler ab. Das passiert schnell, wenn viele Dienste eingetragen wurden.
• Vergessene Dienste oder umgekehrt alte Dienste, die längst nicht mehr genutzt werden.

Ein einfaches Beispiel für die Domain beispiel.de:

beispiel.de.  TXT  "v=spf1 include:_spf.mailanbieter.example ~all"

Schritt 3: DKIM für jeden Dienst einrichten

DKIM signiert jede Mail. Jeder Dienst bekommt dazu einen eigenen Schlüssel („Selector“), den du als DNS-Eintrag veröffentlichst. Die genaue Anleitung liefert der jeweilige Anbieter.

Wichtig für DMARC: Die Signatur muss zur Absender-Domain passen (Alignment). Wenn dein Newsletter-Tool mit der eigenen Domain statt mit deiner signiert, zählt das für DMARC nicht. Die meisten Anbieter bieten dafür eine „eigene Domain“-Einrichtung an.

Schritt 4: DMARC im Beobachtungsmodus starten

Jetzt kommt der DMARC-Eintrag, zunächst ohne Folgen für den Mailverkehr:

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-berichte@beispiel.de"

• p=none bedeutet: nur beobachten, nichts blockieren.
• rua= ist die Adresse, an die Empfänger tägliche Berichte schicken.

Die Berichte sind XML-Dateien und für Menschen schwer lesbar. Ein Auswertungsdienst oder ein Tool macht daraus eine Liste: Welche Server senden für meine Domain, und bestehen sie SPF und DKIM?

Schritt 5: Berichte auswerten und Lücken schließen

Lass die Berichte zwei bis vier Wochen laufen. Du suchst nach zwei Dingen:

1. Legitime Absender, die durchfallen — der vergessene Newsletter-Dienst oder der Scanner. Diese bekommen SPF-/DKIM-Einträge.
2. Fremde Absender, die in deinem Namen senden — das ist der eigentliche Missbrauch. Er wird später blockiert.

Erst wenn die legitimen Absender sauber durchlaufen, geht es weiter.

Schritt 6: Schrittweise verschärfen

_dmarc.beispiel.de.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-berichte@beispiel.de"

Mit p=quarantine landen durchgefallene Mails im Spam-Ordner des Empfängers. Wenn auch das einige Wochen ohne Beschwerden läuft, ist p=reject der letzte Schritt: Mails, die DMARC nicht bestehen, werden abgewiesen. Optional kannst du die Verschärfung mit dem Parameter pct= zunächst nur auf einen Teil der Mails anwenden.

Häufige Fallen

• Weiterleitungen und Mailinglisten. Sie verändern Mails unterwegs, SPF kann dabei durchfallen. Hier ist eine gültige DKIM-Signatur wichtig.
• Subdomains. Wenn von Subdomains gesendet wird (zum Beispiel news.beispiel.de), brauchen sie eigene Einträge oder eine bewusste Regelung über sp=.
• Domains, von denen nie gesendet wird. Für Parkdomains empfiehlt sich ein striktes p=reject und ein leerer SPF-Eintrag.
• Zu früh auf reject gestellt. Das ist der häufigste Fehler: Ein vergessener Dienst, und wichtige Mails kommen nicht mehr an.
• Berichts-Adresse nicht überwacht. Ohne Auswertung bringt p=none nichts.