Produkt
DMARC-Monitoring,
ohne MX-Umstellung.
Deemarc bindet sich über die Microsoft-Graph-API direkt an Ihren M365-Tenant. Keine Veränderung am Mailfluss, keine zusätzlichen MX-Hops, keine Endnutzer- Anmeldungen. Sie hinterlegen einen DMARC-Report-Empfänger — den Rest macht die Plattform.
01 — Grundlage
Was DMARC
wirklich ist.
DMARC beantwortet eine einzige Frage: „Wer darf im Namen unserer Domain Mails verschicken?"
Die Domain veröffentlicht im DNS ein TXT-Record mit dem Tag
v=DMARC1; p=...; rua=mailto:.... Jeder Empfänger-Server
(Google, Microsoft, Yahoo) prüft eingehende Mails dagegen und schickt täglich
einen aggregierten Bericht zurück.
Diese Berichte sind XML-Dateien, komprimiert, oft stündlich, von dutzenden Empfängern parallel. Ohne Tool sind sie praktisch unlesbar — und damit wertlos. Mit Tool zeigen sie minutengenau, wer in Ihrem Namen Mail verschickt und ob die Authentifizierung sauber ist.
02 — Architektur
Warum
Graph-native.
Andere DMARC-Tools setzen einen Mail-Gateway davor (Proofpoint-Modell) oder fordern, dass Sie eine fremde Reporting-Adresse in den DMARC-Record eintragen, die dann via SMTP empfängt. Beides hat Nachteile:
Deemarc nutzt die Graph-API von Microsoft 365: Sie geben uns App-only-Zugriff auf das Postfach, in dem Sie ohnehin die DMARC-Reports empfangen würden, und wir lesen die XML-Anhänge im Hintergrund aus. Kein MX, keine SMTP-Infra, keine DNS-Akrobatik.
03 — Datenfluss
Vom Reporting-Postfach
ins Dashboard.
- A
Empfänger melden
Google, Microsoft, Yahoo & Co. senden täglich DMARC-Aggregate-Reports an Ihre rua-Adresse.
- B
M365 nimmt entgegen
Reports landen im Reporting-Postfach Ihres Tenants. Kein zusätzlicher Mail-Hop, kein MX-Eingriff.
- C
Deemarc liest aus
Graph-Subscription weckt unseren Worker. XML-Anhänge werden entpackt, normalisiert, validiert.
- D
Sie sehen das Bild
Dashboards mit Versandquellen, Pass-/Fail-Raten, Anomalien. Alerts per E-Mail oder Webhook.
04 — MSP-Modell
Ein Konto,
beliebig viele Kunden.
Deemarc ist von Anfang an für Managed Service Provider gebaut. Jeder Kunde ist ein eigener Mandant — und das nicht logisch, sondern physisch:
Cross-Tenant-Queries gibt es nicht. Nicht aus Versehen, nicht aus Bequemlichkeit. Das ist im Code als Constraint verankert und in jedem Repository-Layer-Test verifiziert.
05 — Die Policy-Reise
Von „beobachten"
zu „blockieren".
DMARC ist keine Software, die man installiert — es ist ein Pfad. Drei Policies,
drei Schritte. Wer zu früh auf reject wechselt,
verschickt versehentlich seine eigenen Newsletter in den Spam.
- p=none
Schritt 1 — Monitor
Nur beobachten. Empfänger ignorieren das Verdikt, melden aber Reports. Pflichtschritt — hier sammeln Sie 30–60 Tage Daten.
- p=quarantine
Schritt 2 — Quarantäne
Nicht authentifizierte Mails landen im Spam-Ordner. Erster Härteschritt — nur wenn alle legitimen Versandquellen bestätigt sind.
- p=reject
Schritt 3 — Reject
Nicht authentifizierte Mails werden zugestellt-verweigert. Zielzustand für jede ernstgemeinte Domain — und seit 2024 De-facto-Pflicht für Bulk-Sender.
06 — Häufige Fragen
Was MSPs
uns fragen.
- Müssen wir den MX-Record umstellen, damit Deemarc funktioniert?
- Nein. Deemarc liest die DMARC-Aggregate-Reports direkt aus Microsoft 365 über die Graph API. Der Mailfluss bleibt unverändert.
- Welche Berechtigungen braucht Deemarc in unserem M365-Tenant?
- Lesezugriff auf den oder die Reporting-Postfächer via Microsoft Graph (Mail.Read, App-only). Keine Endbenutzer-Authentifizierung, kein Schreibrecht, keine Mailbox-Manipulation.
- Wir haben mehrere Domains. Können wir alle in einem Setup beobachten?
- Ja. Deemarc behandelt jede Domain individuell, aber Sie sehen alle in einer Konsole. Für MSPs mit vielen Endkunden gibt es Multi-Tenant-Trennung mit eigener Datenbank pro Mandant.
- Was passiert, wenn jemand Phishing in unserem Namen versendet?
- Deemarc erkennt das anhand der Empfänger-Berichte (Google, Microsoft, Yahoo etc. melden Spoof-Versuche). Sie sehen die Quelle (IP/AS), die getroffenen Empfänger und welche DMARC-Policy gegriffen hat.
- Sind die DMARC-Reports nicht öffentlich verfügbar?
- Die Reports landen ausschliesslich bei den in Ihrem DMARC-Record hinterlegten rua-Adressen. Deemarc bekommt sie nur, weil Sie eine Deemarc-Reportadresse in den DMARC-Record eintragen. Sie behalten jederzeit die Kontrolle.
- Wo werden unsere Daten verarbeitet?
- Auf einem Server in Deutschland (Hetzner). Pro Mandant eine eigene SQLite-Datei mit chmod 600. Backups als Restic-Snapshots auf eine separate Storage-Box.
- Können wir den Service kündigen und unsere Daten mitnehmen?
- Ja. Sie bekommen den vollständigen Datenbank-Export Ihrer Tenant-Daten und können den DMARC-Reportadress-Eintrag jederzeit entfernen. Vendor-Lock-in ist kein Geschäftsmodell.
Bereit für eine Demo?
30 Minuten Screenshare. Wir zeigen Deemarc an einem echten M365-Tenant.