DMARC in der Praxis:
Versandquellen finden vor dem Reject

Versender finden vor DMARC

SPF und DKIM prüfen

Foto: viarami / Pixabay

Der Wechsel auf p=reject dauert 1 Minute im DNS. Die Wochen davor gehen für die Frage drauf, welche Website-Formulare, Scanner und Newsletter-Tools im Namen der Domain senden. Wer sie vergisst, sieht sie nach dem Reject im Spam.

Auf einen Blick

• SPF, DKIM und DMARC allein genügen nicht. DNS und Tenant sind zwei Welten, und wer nur eine pflegt, hat Zustellprobleme oder Lücken.
• Ohne Inventar der Versandquellen lässt sich DMARC nicht gefahrlos auf quarantine oder reject stellen. Drittversender wie Formulare, Newsletter-Tools, Scanner oder CRM sind selten dokumentiert.
• Ausnahmen wachsen über Jahre. IP-Allowlists, Transportregeln mit SCL -1 und Einträge in der Tenant Allow/Block List kennt später niemand mehr.
• DNS-Änderungen bleiben Handarbeit. Die Skripte erheben, vergleichen und berichten, sie ändern das DNS nicht.

Das Problem: Zwei Welten, viele Domains

Wer für mehrere Domains zuständig ist, kennt das Muster. Im DNS stehen SPF-, DKIM- und DMARC-Einträge. Im Tenant stehen Anti-Phishing, Quarantäne, Weiterleitungen und Auditing. Beides hängt zusammen, wird aber meist getrennt gepflegt.

Dazu kommen die Drittversender. Ein Kontaktformular auf der Website, ein Scanner im Treppenhaus oder ein Newsletter-Tool schickt Mails im Namen der Domain, oft seit Jahren. Niemand hat sie je aufgeschrieben. Sobald DMARC auf reject steht, verschwinden ihre Mails.

Ebenso unsichtbar sind die Ausnahmen. Eine IP-Allowlist, die jemand für ein altes Problem eingetragen hat, oder eine Transportregel, die den Spamfilter umgeht, wirkt jahrelang weiter. Sie schwächt den Schutz und kostet Punkte im Secure Score.

Der Werkzeugkasten im Überblick

Die Werkzeuge sind PowerShell-Skripte für Windows PowerShell 5.1. Sie liegen in einem Projekt mit Ordnern für Skripte, Vorlagen und Kunden. Die wichtigsten, nach Aufgabe gruppiert:

Dazu kommen Hilfen für die Anmeldung, auch über GDAP als Partner, und eine Aufräumfunktion, die pro Report-Serie nur die neueste Datei behält. Als Voraussetzungen gelten die Module ExchangeOnlineManagement sowie für Graph-Teile Microsoft.Graph.Authentication und Microsoft.Graph.Security, eine Rolle als Exchange- oder Security-Administrator und für Safe Links und Impersonation Defender for Office 365 Plan 1.

Schritt 1: SPF, DKIM und DMARC im DNS erfassen

Der DNS-Report braucht keine Anmeldung. Er fragt SPF, DMARC und typische DKIM-Selektoren ab und bewertet sie, etwa als OK (-all), MONITORING (p=none) oder ZU VIELE LOOKUPS. SPF erlaubt höchstens zehn DNS-Abfragen, mehr macht den Eintrag ungültig.

function Get-SpfRating {
    param([string[]]$Spf)
    if ($Spf.Count -eq 0) { return 'FEHLT' }
    if ($Spf.Count -gt 1) { return 'MEHRFACH (ungueltig)' }
    $lookups = ([regex]::Matches($Spf[0], '\b(include|a|mx|ptr|exists|redirect)[:=]?')).Count
    $all = [regex]::Match($Spf[0], '[~\-\?\+]all').Value
    if ($lookups -gt 10) { return "ZU VIELE LOOKUPS ($lookups)" }
    if ($all -eq '-all') { return 'OK (-all)' }
    if ($all -eq '~all') { return 'OK (~all, Softfail)' }
    return "SCHWACH ($all)"
}

Der Aufruf lautet .\Scripts\Get-EmailAuthReport.ps1 -Domains "contoso.com" -OutputPath .\Customers\Contoso\Inventory. Für viele Domains gibt es einen Massen-Check mit HTML-Übersicht und Ampel.

Schritt 2: Versandquellen finden

Hier liegt der Hauptgewinn. Der Crawler durchsucht die Website nach Formularen, danach liest das zweite Skript die SPF-IPs, löst sie per PTR auf, fragt den Message Trace ab und korreliert die Ergebnisse. Mit -TraceRiskSenderIps verfolgt es ausserdem die auffälligen IPs.

.\Scripts\Invoke-FormCrawler.ps1 -BaseUrl "https://www.contoso.com" -MaxPages 50 -IncludeFormDetails
.\Scripts\Get-WebsiteFormularAndSPFSenders.ps1 -WebsiteUrls @("www.contoso.com") -KundenDomain "contoso.com" `
    -SPFReportPath .\Customers\Contoso\Inventory -AdminUpn "[email protected]" -TraceRiskSenderIps

Der Message Trace reicht in Exchange Online nur 10 Tage zurück. Für seltene Versender wie ein Quartalsformular startet das Skript eine Historical Search, deren Export manuell erfolgt. Auch ohne Client-IP im Trace liefert die Korrelation brauchbare Hinweise.

Schritt 3: Ausnahmen aufspüren

Das Audit prüft für einen Absender fünf Stellen, an denen er in Exchange Online bevorzugt sein kann: Transportregeln, Connection Filter, Anti-Spam-Listen, die Tenant Allow/Block List und Advanced Delivery. Es ändert nichts. Ein Teil davon sieht so aus:

foreach ($r in Get-TransportRule) {
    $hit = ($r.From -contains $SenderAddress) -or ($r.SenderDomainIs -contains $SenderDomain) -or
           ($SenderIP -and ($r.SenderIpRanges -contains $SenderIP))
    if ($hit -or $r.SetSCL -eq -1) {
        Add-Finding 'TransportRule' $r.Name ("SetSCL={0}; State={1}" -f $r.SetSCL, $r.State) $r.WhenChanged
    }
}
foreach ($cf in Get-HostedConnectionFilterPolicy) {
    if ($SenderIP -and ($cf.IPAllowList | Where-Object { $_ -eq $SenderIP -or $_ -like "$SenderIP/*" })) {
        Add-Finding 'ConnectionFilter' $cf.Name 'IP steht in der IPAllowList' $cf.WhenChanged
    }
}

Der klassische Fall lautet «landet trotz Whitelist im Junk». Meist steht der Absender an einer Stelle, die nicht greift, oder an dreien, die sich widersprechen. Dauerhafte IP-Allowlists sind ein Abzug im Secure Score. Besser ist es, DKIM und SPF des Absenders zu korrigieren.

Schritt 4: Baseline vergleichen

Die Custom-Anti-Phishing-Policy wird gegen eine Soll-Datei verglichen und bei Bedarf angepasst. Das Soll nennt zum Beispiel PhishThresholdLevel 3, alle Safety Tips und die Quarantäne-Richtlinie DefaultFullAccessWithNotificationPolicy. Das Skript zeigt je Einstellung OK oder ABWEICHUNG.

$policy = Get-AntiPhishPolicy | Where-Object { -not $_.IsDefault } | Select-Object -First 1
$diff = foreach ($key in $baseline.Keys) {
    $ist = $policy.$key
    [pscustomobject]@{
        Setting = $key; Ist = $ist; Soll = $baseline[$key]
        Status  = if ("$ist" -eq "$($baseline[$key])") { 'OK' } else { 'ABWEICHUNG' }
    }
}
if ($Apply) {
    $toSet = @{}
    $diff | Where-Object Status -eq 'ABWEICHUNG' | ForEach-Object { $toSet[$_.Setting] = $_.Soll }
    if ($toSet.Count -gt 0 -and $PSCmdlet.ShouldProcess($policy.Name, 'Set-AntiPhishPolicy')) {
        Set-AntiPhishPolicy -Identity $policy.Name @toSet
    }
}

Mit -WhatIf lässt sich vorab sehen, was sich ändern würde. Wie ein Team Sicherheitseinstellungen mit niedrigem Risiko hebt, zeigt der Artikel Secure Score Quick Wins: risikoarme Massnahmen per PowerShell.

Schritt 5: DNS in der richtigen Reihenfolge umsetzen

Die Reihenfolge entscheidet, ob die Zustellung stabil bleibt:

1. SPF konsolidieren, damit alle bekannten Versender erlaubt sind und höchstens zehn Lookups entstehen.
2. DKIM aktivieren, im DNS und in der Signierung.
3. DMARC mit p=none und einer rua-Adresse veröffentlichen und die Berichte sichten.
4. Nach der Beobachtung auf quarantine stellen.
5. Zum Schluss auf reject.

Nach jedem Schritt gehört eine Testmail dazu, bei der der Header Authentication-Results geprüft wird. Die Microsoft-Dokumentation beschreibt SPF, DKIM und DMARC für Microsoft 365. Ein SPF-Eintrag lässt sich ausserdem leicht versehentlich löschen, wie der Artikel Tickets selbst lösen: 7 Phasen und ein Prompt für KI-Agenten am Beispiel von dnscmd /recorddelete zeigt.

Typische Fehler

Grenzen

DNS-Änderungen automatisieren die Skripte nicht, sie bleiben beim DNS-Verantwortlichen. Der Message Trace reicht nur 10 Tage zurück. Die Aggregate-Reports (rua) werte das Werkzeug nicht aus. Die Standardwerte einzelner Skripte stammen aus dem ersten Einsatzfall, deshalb gehören die Parameter immer ausdrücklich gesetzt.

Einordnung: Was das für Microsoft-365-Admins und IT-Dienstleister heisst

Für Dienstleister mit vielen Domains lohnt sich ein wiederholbarer Ablauf, denn jeder Kunde hat dieselben Lücken in anderer Verteilung. Die Zeit geht dabei weniger ins DNS als in die Inventur der Versandquellen. Wer sie früh startet, kann DMARC über Wochen im Monitoring-Modus laufen lassen und erst dann verschärfen. Für KMU ohne eigenen Admin ist der Ablauf ein guter Prüfpunkt für die Beratung. Frage zuerst nach der Liste der Versender und der Liste der Ausnahmen. Fehlen beide, ist die Domain noch nicht reif für reject.

Fazit

DMARC auf reject gelingt, wenn alle Versandquellen bekannt sind und alte Ausnahmen aufgeräumt wurden. Ein Werkzeugkasten aus DNS-Report, Formular-Crawler, Message-Trace-Korrelation, Ausnahmen-Audit und Baseline-Vergleich macht diese Inventur wiederholbar. Beginne mit dem DNS-Report und dem Crawler, bevor du auch nur eine Zeile im DNS änderst.

Quellen: SPF bei Microsoft Learn, DKIM bei Microsoft Learn, DMARC bei Microsoft Learn. Skripte gekürzt und anonymisiert. Zuletzt geprüft: 24. Oktober 2026.

Geschrieben von Andreas Brauckmann