Aggregatreports
Google, Microsoft, Yahoo und andere Empfänger senden täglich einen Report für jede Domain mit DMARC. Wir empfangen sie in einem dedizierten Postfach und lesen sie stündlich.
Cybersecurity › E-Mail-Sicherheit › DMARC-Monitoring
Google, Microsoft, Yahoo und andere Empfänger sagen Ihnen jeden Tag, wer im Namen Ihrer Domain Post versendet. Sie tun es mit XML-Reports, die niemand liest. Wir lesen sie stündlich, übersetzen sie in konkrete Maßnahmen und begleiten die Domain Schritt für Schritt bis p=reject. Sie erhalten das Domain-Datenblatt von Ihrem Ansprechpartner: kein Tool, das Sie lernen müssen.
Viele Unternehmensdomains haben einen DMARC-Eintrag veröffentlicht, um die Anforderungen der großen Empfänger zu erfüllen, und sind bei p=none stehen geblieben: Die Reports landen in einem Postfach, das niemand öffnet, und die Richtlinie blockiert nichts. Monitoring ist die Arbeit, die diesen Eintrag in Schutz verwandelt: verstehen, wer sendet, die legitimen Absender autorisieren, die Richtlinie verschärfen, wenn die Zahlen es erlauben.
Nur beobachten. Nachrichten, die die Authentifizierung nicht bestehen, werden trotzdem zugestellt: Die Domain bleibt für Phishing und Spoofing in Ihrem Namen nutzbar, auch mit veröffentlichtem Eintrag.
Das Format der Aggregatreports: eine Datei pro Empfänger und Tag, mit IP-Adressen, Volumen und Ergebnissen. Nützlich nur, wenn jemand sie liest, mit den tatsächlich sendenden Systemen abgleicht und handelt.
Die Grenze an DNS-Abfragen, ab der ein SPF-Eintrag stillschweigend scheitert. Jeder per include ergänzte Dienst verbraucht welche. Sie zu zählen und zu reduzieren gehört zum Monitoring.
So funktioniert es
Der Zyklus beginnt bei den empfangenden Servern und endet im DNS Ihrer Domain. Dazwischen liegt die Arbeit, die sonst niemand macht: lesen, verstehen, autorisieren, verschärfen.
Google, Microsoft, Yahoo und andere Empfänger senden täglich einen Report für jede Domain mit DMARC. Wir empfangen sie in einem dedizierten Postfach und lesen sie stündlich.
Jede Quelle erhält eine verständliche Diagnose: eigener Server zu reparieren, Drittanbieter zu autorisieren, Weiterleitung, blockierter Missbrauch. Daneben die Maßnahme.
Wir autorisieren Absender in SPF, aktivieren DKIM, wo es fehlt, reduzieren Lookups und veröffentlichen die von der Plattform erzeugten Einträge.
Die Domain wechselt zu p=quarantine und dann zu p=reject, sobald der Bereitschaftswert es zulässt. Das Monitoring läuft weiter, die Alarme bleiben aktiv.
Wir verkaufen kein Dashboard. AtWorkStudio konfiguriert die Einträge, autorisiert die Absender, bringt die Domain ins Enforcement und überwacht sie weiter. Der Kunde erhält das Domain-Datenblatt, aktualisiert von seinem Ansprechpartner, und muss kein Tool lernen.
Die Betriebsplattform DMARC Reaper ist den Operatoren von AtWorkStudio vorbehalten. Für Organisationen mit Microsoft 365 ergänzt der Service Defender for Office 365 und unser ACN-qualifiziertes Email Security Gateway: Die Authentifizierung schützt die Domain, das Gateway schützt die Postfächer.
Reports, Verlauf und Datenblätter liegen in der Azure-Region Italien Nord. Keine Ressourcen von Drittanbietern in den Seiten der Plattform.
Aufbewahrung von Reports und Verlauf: genug, um ein ganzes Jahr zu vergleichen und zu dokumentieren, wann eine Quelle auftauchte oder autorisiert wurde.
Jedes Domain-Datenblatt vergleicht die letzten 30 Tage mit den 30 davor: Es ist die periodische Zusammenfassung, die Ihr Ansprechpartner bei AtWorkStudio als PDF übergibt, in der Regel zum Monatsende oder nach einem Eingriff.
Ein Service eines Unternehmens, das für Informationssicherheit, Cloud-Sicherheit, Schutz personenbezogener Daten und Qualität zertifiziert ist. Mitglied im Clusit.
Die Fragen, die wir vor der Aktivierung des Services hören.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein DNS-Eintrag, mit dem der Inhaber einer Domain den empfangenden Servern mitteilt, was mit Nachrichten geschehen soll, die SPF oder DKIM nicht bestehen: nichts (p=none), Quarantäne (p=quarantine) oder Ablehnung (p=reject). Der Teil „Reporting“ wird von den wenigsten genutzt: Google, Microsoft, Yahoo und andere Empfänger senden täglich einen Aggregatreport im XML-Format mit den IP-Adressen, die im Namen der Domain gesendet haben, und dem Ergebnis der Authentifizierung. Regelmäßig gelesen, zeigen diese Reports, wer Ihre Domain tatsächlich nutzt. Der Service empfängt sie, liest sie stündlich und übersetzt sie in eine verständliche Diagnose. Wir arbeiten mit Aggregatreports (RUA): forensische Reports (RUF), die nur wenige Empfänger senden, werden nicht verarbeitet. Die Abdeckung hängt davon ab, wer Reports sendet: die großen Provider ja, viele kleine Server nein, daher beschreiben die Zahlen nie hundert Prozent der Post.
Mit p=none wird die Domain nur beobachtet: Gefälschte Nachrichten werden trotzdem zugestellt, und der Eintrag dient lediglich dem Empfang der Reports. Erst p=reject, mit p=quarantine als Zwischenschritt, weist die Empfänger an, Post ohne bestandene Authentifizierung zu verwerfen. Es ist die einzige Konfiguration, die Dritte wirklich daran hindert, im Namen Ihrer Domain zu senden. Google, Yahoo und Microsoft verlangen bereits einen DMARC-Eintrag von allen, die große Volumen an ihre Postfächer senden. Eine Enforcement-Richtlinie ist zudem eine technische Maßnahme, die sich in einem NIS2- oder ISO/IEC-27001-Audit dokumentieren lässt.
Die Weiterleitung ist der heikelste Fall. Wenn ein Empfänger Post automatisch an eine andere Adresse weiterleitet oder eine Mailingliste die Nachricht umschreibt, scheitert SPF, weil der weiterleitende Server nicht zu den autorisierten gehört. Bricht auch die DKIM-Signatur, wird die Nachricht bei p=reject verworfen. Deshalb erkennt der Service Quellen, die sich wie Weiterleitungen verhalten, und stuft sie entsprechend ein. Der Wechsel zu p=reject erfolgt erst, wenn die legitimen Quellen korrekt mit DKIM signieren, das eine Weiterleitung überlebt. Der Weg ist bewusst schrittweise, damit keine legitime Post verloren geht.
Das hängt davon ab, wie viele Systeme im Namen der Domain senden. Ein Unternehmen, dessen Post ausschließlich über Microsoft 365 läuft, erreicht das Enforcement schnell; eine Organisation mit CRM, Newsletter-Plattformen, ERP-Systemen und Multifunktionsdruckern, die E-Mails versenden, braucht mehr Zeit, weil jede Quelle identifiziert, in SPF autorisiert oder zum Signieren mit DKIM gebracht werden muss. Der Bereitschaftswert auf einer Skala von 0 bis 100 zeigt jederzeit, wie weit die Domain ist und was der nächste Schritt ist: Die Quarantäne beginnt bei 80 Punkten mit 10 % der Post und erreicht 100 % ab 90, die Ablehnung beginnt bei 95 mit 25 % und wird ab 97 vollständig. In der Regel bleibt die Domain einige Wochen unter Beobachtung bei p=none, wechselt zu p=quarantine mit steigendem Prozentsatz und schließlich zu p=reject. Wir erzwingen kein Tempo: Die Domain geht weiter, wenn die Reports zeigen, dass sie bereit ist.
Nein. Der Service ist gemanagt: AtWorkStudio konfiguriert die Einträge, autorisiert die Absender, bringt die Domain ins Enforcement und überwacht sie weiter. Der Kunde erhält das Domain-Datenblatt als PDF, erstellt von seinem Ansprechpartner bei AtWorkStudio bei Bedarf, in der Regel zum Monatsende oder nach einem Eingriff: Es enthält die Zahlen der letzten 30 Tage im Vergleich zu den 30 davor, die DNS-Konfiguration, den Stand des Weges, die durchgeführten Maßnahmen und die Systeme, die für die Domain senden. Alarme und die wöchentliche Zusammenfassung sind interne Werkzeuge der Operatoren. Datenblätter und Diagnosen werden derzeit auf Italienisch erstellt. Die Betriebsplattform DMARC Reaper ist den Operatoren von AtWorkStudio vorbehalten. Reports und Verlauf werden 13 Monate auf Azure in der Region Italien Nord aufbewahrt.
Sagen Sie uns, wie viele Domains Sie haben und welche Systeme E-Mails senden. Wir sagen Ihnen, wo Sie stehen und was bis p=reject fehlt. Das DMARC-Monitoring ergänzt die E-Mail-Sicherheit und ist mit der DNS-Verwaltung Ihrer Unternehmensdomain verzahnt.