Bildquelle: Pexels / https://www.pexels.com/photo/envelopes-on-a-mail-organizer-7054727/
DMARC scheitert im Unternehmensbetrieb oft an geteilten Absenderdomänen
Viele Unternehmen behandeln DMARC noch immer wie einen späten DNS-Schritt. SPF setzen, DKIM aktivieren, TXT-Record anlegen, fertig. Genau so entsteht in der Praxis aber oft der Frust, dass Zustellprobleme plötzlich aus ganz unterschiedlichen Richtungen kommen. Denn die eigentliche Schwierigkeit liegt selten im einzelnen DNS-Eintrag, sondern in der Frage, wie viele Systeme dieselbe sichtbare Absenderdomäne verwenden. Sobald Microsoft 365, Marketing-Tool, Ticketing-Plattform, CRM, Recruiting-Suite und Statusdienst alle im Namen derselben Hauptdomäne senden, wird DMARC vom Sicherheitsthema zur Betriebsaufgabe.
Die offiziellen Quellen sind an diesem Punkt klarer, als viele Organisationen es intern abbilden. Google verlangt für Bulk-Sender SPF, DKIM und DMARC sowie Alignment zwischen der sichtbaren From-Domäne und SPF oder DKIM. Microsoft beschreibt ebenfalls, dass DMARC genau diese Ausrichtung zwischen RFC5322.From und den authentifizierten Domänen prüft, und empfiehlt für Maildienste außerhalb der direkten eigenen Kontrolle ausdrücklich eigene Subdomains. Im DMARC-RFC selbst ist der Grundgedanke eindeutig: Domaininhaber veröffentlichen nicht nur eine Policy, sondern erhalten auch Rückmeldungen darüber, wie ihre Domäne tatsächlich verwendet wird. Genau daraus folgt eine unangenehme Wahrheit für den Unternehmensbetrieb. Wer viele fremde oder nur halb verwaltete Sender unter einer gemeinsamen Hauptdomäne bündelt, baut sich unnötige Kopplungen in Zustellung, Reputation und Störungsanalyse ein.
Die sichtbare From-Domäne ist eine Architekturentscheidung und kein Dekodetail
DMARC knüpft nicht an irgendeine technische Nebendomäne an, sondern an die Adresse im sichtbaren From-Header. Der RFC beschreibt diesen Identifier ausdrücklich als primären Bezugspunkt. Microsoft führt denselben Punkt operativ aus: Eine Nachricht besteht DMARC nur dann, wenn entweder SPF mit ausgerichteter MAIL-FROM-Domäne oder DKIM mit ausgerichteter Signaturdomäne zur From-Adresse passt.
Für den Betrieb ist das wichtiger als viele Projektpläne vermuten lassen. Wenn ein Unternehmen seine Hauptdomäne gleichzeitig für klassische Benutzerpostfächer, Tickets, Newsletter, Rechnungen, Events und Produktbenachrichtigungen nutzt, hängt die DMARC-Fähigkeit all dieser Pfade an derselben sichtbaren Identität. Schon ein einzelner Sender, der nur teilweise sauber integriert ist, erzeugt dann Diskussionen über Ausnahmen, Lockerungen oder Zustellprobleme, die plötzlich alle betreffen.
Praktisch heißt das: Die Frage „Unter welcher From-Domäne darf dieses System senden?“ gehört in Architektur und Change-Freigabe, nicht erst in den DNS-Feinschliff kurz vor Go-live. Wer diese Entscheidung zu spät trifft, versucht später meist, organisatorische Unordnung mit SPF-Workarounds zu kaschieren.
Gemeinsam genutzte Hauptdomänen koppeln Reputation, Richtlinie und Fehlerbilder
Google formuliert die Anforderungen für größere Sender inzwischen sehr deutlich. Wer mehr als 5.000 Nachrichten pro Tag an persönliche Gmail-Konten sendet, braucht SPF, DKIM und DMARC. Außerdem muss die Domain im sichtbaren From-Header mit der SPF- oder DKIM-Domäne ausgerichtet sein, damit DMARC-Alignment besteht. Gleichzeitig verweist Google auf Spamraten, PTR-Einträge und weitere Infrastrukturkriterien.
Im Alltag bedeutet das: Eine gemeinsam genutzte Hauptdomäne ist nicht nur ein Branding-Thema, sondern ein gemeinsamer Risikoraum. Wenn etwa Marketing-Kampagnen, Event-Einladungen oder transaktionale Massenmails unter derselben Hauptdomäne laufen wie Mitarbeiterkommunikation oder Servicebenachrichtigungen, wirken sich Fehlkonfigurationen oder Reputationsprobleme schneller auf mehrere Kommunikationsstränge aus. Dann wird aus einem lokalen Problem eines einzelnen Tools ein unternehmensweiter Zustellungs- und Erklärungsaufwand.
Gerade Service- und IT-Leitungen sollten diesen Kopplungseffekt ernst nehmen. Denn im Incident zählt nicht, ob SPF und DKIM irgendwo grundsätzlich bekannt sind. Entscheidend ist, ob schnell sichtbar wird, welcher Sender für welches Volumen, welche Signatur, welche Return-Path-Domäne und welche sichtbare From-Identität verantwortlich ist.
Drittanbieter gehören in eigene Subdomains, nicht in die zentrale Alltagsdomäne
Microsoft spricht an einer Stelle eine Empfehlung aus, die in vielen Unternehmen noch zu selten konsequent umgesetzt wird: Für E-Mail-Dienste, die nicht vollständig unter eigener Kontrolle stehen, sollte besser eine Subdomain statt der Hauptdomäne verwendet werden. Der Grund ist operativ sehr einleuchtend. Probleme bei externen Diensten sollen nicht direkt die Reputation und Steuerbarkeit der normalen Benutzerkommunikation auf der Hauptdomäne beschädigen.
Genau daraus lässt sich ein robustes Muster ableiten. Marketing sendet zum Beispiel unter news.firma.de, Ticket- oder Benachrichtigungsdienste unter notify.firma.de, Recruiting unter jobs.firma.de und klassische Mitarbeiterkommunikation weiter unter der Hauptdomäne. So bleiben sichtbare Absender, DKIM-Signaturen, SPF-Pfade und DMARC-Policies sauberer voneinander trennbar.
Wichtig ist dabei, dass Subdomains kein Freifahrtschein sind. Microsoft weist ausdrücklich darauf hin, dass jede genutzte Subdomain für funktionierendes DMARC wiederum eigene SPF- und DKIM-Grundlagen braucht. Gleichzeitig erläutert Microsoft, dass DMARC zwar grundsätzlich auf Subdomains vererbt wird, diese Vererbung aber durch eigene DMARC-Records auf der Subdomain bewusst unterbrochen und differenziert gesteuert werden kann. Genau diese Granularität macht Subdomains im Betrieb so wertvoll.
DMARC-Reports sind Betriebstelemetrie und kein Einmalprojekt
Der RFC beschreibt DMARC nicht nur als Policy-Mechanismus, sondern auch ausdrücklich als Feedback-System. Google empfiehlt, DMARC-Reports einzurichten, damit Organisationen sehen, welche Sender im Namen ihrer Domäne auftreten. Microsoft beschreibt Aggregate- und Failure-Reports ebenso als festen Bestandteil der Konfiguration.
Trotzdem werden Reports in vielen Häusern nur einmal zum Projektstart betrachtet. Danach landen XML-Berichte in einem Postfach, das niemand regelmäßig auswertet. Genau das ist verschenkter Betriebswert. Denn DMARC-Reports zeigen nicht nur Angriffe oder Spoofing-Versuche. Sie machen auch sichtbar, welche legitimen Systeme noch ohne saubere Ausrichtung senden, welche Subdomains unerwartet auftauchen und wo nach einer Tool-Einführung oder Anbieteränderung plötzlich neue Quellen aktiv werden.
Für den Regelbetrieb lohnt sich deshalb eine klare Verantwortlichkeit. Mindestens ein Team sollte die Reports regelmäßig auswerten, legitime Sender inventarisieren, unbekannte Quellen eskalieren und bei Änderungen an Versandwegen früh eingreifen. Ohne diese Routine bleibt DMARC formal vorhanden, aber operativ blind.
Parked Domains, Weiterleitungen und neue SaaS-Sender brauchen feste Change-Regeln
Microsoft empfiehlt für registrierte, aber ungenutzte Domains eine harte DMARC-Ansage, dass aus diesen Domänen überhaupt keine Mail kommen soll. Auch das ist kein Randthema. Gerade in größeren Organisationen sammeln sich Marken-, Projekt- oder Alt-Domänen an, die technisch noch vorhanden sind, aber keinen legitimen Mailversand mehr haben. Ohne klare Policy bleiben sie unnötige Angriffs- und Verwirrungsflächen.
Google weist zusätzlich darauf hin, dass Weiterleitungen und fremde Versanddienste sauber berücksichtigt werden müssen. Wer neue SaaS-Tools für Rechnungen, Events, Support oder Recruiting einführt, ändert damit fast immer auch den Mailpfad. Genau deshalb sollte jeder neue Sender wie ein echter Betriebschange behandelt werden: mit definierter From-Domäne, dokumentierter DKIM-Verantwortung, SPF-Prüfung, Reporting-Ziel, Volumenabschätzung und Rückbauplan.
Die wichtigste Reifegradfrage lautet deshalb nicht, ob irgendwo ein DMARC-Record existiert. Sie lautet, ob neue Mailquellen im Unternehmen überhaupt noch unbemerkt an der zentralen Absenderidentität andocken können. Wenn die Antwort ja ist, liegt das eigentliche Problem nicht in DMARC, sondern in fehlender Betriebssteuerung.
Was IT-Leitungen jetzt konkret anstoßen sollten
- Alle sichtbaren From-Domänen inventarisieren: Nicht nur Mailserver, sondern auch CRM, Ticketing, HR, Marketing, Monitoring und Fachanwendungen erfassen.
- Hauptdomäne von Drittanbietern entlasten: Externe oder weniger kontrollierte Versanddienste systematisch auf eigene Subdomains verschieben.
- DMARC-Reports in den Regelbetrieb ziehen: Zuständigkeit, Auswertung und Eskalation verbindlich festlegen.
- Neue Mailsender als Change behandeln: Kein SaaS-Versand ohne definierte From-Domäne, SPF-, DKIM- und DMARC-Prüfung.
- Ungenutzte Domains absichern: Parked Domains und Altmarken mit restriktiver DMARC-Policy versehen und regelmäßig prüfen.
Fazit
DMARC scheitert im Unternehmensbetrieb selten an der Syntax des TXT-Records. Die eigentliche Schwachstelle sind gemeinsam genutzte Absenderdomänen, an die immer neue Tools, Dienstleister und Prozesspfade angehängt werden. Wer die sichtbare From-Identität als Architekturgrenze behandelt, Drittanbieter in eigene Subdomains trennt und Reports wie echte Betriebstelemetrie nutzt, macht aus DMARC kein Nebenprojekt, sondern eine belastbare Mail-Governance.
