DMARC in Sicherheitsfragebögen für Lieferanten

Von Thomas · virtueller CISO · 31. August 2026

Die Datei kommt meist vom Einkauf oder von der Rechtsabteilung: eine Tabelle mit mehreren hundert Zeilen, Rücklauf binnen zwei Wochen, an der die Vertragsunterschrift hängt. Irgendwo zwischen der Frage zur Verschlüsselung ruhender Daten und der zum Notfallplan hat sich in den letzten Jahren eine Zeile etabliert: „Ist für alle versendenden Domains eine DMARC-Policy in Enforcement veröffentlicht?" Lange den Ausschreibungen der Großkonzerne vorbehalten, steht die Frage inzwischen in den Standardfragebögen des Mittelstands, der Plattformen für Drittparteibewertung und der Versicherungsmakler.

Das ist keine Modeerscheinung. Die E-Mail eines Lieferanten ist ein Angriffsvektor auf die Lieferkette: Eine fälschbare Lieferantendomain erlaubt es, dem Kunden eine falsche Rechnung, geänderte Bankverbindungen oder einen präparierten Link zu schicken, die scheinbar von einem vertrauten Partner stammen. Und die DMARC-Zeile hat eine Eigenschaft, die in einem Sicherheitsfragebogen selten ist: Die Antwort lässt sich öffentlich überprüfen, in Sekunden, im DNS. Leichtfertig zu antworten ist der sicherste Weg, ertappt zu werden.

Dieser Artikel zeigt, warum die Frage unvermeidlich wurde, in welchen Formulierungen sie auftritt, was ein Prüfer tatsächlich kontrolliert, wie sich in jeder Phase eines Rollouts ehrlich antworten lässt — und wie sich auf der Einkäuferseite aus dieser einen Zeile mehr herausholen lässt als aus jeder anderen.

Warum die Frage unvermeidlich wurde

Drei Regelwerke haben die Bewertung von Drittparteien von der guten Praxis zur Pflicht gemacht. NIS2 verlangt von wesentlichen und wichtigen Einrichtungen, die Sicherheit ihrer Lieferkette zu beherrschen, direkte Zulieferer eingeschlossen — die Folgen für die Messaging-Landschaft entfaltet die Analyse von NIS2 mit Blick auf E-Mail. DORA tut dasselbe für den Finanzsektor, mit einem ganzen Kapitel zum IKT-Drittparteirisiko. Und ISO/IEC 27001:2022 widmet mehrere Controls des Anhangs A (5.19 bis 5.21) den Lieferantenbeziehungen und der IKT-Lieferkette — wie E-Mail-Authentifizierung diese Nachweismaschine füttert, steht in DMARC als Nachweis im ISO-27001-Audit. In allen drei Fällen ist die operative Konsequenz identisch: Kunden müssen ihre Lieferanten bewerten, und der Fragebogen ist das Massenwerkzeug dafür.

E-Mail gewinnt in diesen Fragebögen an Raum, weil die Lieferkette zuerst über das Postfach angegriffen wird. Der Lieferantenbetrug — eine Rechnung mit geänderter Bankverbindung, versandt von einer Domain, die die des gewohnten Dienstleisters imitiert oder schlicht fälscht — bleibt eines der profitabelsten Szenarien für einen Angreifer, weil das Vertrauen bereits besteht. Ein Lieferant, dessen Domain sich beliebig fälschen lässt, setzt jeden einzelnen Kunden direkt einem Risiko aus: Die eigene Marke wird zum Angriffskanal gegen sie. Die DMARC-Zeile im Fragebogen prüft also keine technische Spielerei; sie schätzt die Wahrscheinlichkeit, dass die nächste betrügerische Überweisungsbitte den Namen des Lieferanten trägt.

Die typischen Formulierungen

Von Fragebogen zu Fragebogen ändert sich die Substanz kaum, die Form dagegen sehr. Die häufigsten Punkte:

„Ist für alle versendenden Domains eine DMARC-Policy in Enforcement (p=quarantine oder p=reject) veröffentlicht?"
„Ist SPF für sämtliche autorisierten Versandquellen veröffentlicht und gepflegt?"
„Wird ausgehende Post DKIM-signiert, mit Schlüsseln von mindestens 2048 Bit und regelmäßiger Rotation?"
„Sind MTA-STS und TLS-RPT im Einsatz, um den eingehenden Transport zu schützen?"
„Werden aggregierte DMARC-Berichte gesammelt und überwacht? Von welchem Team oder Werkzeug?"
„Sind nicht versendende Domains (Markendomains, geparkte Domains) gegen Fälschung verriegelt?"

Manche Tabellen pressen alles in ein einziges Kästchen „E-Mail-Authentifizierung: ja/nein", andere steigen bis zu einzelnen DKIM-Selektoren hinab. Die Fragebögen der Versicherer stellen fast wortgleich dieselben Fragen, mit direkter Wirkung auf die Prämie — die Mechanik der Cyberversicherungs-Fragebögen macht das anschaulich. Gleich welche Formulierung: Hinter jeder Variante steckt dieselbe Frage — „lässt sich mit dieser Domain unser Personal angreifen?"

Was ein Prüfer tatsächlich kontrolliert

Die meisten Kästchen eines Fragebogens sind von außen nicht überprüfbar. Passwortrichtlinie, Verschlüsselung ruhender Daten, Sensibilisierung: Der Prüfer nimmt die Erklärung zu Protokoll und hat kein Mittel, sie zu testen. Die DMARC-Zeile ist anderer Natur, denn die Policy steht im öffentlichen DNS. Eine Abfrage genügt:

dig TXT _dmarc.beispiel.de +short
"v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de"

Ein versierter Prüfer liest mehr als das p=-Tag. Das Vorhandensein von rua= zählt — gesammelte Berichte deuten auf lebendige Überwachung statt auf einen einmal gesetzten und vergessenen Eintrag. Die Abdeckung der Subdomains wird geprüft, ebenso ein stilles sp=none, das den Schutz aushöhlt. Auch der Testmodus von DMARCbis (t=y), der die Durchsetzung der Policy aussetzt, fällt auf — das moderne Gegenstück zum alten pct=0, das der aktuelle Standard gestrichen hat. SPF und das Vorhandensein von DKIM-Selektoren auf denselben Domains werden bestätigt, manchmal auch die Existenz einer MTA-STS-Policy. Und all das lässt sich automatisieren: Rating-Plattformen für Drittparteien bewerten diese Signale kontinuierlich, ganz ohne Fragebogen.

Anders gesagt: Das DMARC-Kästchen ist vermutlich das einzige der ganzen Tabelle, dessen Antwort der Einkäufer schon kennt, bevor die Erklärung gelesen ist. Genau das macht es so gefährlich für alle, die schnell antworten — und so wertvoll für alle, die ehrlich antworten.

Ehrlich antworten, je nach realem Stand

Drei Situationen, drei tragfähige Antworten.

Die Policy steht auf p=reject oder p=quarantine. Die Antwort ist einfach: ja, mit dem DNS-Eintrag als Anlage, der Liste der abgedeckten Domains und einem Satz zur Berichtsüberwachung. Eine Gelegenheit, günstig Punkte zu sammeln: Nur wenige Antwortende dokumentieren so sauber.

Der Rollout läuft, die Policy steht noch auf p=none. Die Versuchung des ungefähren „Ja" ist groß — „DMARC ist vorhanden", technisch wahr, da ein Eintrag existiert. Es ist die schlechteste Option: Der Widerspruch zum öffentlichen DNS springt dem ersten ausgestatteten Prüfer ins Auge, und alle übrigen Antworten der Tabelle werden auf einen Schlag verdächtig. Die tragfähige Antwort ist ein dokumentierter Stand mit datiertem Fahrplan: „Policy p=none mit Berichtssammlung und -analyse seit März; Wechsel zu p=quarantine für Q4 geplant; p=reject für Q1 angepeilt." In den Augen eines ernsthaften Prüfers schlägt diese Präzision ein dürres „konform": Sie beweist, dass das Thema gesteuert, budgetiert und terminiert ist. Ein offen ausgewiesenes p=none mit glaubwürdigem Plan passiert den Filter; ein „Ja", das dem DNS widerspricht, passiert ihn nie zweimal.

Nichts ist vorhanden. Es zuzugeben und eine datierte Verpflichtung statt eines vagen Versprechens beizulegen, bleibt der richtige Zug. Fragebögen sind selten Zeile für Zeile ein K.-o.-Kriterium; die Gesamtkohärenz wiegt schwerer als ein einzelnes Kästchen. Die DMARC-Checkliste 2026 liefert das Gerüst eines glaubwürdigen Plans als Anlage zur Antwort — Quelleninventar, Berichtssammlung, schrittweise Verschärfung.

Die Einkäuferseite: was fragen, und die Prüfung in dreißig Sekunden

Für die Organisation, die ihre Lieferanten bewertet, ist die DMARC-Zeile ein Geschenk: die einzige, deren Überprüfung weniger kostet als das Lesen der Antwort. Die Frage muss trotzdem gut gestellt sein. „Ist DMARC vorhanden" lädt zu einem hohlen Ja ein; die nützlichen Formulierungen verlangen die effektive Policy (p=) auf der Hauptdomain und den Markendomains, das Team oder Werkzeug, das die Berichte beobachtet, und den Umgang mit nicht versendenden Domains.

Die Überprüfung dauert dann dreißig Sekunden: eine TXT-Abfrage auf _dmarc. gefolgt von der Domain des Lieferanten, von jedem Arbeitsplatz aus, oder ein Online-Analyzer, der DMARC-Policy, SPF und DKIM in einem Durchgang liefert. Das Leseraster ist direkt. Ein p=reject, das zur Erklärung passt, verleiht dem gesamten Fragebogen Glaubwürdigkeit. Ein als „konform" deklariertes p=none ist ein Warnsignal, das weit über die E-Mail hinausreicht: Es misst die Aufrichtigkeit des Antwortenden. Die Lücke zwischen erklärter Antwort und beobachtetem DNS-Zustand ist die wertvollste Information der ganzen Tabelle — und sie ist gratis.

Ein Reifesignal über die E-Mail hinaus

Warum so viel Gewicht auf eine Zeile unter dreihundert legen? Weil sich eine DMARC-Policy in Enforcement nicht improvisieren lässt. Sie setzt ein vollständiges Inventar der Versandflüsse voraus — einschließlich derer, die das Marketing ohne Ankündigung angeschlossen hat —, eine funktionierende DNS-Governance, die Abstimmung zwischen internen Teams und Dienstleistern, dann eine laufende Überwachung, damit die Policy Veränderungen übersteht. Eine Organisation, die dieses Projekt zu Ende geführt hat, beweist eine bereichsübergreifende Umsetzungsfähigkeit, die weit über das Mailsystem hinausgeht.

Es ist eine Korrelation, kein Beweis: Eine Domain auf p=reject kann neben einer ansonsten vernachlässigten Infrastruktur existieren, und auch das Umgekehrte kommt vor. Aber in einer Massenbewertung, in der fast alles deklarativ bleibt, ist ein öffentliches, überprüfbares, schwer zu fälschendes Signal Gold wert. Die Prüfer wissen das — genau deshalb steht die Zeile dort.

Die Standardantwort vorbereiten

Statt die Frage mit jeder Tabelle neu zu entdecken, halten eingespielte Teams eine Standardantwort bereit, die zu festen Terminen überprüft wird. Ein Referenzabsatz sieht so aus:

Sämtliche versendenden Domains des Unternehmens veröffentlichen eine DMARC-Policy p=reject, mit Quelle für Quelle verifiziertem SPF- und DKIM-Alignment. Nicht versendende Domains sind verriegelt (v=DMARC1; p=reject; plus SPF-Eintrag ohne Versandmechanismus). Aggregierte Berichte werden über eine dedizierte Plattform kontinuierlich gesammelt und ausgewertet; jede unbekannte Versandquelle löst einen Alarm aus. Letzte Überprüfung: [Datum].

Die Nachweise, die als Anlagen bereitliegen sollten: ein datierter Export der DNS-Einträge, ein Bildschirmfoto des Überwachungs-Dashboards, die Liste der abgedeckten Domains und — bei laufendem Rollout — der Meilensteinkalender. Eine Warnung: Diese Antwort verfällt. Eine bei einer Fusion übernommene Domain, ein von einer Tochter angeschlossenes neues E-Mail-Werkzeug, und der Absatz lügt. Die vierteljährliche Überprüfung des Absatzes und seiner Nachweise ist fester Bestandteil der Antwort.

Fazit

Die DMARC-Frage hat sich in den Lieferantenfragebögen festgesetzt, weil die Bewertung von Drittparteien zur Pflicht wurde — NIS2, DORA, ISO 27001 — und weil die E-Mail eines Lieferanten ein direkter Angriffsvektor gegen dessen Kunden ist. Ihre Besonderheit: Die Antwort ist im öffentlichen DNS überprüfbar, in dreißig Sekunden, für jedermann. Die einzige tragfähige Strategie ist dokumentierte Ehrlichkeit — ein p=none mit datiertem Fahrplan schlägt ein „Ja", dem das DNS widerspricht — und auf der Einkäuferseite der systematische Abgleich zwischen Erklärung und beobachteter Realität, der mehr aussagt als alle übrigen Kästchen zusammen.

Bevor die nächste Tabelle eintrifft, zeigt ein Durchlauf der Domain durch die kostenlose DMARC-Analyse genau das, was der Prüfer sehen wird: effektive Policy, SPF, DKIM, Subdomain-Abdeckung. Und falls der festgestellte Zustand der erhofften Antwort noch nicht entspricht, eröffnet ein Konto den datierten, meilensteingetriebenen Weg zu p=reject — genug, um bis zum nächsten Fragebogen aus einem peinlichen Kästchen einen Reifenachweis zu machen.