DMARCPulse-Update Mai 2026: Hosted Mailbox, App-Only und ehrlicheres SPF

Was sich geändert hat — auf einen Blick

Mit dem heutigen Update entfallen zwei der nervigsten Hürden beim Onboarding und ein Teil der Dashboard-Verwirrung, die uns Kund:innen in den letzten Wochen zurückgemeldet haben:

Hosted DMARC Mailbox — wir hosten die rua=-Adresse für Dich. Kein IMAP-Konto, keine OAuth-Einwilligung, keine Admin-Genehmigung in Microsoft 365.
Microsoft 365 App-Only ohne eigenes Zertifikat — wir bringen das Zertifikat mit. Du legst nur eine Application-Access-Policy an und gibst Deinen Tenant frei.
„Aligned”-Spalte im Auth-Results-Breakdown — sichtbar machen, warum die SPF-Pass-Rate bei z. B. Brevo niedrig aussieht, obwohl raw alles passt. (Spoiler: das ist normal, kein Problem.)

Dazu eine Reihe kleinerer Verbesserungen unter der Haube — Stichworte: ehrlichere OAuth-Fehlermeldungen, robuste Wiederholversuche bei kurzen Datenbank-Aussetzern, Brevo-SMTP-Relay für unsere Transaktionsmails (keine Junk-Klassifizierung mehr in Microsoft 365).

Hosted DMARC Mailbox: keine Mailbox-Konfiguration mehr nötig

Bisher hatten DMARCPulse-Kund:innen drei Optionen, damit Reports überhaupt bei uns ankommen: eigene IMAP-Zugangsdaten hinterlegen, ein Microsoft-365- oder Google-Postfach via OAuth anbinden, oder einen Service-Account verwenden. Alle drei haben Vor- und Nachteile, aber alle drei haben einen gemeinsamen Pferdefuss: es muss überhaupt erstmal ein Postfach existieren, das Reports empfängt — und IT-Abteilungen müssen Zugriff darauf einrichten.

Die neue Option umgeht das komplett. Du wählst einen Alias auf in.dmarcpulse.io, z. B. [email protected], und setzt diesen in Deinen DMARC-rua=-Eintrag. Wir empfangen die Reports, validieren die Anhänge und übernehmen sie direkt in Deine Tenant-Datenbank.

v=DMARC1; p=reject; rua=mailto:[email protected]

Konkret heisst das:

Kein Mail-Server, der konfiguriert oder gewartet werden muss.
Keine Berechtigungen, die durch IT freigegeben werden müssen.
Kein Login, der irgendwann abläuft.
RFC 7489 §7.1 — die für Cross-Domain-Reporting nötigen Authorization-Records (*._report._dmarc.in.dmarcpulse.io) sind bereits publiziert; Empfänger akzeptieren die Adresse direkt.

Wenn Du eine bestehende Konfiguration mit IMAP oder M365-OAuth schon laufen hast, musst Du nichts ändern — Hosted Mailbox ist eine zusätzliche Option, kein Ersatz. Für neue Domains und für Setups mit hartem Microsoft-Defender-Lockdown ist es aber inzwischen unsere Empfehlung.

Eines noch zu Datenschutz und Recht: wir verarbeiten ausschliesslich aggregierte DMARC-Reports (XML-Anhänge mit Statistiken, ohne Inhalt einzelner Mails). Forensische ruf=-Reports werden absichtlich nicht angenommen, weil deren Payload personenbezogene Daten enthält und ohne separates Auftragsverarbeitungs-Vertragsverhältnis nicht haltbar wäre.

Microsoft 365 App-Only — ohne dass Du ein eigenes Zertifikat erzeugst

Microsoft 365 unterstützt seit Jahren Application Permissions (App-Only-Auth), die für DMARC-Polling deutlich sauberer sind als delegierte OAuth-Tokens: kein Refresh-Token-Ablauf, kein User-Consent-Dialog, präzise auf eine einzelne Mailbox einschränkbar via Application Access Policy.

Der Nachteil bisher: Microsoft verlangt für App-Only-Zugriff entweder ein Client-Secret (mit kurzer Lebensdauer) oder ein Zertifikat (mit längerer). Letzteres ist die robustere Lösung, aber jeder Kunde musste sein eigenes Zertifikat erzeugen, im Azure Portal hochladen, und alle 1–2 Jahre rotieren.

Mit diesem Update bringen wir das Zertifikat mit. DMARCPulse betreibt ein zentral verwaltetes Master-Zertifikat, das in jedem Kunden-Azure-Tenant eingetragen wird. Du musst nur noch:

Die Multi-Tenant-App in Deinem Microsoft-365-Tenant zulassen.
Eine Application Access Policy anlegen, die DMARCPulse auf genau die Mailbox(en) einschränkt, die Reports empfangen sollen.
Den Mailbox-Namen im Wizard eintragen.

Der Wizard im Dashboard führt Dich durch die nötigen PowerShell-Schritte — inklusive Auto-Prefill bestehender App-Only-Postfächer, falls Du mehrere Domains betreust und die Policy erweitern möchtest. Der Reset-Pfad bei Fehlkonfigurationen ist ebenfalls dokumentiert (Microsoft-Cache-Propagation kann je nach Region zwischen 30 Sekunden und einer Stunde dauern — der Wizard erklärt’s vor Ort).

„Aligned”-Spalte: ehrliche Zahlen statt scheinbarer Widerspruch

Wer mit Bulk-Mail-Relays arbeitet — Brevo, SendGrid, Mailgun, Postmark — kennt die Verwirrung: ein Blick auf die Reports zeigt „SPF: 100 % pass” in der Detailtabelle, aber die KPI oben sagt „SPF Pass Rate 9,8 %”. Beides stimmt — aber sie messen Unterschiedliches.

Raw SPF (RFC 8601): Die Mail-From-Domain hat einen gültigen SPF-Eintrag, der den absendenden Server autorisiert.
Aligned SPF (DMARC): Zusätzlich muss die organisationelle Domain der Mail-From-Adresse mit der sichtbaren From-Header-Domain übereinstimmen.

Bei Brevo & Co. läuft die Mail über deren Bounce-Domain (bounces.sendgrid.net, gx.d.sender-sib.com o. ä.), während im Header-From Deine eigene Domain steht. Raw-SPF-Pass: ja. DMARC-aligned: nein. DKIM rettet die Sache, weil der Relay mit einer Signatur in Deiner Domain unterschreibt — aber das war im Dashboard nicht sofort sichtbar.

Deshalb gibt es jetzt eine neue Aligned-Spalte im Auth-Results-Breakdown. Pro Mail-From-Domain (SPF) und pro DKIM-Selektor wird angezeigt, wie viele der raw passierenden Nachrichten auch DMARC-aligned sind:

Mailfrom Domain	Pass	Total	Aligned	Pass %
`gy.d.sender-sib.com` (Brevo)	292	292	0 (0 %)	100 %
`acme.com` (direkter Versand)	45	45	45 (100 %)	100 %

Der rote 0 (0 %)-Wert sagt sofort: dieser Sender hilft DMARC nicht — guck stattdessen, ob er DKIM-aligned signiert (das tun Brevo, SendGrid, Mailgun standardmäßig, wenn Du die DKIM-CNAMEs publiziert hast). Die Spalte ersetzt keinen Erklärungstext, aber sie macht den scheinbaren Widerspruch visuell auflösbar — und deutet bei rein roten Werten ohne kompensierendes DKIM-aligned auf ein echtes Problem hin.

Unter der Haube — Stabilität und Deliverability

Drei kleinere Verbesserungen, die im Alltag den Unterschied machen, aber kein eigenes Kapitel verdienen:

Transiente Datenbank-Wackler werden jetzt automatisch wiederholt. Bei kurzen Verbindungsabbrüchen zur Tenant-Datenbank (typisch unter Last oder beim Aufwärmen einer eingefrorenen Replica) versucht ein Lese-Query genau einmal automatisch erneut, statt eine Fehlermeldung an die UI durchzureichen.
Transaktionsmails landen jetzt zuverlässig im Inbox. Wir haben unseren SMTP-Versand auf Brevos Shared-Pool umgestellt — die jüngeren dmarcpulse.io-Reputationswerte reichten für Microsoft Defenders Bulk-Heuristik nicht aus, ein warmer Pool löst das strukturell. Verifikations- und Trial-Mails landen in Microsoft 365 jetzt zuverlässig im Posteingang statt im Junk.
OAuth-Fehler sind jetzt diagnostizierbar. Wenn der Token-Tausch mit Google oder Microsoft scheitert, wird der konkrete Fehlertext (z. B. „access blocked by policy”, „consent required”) in der UI angezeigt statt einem generischen oauth_failed. Das spart einen Support-Ticket-Roundtrip.

Daneben eine Reihe kleinerer UX-Korrekturen: ausgerichtete Spalten in den DKIM/SPF-Subtabellen, eine Warnung bei DMARC-Records mit mehreren rua=-Adressen (Microsoft 365 sendet nur an die erste — RFC 7489 sagt anderes, die Realität gewinnt), UCEPROTECT-L2/L3 als informativer Tier neben tatsächlich aktionierbaren Blacklists.

Wie Du loslegst

Bestehende Tenants müssen nichts tun — alle Verbesserungen sind automatisch aktiv. Wenn Du die Hosted Mailbox ausprobieren möchtest, findest Du den Setup-Schritt in Domain Settings → Hosted Mailbox. Microsoft 365 App-Only liegt im selben Bereich unter Email Sources → Microsoft 365 (App-Only).

Wenn Du noch kein DMARCPulse-Konto hast: 14 Tage Probezeit ohne Kreditkarte — die meisten Setups stehen in unter zehn Minuten. Jetzt registrieren.