Mailchimp und DMARC: vollständige Ausrichtung erreichen

Von Thomas · virtueller CISO · 2026-08-01

In den DMARC-Berichten der meisten Organisationen gehört Mailchimp zu den sichtbarsten Quellen. Newsletter, Produktankündigungen, Vereinsmitteilungen: Die E-Mail-Plattform versendet täglich beträchtliche Volumen im Namen zehntausender Domains. Und doch scheitert ein erheblicher Teil dieser Kampagnen an der DMARC-Auswertung, ohne dass irgendjemand etwas kaputt gemacht hätte — dahinter steckt das Standardverhalten der Plattform. Eine Kampagne verlässt die geteilte Infrastruktur, DKIM-signiert mit der Domain der Plattform, mit einem Envelope auf deren eigenen Servern. Alles „besteht" im engen Sinn, SPF wie DKIM; nichts richtet sich an der im From-Feld angezeigten Domain aus. Und genau diese Ausrichtung — das Alignment — ist das Einzige, was DMARC bewertet.

Der Fall Mailchimp ist ein Lehrbuchbeispiel für das Verhältnis zwischen einem Versanddienstleister und DMARC, und die Korrektur besteht aus wenigen CNAME-Einträgen. Verstehen muss man allerdings, warum DKIM — und nur DKIM — die Ausrichtung tragen wird, warum SPF bei diesem Anbieter nie ausgerichtet sein wird und wie sich in den aggregierten Berichten nachweisen lässt, dass die Umstellung tatsächlich gewirkt hat, bevor die Policy verschärft wird.

Dieser Leitfaden geht die vollständige Mechanik durch: das Standardverhalten und die From-Umschreibung, die im Zuge der Anforderungen der großen Anbieter eingeführt wurde, die Authentifizierung der Versanddomain, die Lektüre der RUA-Berichte vorher und nachher, den Nutzen der dedizierten Subdomain und das, was bei p=reject passiert, wenn nichts unternommen wurde.

Das Standardverhalten: die Plattform authentifiziert sich selbst

Ohne besondere Konfiguration verlässt eine Mailchimp-Kampagne die geteilte Infrastruktur der Plattform. Der SMTP-Envelope — die technische Rücksendeadresse, für den Leser unsichtbar — trägt eine Domain des Anbieters aus der Familie mcsv.net oder rsgsv.net: Diese Domain wertet SPF aus, und da sie korrekt deklariert ist, besteht SPF. Die DKIM-Signatur wird mit dem Schlüssel der Plattform gesetzt, typischerweise d=mcsv.net: Die Kryptographie ist gültig, also besteht auch DKIM. Prüfung für Prüfung ist alles grün.

Aus Sicht von DMARC ist alles rot. Das Protokoll fragt nicht „bestehen SPF oder DKIM?", sondern „besteht einer der beiden für eine Domain, die an der From-Domain ausgerichtet ist?". Eine Kampagne mit Absender newsletter@beispiel.de, signiert von mcsv.net, mit einem Envelope auf rsgsv.net, weist keinerlei Ausrichtung auf: Urteil fail, so sauber der Versand technisch auch sein mag. Das ist das häufigste Missverständnis rund um Versandplattformen: Authentifizierung ist durchaus vorhanden — aber sie authentifiziert die Plattform, nicht die Marke.

Seit den Anforderungen, die Gmail und Yahoo Massenversendern auferlegt haben — im Detail beschrieben in den Gmail- und Yahoo-Regeln für Versender —, hat die Plattform eine Schutzvorrichtung eingebaut, die die Lage verändert: Ist die From-Domain bei ihr nicht authentifiziert, schreibt sie die Absenderadresse um, auf eine Domain unter ihrer Kontrolle, etwa send.mailchimpapp.com. Die Kampagnen gehen weiter hinaus, die Zustellbarkeit bleibt erhalten … doch der Markenname verschwindet aus dem Absenderfeld. Die Nachricht kommt an, signiert von einer Domain, die dem Leser nichts sagt — genau das, was eine Authentifizierungspolitik verhindern soll.

Die Versanddomain authentifizieren: wenige CNAME-Einträge genügen

Die Korrektur spielt sich an zwei Orten ab: in der Oberfläche der Plattform, im Bereich für die Verwaltung der Versanddomains, und in der DNS-Zone der Domain. Die Plattform liefert CNAME-Einträge, die unter _domainkey zu veröffentlichen sind; sie delegieren die Publikation der DKIM-Schlüssel an ihre Infrastruktur:

k1._domainkey.beispiel.de.  CNAME  dkim.mcsv.net.
k2._domainkey.beispiel.de.  CNAME  dkim2.mcsv.net.
k3._domainkey.beispiel.de.  CNAME  dkim3.mcsv.net.

Je nach Alter des Kontos zeigt das Dashboard einen einzelnen k1-CNAME oder ein k2/k3-Paar: Maßgeblich sind die im Dashboard angezeigten Werte, nicht ein generisches Tutorial aus dem Netz. Sobald die Einträge veröffentlicht sind, die DNS-Propagation bestätigt und die Verifizierung auf Plattformseite bestanden ist, gehen die Kampagnen mit d=beispiel.de signiert hinaus: DKIM besteht und richtet sich an der From-Domain aus. DMARC-Urteil: pass. Es ist die einzige wirklich notwendige Änderung — und sie ist struktureller Natur, sie gilt für jede künftige Kampagne.

Der CNAME-Mechanismus hat einen unterschätzten Vorzug: Der öffentliche Schlüssel bleibt bei der Plattform gehostet, die ihn rotieren kann, ohne dass die DNS-Zone erneut angefasst werden muss. Die DKIM-Schlüsselrotation — empfohlene Hygiene, selten praktiziert, wenn der Schlüssel fest publiziert ist — geschieht automatisch. Die Kehrseite: In der Zone steht eine dauerhafte Delegation an einen Dritten — ein Punkt für das Inventar der Einträge, kein Risiko an sich.

Warum die SPF-Ausrichtung nie kommen wird — und warum das unproblematisch ist

Der Reflex nach dem Setzen der CNAMEs besteht oft darin, die Arbeit mit SPF „vervollständigen" zu wollen und das include der Plattform in den Eintrag der Domain aufzunehmen. Dieser Reflex beruht auf einer Verwechslung. SPF wird gegen die Domain des Envelope (den Return-Path) ausgewertet, nicht gegen die im From angezeigte Domain. Bei Mailchimp bleibt der Envelope aber auf den Servern der Plattform: So fließen die Fehlerrückläufer — ungültige Adressen, volle Postfächer — in ihre Listenverwaltung zurück. Eine Option, dort eine eigene Domain zu hinterlegen, existiert nicht.

Die Folge: SPF wird immer für die Domain der Plattform bestehen und sich nie an der From-Domain ausrichten. Das include im SPF der Domain ändert daran nichts — es verbrennt nur eine der zehn erlaubten DNS-Auflösungen für einen Mechanismus, der am Urteil nicht teilnehmen wird. Die Plattform selbst empfiehlt diesen Zusatz seit Langem nicht mehr.

Und es ist unproblematisch, weil DMARC nicht beide Mechanismen verlangt: Ein ausgerichtetes Ergebnis genügt für ein pass. Das über die CNAMEs erreichte, ausgerichtete DKIM deckt den gesamten Bedarf. Es bringt sogar einen Robustheitsvorteil mit: Eine DKIM-Signatur reist mit der Nachricht und überlebt die meisten automatischen Weiterleitungen, während SPF bricht, sobald ein Zwischenglied neu versendet. Für einen Marketingfluss, dessen Empfänger gern weiterleiten, ist die DKIM-Ausrichtung das richtige Pferd.

Was die RUA-Berichte zeigen, vorher und nachher

Die aggregierten Berichte erzählen diese Geschichte präzise. Vor der Authentifizierung zeigt jede Zeile, die den IP-Adressen der Plattform zugeordnet ist, dieselbe charakteristische Signatur:

<record>
  <row>
    <source_ip>205.201.131.xx</source_ip>
    <policy_evaluated><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <auth_results>
    <dkim><domain>mcsv.net</domain><result>pass</result></dkim>
    <spf><domain>mail01.rsgsv.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Die Nuance liegt im Kontrast: In auth_results besteht alles; in policy_evaluated scheitert alles. Das ist der typische Fingerabdruck eines Ausrichtungsproblems, nicht eines Authentifizierungsproblems — die nützlichste Diagnose, die ein RUA-Bericht liefern kann.

Nach dem Setzen der CNAMEs kippt derselbe Adressbereich: dkim=pass mit beispiel.de als signierender Domain, policy_evaluated grün, SPF weiterhin nicht ausgerichtet — folgenlos. Diesen Umschwung über einen vollständigen Kampagnenzyklus zu beobachten ist der Nachweis, der die Verschärfung der Policy erlaubt. Gesammelt werden müssen die Berichte allerdings erst: Ein Eintrag der Art v=DMARC1; p=none; rua=mailto:berichte@beispiel.de ist der Einstiegspunkt, und die kommentierten DMARC-Eintragsbeispiele liefern Vorlagen, die sich an den Reifegrad der Domain anpassen lassen.

Dasselbe Leseraster gilt für die anderen Plattformen im Bestand: Die Logik ist ähnlich bei SPF und DKIM bei Brevo, und der Fall SendGrid zeigt einen anders gesetzten Schieberegler zwischen anpassbarem Envelope und delegiertem DKIM. Jede Plattform trifft eigene Entscheidungen; die Frage bleibt dieselbe: Wer signiert, und für welche Domain?

Die dedizierte Subdomain: Reputation isolieren

Statt die Kampagnen über die Root-Domain laufen zu lassen, vertrauen viele Organisationen sie einer dedizierten Subdomain an: news.beispiel.de, info.beispiel.de. Die Authentifizierungs-CNAMEs werden dann auf dieser Subdomain gesetzt, und das From der Kampagnen zeigt sie an. Die Vorteile sind konkret. Die Versandreputation des Marketingflusses baut sich separat auf: Ein Kampagnenzwischenfall — eine Beschwerdespitze, eine schlecht gepflegte Liste — beschädigt nicht die Reputation der Root-Domain, an der transaktionale E-Mails und die individuelle Korrespondenz hängen. Auch das Quelleninventar gewinnt an Lesbarkeit: In den Berichten gehört alles, was von der Subdomain kommt, zu einem einzigen Fluss, was die Zuordnung vereinfacht.

Auf DMARC-Seite akzeptiert die gelockerte Ausrichtung — der Standardmodus —, dass ein From auf news.beispiel.de sich sowohl an einer Signatur d=news.beispiel.de ausrichtet als auch an einer der Organisationsdomain. DMARCbis, die aktuelle Revision des Standards, bestimmt diese Organisationsdomain über den DNS Tree Walk, das Hinaufsteigen im DNS-Baum, nicht mehr über die Public Suffix List. Die Revision bringt auch das Tag np mit, das das Schicksal nicht existierender Subdomains regelt: genug, um lohn.beispiel.de oder jede andere Phantom-Subdomain zu verriegeln, während news.beispiel.de seine legitimen Kampagnen ausrollt. Eine dedizierte Subdomain kann schließlich eine eigene Policy tragen, veröffentlicht unter _dmarc.news.beispiel.de, und in ihrem eigenen Tempo verschärfen.

p=reject ohne Authentifizierung: die doppelte Strafe

Bleibt das Worst-Case-Szenario: eine Domain, die auf p=reject wechselt, ohne ihre Plattform authentifiziert zu haben. Zwei Mechaniken greifen ineinander. Für Flüsse, in denen das From die Domain behält, werden nicht ausgerichtete Kampagnen von Empfängern, die die Policy durchsetzen, glatt abgewiesen — ganze Aussendungen verdampft, oft erst Wochen später entdeckt, bei der Suche danach, warum „der Newsletter nicht mehr rausgeht". Und für Flüsse, die in die From-Umschreibung laufen, ist die Strafe heimtückischer: Die Nachrichten gehen hinaus und kommen an, aber unter send.mailchimpapp.com — die Marke ist aus dem Absenderfeld verschwunden, die Wiedererkennung sinkt, und die Filter lernen eine Domain, die der Organisation nicht gehört.

Die strikte Policy bleibt das richtige Ziel; nicht verhandelbar ist die Reihenfolge: erst authentifizieren, dann die Ausrichtung in den Berichten feststellen, zuletzt verschärfen. DMARCbis liefert dafür ein sauberes Testwerkzeug, das Tag t=y, das den Empfängern signalisiert, dass eine Policy im Testmodus läuft — der erklärte Nachfolger des alten pct, das aus der aktuellen Revision verschwunden ist.

Fazit

Standardmäßig authentifiziert Mailchimp die eigenen Domains, nicht die der Marke: SPF und DKIM bestehen, nichts richtet sich aus, DMARC scheitert — und seit den Anforderungen der großen Anbieter wird das From auf eine Plattform-Domain umgeschrieben, sobald die Authentifizierung fehlt. Die Korrektur besteht aus wenigen CNAMEs unter _domainkey, die die Kampagnen im Namen der Domain signieren lassen: DKIM richtet sich aus, und das genügt, denn die SPF-Ausrichtung liegt bei diesem Anbieter strukturell außer Reichweite — der Envelope bleibt auf seinen Servern. Die RUA-Berichte liefern den Nachweis des Umschwungs, die dedizierte Subdomain isoliert die Marketingreputation, und die Verschärfung Richtung p=reject kommt nach dem Nachweis, nie davor.

Zur Standortbestimmung zeigt ein Durchlauf der Domain durch die kostenlose DMARC-Analyse in wenigen Sekunden, ob die Kampagnen bereits im Namen der Domain signieren oder noch im Namen der Plattform. Anschließend erlaubt ein neu angelegtes Konto, den Umschwung in den Berichten zu verfolgen, Kampagne für Kampagne, bis zu einer strikten Policy, die die Marke schützt, ohne einen einzigen Newsletter zu verlieren.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos