DMARC von p=none zu p=reject: Schritt für Schritt

· 5 Min. Lesezeit

Die meisten Domains, die überhaupt einen DMARC-Record haben, stehen seit Jahren auf p=none. Das ist ein Monitoring-Modus, kein Schutz. Der Weg zu p=reject ist keine Raketenwissenschaft, braucht aber Reports, Geduld und eine feste Reihenfolge.

Warum p=none nichts schützt

DMARC nach RFC 7489 macht zwei Dinge: Es prüft, ob SPF oder DKIM zur Absenderdomain im From-Header passen (Alignment), und es sagt dem Empfänger, was er mit Mails tun soll, die diese Prüfung nicht bestehen. Bei p=none lautet die Anweisung: nichts tun, nur berichten. Gefälschte Mails werden also genauso zugestellt wie ohne DMARC.

p=none hat trotzdem einen Zweck. Über die rua-Adresse bekommst du Aggregate-Reports von allen großen Empfängern und siehst, wer im Namen der Domain sendet. Ohne diese Phase weißt du nicht, welche Systeme du mit p=reject abschalten würdest.

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

Phase 1: Alle Absender finden

Lass p=none mindestens zwei bis vier Wochen laufen und werte die Reports aus. Jeder Report listet Quell-IPs mit der Anzahl der Mails und dem Ergebnis von SPF und DKIM inklusive Alignment. Sortiere die Quellen in drei Gruppen: eigene Systeme mit pass, eigene Systeme mit fail und Fremde. Die mittlere Gruppe ist deine Arbeitsliste.

Typische Überraschungen sind der Webserver mit den Kontaktformularen, das Rechnungstool der Buchhaltung, ein Newsletter-Dienst, den der Kunde selbst abgeschlossen hat, und Weiterleitungen von Mitarbeitern an private Postfächer. Monatliche Absender wie Gehaltsabrechnungen tauchen erst nach vier Wochen auf, deshalb die Mindestdauer.

Phase 2: Alignment herstellen

DMARC pass braucht nicht nur ein SPF- oder DKIM-pass, sondern ein aligned pass. Bei SPF muss die Envelope-From-Domain (Return-Path) zur From-Domain passen, bei DKIM die d=-Domain der Signatur. Im Standardmodus relaxed reicht dieselbe Organisationsdomain, newsletter.beispiel.de passt also zu beispiel.de. Im Modus strict müssen die Domains exakt übereinstimmen.

Für jeden Absender mit fail gibt es zwei Wege: Entweder der Dienst sendet mit einem Return-Path auf deiner Domain (SPF-Alignment), oder er signiert mit DKIM unter deiner Domain (DKIM-Alignment). Bei den meisten Dienstleistern ist DKIM der zuverlässigere Weg, weil er Weiterleitungen überlebt. Lass strict weg, solange du keinen konkreten Grund dafür hast.

  • aspf=r und adkim=r (relaxed) sind Standard und für fast alle Domains richtig
  • Ein Absender braucht nur eines von beiden: SPF-Alignment oder DKIM-Alignment
  • Bei Diensten ohne Custom Domain ist kein Alignment möglich; dann muss der Dienst gewechselt oder auf eine Subdomain ohne DMARC-Schutz ausgelagert werden

Phase 3: p=quarantine mit pct= einführen

Wenn die Reports zeigen, dass alle bekannten Absender pass liefern, wechselst du auf p=quarantine. Der Parameter pct= erlaubt, die Policy nur auf einen Prozentsatz der fehlgeschlagenen Mails anzuwenden. Starte mit einem niedrigen Wert, beobachte die Reports eine Woche und erhöhe schrittweise. Mails, die nicht vom Prozentsatz erfasst werden, werden mit der nächstniedrigeren Policy behandelt, bei quarantine also mit none.

Quarantine bedeutet: Der Empfänger soll die Mail als verdächtig behandeln, in der Praxis meist Spam-Ordner. Das ist reversibel, falls du doch einen Absender übersehen hast, und deshalb der richtige Zwischenschritt.

Woche 1:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@beispiel.de

Woche 2:
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@beispiel.de

Woche 3:
v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de

Phase 4: p=reject und Subdomains

Nach ein bis zwei Wochen mit voller Quarantine ohne neue Ausreißer stellst du auf p=reject um. Empfänger lehnen dann fehlgeschlagene Mails bereits beim Einliefern ab. Auch hier kannst du pct= zum Hochfahren nutzen, wobei nicht erfasste Mails dann mit quarantine behandelt werden.

Der Tag sp= setzt die Policy für Subdomains, die keinen eigenen DMARC-Record haben. Fehlt sp=, gilt die Hauptpolicy auch für Subdomains. Nutze sp=, wenn du eine Subdomain bewusst lockerer behandeln willst, etwa während ein Newsletter-Tool noch umgestellt wird. Umgekehrt kann sp=reject sinnvoll sein, während die Hauptdomain noch auf quarantine steht, weil Angreifer gern nicht existierende Subdomains fälschen.

Zielzustand:
_dmarc.beispiel.de.  TXT  "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc@beispiel.de"

Was bei reject kaputtgehen kann

Weiterleitungen sind das größte Problem. Ein Empfänger, der Mails an eine andere Adresse weiterleitet, verändert den Absender-Host, damit bricht SPF. DKIM überlebt eine reine Weiterleitung, nicht aber Mailinglisten, die Betreff-Präfixe oder Fußzeilen ergänzen. Solche Mails werden bei p=reject abgewiesen, obwohl sie legitim sind.

ARC (Authenticated Received Chain) soll dieses Problem lösen, indem der weiterleitende Server die ursprünglichen Prüfergebnisse signiert weitergibt. Große Anbieter werten ARC aus, viele kleinere nicht. Du kannst das nicht beeinflussen, nur einplanen: Weise den Kunden darauf hin, dass Mails über Mailinglisten und Weiterleitungsketten bei reject verloren gehen können, und sorge dafür, dass alle eigenen Absender per DKIM signieren.

Zeitplan und Rollback

Für eine typische Kundendomain mit drei bis fünf Absendern brauchst du vier bis acht Wochen. Der Zeitplan lässt sich nicht beliebig verkürzen, weil du auf Reports warten musst, die täglich kommen. Was sich verkürzen lässt, ist die Reaktionszeit auf Ausreißer.

Ein Rollback ist jederzeit möglich: Setze p= zurück auf den vorherigen Wert, und innerhalb der TTL wird die neue Policy wirksam. Bereits abgewiesene Mails kommen allerdings nicht zurück. Deshalb der Weg über quarantine und pct=, nicht der Sprung von none auf reject.

  1. Woche 1 bis 4: p=none mit rua, alle Absender identifizieren, Alignment für jeden Absender herstellen.
  2. Woche 4 bis 6: p=quarantine mit pct=10, dann 50, dann 100. Nach jedem Schritt Reports prüfen.
  3. Woche 6 bis 8: p=reject, zuerst mit pct=, dann voll. sp= für Subdomains festlegen.
  4. Danach: Reports weiter beobachten, denn neue Dienste kommen ständig dazu.

Häufige Fragen

Reicht p=quarantine dauerhaft?
Es ist deutlich besser als none, aber der Spam-Ordner ist kein sicherer Ort. Nutzer holen Mails von dort heraus, und manche Empfänger behandeln quarantine nachsichtig. Wenn eine Domain für Rechnungen oder Kundenkommunikation genutzt wird, ist reject das Ziel.
Muss ich für jede Subdomain einen eigenen DMARC-Record anlegen?
Nein. Ohne eigenen Record gilt die Policy der Organisationsdomain, gesteuert durch sp=. Ein eigener Record auf der Subdomain ist nur nötig, wenn du dort abweichende Regeln oder eigene Report-Adressen willst.
Was mache ich mit einem Dienst, der kein Alignment kann?
Entweder du lässt ihn von einer Subdomain senden, die du per sp=none oder eigenem Record ausnimmst, oder du wechselst den Dienst. Alignment über die Hauptdomain zu erzwingen, indem du reject aufschiebst, ist keine Lösung.
Jetzt prüfen

DMARC-Eintrag kostenlos prüfen: Policy (none, quarantine, reject), pct, Reporting-Adressen und Syntaxfehler. Mit Empfehlungen für den Umstieg auf p=reject.

Der Umstieg auf p=reject ist nur der Anfang, denn jeder neue Dienst kann die Zustellung wieder gefährden. DomainWarn überwacht die DMARC-, SPF- und DKIM-Records deiner Kundendomains und meldet jede Änderung sofort.

Diese Domain dauerhaft überwachen14 Tage kostenlos testen, keine Kreditkarte.

Weitere Anleitungen