Salesforce: DKIM und DMARC-Ausrichtung der verschiedenen Clouds

Von Thomas · virtueller CISO · 10. September 2026

Salesforce ist nicht ein E-Mail-Absender, sondern mehrere. Die Sales Cloud und die Service Cloud versenden datensatzbezogene Nachrichten — Fall-E-Mails, Flow-Benachrichtigungen, Hinweise. Die Marketing Cloud (Engagement) verbreitet Kampagnen im großen Maßstab. Account Engagement (früher Pardot) betreut das B2B-Marketing. Jedes dieser Produkte versendet über eine eigene Infrastruktur, mit seiner eigenen Authentifizierungskonfiguration. Das ist die erste Tatsache, die zu verinnerlichen ist: Es gibt keine einzige „Salesforce"-DMARC-Einstellung, die alles abdecken würde.

Diese Vielheit erklärt die meisten beobachteten Fehlschläge. Eine Organisation konfiguriert sorgfältig DKIM für die Sales Cloud, stellt die Domain auf p=reject und entdeckt, dass ihre Marketing-Cloud-Kampagnen — bei der Standardauthentifizierung belassen — nun abgewiesen werden. Die Ursache ist kein DMARC-Mangel, sondern eine unvollständige Abdeckung: eine Cloud authentifiziert, die anderen vergessen.

Dieser Leitfaden behandelt die DKIM-Schlüsselverwaltung in Setup, die Notwendigkeit, jede Cloud getrennt zu authentifizieren, die DMARC-Ausrichtung, die auf DKIM ruht, das Gewicht des Salesforce-SPF-Includes auf dem Budget von zehn DNS-Abfragen, sowie die häufigen Fehler und den abschließenden Gegenbeweis über die RUA-Berichte.

Die DKIM-Schlüsselverwaltung in Setup

Für die Sales Cloud und die Service Cloud wird die DKIM-Authentifizierung aus Setup gesteuert, im Abschnitt „DKIM Keys". Salesforce erzeugt dort ein Schlüsselpaar: Der private Schlüssel bleibt bei Salesforce, und die Plattform zeigt die in der Zone der Domain zu veröffentlichenden Einträge an — zwei CNAMEs, die zwei Selektoren entsprechen, nach dem Delegationsmodell:

<selektor1>._domainkey.beispiel.de.  CNAME  <selektor1>.<schluessel>.dkim.sfdc.net.
<selektor2>._domainkey.beispiel.de.  CNAME  <selektor2>.<schluessel>.dkim.sfdc.net.

Zwei Selektoren werden von Anfang an bereitgestellt, um den Schlüsselwechsel ohne manuellen Eingriff zu erlauben. Sobald die CNAMEs propagiert sind, wird der Schlüssel in Setup aktiviert, und ausgehende Nachrichten der Sales/Service Cloud tragen eine Signatur d=beispiel.de — die Organisationsdomain selbst. Die DKIM-Ausrichtung ist dann für diese Cloud gesichert, auch im strikten Modus. Wichtiger Punkt: Der Schlüssel muss nach der Propagierung aktiviert werden; ein erzeugter, aber inaktiv gelassener Schlüssel signiert nichts.

Jede Cloud hat ihre eigene Authentifizierung

Das ist der Kern des Salesforce-Themas. Der in Setup konfigurierte DKIM-Schlüssel deckt die Sales Cloud und die Service Cloud ab, aber nicht die Marketing Cloud oder Account Engagement. Diese Produkte haben ihren eigenen Weg:

Die Marketing Cloud authentifiziert sich über das Sender Authentication Package (SAP), das eine dedizierte Versand-Subdomain einrichtet (etwa mkt.beispiel.de) mit eigenem SPF, eigener DKIM-Signatur und einer Markendomain für Links und Bilder. Es ist eine eigenständige Konfiguration, unabhängig vom DKIM-Schlüssel der Sales Cloud.

Account Engagement (Pardot) hat ebenfalls seine eigene DKIM-Konfiguration, in seiner dedizierten Oberfläche vorzunehmen, getrennt von Setup. Diese Trennung zu ignorieren, ist der teuerste Fehler: Eine Domain kann „konfiguriert" wirken, weil die Sales Cloud korrekt signiert, während die Marketing Cloud, nicht abgedeckt, an DMARC scheitert, sobald die Richtlinie sich verschärft. Die Regel lautet daher: alle Salesforce-Produkte inventarisieren, die unter der Domain versenden, und jedes authentifizieren, bevor die Richtlinie steigt.

Dieses Inventar ist nicht immer offensichtlich: Eine Cloud kann von einem Team aktiviert worden sein (das Marketing für die Marketing Cloud, der Support für die Service Cloud), ohne dass die für DNS zuständige Person davon weiß. Die aggregierten Berichte spielen hier eine doppelte Rolle — sie zeigen Quelle für Quelle, welche Salesforce-Systeme tatsächlich unter der Domain versenden, auch solche, die keine interne Dokumentation erwähnte. Von den Berichten statt von einer vermuteten Liste auszugehen, verhindert, eine aktive Cloud beim Verschärfen zu vergessen.

Die DMARC-Ausrichtung ruht auf DKIM

DMARC validiert eine Nachricht nur, wenn SPF oder DKIM besteht und sich an der From-Domain ausrichtet. Für jede korrekt konfigurierte Salesforce-Cloud trägt DKIM die Ausrichtung: Die Signatur d=beispiel.de (Sales/Service) oder die der SAP-Subdomain (Marketing Cloud) richtet sich an der From-Domain aus, im entspannten Modus für eine Subdomain, im strikten für die Domain selbst.

SPF ist heikler. Je nach Konfiguration der Bounce-Verwaltung kann der Umschlag der Salesforce-Nachrichten auf einer Plattformdomain bleiben, in welchem Fall SPF besteht, ohne sich auszurichten — und nicht zählt. Sich auf DKIM zu stützen, ist daher die verlässliche und empfohlene Wahl für Salesforce. Die kommentierten Vorlagen zeigen, wie die _dmarc-Anweisung gesetzt wird, sobald die Clouds authentifiziert sind. Unter DMARCbis wird die Referenz-Organisationsdomain über den DNS Tree Walk bestimmt, ohne Änderung an dieser Überlegung.

Ein DMARCbis-Detail ergibt sich aus dem Subdomain-Ansatz. Da die Marketing Cloud und manche Aufbauten von Subdomains aus versenden (mkt.beispiel.de), bestimmt der sp=-Tag — die auf Subdomains angewandte Richtlinie —, wie streng diese Sendungen behandelt werden, wenn ihnen ein eigener Eintrag fehlt. sp nicht zu setzen bedeutet, dass Subdomains die Haupt-p=-Richtlinie erben; es ausdrücklich zu setzen, erlaubt einer Organisation etwa, den Apex auf p=reject zu halten, während eine Subdomain ihren Rollout noch abschließt. Es ist ein Hebel, den man kennen sollte, wenn mehrere Clouds zu verschiedenen Zeiten in Betrieb gehen, und er vermeidet eine Alles-oder-nichts-Wahl während einer gestaffelten Migration.

Das Budget von zehn DNS-Abfragen bei SPF

Eine für Salesforce spezifische Falle verdient einen eigenen Abschnitt. Viele Anleitungen empfehlen, include:_spf.salesforce.com dem Root-SPF-Eintrag der Domain hinzuzufügen. Doch dieser Include ist schwer: Er verschachtelt weitere und verbraucht allein mehrere der zehn DNS-Abfragen, die SPF erlaubt, bevor es in einen permerror kippt. Kombiniert mit anderen Diensten (einer Office-Suite, einem ESP), überschreitet er rasch die Obergrenze — und ein permerror macht SPF für die gesamte Domain ungültig, einschließlich der Post, die sich ausrichtete.

Zwei praktische Folgen. Erstens richtet das Hinzufügen dieses Includes SPF dennoch nicht aus, wenn der Umschlag auf einer Salesforce-Domain bleibt: Man zahlt den Preis ohne den Nutzen. Zweitens ist der Salesforce-Include oft überflüssig, wenn SPF nicht der gewählte Ausrichtungsmechanismus ist (und das ist er hier nicht, zugunsten von DKIM). Das Limit von zehn DNS-Abfragen bei SPF zu beachten, ist in einer Salesforce-Umgebung umso nützlicher, als die Versuchung, Includes zu stapeln, dort groß ist.

Die Subdomain der Marketing Cloud

Das Sender Authentication Package der Marketing Cloud verdient ein Innehalten, denn es ist die vollständigste Konfiguration der Salesforce-Clouds. Das SAP stellt eine dedizierte Versand-Subdomain bereit — oft von der Form mkt.beispiel.de —, die zur Versanddomain der Kampagnen wird: SPF, DKIM-Signatur und die Domain der Link-Nachverfolgung sind alle an sie gebunden. Die Ausrichtung ist dort also doppelt, SPF und DKIM, im entspannten Modus gegenüber beispiel.de, was die Redundanz bringt, die bei Weiterleitung schützt.

Diese Vollständigkeit hat eine Kehrseite: Das SAP wird einmal konfiguriert, und seine dedizierte Subdomain muss der Marketing Cloud vorbehalten bleiben. Sie mit anderen Nutzungen zu vermischen oder die Subdomain zu ändern, ohne die Konfiguration zu wiederholen, bricht das Ganze. Für eine Organisation, die im großen Maßstab verbreitet, ist es dennoch die solideste Grundlage — und die lesbarste in den Berichten, wo die Subdomain als saubere, ausgerichtete Quelle erscheint, leicht vom Sales/Service-Verkehr zu unterscheiden.

E-Mail-Relais und Bounce-Verwaltung

Zwei Salesforce-Einstellungen berühren die Authentifizierung indirekt und sind wissenswert. Die erste, das E-Mail-Relais, leitet die Salesforce-Post vor der Zustellung über den SMTP-Server der Organisation: In dieser Anordnung verlässt die E-Mail die interne Infrastruktur, erbt deren SPF und Reputation, und die Ausrichtung wird dann wie bei jedem hauseigenen Server betrachtet — ein anderer Fall als der direkte Versand durch Salesforce. Die zweite, die Bounce-Verwaltung, bestimmt die Umschlagdomain der Nachrichten: Je nachdem, ob sie aktiviert ist, neigt der Return-Path zu einer Salesforce-Domain oder zu der der Organisation, was die SPF-Ausrichtung ändert.

Diese Einstellungen ersetzen DKIM nicht — das der verlässliche Ausrichtungsmechanismus bleibt —, aber sie erklären, warum zwei Organisationen unter Salesforce unterschiedliche SPF-Ergebnisse in ihren Berichten sehen können. Zu verstehen, welche in Kraft ist, erspart die Suche nach einem SPF-Ausrichtungsfehler dort, wo nur eine Bounce-Konfigurationswahl vorliegt.

Häufige Konfigurationsfehler

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Nur eine Cloud authentifizieren. Der häufigste: DKIM für die Sales Cloud gesetzt, Marketing Cloud oder Pardot vergessen — Letztere scheitern unter einer strikten Richtlinie an DMARC.

Den Schlüssel erzeugen, ohne ihn zu aktivieren. In Setup signiert ein erstellter, aber inaktiv gelassener DKIM-Schlüssel nichts; die Domain wirkt konfiguriert, die Nachrichten sind nicht signiert.

Den Salesforce-SPF-Include unnötig stapeln. Oben beschrieben: Kosten in Abfragen, Risiko des permerror, ohne Ausrichtungsnutzen, wenn DKIM ausrichtet.

Verschärfen, bevor alles abgedeckt ist. Der Wechsel zu p=reject in dem Glauben, Salesforce sei authentifiziert, während eine Cloud noch ohne ausgerichtete Signatur versendet, bedeutet, einen Teil des eigenen Geschäftsverkehrs abzuweisen.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht der Setup-Bildschirm, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte ist hier besonders wertvoll, denn es zeigt jede Salesforce-Cloud als eigene Quelle: Man sieht auf einen Blick, ob Sales Cloud, Marketing Cloud und Account Engagement sich alle ausrichten oder ob eine noch scheitert.

Eine einfache Kadenz genügt: eine erste Durchsicht wenige Tage nach der Konfiguration, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Es ist die Bestätigung, dass alle sendenden Clouds sich ausrichten, die das Verschärfen erlaubt — eine einzige nicht ausgerichtete Cloud ist Grund genug zu warten. Sobald diese vollständige Abdeckung über mehrere Tage beobachtet ist, erfolgt der Wechsel zu p=reject ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der zu p=reject führt.