DMARC auf p=reject: Wann ist Ihre Unternehmensdomain wirklich bereit?

Eine Domain ist nicht schon deshalb für p=reject bereit, weil Microsoft 365 korrekt eingerichtet ist. Entscheidend ist, ob jede berechtigte Nachricht mindestens einen erfolgreichen und zur sichtbaren Absenderdomain ausgerichteten SPF- oder DKIM-Nachweis liefert.

Das betrifft oft mehr Systeme als erwartet: Während persönliche E-Mails über Microsoft 365 laufen, versenden Warenwirtschaft, Newsletter-Dienst, Website, Scanner oder Alarmierungssysteme möglicherweise ebenfalls unter der Unternehmensdomain. Ein vorschnell veröffentlichter Ablehnungsmodus kann solche legitimen Nachrichten treffen.

Was DMARC tatsächlich prüft

Bei einer E-Mail können drei unterschiedliche Domains beteiligt sein:

• Die sichtbare Absenderdomain steht im From-Feld der Nachricht.
• Für SPF wird die Domain des technischen Envelope-Absenders geprüft.
• Bei DKIM authentifiziert die Signatur eine im Signaturfeld angegebene Domain.

DMARC gilt als bestanden, wenn mindestens einer der beiden Wege erfolgreich und ausgerichtet ist:

• SPF besteht und die geprüfte SPF-Domain passt zur sichtbaren Absenderdomain, oder
• DKIM besteht und die signierende Domain passt zur sichtbaren Absenderdomain.

Bei der standardmäßigen gelockerten Ausrichtung genügt eine Übereinstimmung auf Ebene der organisatorischen Domain. Bei strenger Ausrichtung müssen die Domains exakt übereinstimmen. Ein technisch erfolgreicher Test allein reicht daher nicht.

Beispiel: Eine Newsletter-Plattform authentifiziert ihren eigenen Envelope-Absender erfolgreich per SPF. Im sichtbaren Absender steht jedoch newsletter@unternehmen.de. Ist die SPF-Domain des Dienstes nicht zu unternehmen.de ausgerichtet und fehlt eine passende DKIM-Signatur, besteht die Nachricht DMARC nicht.

Zuerst alle Absender erfassen

DMARC-Berichte bilden nur den tatsächlich beobachteten Versand ab. Ein System, das ausschließlich am Monatsende, jährlich oder bei einer Störung sendet, kann während der Beobachtung unsichtbar bleiben. Deshalb gehört zur technischen Auswertung immer eine organisatorische Bestandsaufnahme.

Bei der ersten Prüfung schauen wir nicht nur auf den DNS-Eintrag, sondern auf alle Systeme, die eine Adresse der Unternehmensdomain in das sichtbare Absenderfeld schreiben dürfen. Dazu können gehören:

• Microsoft 365 sowie andere E-Mail-Plattformen,
• Warenwirtschaft, CRM, Ticket- und Abrechnungssysteme,
• Newsletter- und Marketingdienste,
• Website-Formulare und Webserver,
• Multifunktionsgeräte und Scanner,
• Alarmierungs- und Überwachungssysteme,
• externe Dienstleister mit Versand im Namen des Unternehmens.

Für jede Quelle sollte eine Zeile in der Absenderinventur angelegt werden:

Ergänzend sollten Fachabteilungen gefragt werden, welche Dienste sie selbst beauftragt haben. Auch Geräte ohne Benutzeranmeldung, Anwendungen hinter Adressen wie rechnung@ oder noreply@ und verwendete Subdomains gehören in die Prüfung. Der Name einer Rollenadresse ist dabei nicht das Problem; relevant ist der dahinterliegende Versandweg.

Mit p=none beobachten, ohne die Inventur zu ersetzen

p=none fordert für DMARC-fehlgeschlagene Nachrichten noch keine Quarantäne oder Zurückweisung. Die Richtlinie eignet sich dazu, Versandquellen und Ausrichtungsfehler anhand aggregierter Berichte sichtbar zu machen.

Ein Muster mit Platzhaltern lautet:

``text _dmarc.ihre-domain.de TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de" ``

Vor einer Übernahme müssen Domain und Berichtsadresse angepasst werden. Der Empfänger der Berichte muss erreichbar sein. Die eingehenden XML-Dateien sollten maschinell aufbereitet werden, damit Quellen, Ergebnisse und Veränderungen systematisch zugeordnet werden können.

Jede Auffälligkeit braucht einen Bearbeitungsstatus und eine verantwortliche Person. Nicht jede unbekannte Quelle ist automatisch ein Angriff: Dahinter kann auch eine vergessene Anwendung oder ein dezentral beschaffter Dienst stehen. Ebenso wenig schützt p=none bereits vor dem Missbrauch der Domain. Es ist eine Beobachtungsrichtlinie.

Die Freigabematrix für jede gefundene Quelle

Eine reine Aufteilung in „bestanden“ und „fehlgeschlagen“ ist für die betriebliche Entscheidung zu grob. Sinnvoller ist diese Klassifizierung:

Je nach Funktionsumfang des Systems kann die Korrektur unterschiedlich aussehen. Möglich sind eine DKIM-Signatur mit passender Domain, ein angepasster Envelope-Absender, der Versand über eine bereits korrekt eingerichtete Plattform oder eine klar abgegrenzte Versand-Subdomain. Nicht mehr benötigte Wege sollten abgeschaltet statt nachträglich legitimiert werden.

Ein typischer Fehler besteht darin, eine Quelle allein wegen eines grünen SPF-Ergebnisses freizugeben. Maßgeblich ist nicht nur das Prüfergebnis, sondern auch die Ausrichtung zur sichtbaren Absenderdomain.

Richtlinie, Testmodus und Durchsetzung trennen

Die Richtlinien haben unterschiedliche Zwecke:

• p=none verlangt keine durchsetzende Behandlung DMARC-fehlgeschlagener Nachrichten.
• p=quarantine fordert, solche Nachrichten als verdächtig zu behandeln.
• p=reject fordert ihre Zurückweisung.
• t=y kennzeichnet nach RFC 9989 den Test einer Richtlinie. Empfänger sollen die angeforderte Behandlung dabei nicht durchsetzen, die Nachricht aber weiterhin bewerten und in die Berichterstattung einbeziehen.

Ein Muster für den Test der späteren Ablehnungsrichtlinie ist:

``text _dmarc.ihre-domain.de TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@ihre-domain.de" ``

Für die anschließende Durchsetzung entfällt der Testmodus:

``text _dmarc.ihre-domain.de TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@ihre-domain.de" ``

t=y ist keine prozentuale Verteilung auf einzelne Nachrichten. Das aus dem früheren RFC 7489 bekannte Element pct wurde mit RFC 9989 entfernt und sollte nicht aus älteren Anleitungen in eine aktuelle Zielkonfiguration übernommen werden. p=quarantine kann eine Zwischenstufe sein, ist aber kein vorgeschriebener Schritt.

Weiterleitungen und Mailinglisten eigens prüfen

Ein erfolgreicher Direktversand bildet nicht jeden späteren Zustellweg ab. Bei einer Weiterleitung ändert sich der für SPF relevante Übertragungsweg. Mailinglisten können Nachrichten ebenfalls so verändern, dass eine zuvor gültige Authentifizierung nicht unverändert erhalten bleibt.

Für wichtige Versandarten sollte deshalb geprüft werden, was über bekannte indirekte Wege geschieht. Eine passende DKIM-Signatur kann die Abhängigkeit von SPF reduzieren, sofern das jeweilige System sie unterstützt und die Nachricht unterwegs nicht signaturrelevant verändert wird. Sie ist jedoch keine Garantie für jede Weiterleitung oder Mailingliste.

Auffälligkeiten auf solchen Wegen sollten nicht pauschal als Angriff bewertet werden. Legitime Sonderwege müssen vor der Durchsetzung korrigiert oder bewusst neu gestaltet werden.

Freigabecheck für p=reject

Die Ablehnungsrichtlinie ist erst entscheidungsreif, wenn alle folgenden Punkte nachvollziehbar geklärt sind:

• [ ] Alle bekannten Systeme und Dienstleister mit Versand unter der Unternehmensdomain sind inventarisiert.
• [ ] Jede weiterhin benötigte Quelle erreicht über SPF oder DKIM eine passende DMARC-Ausrichtung.
• [ ] Geschäftlich wichtige Systeme wurden nicht allein wegen eines erfolgreichen, aber unausgerichteten SPF-Tests freigegeben.
• [ ] Unbekannte Quellen aus den Berichten wurden untersucht und eingeordnet.
• [ ] Selten genutzte Versandwege wurden organisatorisch berücksichtigt.
• [ ] Weiterleitungen und Mailinglisten wurden als indirekte Wege geprüft.
• [ ] Wichtige Versandwege hängen bei indirekter Zustellung nicht ungeprüft allein von SPF ab.
• [ ] Verwendete Subdomains und ihre Versandwege sind erfasst.
• [ ] Die Berichtsadresse und die maschinelle Auswertung funktionieren.
• [ ] Für neue oder geänderte Versanddienste existiert ein Freigabeprozess.
• [ ] Änderungen und mögliche Zustellprobleme lassen sich kontrolliert nachvollziehen.
• [ ] Die Verantwortlichen unterscheiden Testmodus und wirksame Durchsetzung.

Freigabe: Alle legitimen Quellen sind geklärt und ausgerichtet; unbekannte Quellen und Sonderwege wurden bearbeitet.

Weiter im Testmodus: Die Zielrichtlinie steht fest, aber Auswirkungen auf einzelne oder indirekte Versandwege sind noch zu prüfen.

Keine Freigabe: Es bestehen unbekannte Quellen, nicht ausgerichtete Geschäftssysteme oder ungeklärte Versandwege mit möglicher betrieblicher Auswirkung.

Eine hohe Erfolgsquote in aggregierten Berichten ersetzt diese Entscheidung nicht. Es gibt weder eine allgemeingültige Mindestdauer für die Beobachtung noch eine einzelne Prozentzahl, die eine Domain automatisch freigabefähig macht.

Was p=reject nicht leistet

DMARC schützt die Verwendung einer Domain innerhalb der E-Mail-Authentifizierung. Es bestätigt weder die Vertrauenswürdigkeit des Inhalts noch die Identität der angezeigten Person.

p=reject verhindert daher nicht automatisch:

• Täuschung allein über den Anzeigenamen,
• Nachrichten von ähnlich geschriebenen fremden Domains,
• schädliche Inhalte aus einer technisch korrekt authentifizierten Domain,
• den Missbrauch eines übernommenen legitimen Postfachs,
• Betrugsnachrichten, die die geschützte Domain gar nicht verwenden.

Auch eine bestandene DMARC-Prüfung garantiert keine Zustellung. DMARC ist ein wichtiger Schutz für die eigene Absenderdomain, aber kein vollständiger Schutz vor Phishing oder kompromittierten Konten.

Der nächste konkrete Schritt

Legen Sie zunächst eine zentrale Liste aller Systeme an, die unter Ihrer Domain senden. Richten Sie anschließend die Beobachtung und eine erreichbare Berichtsadresse ein, bereiten Sie die Berichte maschinell auf und klassifizieren Sie jede Quelle. Erst nach der Korrektur legitimer Fehler sowie der Prüfung von Subdomains und indirekten Wegen sollte der Test einer durchsetzenden Richtlinie beginnen.

Wenn Microsoft 365 den zentralen E-Mail- und Identitätsdienst bildet, beginnt die Prüfung sinnvollerweise mit den dort hinterlegten Domains sowie den SPF- und DKIM-Einstellungen. Danach folgen die externen Versandwege. netzmal kann diese Bestandsaufnahme und Einordnung im Rahmen der belegten Leistungen rund um Cloud Native, Microsoft 365, E-Mail und Identitäten unterstützen.

Der entscheidende Merksatz lautet: Nicht der DNS-Eintrag bestimmt die Reife für p=reject, sondern die geklärte Herkunft und Ausrichtung jedes legitimen Versandwegs.