Drittversender einer Domain inventarisieren: die Karte vor DMARC

Von Thomas · virtueller CISO · 21. August 2026

Jedes DMARC-Projekt beginnt mit einer Illusion: zu wissen, wer im Namen der Domain E-Mails versendet. Die spontane Antwort — „der Mailserver", Microsoft 365 oder Google Workspace — erweist sich in fast jeder Organisation als unvollständig. Ein gewöhnliches Unternehmen versendet in Wirklichkeit über zehn, fünfzehn, manchmal dreißig verschiedene Dienste: eine Marketing-Plattform, ein Rechnungswerkzeug, ein CRM, eine HR-Suite, ein Monitoring-System, einen Anbieter für elektronische Signaturen. Jeder dieser Dritten schreibt mit der Adresse der Organisation, oft seit Jahren — und oft, ohne dass die IT je davon erfahren hätte.

DMARC verzeiht kein Vergessen. Bei p=none stört ein Dritter, der auf der Karte fehlt, niemanden; bei p=reject wird er zum gebrochenen Fluss — Rechnungen, die nicht mehr hinausgehen, blockierte Gehaltsabrechnungen, still verworfene Monitoring-Alarme. Das ist die häufigste Ursache gescheiterter Durchsetzungsprojekte, weit vor der technischen Schwierigkeit: Die Policy wurde verschärft, bevor die Karte vollständig war. Das Inventar der Drittversender bildet deshalb das Fundament der DMARC-Checkliste 2026 — die Karte entsteht vor der Reise, nie währenddessen.

Dieser Artikel entfaltet die vollständige Methode: warum der vergessene Dritte das Projekt zum Scheitern bringt, welche Familien von Diensten zu suchen sind, welche Wahrheitsquellen sich kreuzen lassen, wie sich die Karte strukturiert und wie sie lebendig bleibt, sobald p=reject erreicht ist.

Der vergessene Dritte: Fehlerursache Nummer eins

Der Mechanismus verdient eine klare Darstellung. DMARC beurteilt nicht die Legitimität einer Nachricht; es beurteilt die Ausrichtung. Eine E-Mail besteht, wenn SPF oder DKIM eine Domain validiert, die mit der sichtbaren Absenderadresse ausgerichtet ist. Ein völlig legitimer Dienstleister, unter Vertrag, jeden Monat bezahlt, dessen Authentifizierung aber niemand konfiguriert hat, scheitert exakt wie ein Betrüger: gleiches Urteil, gleiches Schicksal. Der Standard kann das Rechnungswerkzeug, das die Buchhaltung seit fünf Jahren nutzt, nicht von einem Fälschungsversuch unterscheiden.

Die Asymmetrie der Entdeckung verschlimmert alles. Solange die Policy bei p=none bleibt, funktioniert das nicht ausgerichtete Werkzeug: Nichts alarmiert irgendwen. Am Tag des Wechsels zu p=reject bricht es — und es bricht lautlos. Die IT sieht nichts: Kein Server in diesem Fluss gehört ihr, kein Log landet bei ihr. Die Fachabteilungen entdecken den Vorfall Tage oder Wochen später: Kundenerinnerungen ohne jede Wirkung, Bewerber ohne Antwort, nie angekommene Monitoring-Alarme. Der Klassiker des Genres ist das Rechnungswerkzeug, das die Finanzabteilung ohne IT-Ticket angeschlossen hat: unsichtbar bis zur Durchsetzung, danach havariert. Die Sequenz, die dieses Szenario vermeidet, steht in p=reject erreichen, ohne die E-Mails zu zerstören; sie setzt eine vollständige Karte voraus — und genau darum geht es im Rest dieses Artikels.

Die Familien der Drittversender: weit über das Marketing hinaus

Der übliche Reflex endet beim Newsletter. In Wirklichkeit verteilen sich die Dritten, die im Namen einer Domain versenden, auf gut zehn Familien, und jede hat ihren blinden Fleck:

Marketing-E-Mails. Plattformen wie Mailchimp oder Brevo sind am besten identifiziert — das Marketing weiß, dass es versendet. Die sichtbarste Familie, selten die riskanteste.
Transaktionaler Anwendungsversand. Bestellbestätigungen, Passwort-Zurücksetzungen, Produktbenachrichtigungen, verschickt über SendGrid, Mailjet oder Amazon SES durch die hauseigenen Anwendungen. Die Entwickler wissen es; das Sicherheitsteam nicht immer.
CRM und Vertriebswerkzeuge. Prospektionssequenzen, Nachfassaktionen, Angebote, „von" der Adresse des Vertrieblers gesendet — durch die Plattform, nicht durch das Postfach.
Kundensupport. Jede Ticketantwort verlässt das Haus im Namen der Domain, über das Helpdesk-Werkzeug — ein beachtliches Tagesvolumen, das fast nie deklariert wird.
Ticketing und Events. Anmeldebestätigungen, Erinnerungen, Tickets: saisonale Versandspitzen, die ohne Vorwarnung in den Berichten auftauchen.
HR und Lohnabrechnung. HR-Suite, digitaler Tresor der Gehaltsabrechnungen, Recruiting-Plattformen: volumenarme, aber kritische Flüsse voller personenbezogener Daten.
Finanzen. Rechnungsstellung, Zahlungserinnerungen, Spesenabrechnungen — die Familie, die am häufigsten ohne IT-Ticket angeschlossen wird.
Monitoring und Sicherheit. Infrastruktur-Alarme, Backup-Berichte: der Fluss, den niemand ausgerechnet am Tag eines Vorfalls brechen sehen will.
Druckdienstleister und Hybridpost. Versandavise und Benachrichtigungen von Postdienstleistern — die Familie, die niemand je spontan nennt.

Jede Familie bringt ihr eigenes Ausrichtungsrezept mit, und Zeit kostet das Detail, nicht das Prinzip: Die SPF- und DKIM-Einrichtung von Amazon SES hat nichts mit der von Mailgun oder Postmark gemein. Die Vertriebsplattformen fügen eine weitere Schwierigkeit hinzu, die der Versanddomain: HubSpot, Klaviyo und Salesforce signieren jeweils nach eigenen Regeln, und eine einzige falsch eingestellte genügt, um die Ausrichtung der gesamten Domain scheitern zu lassen. Das Inventar eröffnet die Liste der Baustellen; geschlossen werden sie Anbieter für Anbieter.

Eine Organisation mit mehreren Marken multipliziert jede Familie mit der Zahl der Domains; die passende Disziplin behandelt die DMARC-Governance für mehrere Marken.

Drei Wahrheitsquellen — nur eine ist vollständig

Zuerst die RUA-Berichte. p=none mit einer Sammeladresse zu veröffentlichen — v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de — macht die großen Empfänger (Gmail, Microsoft, Yahoo) zu Beobachtern: Jede IP, die im Namen der Domain geschrieben hat, erscheint in den aggregierten Berichten, samt Volumen und Authentifizierungsergebnissen. Das ist die einzige vollständige Quelle: Diese Berichte sehen den offiziellen Dienstleister, das ohne Ticket angeschlossene Werkzeug, das vergessene Skript auf irgendeinem Server — und den Fälscher. Ihre Lektüre verlangt etwas Dekodierung, ausgeführt in den erklärten aggregierten DMARC-Berichten, und etwas Geduld: mindestens vier Wochen Sammlung, um die wöchentlichen und monatlichen Sendungen vorbeiziehen zu sehen.

Dann die Rechnungen und Verträge. Jedes SaaS, das Post versendet, wird irgendwem in Rechnung gestellt. Ein Buchhaltungsauszug der Software-Abonnements bringt Werkzeuge ans Licht, die niemand erwähnt hat — mit Anbieternamen, Vertrag, Ansprechpartner. Die Grenze ist bekannt: Kostenlose Werkzeuge und Schatten-IT auf privater Karte erreichen die Buchhaltung nie.

Zuletzt die Gespräche mit den Fachabteilungen. Eine halbe Stunde mit Marketing, HR, Finanzen, Support und IT, eine einzige Frage: „Welche Werkzeuge versenden E-Mails?" Das Gedächtnis ist fehlbar, und Abgänge löschen das Wissen — aber diese Quelle liefert, was den beiden anderen fehlt: den Eigentümer jedes Flusses, seine Kritikalität, seinen Kalender.

Die Kreuzung macht den Wert aus: RUA liefert die technische Vollständigkeit, die Buchhaltung den vertraglichen Hebel, die Gespräche die menschliche Dimension. Ein Inventar auf nur einer der drei Quellen ist ein löchriges Inventar.

Die Karte aufbauen: vom Werkzeugnamen zum internen Eigentümer

Die Karte nimmt die Form einer Tabelle an — ein geteiltes Tabellenblatt genügt völlig — mit einer Zeile pro Werkzeug-Domain-Paar und sechs Spalten: Quelle, technische Versanddomain, SPF-Status, DKIM-Status, beobachtete Ausrichtung, interner Eigentümer.

Quelle	Technische Domain	SPF	DKIM	Ausrichtung	Eigentümer
Newsletter-Plattform	`em.beispiel.de`	include gesetzt	delegierte CNAMEs	ausgerichtet	Marketing
SaaS-Rechnungsstellung	`bounce.beispiel.de`	include gesetzt	fehlt	nur SPF	Finanzen
HR- / Lohnsystem	keine (Direktversand)	fehlt	fehlt	nicht ausgerichtet	HR
Monitoring	`beispiel.de`	enthalten	selbst signiert	ausgerichtet	IT

Die technische Domain ist die, die der Dienstleister tatsächlich für SPF (die Rücksendeadresse) und für DKIM (die Signaturdomain) verwendet — nicht der kommerzielle Name des Werkzeugs. Genau diese Domain entscheidet über die Ausrichtung. Für jede Zeile nennt die Dokumentation des Dienstleisters das Vorgehen: ein SPF-include: (etwa include:servers.mcsv.net für Mailchimp) und vor allem CNAME-Einträge zur DKIM-Delegation der Form s1._domainkey.beispiel.de, die auf die Infrastruktur des Anbieters zeigen. DKIM verdient den Vorrang: Die Signatur überlebt Weiterleitungen, während SPF am ersten Relais bricht.

Die Spalte „Eigentümer" ist nicht dekorativ: Erst dank ihr wird die Remediation überhaupt möglich. Die Authentifizierung eines Werkzeugs zu konfigurieren setzt Zugang zu dessen Einstellungen voraus — also eine identifizierte Person auf der Fachseite, die die Konsole des Dienstleisters öffnet, während das DNS-Team die Einträge setzt. Eine Zeile ohne Eigentümer ist eine Zeile, die nie korrigiert wird.

Dritte, die sich nicht ausrichten können

Die Karte offenbart fast immer einige Zeilen, die im Ist-Zustand unlösbar sind: Dienstleister, die mit der Adresse der Domain versenden, aber weder anpassbares SPF noch delegiertes DKIM anbieten. Kein DNS-Eintrag kann ein Werkzeug retten, das nicht signiert.

Vier Auswege, in der Reihenfolge der Präferenz. Fragen: Die Funktion existiert manchmal auf einer höheren Stufe oder auf einfache Support-Anfrage — der Vertrag ist ein Verhandlungshebel. Verschieben: das Werkzeug von seiner eigenen Domain versenden lassen, der des Dienstleisters, in der sichtbaren Adresse; der Fluss verlässt den DMARC-Geltungsbereich der Hauptdomain, um den Preis einer weniger schmeichelhaften Adresse. Isolieren: das Werkzeug für die Dauer des Übergangs auf eine dedizierte Subdomain (notif.beispiel.de) mit eigener Policy beschränken — DMARCbis, die aktuelle Fassung des Standards, sieht dafür sogar einen expliziten Testmodus vor, das Tag t=y, das den alten Prozentmechanismus ersetzt. Ersetzen: Ein Dienstleister, der seine Post 2026 nicht authentifizieren kann, sagt etwas über seine technische Reife; die Vertragsverlängerung ist der richtige Moment, die Konsequenzen zu ziehen.

Entscheidend ist, jede Zeile vor der Verschärfung zu klären: Eine Zeile „nicht ausgerichtet" ohne dokumentierte Entscheidung ist genau der Fluss, der bei strikter Durchsetzung brechen wird.

Ein lebendes Inventar, keine Momentaufnahme

Ein Inventar mit dem Datum des Projektstarts, das nie wieder geöffnet wird, ist kaum besser als gar keines: Der Werkzeugbestand bewegt sich ständig. Drei Mechanismen halten es aktuell.

Der erste ist organisatorisch: eine Frage im Beschaffungsprozess. „Wird dieser Dienst E-Mails im Namen der Domain versenden?" — falls ja, kommt eine Zeile auf die Karte, und die Authentifizierung wird vor der Inbetriebnahme konfiguriert, nicht nach der ersten Abweisung. Neues Werkzeug, neue Zeile: Die ganze Regel passt in vier Worte.

Der zweite ist technisch: die kontinuierliche Überwachung der RUA-Berichte. Eine unbekannte Quelle, die im Dashboard auftaucht, ist entweder ein ohne Ankündigung angeschlossenes Werkzeug — die Karte wird vervollständigt — oder eine Fälschung — der Vorfall wird behandelt. In beiden Fällen zeigt sich die Lücke zwischen Karte und Realität in Tagen, nicht in Jahren.

Der dritte ist ereignisgetrieben: Jede größere Veränderung des Informationssystems spielt das Inventar neu durch. Der brutalste Fall ist die Migration des E-Mail-Anbieters, die den größten Versender der Domain auf einen Schlag verschiebt und jede schlafende Zeile der Karte aufweckt. Fusionen, Übernahmen und Anwendungsumbauten haben denselben Effekt, mit weniger vorhersehbarem Zeitpunkt.

Fazit

Ein DMARC-Projekt wird nicht im DNS gewonnen, sondern auf der Karte. Die Drittversender — Marketing, Transaktion, CRM, Support, Ticketing, HR, Finanzen, Monitoring, Hybridpost — schreiben im Namen der Domain, oft ohne Wissen der IT, und jedes Vergessen wird beim Wechsel zu p=reject zum gebrochenen Fluss. Die Methode passt in vier Schritte: die drei Wahrheitsquellen kreuzen (RUA-Berichte, als einzige vollständig; Rechnungen und Verträge; Fachgespräche), jeden Fluss in einer Tabelle festhalten, die Quelle, technische Domain, SPF/DKIM und internen Eigentümer verbindet, das Schicksal der nicht ausrichtbaren Dritten klären und dann die Karte lebendig halten — neues Werkzeug, neue Zeile.

Die erste Geländeaufnahme verlangt kein Projekt: Die kostenlose DMARC-Analyse zeigt in Sekunden den Authentifizierungszustand der Domain und das, was die Empfänger bereits davon sehen. Für den Schritt von der Aufnahme zur vollständigen Karte startet ein Konto die RUA-Sammlung — und das Inventar entsteht dann aus beobachteten Fakten, nicht aus dem Gedächtnis der Teams.