Pardot-E-Mails (Account Engagement) landen im Spam? So behebst du es

Marketing Cloud Account Engagement, in weiten Teilen der App weiterhin als Pardot beschriftet, ist ein anderes Produkt als Marketing Cloud Engagement und authentifiziert auf völlig andere Weise. Es verifiziert deine Versanddomain mit einem Validierungsschlüssel, der nur den Besitz nachweist und sonst nichts, behandelt DKIM als optional und leitet jeden Bounce über einen Salesforce-Host wie bounce.s7.exacttarget.com, sodass SPF nicht zu deiner Absenderadresse ausgerichtet ist, solange du keinen eigenen Return-Path beantragst. Dieser Guide behandelt den DomainKey-Record auf 200608._domainkey, den CNAME der Tracker-Domain, der jeden Link in deiner E-Mail umschreibt, den eigenen Return-Path, für den du einen Case eröffnen musst, und wie du einen echten Account-Engagement-Versand mit Unspam prüfst.

Kostenlosen Spam-Test starten So testest du deine Mailings

Warum Marketing Cloud Account Engagement-E-Mails im Spam landen.

Account Engagement hat DKIM nie verlangt, deshalb hat die Mehrzahl der Accounts keinen ausgerichteten Identifier

Salesforce verifiziert eine Versanddomain über einen TXT-Record mit Validierungsschlüssel, und dieser Schlüssel allein reicht zum Senden: Die Hilfe-Dokumentation hält fest, dass Account Engagement derzeit keinen verifizierten DKIM-Record auf der E-Mail-Versanddomain verlangt und einen solchen nur nachdrücklich empfiehlt. DKIM ist der einzige Identifier, der sich ab Werk an deiner Absenderadresse ausrichtet, denn der Return-Path bleibt auf einem Salesforce-Host, solange du keinen Support-Case für einen eigenen Return-Path eröffnest. Ohne den auf 200608._domainkey.deinedomain.de veröffentlichten DomainKey-TXT-Record hat eine DMARC-Auswertung nichts Ausgerichtetes, worauf sie bestehen könnte, und eine p=quarantine- oder p=reject-Policy auf deiner eigenen Domain filtert dann deine eigenen Kampagnen weg. Domain Management zeigt die Domain so oder so als verifiziert an, und genau deshalb sind so viele verifizierte Domains vollständig unauthentifiziert.

SPF besteht für Salesforce, nie für dich

Salesforce dokumentiert, dass Account-Engagement-E-Mails SPF automatisch bestehen, weil Salesforce die Versandinfrastruktur kontrolliert, und dass auf deiner Seite keine spezielle SPF-Konfiguration nötig ist. Der empfangende Server prüft den Return-Path, den Salesforce als Host wie bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com oder bounce.j.s11.pdmailservice.com dokumentiert, das Bestehen wird also gegen eine Salesforce-Domain protokolliert und das SPF-Alignment scheitert bei jedem Versand. Einen Salesforce-Include in deinen Root-SPF-Record aufzunehmen ändert daran nichts. Der einzige Weg, den Return-Path auszurichten, ist ein eigener Return-Path, den Salesforce über einen Support-Case bereitstellt und über keinen Bildschirm im Produkt.

Jeder Link in der E-Mail zeigt weiterhin auf pardot.com

Account Engagement schreibt Links und Vanity-URLs über die Tracker-Domain um, und wenn auf einem Asset keine Tracker-Domain ausgewählt ist, fällt es auf die primäre Tracker-Domain des Accounts zurück. Ein Account, der nie einen eigenen CNAME validiert hat, liefert all das über die Standarddomain go.pardot.com aus, eine Nachricht mit deiner Marke in der Absenderzeile trägt also Links auf einer Domain, der die empfangende Person keinerlei Grund hat zu vertrauen. Salesforce empfiehlt, eine eigene Domain hinzuzufügen und sämtliche Account-Engagement-Inhalte darüber auszuliefern. Sobald du deine eigene Tracker-Domain validierst und Set as Primary nutzt, schreibt Account Engagement die URLs auf deinen Assets darauf um.

Die Absenderhierarchie sendet von Domains, die du nie eingerichtet hast

In Account Engagement entscheidet die E-Mail-Adresse der absendenden Person, welche Versanddomain genutzt wird, eine Kampagne mit Assigned User, Account Owner oder einem CRM-Benutzerfeld geht also von der jeweils eigenen Adresse der Vertriebsperson raus. Zum Versandzeitpunkt läuft Salesforce die Absenderhierarchie von oben durch und nimmt die erste Adresse, deren Domain verifiziert ist, und ist keine der Absenderadressen in der Hierarchie gültig, schlägt der Versand komplett fehl. Eine einzige Kampagne kann also unter mehreren Absenderdomains rausgehen, von denen nur einige einen DomainKey-Record tragen, was deine Reputation aufsplittet und den unsignierten Teil in den Spam kippt. Jede Domain, von der deine Nutzer senden, braucht ihren eigenen Eintrag im Domain Management mit beiden veröffentlichten Records.

Du beurteilst die Zustellbarkeit anhand von Testproofs, die keine echten E-Mails sind

Salesforce dokumentiert, dass die einmalige Option Send to Individual Emails keine mehrteilige MIME-Nachricht erzeugt: Die HTML- und die Nur-Text-Version gehen als zwei getrennte Nachrichten raus, und viele Mailsysteme werten das als verdächtig. Derselbe Artikel warnt, dass wiederholte einzelne Testsendungen zu Greylisting des Absenders führen können, nennt dabei ausdrücklich Microsoft und Verzögerungen von mehreren Stunden, und stellt klar, dass E-Mail-Testproofs nicht als Maßstab für Zustellbarkeit dienen sollten. Wenn dein einziger Beleg ein Proof an deine eigene Arbeitsadresse ist, misst du ein Artefakt des Testwerkzeugs. Eine Firmenadresse auf beiden Seiten fügt einen zweiten Fehler hinzu, denn der Filter stuft Mail zwischen zwei Adressen deiner Domain als intern ein und sieht sie dann von einem externen Server ankommen.

Du hast Marketing-Cloud-Engagement-Anleitungen auf einen Pardot-Account angewendet

Marketing Cloud Engagement und Marketing Cloud Account Engagement sind getrennte Produkte mit getrennten Authentifizierungswegen, und die Namen liegen nah genug beieinander, dass Teams monatelang dem falschen Runbook folgen. In Account Engagement gibt es kein Sender Authentication Package, keine Private Domain und kein Reply Mail Management. Die Authentifizierung liegt in den Account Engagement Settings und dann im Domain Management: ein Validierungsschlüssel, ein DomainKey-Record und ein CNAME der Tracker-Domain auf go.pardot.com. SAP für eine Marketing-Cloud-Engagement-Org zu kaufen bringt der Mail, die deine Account-Engagement-Business-Unit versendet, gar nichts, prüfe also, welches Produkt die Nachricht tatsächlich verschickt hat, bevor du ein Quartal in die Konfiguration des anderen steckst.

So authentifiziert Marketing Cloud Account Engagement deine E-Mails.

Account Engagement hält vier DNS-Tatsachen auseinander, die die meisten Teams als eine behandeln. Der Validierungsschlüssel weist nach, dass dir die Domain gehört, und ist der einzige Record, der zum Senden nötig ist. Der DomainKey-Record ist das, was deine Mail tatsächlich signiert. SPF gehört Salesforce, nicht dir. DMARC gehört allein dir, denn Salesforce erklärt, dass Account Engagement keine DMARC-Authentifizierung liefern kann und der Support bei der Einrichtung nicht helfen darf. Nur zwei der vier kommen aus dem Produkt: Account Engagement Settings, dann Domain Management, dann der Link Expected DNS Entries neben der Domain, der den Validierungsschlüssel und den DomainKey enthält. Salesforce liefert überhaupt keinen SPF- und keinen DMARC-Wert. Unabhängig davon ist die Tracker-Domain ein CNAME auf go.pardot.com und darf niemals dieselbe Domain sein wie deine E-Mail-Versanddomain. Prüfe jeden Record vor und nach der Änderung mit den SPF-, DKIM- und DMARC-Checkern von Unspam.

Eintrag	Standard	das Problem	die Lösung
Validation key (TXT)	Es wird nichts veröffentlicht, bis du die Domain hinzufügst. Seit dem 1. Juli 2023 muss eine Domain per Validierungsschlüssel verifiziert sein, bevor Account Engagement von ihr sendet. Domains, die nach der älteren Methode bereits über DKIM verifiziert waren, behielten ihren Status ohne den neuen Schlüssel.	Eine verifizierte Domain ist keine authentifizierte Domain. Der Status verifiziert im Domain Management bedeutet nur, dass du den Besitz nachgewiesen hast, und Teams hören dort auf, in dem Glauben, die Authentifizierung sei fertig. Lass den TXT-Record veröffentlicht, denn an ihm prüft Account Engagement den Besitz der Domain.	Öffne in den Account Engagement Settings das Domain Management, klick auf Add New Domain, dann in der Spalte Actions auf Expected DNS Entries und kopiere den Validierungsschlüssel. Veröffentliche ihn als TXT-Record auf dieser Domain oder einer übergeordneten und klick zum Prüfen auf Check DNS Entries. Lass den Record dauerhaft stehen.
DKIM (DomainKey)	Aus, bis du ihn veröffentlichst. Salesforce erklärt, dass Account Engagement derzeit keinen verifizierten DKIM-Record verlangt, um von einer E-Mail-Versanddomain zu senden, und ihn nur nachdrücklich empfiehlt. Der Schlüssel, den Account Engagement ausgibt, hat standardmäßig 1024 Bit.	DKIM ist der einzige Identifier, den Account Engagement an deiner Absenderdomain ausrichten kann, ohne ihn hat eine DMARC-Auswertung also nichts, worauf sie bestehen könnte, und die Erwartungen von Gmail und Yahoo an Bulk-Absender bleiben unerfüllt. Der Fehler ist im Produkt unsichtbar, weil das Domain Management die Domain mit und ohne DomainKey als verifiziert meldet.	Öffne im Domain Management Expected DNS Entries für die Domain, kopiere den DomainKey-Wert und veröffentliche ihn als TXT-Record auf 200608._domainkey.deinedomain.de. Bei Anbietern, die die Zone an das Eingegebene anhängen, GoDaddy zum Beispiel, trag nur den Host-Teil ein, sonst propagiert der Record mit doppelter Domain. Rechne mit bis zu 24 Stunden, bis die Signatur greift, und bestätige danach den d=-Wert an einem echten Versand mit dem DKIM-Checker von Unspam.
SPF	Von Salesforce konfiguriert, nicht von dir. Die Dokumentation sagt, dass Account-Engagement-E-Mails SPF automatisch bestehen und auf deiner Seite keine spezielle SPF-Konfiguration nötig ist, und das Domain Management spiegelt dieses Bestehen wider.	Das Bestehen wird gegen den Return-Path protokolliert, den Salesforce je nach Account als bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com oder bounce.j.s11.pdmailservice.com dokumentiert. Keiner davon ist deine Domain, das SPF-Alignment scheitert also bei jedem Account-Engagement-Versand und DMARC kann sich nicht darauf stützen.	Halte deinen eigenen SPF-Record für deine anderen Absender gültig und bestätige ihn mit dem SPF-Checker von Unspam, erwarte aber nicht, dass er Account Engagement hilft. Für das Alignment eröffnest du einen Account-Engagement-Support-Case und beantragst einen eigenen Return-Path. Salesforce liefert die DNS-Records und überlässt dir die Veröffentlichung, und es kann pro Business Unit nur eine eigene Return-Path-Domain geben, ohne Variation je Versand.
DMARC	Nicht vorhanden, solange du es nicht veröffentlichst. Salesforce sagt ausdrücklich, dass Account Engagement keine DMARC-Authentifizierung liefern kann, dass die Konfiguration außerhalb des Produkts liegt und dass der Support bei der Einrichtung nicht unterstützen kann.	Mit veröffentlichtem DomainKey besteht DMARC allein über das DKIM-Alignment, und genau das meint Salesforce mit der Aussage, DMARC funktioniere mit Account Engagement ab Werk. Ohne ihn richtet sich kein Identifier aus, und eine p=quarantine- oder p=reject-Policy auf deiner eigenen Domain stellt deine eigenen Kampagnen unter Quarantäne. Account Engagement erfasst DMARC-Fehler auch nicht und meldet sie nicht, in der App wird es dir also nichts sagen.	Veröffentliche v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.de auf _dmarc.deinedomain.de, bestätige an einem echten Versand, dass DKIM sich an deiner Absenderdomain ausrichtet, und zieh dann auf quarantine und später reject an, sobald deine Reports sauber sind. Salesforce empfiehlt, für das DMARC-Reporting mit einem externen Anbieter zusammenzuarbeiten, weil es selbst keines erfasst. Prüfe den veröffentlichten Record mit dem DMARC-Checker von Unspam.

Wenn du diese Einträge aktualisiert hast, prüfe mit den kostenlosen Tools von Unspam, ob alles passt: SPF-Check, DKIM-Check und DMARC-Check.

So testest du eine Marketing Cloud Account Engagement-Kampagne mit Unspam.

Account Engagement hat zwei eingebaute Tests und keiner davon misst die Platzierung. Der Reiter Testing im klassischen Builder führt Litmus-Rendering-Vorschauen und eine Spam-Analyse aus, und Salesforce sagt, die Ergebnisse garantieren nicht, ob eine E-Mail im Spam-Ordner landet. Der Testversand im Lightning-Builder entfernt die Daten der Merge Fields und ersetzt, falls die Domain der angemeldeten Person nicht verifiziert ist, deine Absenderadresse durch test@ plus deiner ersten verifizierten Versanddomain. Unspam verbindet sich weder mit der Account-Engagement-API noch mit irgendeinem anderen Plattform-Account, der ehrliche Test ist also eine echte Listen-E-Mail an eine Seed-Adresse über deine normale Versanddomain und Tracker-Domain.

01
Hol dir deine Unspam-Seed-Adresse und die Test ID

Starte in Unspam einen kostenlosen Spam-Test oder einen Inbox-Placement-Test und kopiere die erzeugte Seed-Adresse. Ein Placement-Test stellt an Seed-Postfächer bei Gmail, Outlook, Yahoo, Zoho, ProtonMail, AOL, GMX und Amazon WorkMail zu, damit du siehst, wo jede Kopie gelandet ist. Er vergibt außerdem eine Test ID, und die musst du vor dem Versand in die Betreffzeile oder in den Text einfügen. Lässt du sie weg, erreicht die Nachricht die Seed-Postfächer trotzdem, wird deinem Test aber nie zugeordnet.
02
Füge den Seed als Prospect auf einer normalen Liste hinzu

Greif nicht zu einer Email Test List. Account Engagement baut diese aus deinen eigenen Nutzern auf und legt für jeden einen Test-Prospect an, bis zu 100 Empfänger, eine externe Seed-Adresse kann also nicht darauf. Leg den Seed stattdessen als Prospect an und füge ihn einer Segmentierungsliste mit einem Namen wie Deliverability Seed hinzu, damit die Nachricht exakt den Weg nimmt, den eine Kampagne nimmt.
03
Verschick sie als echte Listen-E-Mail, nicht als Testproof

Schick die tatsächliche E-Mail über Account Engagement Email an diese Liste, mit deinem Produktionsabsender und derselben Tracker-Domain, die deine Kampagnen nutzen. Vermeide die Option Send to Individual Emails im Reiter Testing: Salesforce dokumentiert, dass sie HTML und Nur-Text in zwei getrennte Nachrichten aufteilt statt in eine mehrteilige MIME-Nachricht, und sagt, E-Mail-Testproofs sollten nicht als Maßstab für Zustellbarkeit dienen.
04
Prüfe, was Account Engagement tatsächlich verlassen hat

Bestätige in Unspam, dass der d=-Wert von DKIM deine Versanddomain ist und kein Salesforce-Host, dass der Return-Path dem entspricht, was du erwartest (ein Host im Stil von bounce.s7.exacttarget.com, sofern du keinen eigenen Return-Path hast), und dass jeder Link auf deiner Tracker-Domain auflöst statt auf pardot.com. Das ist der erste Punkt im Ablauf, an dem du dieselben Header siehst wie ein Mailbox-Provider.
05
Lies die Ergebnisse und behebe sie vor der nächsten Kampagne

Sieh dir den Spam-Score an, die am echten Versand gemessenen SPF-, DKIM- und DMARC-Urteile, die Blocklist- und HTML-Prüfungen, die Platzierung je Anbieter in Posteingang, Werbung, Spam oder Fehlend, die Client-Vorschauen inklusive Dark Mode und die KI-Eyetracking-Heatmap. Ändere eine Sache, sende erneut, und du kannst den Unterschied zuordnen, statt zu raten.

Derselbe Test rendert deine Kampagne in über 50 echten E-Mail-Clients, darunter Gmail, Outlook, Apple Mail, iPhone und Android, jeweils im hellen und im dunklen Modus, über Client-Vorschauen, damit du Platzierung und Darstellung in einem Durchgang prüfst.

Marketing Cloud Account Engagement-Funktionen, die still und leise die Zustellung beeinflussen.

Verifiziert heißt nicht authentifiziert

Das Domain Management markiert eine Domain als verifiziert, sobald der TXT-Record mit dem Validierungsschlüssel auflöst, und das ist der einzige Record, den Account Engagement zum Senden braucht. DKIM sitzt auf demselben Bildschirm Expected DNS Entries und ist bloß empfohlen. Accounts laufen jahrelang in diesem Zustand, verifiziert und ohne eine einzige Nachricht je mit der eigenen Domain zu signieren. Öffne Expected DNS Entries und such gezielt nach der DomainKey-Zeile, statt dem Label verifiziert zu trauen.

Einzelne Testsendungen sind kein mehrteiliges MIME

Salesforce dokumentiert, dass die Option Send to Individual Emails HTML und Nur-Text als zwei getrennte Nachrichten zustellt statt als eine mehrteilige MIME-Nachricht, dass viele Mailsysteme das als verdächtig werten und dass wiederholter Einsatz zu Greylisting des Absenders führen kann, mit ausdrücklicher Nennung von Microsoft und Verzögerungen über Stunden. Wenn dein Zustellbarkeitsbeleg aus diesem Button stammt, ist er ein Beleg über den Button. Salesforce empfiehlt stattdessen Testlisten, und ein echter Versand an einen externen Seed schlägt beides.

Tracker-Domain und E-Mail-Versanddomain müssen verschieden sein

Salesforce erklärt, dass dieselbe Domain für beide Funktionen zu nutzen wahrscheinlich zu Authentifizierungsfehlern und Zustellproblemen führt. Ist go.firma.de deine Tracker-Domain, kann sie nicht zugleich deine E-Mail-Versanddomain sein. Tracker-Domains müssen außerdem über Business Units hinweg eindeutig sein, eine zweite Business Unit braucht also etwas wie go2.firma.de statt eines Duplikats der ersten.

Die Geschichte zum 2048-Bit-DKIM-Schlüssel ist widersprüchlich

Account Engagement gibt standardmäßig einen DomainKey mit 1024 Bit aus. Die Anleitung zur DNS-Konfiguration sagt, du könntest per Support-Case einen 2048-Bit-Schlüssel anfordern, und nennt eine dedizierte Versand-IP davor sehr empfehlenswert. Salesforce beschreibt das Ergebnis danach auf zwei verschiedene Arten. Ein Artikel sagt, ein 2048-Bit-Schlüssel erzeuge in der Tabelle Email Sending Domain eine Warnung Custom DKIM Entry und weitere Schritte seien nicht nötig, solange deine DNS-Einträge stehen bleiben. Ein anderer sagt, wer einen 2048-Bit-Schlüssel nutzt, werde seine E-Mail-Versanddomain in Account Engagement gar nicht als DKIM-verifiziert sehen, obwohl der Record im DNS vorhanden ist. Behandle das Verifiziert-Flag in der App bei 2048 Bit als unzuverlässig und bestätige die Signatur stattdessen an einem echten Versand.

Worauf Marketing Cloud Account Engagement-Absender in der Praxis stoßen.

Die häufigsten Probleme mit der Zustellbarkeit bei Marketing Cloud Account Engagement-Absendern, jeweils mit der passenden Lösung.

Unsere Test-E-Mails landen immer wieder im Junk, aber der Salesforce-Support sagt, mit dem Account sei alles in Ordnung

Hast du mit Send to Individual Emails aus dem Reiter Testing getestet, dann sagt Salesforces eigene Dokumentation, dass diese Proofs keine mehrteiligen MIME-Nachrichten sind: HTML und Nur-Text gehen als zwei getrennte Nachrichten raus, und viele Mailsysteme werten das als verdächtig. Eine Firmenadresse auf beiden Seiten stapelt einen zweiten Fehler obendrauf, denn der Filter stuft Mail zwischen zwei Adressen deiner Domain als intern ein und sieht sie dann von einem Drittanbieter-Server außerhalb deines Netzes ankommen. Salesforce stellt unmissverständlich fest, dass E-Mail-Testproofs nicht als Maßstab für Zustellbarkeit dienen sollten.

Die Lösung Hör auf, mit Einzelproofs zu testen. Lass die IT eure Account-Engagement-Versand-IP auf die Allowlist setzen, die du in den Account Engagement Settings unter Account Information im Feld Sending IPs findest, damit interne Tests die Internes-Netz-Regel nicht mehr auslösen. Miss die Platzierung dann mit einer echten Listen-E-Mail an eine externe Seed-Adresse statt an eine Kollegin auf deiner eigenen Domain, und lies die Header dieses Versands. Bedenke, dass eine Serie von Einzelproofs zu Greylisting führen kann, besonders bei Microsoft, was den nächsten echten Versand schlechter aussehen lässt, als er ist.

Der Newsletter erreicht den Posteingang, aber alles, was aus dem Vertrieb kommt, geht direkt in den Spam

Kampagnen mit Assigned User, Account Owner oder einem CRM-Benutzer-Custom-Field nehmen die Absenderadresse aus dem Benutzerdatensatz, die Versanddomain wechselt also von Prospect zu Prospect. Salesforce wertet die Absenderhierarchie zum Versandzeitpunkt von oben aus und nimmt die erste Adresse, deren Domain verifiziert ist, eine nicht verifizierte Vertriebsdomain fällt also stillschweigend auf den nächsten Eintrag durch, und ist in der Hierarchie nichts gültig, schlägt der Versand fehl. Domains, die du nie im Domain Management hinzugefügt hast, haben keinen DomainKey-Record, diese Nachrichten gehen also unsigniert raus, während deine Marketing-Domain signiert ist.

Die Lösung Liste jede Domain auf, von der deine Nutzer senden, und füge jede in den Account Engagement Settings unter Domain Management mit veröffentlichtem Validierungsschlüssel und DomainKey-Record hinzu. Wo Vertriebsleute auf einer Domain sitzen, die du nicht authentifizieren kannst, setz als letzten Eintrag der Absenderhierarchie einen General User oder Specific User auf einer verifizierten Domain und leg die persönliche Note in die Antwortadresse statt in den Absender. Sende danach von jeder Domain an eine Seed-Adresse und bestätige, dass der d=-Wert von DKIM passt, bevor du dich darauf verlässt.

Ich habe den DomainKey vor einer Woche hinzugefügt und Account Engagement zeigt DKIM immer noch nicht als verifiziert

Der DomainKey-Record muss auf 200608._domainkey.deinedomain.de liegen, und DNS-Anbieter, die die Zone an das Eingegebene anhängen, machen daraus einen doppelten Hostnamen, der nirgends auflöst. Salesforce nennt GoDaddy für dieses Verhalten namentlich. Die Signatur beginnt außerdem nicht in dem Moment, in dem der Record auflöst: Die Dokumentation bittet um bis zu 24 Stunden, nachdem der Record steht. Und hat jemand einen 2048-Bit-Schlüssel angefordert, warnt Salesforce, dass die Domain in der App überhaupt nicht als DKIM-verifiziert erscheint, selbst mit korrektem Record im DNS.

Die Lösung Frag den Record direkt ab, statt der App zu trauen: Schlag 200608._domainkey.deinedomain.de nach und prüfe, dass du genau einen TXT-Record zurückbekommst, der dem Wert aus Expected DNS Entries entspricht, ohne doppelte Domain und ohne Dubletten. Hängt dein Anbieter die Zone an, trag nur den Host-Teil ein. Gib der Signatur volle 24 Stunden, sende dann an eine Seed-Adresse und lies den d=-Wert der zugestellten Nachricht, denn das ist die einzige Prüfung, die abbildet, was Mailbox-Provider sehen.

Unsere eigene IT hat die Kampagne als Phishing gemeldet, weil jeder Link auf pardot.com ging

Account Engagement schreibt Links und Vanity-URLs über die Tracker-Domain um, und wenn auf dem Asset keine Tracker-Domain gewählt ist, nimmt es die primäre Tracker-Domain des Accounts. Ein Account, der nie einen eigenen CNAME validiert hat, liefert all das über die Standarddomain go.pardot.com aus, in der Absenderzeile steht also deine Marke und in jedem href etwas anderes, und genau auf dieses Muster ist ein Phishing-Filter trainiert. Salesforce empfiehlt, eine eigene Domain hinzuzufügen und sämtliche Account-Engagement-Inhalte darüber auszuliefern.

Die Lösung Füge im Domain Management eine Tracker-Domain hinzu, richte den CNAME für die Produktion auf go.pardot.com oder für eine Sandbox auf go.demo.pardot.com, veröffentliche den Validierungsschlüssel als TXT-Record auf deiner Root-Domain oder lade die Validierungsdatei pardot_XXXXXX.txt in dein Web-Root, validiere sie dann und wähle Set as Primary. Das schreibt die URLs auf deinen Account-Engagement-Assets auf die neue Domain um. Nimm eine Subdomain, die nicht deine E-Mail-Versanddomain ist, denn Salesforce warnt, dass eine Domain für beides Authentifizierungsfehler verursacht, und bestätige an einem Seed-Versand, dass kein pardot.com-Link überlebt.

Ein Teil unserer Liste bekam still und leise keine E-Mails mehr und niemand hatte sich abgemeldet

Account Engagement markiert einen Prospect nach einem einzigen Hard Bounce oder nach fünf Soft Bounces als Undeliverable und unterdrückt ihn danach bei jedem Versand. Die Falle steckt in Salesforces eigener Definition eines Hard Bounce: Manche Mailserver quittieren eine Adresse mit einem Hard Bounce, wenn die Nachricht als Spam verdächtigt wird. Eine Phase mit kaputter Authentifizierung schiebt dich also nicht nur in den Spam-Ordner, sie verwandelt gefilterte Empfänger in dauerhaft unterdrückte Prospects, und die Liste schrumpft noch lange weiter, nachdem die eigentliche Ursache behoben ist.

Die Lösung Behebe zuerst die Authentifizierung und arbeite dich dann rückwärts durch die Bounce-Datensätze: Account Engagement lässt dich den Hard- oder Soft-Bounce-Zähler auf einem Prospect-Datensatz zurücksetzen, sobald die Ursache beseitigt ist. Leg die Bounce-Spitze über die Daten, an denen du DNS oder Absendereinstellungen geändert hast, um eine wirklich schlechte Adresse von einer gefilterten zu trennen. Halte künftig die Bounce-Rate deutlich unter den 10 % pro Versand, vor denen Salesforce als Gefahr für die Zustellbarkeit warnt, sowie die Beschwerderate unter den 0,3 %, die Gmail durchsetzt, und bau das Volumen schrittweise wieder auf, wenn du den Versand länger als eine Woche pausiert hast.

Zustellbarkeit bei Marketing Cloud Account Engagement, kurz beantwortet.

Ist Marketing Cloud Account Engagement dasselbe wie Marketing Cloud Engagement?

Nein. Es sind getrennte Produkte mit getrennten Authentifizierungswegen, und das ist der mit Abstand häufigste Grund, warum ein Pardot-Fix ins Leere läuft. Account Engagement ist das Produkt, das früher Pardot hieß, und Salesforce zeigt den alten Namen in Teilen der App weiterhin an. Seine Authentifizierung liegt in den Account Engagement Settings und dann im Domain Management: ein Validierungsschlüssel, ein DomainKey-TXT-Record und ein CNAME der Tracker-Domain auf go.pardot.com. Marketing Cloud Engagement nutzt das Sender Authentication Package und Private Domain, und beides gibt es hier nicht.

Muss ich Salesforce für Account Engagement in meinen SPF-Record aufnehmen?

Nein. Salesforce dokumentiert, dass Account-Engagement-Mail SPF automatisch besteht, weil Salesforce die Versandinfrastruktur kontrolliert, und dass auf deiner Seite keine spezielle SPF-Konfiguration nötig ist. Ein Include würde auch nicht helfen, weil die Prüfung gegen den Salesforce-Return-Path läuft und nicht gegen deine Absenderdomain. Halte deinen eigenen SPF-Record für deine anderen Absender korrekt und verlass dich für das DMARC-Alignment auf DKIM.

Warum sieht meine Account-Engagement-Mail aus, als käme sie von einer Salesforce-Domain?

Der Return-Path bei Account-Engagement-Sendungen ist ein Salesforce-Host. Salesforce dokumentiert Beispiele wie bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com und bounce.j.s11.pdmailservice.com und sagt, dass sich die Return-Path-Angabe nicht entfernen lässt. Gmail zeigt die Abweichung als via-Zeile. Den DomainKey-Record zu veröffentlichen sorgt dafür, dass DKIM mit deiner eigenen Domain signiert, und genau das braucht DMARC und genau das räumt die via-Zeile meist ab, und ein über den Support beantragter eigener Return-Path richtet den Envelope selbst aus.

Wie bekomme ich SPF-Alignment bei Account Engagement?

Eröffne einen Account-Engagement-Support-Case und bitte um einen eigenen Return-Path. Salesforce arbeitet mit seinem Zustellbarkeitsteam zusammen, gibt dir die zu veröffentlichenden DNS-Records und konfiguriert dein DNS nicht für dich. Es kann pro Business Unit nur eine eigene Return-Path-Domain geben, und sie ist nicht je Versand variabel. Salesforce sagt klar, dass dies SPF-Domain-Alignment ergänzt, um eine bestehende DMARC-Policy zu stärken, und DKIM nicht ersetzt, veröffentliche also zuerst den DomainKey.

Sagt mir die Spam-Analyse im Reiter Testing, ob ich in den Posteingang komme?

Nein, und Salesforce sagt das auch. Die Rendering-Tests und die Spam-Analyse im Reiter Testing des klassischen Builders laufen über Litmus, und Salesforce erklärt, dass die Ergebnisse nicht garantieren, ob E-Mails im Spam-Ordner landen, weil eine Inhaltsprüfung die Absenderreputation nicht sehen kann. Die Funktion kommt mit dem Paket Advanced Email Analytics, in den Editionen Plus, Advanced und Premium und gegen Aufpreis bei Growth, und jedes Rendering wird 90 Tage gespeichert. Nutz sie für Rendering und Inhalt und miss die Platzierung mit einem echten Versand.

Kann Unspam sich mit meinem Account-Engagement-Account verbinden und Sendungen automatisch testen?

Nein. Unspam integriert sich weder mit der Account-Engagement-API noch mit irgendeiner anderen Plattform-API und verbindet sich nie mit deinem Account. Die zwei Berührungspunkte sind eine Seed-Adresse, an die du sendest, und für automatisierte Tests SMTP-Zugangsdaten, die du selbst hinterlegst. Für Account Engagement heißt das, den Seed als Prospect anzulegen und eine echte Listen-E-Mail zu fahren, denn nur so siehst du die Header, die umgeschriebenen Tracker-Domain-Links und die Platzierung, die deine Prospects wirklich bekommen.

Die Angaben zur Plattform Marketing Cloud Account Engagement wurden anhand öffentlich zugänglicher Dokumentation geprüft (Stand: August 2026) und können sich seitdem geändert haben. Marketing Cloud Account Engagement ist eine Marke des jeweiligen Inhabers. Unspam ist weder mit Marketing Cloud Account Engagement verbunden noch wird Unspam von Marketing Cloud Account Engagement unterstützt.

Teste deine nächste Marketing Cloud Account Engagement-Kampagne, bevor deine Abonnenten es tun.

Kostenlosen Spam-Test starten Inbox-Placement-Test