Verhindere, dass Salesforce Marketing Cloud E-Mails im Spam landen

Wenn Sendungen aus Marketing Cloud Engagement im Spam landen, liegt es fast immer daran, wie die Authentifizierung eingerichtet ist, nicht an deiner Betreffzeile. Ohne das Sender Authentication Package bleiben deine Bounce- und Link-Wrapping-Domains auf Salesforce-eigenen Hosts wie exacttarget.com und mc.pd25.com, SPF richtet sich also nie aus und DKIM signiert die falsche Domain. Dieser Leitfaden behandelt den Unterschied zwischen SAP und Private Domain, die Ausrichtungsfalle der Standarddomain, das Warm-up der dedizierten IP, multi-bounce domain und Reply Mail Management, dazu, wie du einen echten Marketing-Cloud-Versand mit Unspam prüfst. Beachte: Account Engagement (Pardot) ist ein eigenes Produkt und authentifiziert sich anders.

Kostenlosen Spam-Test starten So testest du deine Mailings

Warum Salesforce Marketing Cloud-E-Mails im Spam landen.

Deine Bounce- und Link-Domains gehören immer noch Salesforce (exacttarget.com)

Ohne das Sender Authentication Package (SAP) sendet Marketing Cloud mit einem Return-Path auf einem Salesforce-Host wie bounce.s7.exacttarget.com oder bounce.s10.mc.pd25.com und leitet jede Link- und Bild-URL über Marketing-Cloud-Domains um. SPF besteht gegen die Domain von Salesforce, richtet sich aber nie auf deine From-Domain aus, und die umgeschriebenen Links liest Gmail als Widerspruch. Die Lösung ist SAP: Es stellt eine authentifizierte Private Domain bereit, die DKIM als deine Domain signiert und Link- und Bild-Wrapping mit ihr brandet. Prüfe die d=-Domain und die Link-Domain an einem echten Versand, nicht nur im DNS.

Du hast eine Private Domain gekauft, aber kein volles SAP, deshalb steht auf den Links weiter Marketing Cloud

Private Domain allein ist ein reines Authentifizierungs-Add-on: Es legt SPF und DKIM auf eine Versand-Subdomain, schreibt aber weder Links noch Bilder um und enthält keine dedizierte IP. Für Bild-URLs, View as Webpage, CloudPages und das Link-Wrapping wird weiter die SAP-Domain (oder die Standarddomain von Marketing Cloud) genutzt. Filter sehen deine From-Domain im Envelope, aber eine andere Domain in jedem klickbaren Link, und das schwächt das Vertrauen. Willst du volles Branding, brauchst du die komplette SAP-Konfiguration, nicht nur Private Domain.

Die SPF-Ausrichtung stimmt erst, wenn jemand multi-bounce domain aktiviert

Auch nach SAP steht die Bounce-Domain standardmäßig auf einem festen Wert, der an deine SAP-Domain gebunden ist. Der Return-Path passt also womöglich weiter nicht zu deiner sichtbaren From-Domain und die SPF-Ausrichtung scheitert. Salesforce hat die Funktion multi-bounce domain, mit der sich die Bounce-Domain an eine Domain wie bounce.yourdomain.com ausrichten lässt, sodass SPF ausgerichtet ist. Der Schalter ist aber nicht in der Oberfläche sichtbar: Du musst den Salesforce-Support bitten, ihn zu setzen. Für ein bestandenes DMARC reicht die DKIM-Ausrichtung allein, mit multi-bounce domain bekommst du aber einen zweiten ausgerichteten Identifier und sauberere DMARC-Berichte.

DMARC wurde nie veröffentlicht, weil Salesforce es nicht für dich anlegt

Wenn Salesforce deine Private Domain oder SAP-Domain im DNS konfiguriert, wird der Versanddomain kein DMARC-Eintrag hinzugefügt. Viele Marketing-Cloud-Konten laufen jahrelang mit ausgerichtetem DKIM, aber ganz ohne DMARC-Richtlinie auf der From-Domain. Seit den Regeln für Massenversender von Gmail und Yahoo aus Februar 2024 müssen Absender mit mehr als 5.000 Nachrichten pro Tag an Gmail mindestens p=none veröffentlichen. Leg selbst einen v=DMARC1-Eintrag mit einer rua-Berichtsadresse an und verschärfe die Richtlinie, sobald DKIM- und SPF-Ausrichtung an einem echten Versand sauber sind.

Du hast eine dedizierte IP aufgesetzt und am ersten Tag das volle Volumen rausgeblasen

Eine dedizierte IP gehört zu SAP und lohnt sich in der Regel erst über rund 250.000 Nachrichten pro Monat, dem Volumen, das Salesforce empfiehlt, um die Reputation einer IP warm zu halten. Eine brandneue IP hat null Historie bei Gmail und Yahoo, ein Versand an die ganze Liste wirkt deshalb wie eine Spam-Kanone. Wärm sie über 4 bis 6 Wochen auf: Starte mit etwa 500 Nachrichten pro Tag an deine aktivsten Empfänger und steigere das Volumen dann Schritt für Schritt, während du die Beschwerden im Blick behältst. Unterhalb dieser Volumenschwelle kann eine kaum genutzte dedizierte IP schlechter abschneiden als der bereits aufgewärmte geteilte Pool von Salesforce.

Antworten bouncen oder verschwinden ohne Reply Mail Management

Standardmäßig gehen Antworten auf einen Marketing-Cloud-Versand an eine No-Reply-Adresse von Salesforce und werden verworfen, und eine From-Adresse, die keine Mail annehmen kann, ist für manche Filter selbst schon ein negatives Signal. Reply Mail Management (RMM), Teil von SAP, leitet Antworten in ein verwaltetes Postfach, filtert Abwesenheits- und Bounce-Rauschen heraus und kann echte Antworten an dein Team weiterleiten. Richte RMM ein, damit deine From-Adresse Mail annimmt und die Abmeldung per Antwort funktioniert, statt von einer Adresse zu senden, die jede Antwort verschluckt.

So authentifiziert Salesforce Marketing Cloud deine E-Mails.

Marketing Cloud signiert Mail und verarbeitet Bounces auf einer Infrastruktur, die Salesforce kontrolliert, es gibt für die Ausrichtung also nichts, was du in dein Root-SPF einfügen könntest. Die Authentifizierung hängt an einer Frage: Hast du eine authentifizierte Private Domain bereitgestellt (einzeln oder als Teil des Sender Authentication Package) und einen eigenen DMARC-Eintrag veröffentlicht? Jeden Eintrag unten kannst du vor und nach der Änderung mit dem SPF-Check, dem DKIM-Check und dem DMARC-Check von Unspam gegenprüfen.

Eintrag	Standard	das Problem	die Lösung
DKIM	Ohne Private Domain oder SAP signiert Marketing Cloud DKIM mit einer Salesforce-eigenen Domain, nicht mit deiner From-Domain. Selbst erzeugte Schlüssel kannst du nicht hochladen; Salesforce hält den privaten Schlüssel und gibt dir die Einträge zum Veröffentlichen.	Die DKIM-Domain d= stimmt nicht mit deiner From-Domain überein, deshalb scheitert die DMARC-Ausrichtung und die Nachricht liest sich, als wäre sie im Auftrag einer Salesforce-Domain verschickt worden.	Stell eine authentifizierte Private Domain (oder ein volles SAP) bereit, damit DKIM als deine Subdomain signiert, und veröffentliche dann genau die CNAME- oder TXT-Einträge, die Salesforce liefert (zum Beispiel s1._domainkey.email.yourbrand.com). Verwaltet Salesforce dein DNS, delegiere die Subdomain stattdessen an die Salesforce-Nameserver (ExactTarget), die du von Salesforce bekommst. Bestätige die Signatur mit dem DKIM-Check von Unspam.
SPF	Die Return-Path-Domain (Bounce-Domain) ist ein Salesforce-Host wie bounce.s7.exacttarget.com oder bounce.s10.mc.pd25.com, SPF besteht also, aber gegen die Domain von Salesforce statt gegen deine.	SPF besteht ohne Ausrichtung, deshalb zeigen DMARC-Berichte bei Standardsendungen SPF pass, aber SPF alignment fail. Ein Salesforce-include in deinem Root-SPF ändert daran nichts.	Bitte den Salesforce-Support, multi-bounce domain zu aktivieren, damit der Return-Path sich auf eine Domain wie bounce.yourbrand.com ausrichten kann. Es ist standardmäßig aus und der Schalter ist nicht in der Oberfläche zu finden; bis dahin erfüllt allein die DKIM-Ausrichtung weiter DMARC. Prüfe mit dem SPF-Check von Unspam, ob dein veröffentlichter Eintrag gültig bleibt.
DMARC	Salesforce legt keinen DMARC-Eintrag an, wenn es deine Private Domain oder SAP-Domain im DNS konfiguriert, viele Konten haben deshalb gar keinen.	Gmail und Yahoo erwarten mindestens p=none auf den From-Domains von Absendern über 5.000 Nachrichten pro Tag, und eine quarantine- oder reject-Richtlinie ohne ausgerichtetes DKIM kann deine eigenen Kampagnen in den Spam-Ordner schicken.	Veröffentliche selbst v=DMARC1; p=none mit einer rua-Adresse unter _dmarc.yourbrand.com, bestätige an einem echten Versand, dass DKIM ausgerichtet ist, und verschärfe dann auf quarantine oder reject, sobald die Berichte sauber laufen. Marketing Cloud erfasst und meldet DMARC-Fehler nicht, verlass dich also auf deinen eigenen rua-Feed und den DMARC-Check von Unspam.
Link and image wrapping	Links, Bilder, View as Webpage und CloudPages laufen über Salesforce-eigene Domains, bis das volle SAP Account Branding aktiv ist. Private Domain allein ändert daran nichts.	Jeder klickbare Link zeigt auf eine Marketing-Cloud-Domain, die du nicht kontrollierst, während dein From deine Marke anzeigt. Manche Filter behandeln diesen Widerspruch als phishing-nah.	Konfiguriere das volle SAP Account Branding, damit Link- und Bild-Wrapping deine authentifizierte Domain nutzt. Private Domain allein authentifiziert den Envelope, lässt das Wrapping aber auf der SAP-Domain oder der Standarddomain.

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 Salesforce Marketing Cloud-Kampagne mit Unspam.

Die Vorschau in Marketing Cloud und der Testversand aus dem E-Mail-Editor verhalten sich nicht wie ein Produktionsversand: Tracking, umgeschriebene Links und Routing können abweichen. Unspam verbindet sich nicht mit der Marketing Cloud API, der einzige ehrliche Test ist also ein echter Versand an eine Test-Adresse über deinen normalen Versandweg.

01
Hol dir deine Test-Adresse von Unspam

Starte in Unspam einen Spam-Test oder einen Inbox-Placement-Test und kopiere die Test-Adresse, die dabei erzeugt wird. Inbox-Placement-Tests enthalten Adressen bei Gmail, Outlook, Yahoo, Zoho, ProtonMail und AOL, sodass du die Platzierung je Anbieter siehst.
02
Leg die Test-Adresse in Marketing Cloud an

Erstelle im Email Studio eine Data Extension oder Liste, zum Beispiel Deliverability Seeds, und füge die Unspam-Adresse als Subscriber hinzu, oder nimm sie in eine bestehende Testzielgruppe auf, die du direkt ansteuern kannst.
03
Schick die echte E-Mail, keine Vorschau

Nutze einen Guided Send oder User-Initiated Send der echten E-Mail an die Testzielgruppe über dein normales Sender Profile, damit sie mit deiner echten Versanddomain, deiner IP und deinen umgeschriebenen Links rausgeht. Meide den Test Send des Editors, der anders routen und Links anders umschreiben kann als die Produktion.
04
Prüfe, ob sie von deiner authentifizierten Domain kam

Sieh in Unspam nach, ob DKIM deine Subdomain signiert (nicht eine Salesforce-Domain), ob der Return-Path ausgerichtet ist, falls du multi-bounce domain aktiviert hast, und ob die umgeschriebenen Links deine gebrandete Domain statt eines Marketing-Cloud-Hosts nutzen.
05
Lies die Ergebnisse in Unspam

Sieh dir den Spam-Score sowie die SPF-, DKIM- und DMARC-Ergebnisse des echten Versands an, dazu Blacklist- und HTML-Prüfungen, die Platzierung je Anbieter (Posteingang, Werbung, Spam oder fehlend), die Client-Vorschauen inklusive Dark Mode und die KI-Eyetracking-Heatmap. Der KI-Assistent zeigt dir, was du vor der nächsten Kampagne ändern solltest.

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.

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

Domainverifizierung ist keine Authentifizierung

Der Button Register Domain in From Address Management erzeugt einen TXT-Token, den du im DNS hinterlegst, aber das belegt nur, dass dir die Domain gehört, damit Marketing Cloud dich als diese Domain senden lässt. SPF, DKIM oder DMARC richtet es damit nicht ein. Eine Domain kann verifiziert sein und trotzdem jede Ausrichtungsprüfung reißen. Authentifizierung braucht eine Private Domain oder ein volles SAP, nicht nur die Verifizierung.

Multi-bounce domain ist unsichtbar, bis der Support es aktiviert

Die Einstellung, die deine Bounce-Domain auf eine Domain wie bounce.yourbrand.com ausrichtet, ist in der Oberfläche von Marketing Cloud nicht zu finden. Du kannst sie nicht selbst setzen, sondern musst einen Case beim Salesforce-Support eröffnen und um die Aktivierung von multi-bounce domain bitten. Bis dahin bleibt dein Return-Path auf der SAP-Domain und die SPF-Ausrichtung besteht nicht.

Private Domain schreibt keine Links um, das tut nur SAP

Teams kaufen oft Private Domain in der Erwartung vollständig gebrandeter Mail und stellen dann fest, dass Links und Bilder weiter über eine Marketing-Cloud-Domain aufgelöst werden. Link- und Bild-Wrapping, CloudPages und das Branding von View as Webpage kommen nur mit dem vollen SAP Account Branding. Sind gebrandete Links für deine Reputation wichtig, vergewissere dich, dass du SAP hast und nicht nur Private Domain.

Account Engagement (Pardot) ist ein anderes Produkt

Sendest du tatsächlich über Account Engagement statt über Marketing Cloud Engagement, sieht die Einrichtung anders aus: Es signiert DKIM standardmäßig mit deiner Versanddomain, nutzt einen Return-Path wie bounce.s7.exacttarget.com, der ohne einen eigens angeforderten Return Path nicht SPF-ausgerichtet ist, und liefert keine DMARC-Authentifizierung. Wende die SAP-Schritte aus Marketing Cloud nicht auf ein Pardot-Konto an, kläre zuerst, welches Produkt sendet.

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

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

Dieselbe Person hat dieselbe Kampagne dreimal bekommen und uns dann als Spam gemeldet

Wenn dein Subscriber Key eine CRM Contact ID statt der E-Mail-Adresse ist, kann eine Adresse unter mehreren Keys existieren, und SFMC behandelt jede als eigenen Kontakt. Sendungen an eine Data Extension entfernen Dubletten nicht nach E-Mail-Adresse, außer du aktivierst es, und Triggered Sends tun es nie. Eine Person bekommt dieselbe Kampagne also einmal pro Datensatz, drückt den Spam-Button, und der Ausschlag bei den Beschwerden bringt Gmail und Yahoo dazu, dich zu filtern.

Die Lösung Aktiviere für Sendungen an Data Extensions in der Zielgruppenauswahl die Option Remove Duplicates; sie ist standardmäßig aus, dedupliziert nach E-Mail-Adresse und fängt innerhalb dieses Versands eine Adresse ab, die unter mehreren SubscriberKeys auftaucht. Sendungen an Listen deduplizieren beim Versand immer automatisch, aber für E-Mail-Aktivitäten im Journey Builder und für Triggered Sends bringt diese Checkbox nichts, dort gibt es keine Deduplizierung. Die dauerhafte Lösung liegt weiter vorn: Einige dich auf einen stabilen ContactKey/SubscriberKey, bereinige Dubletten in deinem CRM oder deiner CDP, sodass jede Person genau einen führenden Datensatz hat, und prüfe die Liste All Subscribers auf dieselbe E-Mail-Adresse unter mehreren Keys.

Gmail hat angefangen, uns massenhaft wegzufiltern, und dann war unsere Promo als Transactional eingestuft

Eine Transactional Send Classification entfernt standardmäßig den sichtbaren Abmeldelink, den Block mit der Postanschrift und den One-Click-List-Unsubscribe-Header. Für eine Quittung ist das richtig, für eine Nachricht mit Werbeinhalt ist es ein Verstoß. Teams stufen kommerzielle Mail als transaktional ein, aus Versehen oder um Abmeldungen zu unterdrücken, und seit Februar 2024 reißt der fehlende One-Click-Header für alle über 5.000 Nachrichten pro Tag die Regeln für Massenversender von Gmail und Yahoo.

Die Lösung Prüfe deine Send Classifications daraufhin, was jede E-Mail tatsächlich enthält, und verschick alles Werbliche unter einer Commercial Send Classification. Erst die Einstufung Commercial bringt Marketing Cloud dazu, den sichtbaren Abmeldelink zu ergänzen und die Header List-Unsubscribe und List-Unsubscribe-Post für den Klick zu setzen; sie gehen bei allen kommerziellen Sendungen mit und lassen sich nicht abschalten. Prüfe getrennt davon, ob das beim Versand genutzte Delivery Profile Kopf- und Fußzeileninhalt mit deiner CAN-SPAM-Postanschrift konfiguriert hat, denn dieser Block kommt aus dem Delivery Profile, nicht aus der Klassifizierung. Beschränke, wer die Send Classification wählen und Sender Profiles und Delivery Profiles bearbeiten darf, und reserviere Transactional strikt für echte Quittungen, Passwort-Resets und Bestellbestätigungen.

Unsere Zustellrate ist eingebrochen, ohne dass wir etwas angefasst haben: Es war ein Fremder auf unserer geteilten IP

Im geteilten IP-Pool von SFMC hängt deine Reputation an jedem anderen Mandanten. Ein lauter Nachbar, der Spam oder Bounces raushaut, löst deshalb B2C-Blocks bei Yahoo, AOL und Microsoft aus und bei Gmail Verzögerungen, selbst bei perfekter Authentifizierung. Der Support bestätigt, dass Deliverability und Abuse an der Sache sind, nennt aber weder den auffälligen Absender noch die laufende Gegenmaßnahme, und genau das fühlt sich unlösbar an.

Die Lösung Eröffne einen Case und leg Belege bei, die deinen Versand vom Einbruch des Pools trennen: Bounce-Logs, SMTP-Codes für Deferrals und Blocks, deine Beschwerderate und den Blacklist-Status, der zeigt, dass sich der ganze IP-Bereich gemeinsam bewegt hat, während deine Kennzahlen stabil blieben. Eskaliere über den Support und dein Account-Team und bitte darum, entweder in einen gesünderen geteilten Pool zu wechseln (das liegt im Ermessen von Salesforce, behandle es also als Bitte) oder über deinen Account Executive die Migration auf eine dedizierte IP zu starten. Im klassischen Email Studio wärmst du die neue IP manuell über 4 bis 6 Wochen auf, beginnend bei etwa 500 Nachrichten pro Tag an deine aktivsten Empfänger, und steigerst das Volumen schrittweise, während du die Beschwerden beobachtest. In Marketing Cloud Next automatisiert Salesforce das Warm-up der dedizierten IP über etwa die ersten 35 Tage.

Nach der Migration auf Marketing Cloud kam unsere Mail bei Gmail nicht mehr sofort an, sondern Stunden später

Nach der Migration berichten Absender im geteilten SFMC-Pool von Mail, die in der Warteschlange hängt oder von Gmail immer wieder verzögert wird, sodass Nachrichten Stunden zu spät ankommen, obwohl SPF, DKIM und DMARC alle bestehen. Gmail schaut beim hohen Marketingvolumen der geteilten IP genauer hin, und zeitkritische transaktionale Mail, die hinter Massenkampagnen in der Warteschlange steht, wird mitgedrosselt.

Die Lösung Zieh die vollständigen E-Mail-Header und lies die Received-Zeitstempel von unten nach oben, um zu belegen, wo die Verzögerung entsteht, statt zu raten: bei SFMC vor der Übergabe oder bei Gmail, das mit einem 4xx immer wieder verzögert. Prüfe eine Verzögerung auf Gmail-Seite gegen deine Domain- und IP-Reputation in den Google Postmaster Tools, denn Marketing Cloud zeigt die Gründe für Deferrals nicht an. Ist die transaktionale Mail das Opfer, trenn sie auf eine eigene Subdomain und ein eigenes Routing, ein eigenes Sender Profile und eine transaktionale Send Classification, und bei entsprechendem Volumen auf eine dedizierte IP oder die Transactional Messaging API, damit sie nicht hinter den Kampagnen-Warteschlangen feststeckt. Verzögert der geteilte Pool selbst, eskaliere bei Salesforce für einen Poolwechsel oder eine dedizierte IP, und stell sicher, dass du eine neue IP nicht zu schnell auf volles Volumen hochziehst.

User-Initiated Sends aus Marketing Cloud landen im Spam, während Journey-E-Mails meist den Posteingang erreichen

Absender mit vollständig konfiguriertem SPF, DKIM und DMARC sehen trotzdem, wie User-Initiated Sends im Spam landen, teils gefolgt von Journey-E-Mails. User-Initiated Sends zielen oft auf inaktive oder genervte Empfänger, was die Domain-Reputation schnell nach unten zieht, und dieser Schaden schwappt auf Journeys über, die sich dieselbe Versanddomain und IP teilen.

Die Lösung Das ist kein Problem der Authentifizierungskonfiguration, sondern eines von Reputation und Zielgruppe. Prüfe die Ausrichtung, nicht nur die Einrichtung: SPF und DKIM können bestehen, während die sichtbare From-Domain, der Return-Path und die signierende Domain nicht zueinander passen, und Anbieter werten das weiterhin als höheres Risiko. Schließ inaktive Empfänger bei User-Initiated Sends aus und lösch Kontakte, die sich vor Monaten angemeldet und nie geöffnet haben, damit diese Sendungen keine Beschwerden mehr erzeugen, die in deine Journeys durchschlagen. Halte Vorlageninhalte kurz und zielgerichtet, und wenn du auf einer dedizierten IP sendest, sende regelmäßig, denn Lücken im Volumen setzen deine Absender-Reputation zurück.

Zustellbarkeit bei Salesforce Marketing Cloud, kurz beantwortet.

Warum sieht meine Marketing-Cloud-Mail so aus, als käme sie von einer Salesforce-Domain?

Dein Konto hat keine authentifizierte Private Domain bereitgestellt, also signiert DKIM mit einer Salesforce-eigenen Domain und Links laufen über Marketing-Cloud-Hosts wie exacttarget.com. Richte eine Private Domain ein, damit DKIM auf deine Subdomain ausgerichtet ist, und das volle SAP Account Branding, damit Link- und Bild-Wrapping deine Marke tragen. Die Domainverifizierung allein behebt das nicht.

Muss ich Salesforce in den SPF-Eintrag meiner Domain aufnehmen?

Nein. Marketing Cloud kontrolliert die Return-Path-Domain, SPF wird also gegen die Infrastruktur von Salesforce geprüft und besteht ohnehin, nur eben ohne Ausrichtung. Ein include in deinem Root-SPF bringt der Ausrichtung nichts. SPF richtet sich erst aus, wenn du den Salesforce-Support bittest, multi-bounce domain zu aktivieren, und die DKIM-Ausrichtung über eine Private Domain lässt DMARC schon allein bestehen.

Was ist der Unterschied zwischen Private Domain und dem Sender Authentication Package?

Private Domain ist ein reines Authentifizierungs-Add-on: SPF und DKIM auf einer Versand-Subdomain, ohne dedizierte IP und ohne Branding von Links und Bildern. SAP ist das komplette Paket: Private Domain plus dedizierte IP, Account Branding für Link- und Bild-Wrapping und Reply Mail Management. Salesforce empfiehlt eine dedizierte IP ab etwa 250.000 Nachrichten pro Monat.

Holt mich eine dedizierte IP aus dem Spam-Ordner?

Nur wenn du das Volumen hast, um sie warm zu halten. Eine dedizierte IP kommt mit SAP und lohnt sich in der Regel ab etwa 250.000 Nachrichten pro Monat. Eine neue IP musst du über 4 bis 6 Wochen aufwärmen, beginnend bei etwa 500 Nachrichten pro Tag an aktive Empfänger, und eine kaum genutzte dedizierte IP kann schlechter abschneiden als der bereits aufgewärmte geteilte Pool von Salesforce. Bring zuerst Authentifizierung, Listenhygiene und Beschwerderate in Ordnung, bevor du zur dedizierten IP greifst.

Kann Unspam sich mit meinem Marketing-Cloud-Konto verbinden und Sendungen automatisch testen?

Nein. Unspam integriert sich weder mit der Marketing Cloud API noch mit der API einer anderen E-Mail-Versandplattform (ESP). Der Ablauf ist bewusst manuell: Test-Adresse von Unspam in eine Data Extension oder Liste aufnehmen, einen echten Guided Send dorthin schicken und die Ergebnisse in Unspam lesen. Nur so prüfst du genau die Mail, die deine Empfänger bekommen, inklusive Authentifizierung und umgeschriebener Links.

Ich nutze Pardot, nicht Marketing Cloud Engagement. Gelten diese Schritte?

Nicht direkt. Account Engagement (früher Pardot) ist ein eigenes Produkt: Es signiert DKIM standardmäßig mit deiner Versanddomain und nutzt eine Salesforce-Bounce-Domain, die ohne einen eigens angeforderten Return Path nicht SPF-ausgerichtet ist. DMARC-Authentifizierung liefert es ebenfalls nicht. Kläre, welches Produkt deine Mail verschickt, und folge dann dem Authentifizierungsweg dieses Produkts, statt beide zu vermischen.

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

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

Kostenlosen Spam-Test starten Inbox-Placement-Test