Phishing über stillgelegte Mailchimp-Accounts: Wenn DMARC grünes Licht gibt, obwohl es das nicht sollte
Der Fall: Eine Phishing-Mail, die alle Checks besteht
Ein IT-Sicherheitsteam meldet eine Phishing-Mail an den Abuse-Desk – und bekommt zur Antwort, dass die Mail vollständig authentifiziert war. SPF: pass. DKIM: pass. DMARC: pass. Kein Filter hat angeschlagen, kein Gateway hat geblockt. Die Mail kam über Mailchimp, war kryptografisch einwandfrei signiert und stammte scheinbar von einer legitimen Domain.
Der Haken: Der Mailchimp-Account gehörte einem ehemaligen Mitarbeiter, der das Unternehmen längst verlassen hatte. Das Konto war nie deaktiviert worden. Jemand hatte es übernommen – oder der Ex-Mitarbeiter selbst hatte es genutzt – und eine täuschend echte Phishing-Kampagne verschickt.
Dieser Fall, der auf Reddit in r/EmailSecurity diskutiert wurde, ist kein Einzelfall. Er zeigt eine strukturelle Lücke, die in vielen Unternehmen existiert.
Was DMARC kann – und was nicht
DMARC ist ein Authentifizierungsprotokoll. Es prüft, ob eine E-Mail tatsächlich von einem autorisierten Mailserver der angegebenen Domain stammt. Dafür kombiniert es SPF (welche IP-Adressen dürfen senden?) und DKIM (ist die Mail kryptografisch signiert?).
Was DMARC nicht kann: Es prüft nicht, ob der Account, der die Mail verschickt hat, noch aktiv genutzt werden darf. Es unterscheidet nicht zwischen einem autorisierten Marketing-Mitarbeiter und einem ehemaligen Kollegen, dessen Mailchimp-Zugang nie gesperrt wurde.
Das ist kein Fehler in DMARC – es ist eine Grenze des Protokolls. Authentifizierung und Autorisierung sind zwei verschiedene Dinge. DMARC löst das erste Problem, nicht das zweite.
Die eigentliche Lücke: Offboarding ohne Sender-Inventar
In den meisten Unternehmen gibt es einen Offboarding-Prozess für interne Systeme: Active Directory-Account deaktivieren, Laptop einsammeln, VPN-Zugang sperren. Was dabei regelmäßig vergessen wird: externe Dienste, die Mitarbeiter im Laufe ihrer Tätigkeit eigenständig eingerichtet haben.
Mailchimp ist ein gutes Beispiel. Ein Marketing-Mitarbeiter richtet einen Account ein, verknüpft ihn mit der Unternehmens-Domain, konfiguriert SPF und DKIM – und wenn er das Unternehmen verlässt, bleibt der Account bestehen. Die DNS-Einträge zeigen weiterhin auf Mailchimps Server. DMARC vertraut weiterhin dieser Konfiguration.
Das Ergebnis: Jeder, der Zugriff auf diesen Mailchimp-Account hat, kann E-Mails im Namen der Unternehmens-Domain versenden – und alle Empfänger-Filter werden sie als legitim einstufen.
Diese Lücke entsteht nicht durch technisches Versagen, sondern durch fehlende Prozesse:
- Kein zentrales Inventar aller autorisierten E-Mail-Sender
- Kein Offboarding-Schritt für externe Marketing- oder Kommunikationstools
- Keine regelmäßige Überprüfung, welche Dienste aktuell SPF-berechtigt sind
Wie man die Lücke schließt
Sender-Inventar aufbauen. Wer darf E-Mails im Namen eurer Domain versenden? Diese Frage sollte eine vollständige, aktuelle Liste erzeugen: ESP (E-Mail-Service-Provider) wie Mailchimp, HubSpot, Brevo; Transaktionsdienste wie SendGrid oder Postmark; interne Mailserver. Jeder Eintrag im SPF-Record sollte einem konkreten, aktiven Dienst zugeordnet sein.
Offboarding-Checkliste erweitern. Wenn ein Mitarbeiter das Unternehmen verlässt, sollte geprüft werden: Welche externen Dienste hat diese Person im Namen der Domain konfiguriert? Mailchimp-Accounts, HubSpot-Instanzen, Zapier-Verbindungen – alles, was E-Mails senden kann, muss auf den Prüfstand.
SPF-Records regelmäßig auditieren. Ein SPF-Record, der vor drei Jahren konfiguriert wurde, enthält möglicherweise Einträge für Dienste, die längst nicht mehr genutzt werden. Regelmäßige Audits – mindestens quartalsweise – helfen, verwaiste Einträge zu identifizieren und zu entfernen.
DMARC-Reports auswerten. DMARC-Aggregate-Reports zeigen, welche Quellen tatsächlich E-Mails im Namen eurer Domain versenden. Wenn dort ein Mailchimp-Server auftaucht, den ihr nicht kennt, ist das ein Warnsignal. Diese Reports sind genau dafür gedacht: unbekannte oder unerwartete Sender sichtbar zu machen.
Der blinde Fleck zwischen Authentifizierung und Autorisierung
Der Reddit-Fall macht einen wichtigen Unterschied deutlich, der in der Praxis oft verwischt wird: Authentifizierung bedeutet, dass eine Mail technisch korrekt von einem autorisierten Sender stammt. Autorisierung bedeutet, dass dieser Sender auch heute noch das Recht hat, im Namen eurer Domain zu senden.
Ein Mailchimp-Account, der korrekt mit SPF und DKIM konfiguriert ist, besteht die Authentifizierung. Ob der Account noch aktiv genutzt werden darf, ist eine Autorisierungsfrage – und die beantwortet kein technisches Protokoll automatisch.
Das bedeutet: Technische Maßnahmen allein reichen nicht. DMARC auf p=reject zu setzen ist wichtig und richtig. Aber es schützt nicht vor Missbrauch durch Accounts, die technisch berechtigt, aber organisatorisch längst nicht mehr autorisiert sind.
Die Lösung liegt in der Kombination: technische Kontrolle durch DMARC, ergänzt durch organisatorische Kontrolle durch Prozesse und Inventar-Management.
Was dieser Fall für MSPs bedeutet
Für Managed Service Provider, die mehrere Kunden betreuen, ist dieser Fall besonders relevant. Wenn ein Mitarbeiter beim Kunden das Unternehmen verlässt und dabei einen Mailchimp-Account hinterlässt, der auf die Kundendomain konfiguriert ist, liegt das Risiko beim Kunden – aber die Verantwortung für die Erkennung oft beim MSP.
Ein strukturiertes Sender-Inventar und ein Offboarding-Prozess, der externe Dienste einschließt, sind keine Nice-to-haves. Sie sind Teil einer vollständigen E-Mail-Sicherheitsstrategie.
Welche Dienste senden gerade E-Mails im Namen eurer Domain? Mit dem kostenlosen Domain-Check von DMARCPulse bekommt ihr einen ersten Überblick über eure aktuelle DMARC-Konfiguration und könnt unbekannte Sender in euren Reports sichtbar machen: https://dmarcpulse.io/de/free-domain-check