DMARC im Unternehmen einführen: SPF, DKIM und Domain-Spoofing-Schutz richtig umsetzen

Montagmorgen, kurz nach neun: Die Buchhaltung erhält eine E-Mail der angeblichen Geschäftsführung mit einer dringenden Zahlungsanweisung. Name, Signatur und Tonfall wirken glaubwürdig. Nur die Absenderdomain enthält ein kaum auffälliges Zeichen mehr. Solche Angriffe gehören zum Alltag vieler Unternehmen. Mit DMARC kannst du fremden Mailservern mitteilen, wie sie mit Nachrichten umgehen sollen, die scheinbar von deiner Domain stammen, aber SPF oder DKIM nicht bestehen.

DMARC steht für „Domain-based Message Authentication, Reporting and Conformance“. Das Verfahren ergänzt SPF und DKIM, ersetzt sie aber nicht. Seine Stärke liegt in der Kombination: DMARC prüft, ob eine Nachricht technisch autorisiert ist und ob die sichtbare Absenderdomain zum geprüften SPF- oder DKIM-Ergebnis passt. Zusätzlich erhältst du Berichte über Mailverkehr, der deine Domain als Absender verwendet.

Für IT-Teams ist DMARC deshalb nicht nur ein DNS-Projekt. Es betrifft E-Mail-Infrastruktur, Cloud-Dienste, Marketing, Fachanwendungen und Dienstleister. Wer zu schnell eine harte Richtlinie aktiviert, riskiert, legitime Nachrichten zu blockieren. Wer dauerhaft nur überwacht, lässt missbräuchliche Absenderdomains hingegen weitgehend ungeschützt.

Infografik zu DMARC im Unternehmen einführen: SPF, DKIM und Domain-Spoofing-Schutz richtig umsetzen (KI-generiert).

Warum SPF und DKIM allein nicht genügen

SPF definiert, welche Mailserver im Namen einer Domain versenden dürfen. Der empfangende Server prüft dazu die Absender-IP gegen den SPF-Eintrag im DNS. Das ist sinnvoll, hat aber Grenzen: SPF prüft häufig die technische Envelope-Absenderadresse, nicht zwingend die sichtbare Absenderadresse im Feld „From“.

DKIM versieht ausgehende E-Mails mit einer kryptografischen Signatur. Empfangende Systeme prüfen den öffentlichen Schlüssel im DNS und können damit erkennen, ob bestimmte Inhalte der Mail nach dem Versand verändert wurden und ob der signierende Server berechtigt erscheint.

DMARC führt beides zusammen. Entscheidend ist das sogenannte Alignment, also die Übereinstimmung zwischen der sichtbaren From-Domain und der Domain, die SPF oder DKIM erfolgreich bestätigt.

Ein Beispiel: Ein Angreifer versendet eine Mail mit „rechnung@deinefirma.de“ als sichtbarem Absender. Die Mail kommt aber von einem fremden Server und trägt keine passende DKIM-Signatur. Ein empfangender Mailserver kann anhand deiner DMARC-Richtlinie entscheiden, ob er die Nachricht akzeptiert, in Quarantäne verschiebt oder ablehnt.

Das reduziert besonders das Risiko von Domain-Spoofing bei CEO-Fraud und Phishing. Es verhindert allerdings nicht jede betrügerische Mail. Angreifer können ähnlich aussehende Domains registrieren, kompromittierte Konten missbrauchen oder externe Freemail-Adressen nutzen. Ergänze DMARC daher mit Awareness, sicheren Anmeldeverfahren und technischen Kontrollen. Praktische Hinweise zu typischen Angriffsmustern findest du auch in unserem Beitrag Phishing erkennen und richtig reagieren.

Zuerst alle sendenden Systeme inventarisieren

Der häufigste Fehler bei der DMARC-Einführung ist ein unvollständiges Inventar. Viele Unternehmen denken zunächst an Microsoft 365, Google Workspace oder das eigene Mail-Gateway. Tatsächlich versenden oft deutlich mehr Systeme unter der Unternehmensdomain.

Typische Quellen sind:

• zentrale Mailplattformen und SMTP-Relays
• Newsletter- und Marketing-Dienste
• CRM-, ERP- und Ticketsysteme
• Personalsoftware und Bewerbermanagement
• Monitoring-, Backup- und Alarmierungssysteme
• Multifunktionsgeräte, Scanner und lokale Anwendungen
• SaaS-Plattformen für Signaturen, Umfragen oder Terminbuchungen
• externe Dienstleister, die im Auftrag E-Mails versenden

Erfasse für jede Quelle mindestens den fachlichen Eigentümer, die verwendete Absenderdomain, die Envelope-Absenderadresse, den Versandweg, die konfigurierte DKIM-Domain und den Status der SPF-Autorisierung. Dokumentiere auch, ob der Dienst ausschließlich transaktionale Mails oder große Mengen an Marketing-Nachrichten verschickt.

Besonders wichtig: Nicht jede Anwendung muss unbedingt mit deiner Hauptdomain senden. Für Newsletter oder technische Benachrichtigungen können Subdomains sinnvoll sein, etwa „news.beispiel.de“ oder „alerts.beispiel.de“. Das erleichtert die Trennung von Zuständigkeiten und reduziert die Auswirkungen einzelner Fehlkonfigurationen.

SPF belastbar konfigurieren

Ein SPF-Eintrag liegt als TXT-Record im DNS vor. Er beschreibt zulässige Versandquellen und endet üblicherweise mit einer Regel, die nicht autorisierte Server bewertet. Für DMARC reicht es nicht, einen SPF-Record zu besitzen. Er muss vollständig, aktuell und technisch auswertbar sein.

Achte besonders auf diese Punkte:

• Pro Domain darf es nur einen SPF-TXT-Record geben. Mehrere Einträge führen zu einem Permerror.
• Führe alle legitimen Versandwege in einem konsolidierten Record zusammen.
• Prüfe Include-Mechanismen von Cloud- und Newsletter-Anbietern regelmäßig.
• Beachte das SPF-Lookup-Limit. Zu viele DNS-Abfragen können dazu führen, dass Empfänger den SPF-Check nicht zuverlässig auswerten.
• Verwende „-all“ erst, wenn dein Inventar belastbar ist. „~all“ kann während der Einführungsphase sinnvoll sein, ist aber kein dauerhafter Sicherheitsnachweis.
• Prüfe Subdomains getrennt, wenn diese eigenständig E-Mails versenden.

SPF ist außerdem anfällig für Weiterleitungen. Wird eine Nachricht weitergeleitet, versendet sie oft über einen Server, der nicht in deinem SPF-Record steht. Deshalb sollte DKIM für jede wichtige Versandquelle ebenfalls eingerichtet sein. DMARC kann dann über eine korrekt ausgerichtete DKIM-Signatur weiterhin bestehen.

DKIM für jede Versandquelle einrichten

DKIM ist in der Praxis meist robuster als SPF, weil die Signatur beim Weiterleiten erhalten bleiben kann. Jeder Versanddienst benötigt eine korrekt konfigurierte DKIM-Signatur. Der Dienst stellt dafür üblicherweise DNS-Einträge bereit, oft als CNAME- oder TXT-Records.

Bei der Prüfung geht es nicht nur darum, ob DKIM „irgendwie“ besteht. Für DMARC muss die Signatur mit der sichtbaren Absenderdomain ausgerichtet sein. Wenn deine Mails als „@beispiel.de“ erscheinen, aber ausschließlich eine fremde Dienstleisterdomain signiert, kann DMARC scheitern.

Diese Punkte gehören in deine DKIM-Checkliste:

• Nutze für produktive Versandquellen eigene Selector-Namen, damit Schlüssel und Zuständigkeiten nachvollziehbar bleiben.
• Stelle sicher, dass die DKIM-Domain zur sichtbaren From-Domain passt oder organisatorisch sauber als Subdomain ausgerichtet ist.
• Verwende aktuelle, ausreichend starke Schlüssel gemäß den Möglichkeiten deines Maildienstes.
• Plane Schlüsselwechsel und dokumentiere, wer DNS-Einträge ändern darf.
• Prüfe nach Änderungen an Newsletter- oder Cloud-Diensten immer Versand, Signatur und Alignment.
• Behalte im Blick, ob Gateways oder Disclaimer-Lösungen E-Mails nachträglich verändern und damit Signaturen ungültig machen.

Wenn Entwicklerteams automatisierte Benachrichtigungen über CI/CD-Systeme versenden, gehören auch diese Prozesse in das Inventar. Gerade bei automatisierten Workflows können Secrets, Tokens und Versandberechtigungen schnell unübersichtlich werden. Ergänzende Maßnahmen behandeln wir in unserem Ratgeber GitHub Actions sicher konfigurieren: Secrets schützen, Rechte minimieren, Supply-Chain-Risiken senken.

Mit p=none starten und DMARC-Reports auswerten

Ein DMARC-Record wird ebenfalls als TXT-Record im DNS veröffentlicht, unter „_dmarc.deinedomain.tld“. Die Richtlinie „p=none“ fordert Empfänger noch nicht zum Blockieren auf. Sie dient zunächst dem Monitoring und ist der richtige Einstieg für fast jedes Unternehmen.

DMARC kennt zwei wichtige Berichtsarten:

• Aggregierte Berichte zeigen in strukturierter Form, welche IP-Adressen E-Mails im Namen deiner Domain versenden, wie SPF und DKIM bewertet wurden und welche DMARC-Entscheidung getroffen wurde.
• Forensische Berichte können detailliertere Informationen zu einzelnen Fehlschlägen enthalten. Ihre Verfügbarkeit hängt vom empfangenden Anbieter ab, und sie müssen wegen möglicher personenbezogener Daten besonders sorgfältig behandelt werden.

Die XML-Dateien aggregierter Reports sind ohne Auswertung wenig hilfreich. Nutze ein geeignetes Auswertungsverfahren, intern oder mit einem spezialisierten Dienst, und kläre vorab Verantwortlichkeiten, Aufbewahrung sowie Zugriffsrechte.

Bei der Analyse solltest du nicht nur auf „pass“ und „fail“ schauen. Stelle für jede auffällige Quelle diese Fragen:

1. Gehört die sendende IP oder der Dienst zu uns oder einem beauftragten Partner?
2. Welche sichtbare Absenderdomain wurde genutzt?
3. Besteht SPF, DKIM oder beides?
4. Ist mindestens eines der Verfahren zur From-Domain ausgerichtet?
5. Handelt es sich um legitime Weiterleitungen, Fehlkonfigurationen oder Missbrauch?
6. Wer ist fachlich und technisch für die Korrektur zuständig?

Unbekannte Versandquellen sind nicht automatisch ein Angriff. Sie sind aber ein Untersuchungssignal. Häufig kommen dabei vergessene SaaS-Abonnements, alte Kampagnen-Tools oder nicht dokumentierte Scanner ans Licht.

Schrittweise zu Quarantäne und Ablehnung wechseln

Erst wenn die Reports über einen ausreichend repräsentativen Zeitraum zeigen, dass legitime Versandquellen zuverlässig bestehen, solltest du die Richtlinie verschärfen. Wie lange diese Beobachtung dauert, hängt von deinen Geschäftsprozessen, saisonalen Kampagnen und der Zahl externer Dienste ab.

Ein praxistauglicher Ablauf sieht so aus:

• Beginne mit „p=none“ und sammle Reports.
• Behebe SPF-, DKIM- und Alignment-Fehler für bekannte Systeme.
• Setze zunächst „pct“ ein, um eine Quarantäne-Richtlinie nur auf einen Teil der nicht konformen Mails anzuwenden.
• Erhöhe den Anteil schrittweise, während du Reports und Fachbereichsrückmeldungen weiter prüfst.
• Wechsle zu „p=quarantine“, wenn Fehlkonfigurationen unter Kontrolle sind.
• Setze „p=reject“ erst, wenn du sicher bist, dass keine relevante legitime Quelle mehr scheitert.
• Wiederhole die Prüfung für wichtige Subdomains und externe Marken-Domains.

„Quarantine“ bedeutet nicht zwingend, dass jede Mail im Spam-Ordner landet. Empfänger entscheiden weiterhin anhand eigener Regeln. „Reject“ ist dagegen das klarste Signal: Nachrichten, die deine DMARC-Prüfung nicht bestehen, sollen abgewiesen werden.

Für die Durchsetzung ist ein strenges Alignment besonders wirksam, aber nicht immer sofort praktikabel. Prüfe daher sorgfältig, ob Subdomains, Dienstleister oder komplexe Versandwege betroffen sind. Ziel ist nicht ein möglichst strenger DNS-Eintrag, sondern ein wirksamer Schutz ohne Unterbrechung legitimer Kommunikation.

DMARC ist Teil deiner E-Mail-Sicherheitsarchitektur

DMARC schützt deine Domain nach außen. Für den Schutz eingehender Mails brauchst du zusätzlich sichere Konten, Mehrfaktor-Authentisierung, Spam- und Malware-Filter, sichere Prozesse für Zahlungsfreigaben sowie geschulte Mitarbeitende. Gerade bei Angriffen auf Microsoft-365-Umgebungen spielen auch missbrauchte OAuth-Berechtigungen eine Rolle. Lies dazu unseren Beitrag OAuth-Apps im Microsoft-365-Tenant absichern: Consent Phishing erkennen und verhindern.

Ebenso wichtig sind Logging und klare Zuständigkeiten. Wenn DMARC-Reports plötzlich neue Versandquellen zeigen oder ein wichtiger Dienst nicht mehr korrekt signiert, muss dein Team schnell nachvollziehen können, was sich verändert hat. Grundlagen für aussagekräftige Protokollierung findest du in unserem Ratgeber Angriffe früh erkennen: Logging und Monitoring.

Plane DMARC daher als dauerhaften Betriebsprozess:

• Überwache Reports kontinuierlich.
• Prüfe neue SaaS-Dienste vor der Produktivsetzung.
• Aktualisiere SPF und DKIM bei Änderungen am Versandweg.
• Dokumentiere Ausnahmen und entferne nicht mehr benötigte Einträge.
• Stimme Änderungen zwischen IT, Marketing, Kommunikation und Fachbereichen ab.
• Teste regelmäßig, ob externe Empfänger deine legitimen Nachrichten akzeptieren.

Passende Seminare und Termine findest du bei uns auf cmt.de.