DMARC verstehen — Reporting, Policy-Stufen, häufige Fehler

Die Regel, die entscheidet, was mit gefälschten Mails in eurem Namen passiert

Es gibt einen Punkt, an dem viele Betriebe die E-Mail-Absicherung für erledigt halten, obwohl das Wesentliche noch fehlt. Zwei Verfahren sind eingerichtet, alles sieht sauber aus – und trotzdem kann jemand eine Mail mit eurem Firmennamen im Absenderfeld verschicken, die technisch einwandfrei durch alle Prüfungen läuft.

Der Grund ist ein Konstruktionsdetail der E-Mail: Es gibt zwei Absenderadressen. Eine prüfen die Maschinen, die andere lest ihr am Bildschirm. Nichts zwingt sie dazu, dieselbe zu sein. Ein Absender kann seine eigene Domain sauber ausweisen und in dem Feld, das euer Kunde sieht, trotzdem eure Firma eintragen.

Genau hier setzt die dritte Regel an. Sie verlangt zweierlei: dass die geprüfte Adresse zu der passt, die im Postfach erscheint – und sie legt fest, was passieren soll, wenn das nicht der Fall ist. Ignorieren, in den Spam-Ordner, oder gar nicht erst annehmen. Diese Entscheidung trefft ihr, und sie ist der Punkt, an dem es ernst wird.

Warum niemand diese Regel scharf stellen sollte, bevor er weiss, wer alles Post verschickt

DMARC

DMARC steht für «Domain-based Message Authentication, Reporting and Conformance» – eine Regel, die ihr für eure Domain veröffentlicht und die zwei Dinge festlegt: dass die technisch geprüfte Absenderadresse zu der passen muss, die der Empfänger im Postfach sieht – und wie ein Empfänger reagieren soll, wenn eine Mail das nicht erfüllt. Ohne DMARC entscheidet jeder Empfänger selbst; mit DMARC gebt ihr die Antwort vor.

Policy-Stufe

Der Teil der Regel, der die Reaktion bestimmt. «Beobachten» heisst, dass nichts blockiert wird und ihr nur Berichte erhaltet. «Quarantäne» schickt auffällige Mails in den Spam-Ordner. «Abweisen» sorgt dafür, dass sie gar nicht erst angenommen werden. Der Weg führt in dieser Reihenfolge – wer direkt bei «Abweisen» beginnt, blockiert zuverlässig auch die eigenen vergessenen Versandwege.

Report

Ein täglicher Bericht, den grosse Mail-Anbieter an eine von euch angegebene Adresse schicken. Er listet auf, welche Server im Namen eurer Domain Mails verschickt haben und ob die Prüfungen bestanden wurden. Diese Berichte sind der eigentliche Wert der Beobachtungsphase: Sie zeigen die Versandwege, die niemand im Betrieb mehr auf dem Radar hatte.

Warum ich die Beobachtungsphase für den wertvollsten Teil halte

Der Reflex, den ich am häufigsten bremsen muss, ist der Wunsch, gleich die strengste Einstellung zu wählen. Die Logik dahinter ist verständlich: Wenn ich mich schon schütze, dann richtig. Nur schützt die strengste Einstellung nicht vor mehr Fälschungen als die mittlere – sie erhöht nur, was ein Fehler im eigenen Setup kostet.

Was in dieser Phase wirklich passiert, hat mit Sicherheit im engeren Sinn zunächst wenig zu tun: Ihr bekommt zum ersten Mal eine vollständige Liste aller Systeme, die im Namen eurer Firma Mails verschicken. In den Berichten steht die Buchhaltungssoftware, die niemand erwähnt hat. Das Ticketsystem. Das Kontaktformular der Website. Der Newsletter-Dienst, den vor zwei Jahren jemand eingerichtet und nie abgeschaltet hat. Diese Inventur ist der Ertrag – die verschärfte Policy ist danach nur noch eine Zeile.

Wirtschaftlich ist die Rechnung eindeutig, aber sie zeigt nicht in die Richtung, in die man zuerst schaut. Der Schaden aus einer gefälschten Mail in eurem Namen ist unangenehm und schwer zu beziffern. Der Schaden aus abgewiesenen eigenen Rechnungen ist sofort da, trifft euren Zahlungseingang und fällt oft erst auf, wenn ein Kunde nachfragt. Beides adressiert dieselbe Konfiguration – aber nur, wenn sie in der richtigen Reihenfolge entsteht.

Einen Einwand höre ich regelmässig: Am Ende entscheidet immer der Empfänger. Ihr könnt die strengste Stufe wählen – ob sich ein Empfängerserver daran hält, bestimmt er selbst. Das ist richtig, misst DMARC aber an einer Garantie, die kein Verfahren dieser Art einlöst. Meine Frage lautet anders: Was trägt dazu bei, dass meine Rechnung ankommt? Darauf haben die grossen Anbieter selbst geantwortet – Google und Yahoo verlangen seit Februar 2024 von Versendern ab rund 5000 Mails pro Tag eine DMARC-Regel, Microsoft seit Mai 2025 dasselbe für Mails an Outlook.com. Diese Schwelle erreicht ein KMU nicht. Aber was dort Pflicht ist, zählt bei allen anderen als Signal – und zwar in die Richtung, in die ihr es braucht.

Die ehrliche Grenze: DMARC schützt eure Domain davor, missbraucht zu werden. Es schützt euch nicht vor dem, was in eurem eigenen Posteingang landet. Wer euch eine gefälschte Rechnung von einer ähnlich aussehenden Domain schickt, wird von eurer eigenen Regel nicht aufgehalten – dafür braucht es die Aufmerksamkeit eurer Mitarbeitenden und keinen Eintrag im DNS, dem «Domain Name System»: dem Adressverzeichnis des Internets, in dem steht, welcher Server zu welchem Namen gehört.

DMARC schliesst die Lücke, die SPF und DKIM einzeln offenlassen: Es verlangt, dass mindestens eines der beiden Verfahren nicht nur bestanden wird, sondern auch zur Domain passt, die der Empfänger im «From»-Feld tatsächlich sieht. Zusätzlich legt ein DMARC-Eintrag fest, was mit Mails passiert, die diese Prüfung nicht bestehen, und schickt euch dafür regelmässig Berichte zu.

Was Alignment bedeutet, und warum es fehlt

SPF prüft den versendenden Server, DKIM die Signatur – beide beziehen sich dabei auf eine technische Absenderdomain, die im Header steckt, aber für den Empfänger unsichtbar bleibt. Die Adresse, die tatsächlich im Postfach als Absender erscheint (das sichtbare «From»-Feld), kann davon abweichen, ohne dass SPF oder DKIM das bemerken. Genau diese Lücke nutzen gefälschte Mails: Technisch sauber authentifiziert, aber mit einer völlig anderen sichtbaren Absenderadresse.

DMARC verlangt «Alignment»: Mindestens eine der beiden Prüfungen muss sich auf dieselbe Domain beziehen, die der Empfänger sieht. Erst dann gilt eine Mail als DMARC-konform.

Relaxed oder strict: wie streng Alignment ausgelegt wird

Ob zwei Domains als «dieselbe» gelten, steuern die Tags aspf= (für SPF) und adkim= (für DKIM). Beide kennen zwei Modi, und die Voreinstellung ist in beiden Fällen r:

Modus	Bedeutung	`rechnung@euredomain.ch` im «From», geprüfte Domain ist …
`r` (relaxed, Standard)	Die Organisationsdomain muss übereinstimmen, Subdomains sind erlaubt	`mail.euredomain.ch` → aligned
`s` (strict)	Die Domain muss exakt identisch sein	`mail.euredomain.ch` → nicht aligned
beide	Eine fremde Domain genügt nie	`versand.mailtool.example` → nicht aligned

Praktisch heisst das: Signiert ein Dienstleister mit seiner eigenen Domain, besteht DKIM zwar, das Alignment aber nicht. Der Dienst muss unter eurer Domain signieren – sonst ist die Signatur für DMARC wertlos. strict setzt man nur, wenn man weiss, dass keine Subdomain im Versand beteiligt ist; als Ausgangspunkt genügt der Standard.

Die drei Policy-Stufen

Ein DMARC-Eintrag sieht etwa so aus: v=DMARC1; p=none; rua=mailto:reports@euredomain.ch. Das Kernstück ist p=, die Policy:

Stufe	Wirkung	Wann sinnvoll
`p=none`	Nur beobachten, nichts wird blockiert	Immer als Startpunkt
`p=quarantine`	Nicht konforme Mails wandern in den Spam-Ordner	Wenn die Reports sauber aussehen
`p=reject`	Nicht konforme Mails werden hart abgewiesen	Erst nach mehrwöchiger Beobachtung

Der Sprung direkt zu p=reject ist der häufigste Anfängerfehler. Er blockiert zuverlässig gefälschte Mails – aber genauso zuverlässig auch jeden legitimen Versandweg, der im eigenen SPF/DKIM-Setup vergessen wurde.

Was die Reports zeigen

rua= legt eine Adresse fest, an die teilnehmende Mailserver (Google, Microsoft, und weitere) täglich einen aggregierten Bericht schicken: wie viele Mails von welcher IP-Adresse im Namen eurer Domain unterwegs waren, und ob SPF, DKIM und Alignment bestanden wurden. Diese Berichte kommen als XML-Dateien und sind roh kaum lesbar – dafür gibt es kostenlose wie kommerzielle Auswertungswerkzeuge, die daraus eine Übersicht machen.

Genau diese Reports sind der Grund, warum p=none kein Leerlauf ist, sondern die eigentliche Arbeitsphase: Sie zeigen zuverlässige Versandwege ebenso wie vergessene – etwa ein Formular-Plugin der Website oder ein CRM, das im eigenen Namen sendet, aber nie im SPF-Record aufgetaucht ist.

Häufige Fehler beim Einführen

Ein Treuhandbüro plant, DMARC einzuführen, und setzt direkt p=reject, weil das «am sichersten» klingt. Zwei Tage später bleiben Rechnungsmails der externen Buchhaltungssoftware beim Kunden aus – der Dienst versendet im Namen der Kanzlei, war aber nie im SPF-Record erfasst und hatte keinen eigenen DKIM-Selector. Die Mails bestehen weder SPF- noch DKIM-Alignment und werden zuverlässig abgewiesen, ohne dass jemand eine Fehlermeldung sieht.

Weitere wiederkehrende Fehler:

Subdomains vergessen. Ohne sp=-Tag gilt die Hauptpolicy auch für Subdomains – das ist gewollt, wird aber selten bedacht. Für Subdomains, die es im DNS gar nicht gibt, setzt der Tag np= eine eigene Regel. Das ist nützlich, weil Fälscher gern erfundene Subdomains wie rechnung.euredomain.ch verwenden; da solche Namen nie legitim versenden, darf np= strenger sein als p=.
rua= nie eingerichtet. Ohne Reports fliegt man beim Verschärfen der Policy blind.
Zu schneller Sprung von none zu reject. Der Zwischenschritt quarantine, zuerst mit dem Testmodus t=y, macht Fehler sichtbar statt destruktiv.

p=reject ist das Ziel einer DMARC-Einführung, nicht der Startpunkt.

Wie ihr DMARC schrittweise einführt, ohne den Versand abzuwürgen

Die Einführung ist kein Konfigurationsschritt, sondern ein Prozess in vier Etappen. Jede endet mit einem Kriterium, das erfüllt sein muss, bevor die nächste beginnt:

Bestandsaufnahme im DNS. dig TXT _dmarc.euredomain.ch +short zeigt, ob bereits ein Eintrag existiert. Parallel dazu SPF-Record und DKIM-Selectoren aller Versanddienste prüfen – DMARC bewertet nur, was diese beiden liefern, es fügt selbst keine Authentifizierung hinzu.
Beobachten mit p=none. Ein TXT-Eintrag auf _dmarc.euredomain.ch mit v=DMARC1; p=none; rua=mailto:dmarc@euredomain.ch. Nichts wird blockiert; ab dem nächsten Tag laufen die aggregierten Reports ein. Diese Phase dauert so lange, bis mindestens ein vollständiger Geschäftszyklus mit allen wiederkehrenden Versandarten abgedeckt ist – Monatsrechnungen, Newsletter, Kampagnen, Lohnabrechnungen.
Die Reports aufräumen. Jede sendende IP-Adresse aus den Berichten muss einer der drei Kategorien zugeordnet werden: bekannt und korrekt authentifiziert, bekannt aber noch nicht in SPF/DKIM erfasst (nachtragen), oder unbekannt und nicht erklärbar. Kriterium für den nächsten Schritt: In den Reports tauchen keine legitimen Quellen mehr auf, die scheitern.
Verschärfen in Stufen. Zuerst p=quarantine; t=y: Der Testmodus bittet die Empfänger, eine Stufe milder zu verfahren – nicht konforme Mails werden noch zugestellt, die Reports zeigen aber, was die strengere Regel treffen würde. Den früher üblichen Prozentsatz pct= gibt es seit dem aktuellen Standard (RFC 9989, Mai 2026) nicht mehr. Bleiben die Reports sauber, fällt t=y weg, und quarantine greift. Bleiben die Reports über mehrere Wochen sauber, folgt p=reject. Der sp=-Tag steuert dabei separat, was für Subdomains gilt. Nach jeder Umstellung zeigen die Reports der ersten ein, zwei Tage oft noch die alte Stufe, weil die Berichtszeiträume der Empfänger über den Zeitpunkt der Änderung hinausreichen – die Wirkung erst danach beurteilen.

Zwei Fallstricke, an denen es in der Praxis scheitert:

rua= zeigt auf eine fremde Domain, ohne dass diese zustimmt. Lasst ihr die Berichte an einen Dienstleister schicken (rua=mailto:xyz@auswerter.example), verlangt die DMARC-Spezifikation (RFC 9990, Abschnitt 4) eine ausdrückliche Erlaubnis der Zieldomain: einen TXT-Eintrag auf euredomain.ch._report._dmarc.auswerter.example mit dem Wert v=DMARC1. Fehlt er, verwerfen viele Reporting-Server den Bericht stillschweigend – ihr wartet auf Daten, die nie kommen, und haltet die Stille für ein gutes Zeichen. Der Dienstleister richtet diesen Eintrag üblicherweise selbst ein, oft als Platzhalter für alle Domains (*._report._dmarc.auswerter.example); prüfen solltet ihr ihn trotzdem.
p=reject ohne Monitoring wirkt rückwirkend nicht sichtbar. Eine abgewiesene Mail erzeugt beim Absender oft eine Fehlermeldung, beim betroffenen Fachdienst aber niemanden, der sie liest – automatisierte Versender aus Buchhaltung oder Ticketsystem verschlucken den Bounce. Der Ausfall fällt erst auf, wenn ein Kunde nachfragt, wo seine Rechnung bleibt. Das ist der Grund, warum die Beobachtungsphase nicht abgekürzt werden darf: Ohne Reports habt ihr keinen anderen Kanal, der euch den Schaden meldet.

Häufige Fragen

Haben wir überhaupt schon eine DMARC-Regel?

Das lässt sich in einer Minute herausfinden: Gebt eure Domain in einem frei zugänglichen DMARC-Prüfwerkzeug im Web ein oder fragt eure IT, was unter _dmarc.euredomain.ch steht. DMARC – kurz für Domain-based Message Authentication, Reporting and Conformance – ist die Regel, die festlegt, was mit gefälschten Mails in eurem Namen passiert. Kommt nichts zurück, habt ihr keine Regel, und jeder Empfänger entscheidet selbst. Steht dort p=none, seid ihr in der Beobachtungsphase – die Frage ist dann, ob jemand die Berichte auch liest.

Was frage ich meine IT, bevor wir die Regel verschärfen?

Die Kernfrage lautet: «Haben wir aus den DMARC-Berichten eine vollständige Liste aller Systeme, die in unserem Namen Mails verschicken, und bestehen alle davon die Prüfung?» Lasst euch diese Liste zeigen und gleicht sie mit eurem Alltag ab: Buchhaltung, Newsletter, Ticketsystem, Kontaktformular der Website. Fragt zusätzlich, an welche Adresse die Berichte gehen und wer sie auswertet. Ohne Antwort auf beides ist es für eine Verschärfung zu früh.

Wie lange dauert die Beobachtungsphase, und lohnt sich der Aufwand?

Rechnet mit mehreren Wochen, mindestens einem vollständigen Geschäftszyklus mit allen wiederkehrenden Versandarten – Monatsrechnungen, Newsletter, Lohnabrechnungen. Der Aufwand liegt weniger in der Technik als in der Zuordnung: Wer kennt welchen Versandweg? Der Ertrag ist eine Inventur, die ihr sonst nie bekommt, und die Gewissheit, dass eine spätere Verschärfung keine eigenen Rechnungen abweist.

Unser Newsletter-Dienst sagt, DKIM sei eingerichtet. Reicht das für DMARC?

Nur, wenn er unter eurer eigenen Domain signiert. Signiert er mit seiner Domain, ist die Signatur gültig, passt aber nicht zu der Absenderadresse, die eure Empfänger sehen – für DMARC zählt sie dann nicht. Fragt den Anbieter: «Signiert ihr mit d=unseredomain.ch, und welchen DNS-Eintrag müssen wir dafür setzen?» Die Antwort bestimmt, ob eure Newsletter eine Verschärfung überstehen.

Schützt DMARC uns auch vor Phishing-Mails im eigenen Posteingang?

Nein. DMARC schützt eure Domain davor, dass andere in eurem Namen Mails verschicken – es schützt eure Kunden und Partner vor Fälschungen mit eurem Absender. Gefälschte Mails an euch, etwa von einer ähnlich aussehenden Domain, hält eure eigene Regel nicht auf. Dafür sind der Spamfilter eures Mail-Anbieters und die Aufmerksamkeit eurer Mitarbeitenden zuständig.

Quellen

DMARC-Standard: Herr, T.; Levine, J. (Hrsg.) (2026). «RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)». — Der aktuelle IETF-Standard zu DMARC vom Mai 2026; er ersetzt RFC 7489 und RFC 9091.
DMARC-Berichte: Brotman, A. (Hrsg.) (2026). «RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting». — Format der täglichen Berichte; Abschnitt 4 «Verifying External Destinations» regelt die Erlaubnis für fremde Empfangsadressen, inklusive Platzhalter-Eintrag.
Anforderungen von Gmail: Google. «Richtlinien für E-Mail-Absender». — Pflichten für Versender an Gmail seit dem 1. Februar 2024, inklusive DMARC ab mehr als 5’000 Mails pro Tag.
Anforderungen von Outlook.com: Microsoft Defender for Office 365 Blog (2025). «Strengthening Email Ecosystem: Outlook’s New Requirements for High‐Volume Senders». — Microsofts Ankündigung der Vorgaben für Versender mit mehr als 5’000 Mails pro Tag an Outlook.com, Hotmail und Live.