DMARC auf p=reject umstellen – ohne dass Mails verschwinden

Die Empfehlung klingt einfach: «Stellen Sie DMARC auf p=reject.» Microsoft Secure Score, CIS-Benchmarks und Versicherer fordern es. Und dann wird umgestellt – und plötzlich verschwinden die Mails der Marketingagentur, Benachrichtigungen aus dem Ticketsystem landen im Spam, und Rechnungen aus dem ERP kommen beim Kunden nicht mehr an.

Das liegt nicht an DMARC. Es liegt daran, dass kaum ein Unternehmen genau weiss, wer alles im Namen seiner Domain versendet. Dieser Artikel zeigt, wie Sie das vorab herausfinden und DMARC schrittweise auf p=reject bringen.

SPF, DKIM und DMARC – das Minimum

SPF legt per DNS-TXT-Record fest, welche Server Mails für eine Domain versenden dürfen. Geprüft wird dabei die Domain der technischen Absenderadresse (Envelope-From bzw. Return-Path), nicht die im Mailprogramm sichtbare From-Adresse:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

DKIM signiert jede Mail kryptografisch. Der Empfänger prüft die Signatur mit dem öffentlichen Schlüssel im DNS der signierenden Domain (d= im DKIM-Header). DKIM übersteht im Gegensatz zu SPF auch Weiterleitungen.

DMARC verbindet beides mit der sichtbaren From-Adresse. Eine Mail besteht DMARC, wenn mindestens einer der beiden Mechanismen besteht und dessen Domain zur From-Domain passt. Dieses «Passen» heisst Alignment – und genau dort scheitern die meisten Drittanbieter. Die Richtlinie legt fest, was mit Mails passiert, die DMARC nicht bestehen:

• p=none: normale Zustellung, nur Reporting
• p=quarantine: Zustellung in den Spam-Ordner
• p=reject: Ablehnung bereits bei der Annahme

v=DMARC1; p=reject; rua=mailto:dmarc@example.ch

Was bei p=reject wirklich bricht

Ein typisches Bild in einem KMU: Exchange Online für die Mitarbeitenden, dazu ein Newsletter-Tool, ein CRM, ein Ticketsystem, ein Multifunktionsgerät mit Scan-to-Mail und ein altes Skript, das nachts Berichte verschickt. Die Fehlerbilder wiederholen sich:

Fremder Return-Path

Das Newsletter-Tool versendet mit From: info@example.ch, setzt aber seine eigene Bounce-Adresse, etwa bounces@mail.anbieter.net. SPF besteht – aber für die Domain des Anbieters. Für DMARC zählt das nicht, weil die Domain nicht zur From-Domain passt. Ein include: des Anbieters in Ihrem SPF-Record hilft in diesem Fall übrigens gar nichts.

Fremde DKIM-Signatur

Viele Dienste signieren standardmässig mit ihrer eigenen Domain. Die Signatur ist gültig, aber nicht aligned. Erst wenn Sie im Dienst eine eigene Absenderdomain einrichten und die DKIM-Records in Ihrem DNS hinterlegen, signiert er mit d=example.ch.

Lokale Geräte und Skripte

Der Drucker oder das Skript versendet über eine IP, die nirgends im SPF steht, und signiert nicht. Ohne Anpassung werden diese Mails mit p=reject abgelehnt.

Gateways, die Mails verändern

Ein Gateway, das Betreff, Body oder Header verändert (Disclaimer, Banner, Umschreiben von Links), kann bestehende DKIM-Signaturen ungültig machen. Schreibt es zusätzlich den Return-Path um, scheitern beide Mechanismen.

Versteckte Sender finden: DMARC-Reports auswerten

Bevor Sie irgendetwas verschärfen, brauchen Sie eine vollständige Liste aller Systeme, die im Namen Ihrer Domain senden. Die liefern die Aggregate Reports.

Schritt 1: Mit p=none und Reporting starten

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ch; fo=1

• rua: Adresse für die täglichen Aggregate Reports (XML)
• fo=1: Fehlerberichte bereits auslösen, wenn SPF oder DKIM scheitert (Standard ist: nur wenn beide scheitern). Wirkt nur zusammen mit ruf; viele grosse Provider versenden solche forensischen Einzelberichte heute aber gar nicht mehr.

Schritt 2: Reports lesen

Nach ein bis zwei Tagen treffen die ersten XML-Reports der grossen Mailprovider ein. Ein Ausschnitt:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
  </report_metadata>
  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>523</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.ch</header_from>
    </identifiers>
  </record>
</feedback>

Gelesen heisst das: 523 Mails mit From example.ch kamen von 203.0.113.42, DKIM war nicht aligned, SPF schon. Diese Quelle besteht DMARC – würde aber sofort scheitern, wenn sich die IP ändert. Ein Kandidat, um DKIM nachzurüsten.

Von Hand ist das ab einer gewissen Menge mühsam. Ein DMARC-Analysedienst oder ein kleines Auswertungsskript fasst die Reports nach Quelle zusammen und zeigt, welche Absender scheitern. Wichtig ist nicht das Werkzeug, sondern dass jemand die Ergebnisse regelmässig ansieht.

Schritt 3: Jede Quelle zuordnen

Ordnen Sie jede sendende IP einem System und einer verantwortlichen Person zu. Prüfen Sie dabei auch Ihre bestehenden SPF-Includes: Oft stehen dort Dienste, die längst nicht mehr genutzt werden – oder es fehlt ein Gerät, das niemand mehr auf dem Radar hat.

SPF und DKIM für jeden Sender sauber machen

SPF: unter 10 DNS-Lookups bleiben

Jedes include: und jeder a- oder mx-Mechanismus verursacht DNS-Abfragen, verschachtelte Includes zählen mit. Mehr als 10 Lookups führen zu einem permanenten Fehler, und SPF gilt als nicht bestanden. Auf Subdomain-Records auszuweichen, die per include: eingebunden werden, löst das Problem nicht – die Lookups zählen über die ganze Auswertung. Was hilft:

• Includes nicht mehr genutzter Dienste entfernen
• Dienste, die ohnehin mit eigenem Return-Path senden, gar nicht erst ins SPF aufnehmen
• Dienste auf eigene Subdomains verlagern (z.B. news.example.ch) – mit eigenem SPF-Record für diese Subdomain
• Für Drittanbieter primär auf DKIM-Alignment setzen

DKIM in Exchange Online aktivieren

Connect-ExchangeOnline
# Falls für die Domain noch keine Konfiguration existiert
New-DkimSigningConfig -DomainName "example.ch" -Enabled $false
# Die beiden CNAME-Ziele für das DNS auslesen
Get-DkimSigningConfig -Identity "example.ch" | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME
# Nach dem Eintragen der CNAMEs im DNS aktivieren
Set-DkimSigningConfig -Identity "example.ch" -Enabled $true

Im DNS legen Sie selector1._domainkey und selector2._domainkey als CNAME auf die ausgegebenen Ziele an. Übernehmen Sie die Werte immer aus Get-DkimSigningConfig – Microsoft hat das Format der Ziele geändert, abgeschriebene Beispiele aus dem Internet passen oft nicht.

DKIM bei Drittanbietern

Fast jeder seriöse Dienst bietet eine Domain-Authentifizierung an, meist unter «Sender Authentication» oder «Domain Verification». Der Ablauf ist immer ähnlich:

1. Absenderdomain im Dienst hinterlegen
2. Die angezeigten DKIM-Records (oft CNAMEs) im DNS eintragen
3. Im Dienst verifizieren lassen
4. Falls angeboten: eigene Bounce-Domain (Return-Path) als Subdomain einrichten – dann ist auch SPF aligned

Geräte und Skripte

Versenden Geräte oder Skripte über Exchange Online, signiert Exchange Online mit dem DKIM-Schlüssel Ihrer Domain. Das ist meist der einfachste Weg zu DMARC-konformen Mails. Wie Sie Geräte und Applikationen ohne veraltetes SMTP AUTH an Exchange Online anbinden, beschreibt der Artikel SMTP-Relay ablösen.

Spezialfall Exchange Hybrid und Gateways

Mit lokalem Exchange oder einem vorgelagerten Gateway gibt es zusätzliche Stellen, an denen Alignment verloren geht:

• Return-Path-Umschreibung: Manche Gateways ersetzen die Absenderadresse im Envelope durch eine eigene. Konfigurieren Sie das Gateway so, dass es den Return-Path nicht verändert oder eine Subdomain Ihrer Domain verwendet.
• Veränderte Inhalte: Disclaimer, Banner oder Link-Umschreibung nach der DKIM-Signatur machen die Signatur ungültig. Signieren muss das System, das die Mail als letztes verändert.
• Versandweg ins Internet: Geht ausgehende Mail lokaler Postfächer direkt ins Internet, muss die öffentliche IP im SPF stehen und das sendende System DKIM signieren. Läuft sie über Exchange Online, wird sie dort behandelt.

Rollout-Plan: von p=none zu p=reject

Umgestellt wird erst, wenn in den Reports keine legitime Quelle mehr scheitert – nicht nach Kalender. Was dann noch scheitert, sollte ausschliesslich Spoofing oder Weiterleitung sein.

Weitere nützliche Tags:

• sp=: eigene Richtlinie für Subdomains. Damit lassen sich auch nicht genutzte Subdomains gegen Missbrauch schützen.
• pct=: wendet die Richtlinie nur auf einen Teil der Mails an. Wird von Empfängern unterschiedlich konsequent umgesetzt – verlassen Sie sich nicht darauf als Sicherheitsnetz.

Domains, die gar keine Mails versenden, sollten direkt v=spf1 -all und p=reject erhalten.

Fazit

Der häufigste Fehler ist, p=reject zu setzen, bevor die Hausaufgaben gemacht sind. Dann kommen Beschwerden, die Richtlinie wird zurückgedreht, und das Thema gilt als «schwierig». Wer dagegen erst die Sender kartografiert, SPF und DKIM für jeden einzelnen sauber ausrichtet und schrittweise verschärft, erreicht p=reject ohne verlorene Mails – und schützt die eigene Domain wirksam gegen Spoofing und Phishing in ihrem Namen.

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen