SPF, DKIM & DMARC für Salesforce.
Salesforce (Sales, Service und Platform Cloud) authentifiziert Ihre Domain über drei bewegliche Teile, und seit Spring '26 weigert es sich, E-Mails von einer Domain zu versenden, die Sie nicht verifiziert haben. SPF ist ein echtes gemeinsames include (include:_spf.salesforce.com), das Sie in Ihren einen Root-SPF-Record einbinden. DKIM ist ein Paar von CNAME-„Selector"-Records, die Sie unter Setup - DKIM Keys erzeugen und anschließend aktivieren - und das Anlegen eines aktiven DKIM-Schlüssels ist zugleich der empfohlene Weg, um Salesforces neue Domain-Verifizierung für den E-Mail-Versand zu erfüllen. DMARC ist ein vierter, separater Record, den Salesforce niemals für Sie anlegt. Der Haken, über den fast jeder stolpert: Salesforce versendet Bounces von seiner eigenen Return-Path-Domain, sodass SPF nicht zu Ihrer From-Adresse ausgerichtet ist - DKIM ist der Mechanismus, der DMARC tatsächlich trägt.
Warum Salesforce authentifizieren?
Die Authentifizierung von Salesforce-Mail ist keine optionale Fleißaufgabe mehr - seit Spring '26 (die Durchsetzung begann am 9. März 2026 und wurde bis Ende April 2026 ausgerollt) blockiert Salesforce jede von Nutzern verfasste oder automatisierte E-Mail, die von einer nicht verifizierten Domain versendet wird. Manuelle Sendungen scheitern im Email Composer mit „Not allowed to send from an unauthorized domain", und automatisierte Flows scheitern stillschweigend und zeigen „550 5.7.1 Delivery not authorized, message discarded" nur in Ihren Email Logs. Hinzu kommt: Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob 5,000+ Nachrichten pro Tag), SPF, DKIM und DMARC mit Ausrichtung zu bestehen, und Microsoft begann 2025, dasselbe für Mail mit hohem Volumen an Outlook.com durchzusetzen. Das Standardverhalten von Salesforce bricht DMARC klammheimlich: Es setzt einen Return-Path auf seine eigene Bounce-Domain, sodass SPF zwar authentifiziert, aber nicht zu Ihrer From-Adresse ausgerichtet ist, und von Haus aus gibt es überhaupt keine DKIM-Signatur auf Ihrer Domain - das heißt, eine Salesforce-E-Mail, die einwandfrei aussieht, kann dennoch überall an DMARC scheitern. Das Einrichten eines DKIM-Schlüssels behebt beide Probleme auf einen Schlag: Es erfüllt die Anforderung an die Domain-Verifizierung und verschafft Ihnen eine ausgerichtete Signatur, die DMARC bestehen lässt, sodass die Reputation, die Sie aufbauen, Ihrer eigenen Domain zugutekommt, statt an Salesforces geteilter Infrastruktur abzuprallen.
Die SPF-Realität bei Salesforce
Salesforce Core ist ein echter „include"-Anbieter: Es gibt genau einen realen gemeinsamen Mechanismus, include:_spf.salesforce.com, den Sie zum einzigen SPF-TXT-Record auf Ihrer Root-Domain hinzufügen, z. B. v=spf1 include:_spf.salesforce.com ~all. Aber machen Sie sich klar, was er bewirkt. Das include löst zu v=spf1 exists:%{i}._spf.mta.salesforce.com -all auf - ein Exists-Makro-Record, der die aktuellen Versand-IPs von Salesforce autorisiert - und es kostet ZWEI Ihrer 10 SPF-DNS-Lookups (einen für das include selbst, einen für den verschachtelten exists-Mechanismus). Die wichtige Feinheit: Dieses include hinzuzufügen autorisiert Salesforce für SPF, sorgt aber NICHT dafür, dass SPF ausgerichtet ist. Standardmäßig verwendet Salesforce seine eigene Domain als Envelope-From / Return-Path (seine Bounce-Handling-Domain), sodass die SPF-Prüfung gegen die Domain von Salesforce läuft, nicht gegen Ihre - was bedeutet, dass SPF zwar besteht, aber nicht zu Ihrer sichtbaren From-Adresse ausgerichtet ist, und DMARC bekommt daraus nichts. Deshalb ist DKIM hier nicht optional: DMARC benötigt mindestens einen ausgerichteten Mechanismus, und bei Salesforce ist dieser Mechanismus DKIM. Veröffentlichen Sie das include trotzdem (es ist die dokumentierte Empfehlung von Salesforce und autorisiert die Versand-IPs sauber), aber behandeln Sie DKIM - nicht SPF - als das, was Ihr DMARC-Bestehen trägt.
Zwei Wege zur Einrichtung
DKIM-Schlüssel (empfohlen)
- CNAME-delegiert an custdkim.salesforce.com, sodass Salesforce die privaten Schlüssel hält und rotiert
- Verschafft Ihnen eine ausgerichtete DKIM-Signatur - den Mechanismus, der DMARC tatsächlich bestehen lässt
- Ein aktiver DKIM-Schlüssel erfüllt zugleich die Anforderung der Spring '26-Domain-Verifizierung für den E-Mail-Versand
- Ein Schlüssel kann über sein Domain Match Pattern mehrere From-Adress-Domains abdecken
Authorized Email Domains - TXT (nur Verifizierung)
- Ein einzelner TXT-Record unter _sfdv.yourdomain.com (oder am Apex) belegt, dass Ihnen die Domain gehört
- Erfüllt die Spring '26-Verifizierungsanforderung, sodass Sendungen nicht blockiert werden
- Signiert Ihre Mail NICHT - keine DKIM-Signatur, keine DMARC-Ausrichtung dadurch
- Nutzen Sie es nur als Übergangslösung; für die Zustellbarkeit benötigen Sie dennoch einen DKIM-Schlüssel
Schritt für Schritt
- 1
Legen Sie Ihre Deliverability-Zugriffsstufe fest
Öffnen Sie in Setup über Quick Find den Bereich Email - Deliverability. Setzen Sie „Access to Send Email" (Access level) auf „All email", damit Salesforce tatsächlich ausgehende Mail versendet - Sandboxes und manche Orgs stehen standardmäßig auf „System email only" oder „No access", was Ihre Testnachrichten stillschweigend verwirft, noch bevor die Authentifizierung überhaupt eine Rolle spielt.
- 2
Erstellen Sie einen DKIM-Schlüssel
Suchen Sie in Setup über Quick Find nach „DKIM Keys" und klicken Sie auf Create New Key. Wählen Sie 2048-bit als RSA-Schlüssellänge. Geben Sie einen eindeutigen Selector (z. B. example-sf-a) und einen eindeutigen Alternate Selector (z. B. example-sf-b) ein. Geben Sie die Domain an, von der Sie senden, sowie ein Domain Match Pattern (z. B. example.com, um diese Domain abzudecken, oder ein breiteres Pattern für Subdomains) und speichern Sie dann. Hinweis: Das Feld Domain ist nach dem Speichern dauerhaft.
- 3
Veröffentlichen Sie die beiden DKIM-CNAME-Records
Öffnen Sie die Seite DKIM Key Details - Salesforce zeigt einen CNAME und einen Alternate CNAME. Legen Sie bei Ihrem DNS-Hoster beide als CNAME-Records an: Host example-sf-a._domainkey.yourdomain.com, der auf das von Salesforce angezeigte Ziel verweist, etwa example-sf-a.k4tyd2.custdkim.salesforce.com (und den -b-Selector auf sein eigenes custdkim.salesforce.com-Ziel). Kopieren Sie die Ziele exakt - ein einziges falsches Zeichen macht das Signieren kaputt. Wenn Ihr DNS hinter Cloudflare liegt, setzen Sie sie auf DNS-only (graue Wolke).
- 4
Aktivieren Sie den DKIM-Schlüssel
Nachdem die CNAMEs propagiert sind (Minuten, bis zu 48-72 Stunden), kehren Sie zu Setup - DKIM Keys zurück, öffnen den Schlüssel und klicken auf Activate. Salesforce lässt eine Aktivierung erst zu, wenn beide CNAMEs im öffentlichen DNS auflösen. Sobald er aktiv ist, signiert Salesforce ausgehende Mail mit d=yourdomain.com und Ihre Domain gilt für die Spring '26-Anforderung als verifiziert.
- 5
Fügen Sie das SPF-include hinzu oder führen Sie es zusammen
Veröffentlichen Sie bei Ihrem DNS-Hoster GENAU EINEN SPF-TXT-Record auf der Root (Host @): v=spf1 include:_spf.salesforce.com ~all. Wenn Sie bereits über Google Workspace, Microsoft 365, ein Marketing-Tool usw. senden, führen Sie include:_spf.salesforce.com in diese eine bestehende v=spf1-Zeile ein - erstellen Sie niemals einen zweiten SPF-Record. Dies autorisiert die IPs von Salesforce (es kostet 2 Lookups), aber denken Sie daran: Von allein richtet es sich nicht aus.
- 6
Verifizieren Sie die Domain, falls Sie noch kein DKIM nutzen
Wenn Sie den Versand freigeben müssen, bevor DKIM live ist, nutzen Sie die TXT-Alternative: Setup - Quick Find „Authorized Email Domains" - Add, geben Sie Ihre Domain ein, und Salesforce erzeugt einen Verifizierungsschlüssel. Veröffentlichen Sie ihn als TXT-Record (Host _sfdv.yourdomain.com oder am Apex), warten Sie auf die Propagierung, bearbeiten Sie dann die Domain und aktivieren Sie „Verify domain ownership". Dies belegt die Inhaberschaft, signiert aber keine Mail - ein DKIM-Schlüssel bleibt das Ziel.
- 7
Richten Sie Ihre Org-Wide Address auf die verifizierte Domain aus
Jede From-Adresse muss auf einer verifizierten Domain liegen. Öffnen Sie in Setup über Quick Find - „Organization-Wide Addresses" und stellen Sie sicher, dass die Adressen, von denen Ihre Nutzer, Flows und E-Mail-Benachrichtigungen senden (z. B. no-reply@yourdomain.com), auf der Domain liegen, die Sie gerade authentifiziert haben. Nicht verifizierte Org-Wide Addresses sind die häufigste Ursache für blockierte automatisierte Sendungen.
- 8
Veröffentlichen Sie Ihren DMARC-Record
Salesforce legt niemals DMARC an. Fügen Sie einen TXT-Record unter _dmarc.yourdomain.com hinzu: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist reiner Beobachtungsmodus - es ändert nichts an der Zustellung, während Sie bestätigen, dass Salesforce-Mail DKIM ausgerichtet zu Ihrer Domain besteht. Behalten Sie genau einen _dmarc-Record für die gesamte Domain.
- 9
Senden Sie einen Test und lesen Sie die Header
Senden Sie eine echte Nachricht von einer Salesforce Org-Wide Address an ein Gmail-Postfach, öffnen Sie sie und wählen Sie im Drei-Punkte-Menü - Original anzeigen. Sie möchten DKIM: PASS mit signed-by / d=yourdomain.com (nicht salesforce.com) und DMARC: PASS sehen. SPF zeigt typischerweise die Return-Path-Domain von Salesforce - das ist zu erwarten; DKIM sollte dasjenige sein, das das DMARC-Bestehen trägt.
Einzutragende Einträge
Salesforce erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.salesforce.com ~allRoot-SPF - behalten Sie GENAU EINEN SPF-Record; führen Sie dieses include in Ihre bestehende v=spf1-Zeile ein, falls Sie eine haben. Kostet ~2 DNS-Lookups (include + verschachteltes exists). Autorisiert Salesforce, richtet sich aber nicht aus. |
| CNAME | example-sf-a._domainkey | example-sf-a.k4tyd2.custdkim.salesforce.comDKIM-Selector 1 - beispielhaft. Kopieren Sie das exakte Ziel von Ihrer Seite DKIM Key Details; der Partitions-String k4tyd2 ist für Ihren Schlüssel eindeutig. |
| CNAME | example-sf-b._domainkey | example-sf-b.e6mxu6.custdkim.salesforce.comDKIM-Alternate-Selector - beispielhaft. Der zweite Selector lässt Salesforce Schlüssel rotieren, ohne dass Sie das DNS erneut anfassen müssen. Verwenden Sie den exakten Wert, den Salesforce anzeigt. |
| TXT | _sfdv | 00D000000000P18=1AB00000000000BAuthorized Email Domains-Verifizierungsschlüssel - beispielhaft und pro Org. Nur nötig, wenn Sie die TXT-Inhaberschaftsmethode statt (oder vor) einem aktiven DKIM-Schlüssel nutzen; der Apex funktioniert ebenfalls als Host. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu - Salesforce legt ihn niemals an. Einer pro Domain; beginnen Sie bei p=none und verschärfen Sie später. |
Behalten Sie genau einen SPF-TXT-Eintrag (v=spf1) auf Ihrer Root-Domain — führen Sie jeden Absender darin zusammen. Zwei SPF-Einträge sind bereits an sich ein Fehler.
Das Budget von 10 Lookups
SPF ist auf harte 10 DNS-Lookups begrenzt — wird dieser Wert überschritten, gibt SPF einen permerror zurück und validiert überall nicht mehr. Hier sehen Sie, was die Einrichtung von Salesforce von diesem Budget verbraucht.
Salesforce verbraucht 2 Ihrer 10 Lookups; ip4:- und ip6:-Mechanismen sind kostenlos.
DKIM
DKIM ist das Herzstück der Salesforce-Authentifizierung, denn es ist der einzige Mechanismus, der zu Ihrer Domain ausgerichtet ist - und seit Spring '26 ist ein aktiver DKIM-Schlüssel der von Salesforce empfohlene Weg, die Domain-Inhaberschaft zu verifizieren, damit Ihre Sendungen nicht blockiert werden. Legen Sie ihn unter Setup - Quick Find - „DKIM Keys" - Create New Key an: Wählen Sie 2048-bit, geben Sie einen eindeutigen Selector und einen eindeutigen Alternate Selector ein (Salesforce verwendet zwei Selektoren, um Schlüssel rotieren zu können), geben Sie die Domain an und legen Sie ein Domain Match Pattern fest, das steuert, welche From-Adress-Domains dieser Schlüssel signiert. Nachdem Sie gespeichert haben, zeigt die Seite DKIM Key Details einen CNAME und einen Alternate CNAME - zum Beispiel example-sf-a._domainkey.yourdomain.com auf example-sf-a.k4tyd2.custdkim.salesforce.com und example-sf-b._domainkey.yourdomain.com auf example-sf-b.e6mxu6.custdkim.salesforce.com. Da es sich um CNAMEs handelt, die in custdkim.salesforce.com delegiert sind (keine TXT-Records zum Einfügen), hält Salesforce die privaten Schlüssel und rotiert die veröffentlichten Schlüssel hinter den beiden Selektoren, ohne dass Sie jemals DNS erneut bearbeiten müssen. Zwei Dinge, die man leicht übersieht: Das Feld Domain ist nach dem Speichern dauerhaft (um es zu ändern, müssten Sie einen neuen Schlüssel anlegen), und Sie können erst dann auf Activate klicken, wenn beide CNAMEs tatsächlich im öffentlichen DNS auflösen. Veröffentlichen Sie beide Records, warten Sie auf die Propagierung, kehren Sie dann zu DKIM Keys zurück und klicken Sie auf Activate - erst dann beginnt Salesforce, ausgehende Mail mit d=yourdomain.com zu signieren. Ältere Salesforce-DKIM-Schlüssel waren selbstverwaltete TXT-Schlüssel, die Sie erzeugt und eingefügt haben; der moderne „secure"-DKIM-Schlüssel ist die hier beschriebene CNAME-delegierte Variante und die, die Sie verwenden sollten.
DMARC
DMARC ist ein separater Richtlinien-TXT-Record auf Ihrer Domain, den Salesforce nicht anlegt - Sie veröffentlichen ihn selbst unter _dmarc.yourdomain.com, beginnend mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist reiner Beobachtungsmodus: Es ändert nichts an der Zustellung, während Sie die aggregierten (rua-)Berichte auswerten, um zu bestätigen, dass Salesforce-Mail DKIM ausgerichtet zu Ihrer Domain besteht. Dies ist der Schritt, in dem Salesforces Ausrichtungs-Eigenheit am meisten ins Gewicht fällt: Weil Salesforce Bounces von seiner eigenen Return-Path-Domain versendet, authentifiziert SPF zwar, richtet sich aber nicht aus, sodass bei Salesforce-Mail DMARC allein über die DKIM-Ausrichtung besteht. Das ist in Ordnung - DMARC erfordert nur einen ausgerichteten Mechanismus - aber es bedeutet, dass Ihr DKIM-Schlüssel aktiv sein und signieren muss, bevor Sie die Richtlinie verschärfen, sonst scheitert legitime Salesforce-Mail. Beobachten Sie die Berichte ein bis zwei Wochen, stellen Sie sicher, dass Salesforce (und jeder andere Versender - Google Workspace, Microsoft 365, Marketing-Tools) ein ausgerichtetes Bestehen zeigt, und steigern Sie dann auf p=quarantine und schließlich p=reject. Behalten Sie genau einen _dmarc-Record für die gesamte Organisations-Domain; fügen Sie niemals einen zweiten nur für Salesforce hinzu.
Prüfen, ob es wirklich funktioniert hat
Verlassen Sie sich nicht allein auf den Status auf der Salesforce-Seite DKIM Keys - bestätigen Sie es an einer echten Nachricht. Senden Sie von einer Ihrer Org-Wide Addresses an ein Gmail-Postfach, öffnen Sie die Nachricht und wählen Sie im Drei-Punkte-Menü - Original anzeigen. Sie möchten DKIM: PASS mit signed-by / d=yourdomain.com sehen (wenn dort salesforce.com steht, ist Ihr Schlüssel nicht aktiv oder Ihre Org-Wide Address liegt auf der falschen Domain) und DMARC: PASS. SPF wird in der Regel eine Salesforce-Return-Path-Domain statt Ihrer eigenen anführen - das ist zu erwarten, denn DKIM, nicht SPF, übernimmt die Ausrichtung. In Salesforce sollte die Seite DKIM Key Details Active anzeigen. Lassen Sie dann Ihre Domain durch den Domain-Health-Check von Qualisend laufen, um zu bestätigen, dass der SPF-Record, beide DKIM-Selector-CNAMEs und der DMARC-Record allesamt sauber auflösen und SPF unter dem Limit von 10 Lookups bleibt; sobald aggregierte DMARC-Berichte eintreffen, geben Sie einen in den DMARC-Report-Analyzer ein, um zu bestätigen, dass Salesforce als ausgerichtete, bestehende Quelle erscheint.
Häufige Stolperfallen
- Abdeckung
Spring '26-Durchsetzung: Salesforce blockiert nun Mail von nicht verifizierten Domains - manuelle Sendungen scheitern mit „Not allowed to send from an unauthorized domain" und automatisierte Flows scheitern stillschweigend und protokollieren „550 5.7.1 Delivery not authorized, message discarded" in den Email Logs. Aktivieren Sie einen DKIM-Schlüssel (oder verifizieren Sie über Authorized Email Domains) für jede Domain, die Ihre Org-Wide Addresses verwenden.
- Abdeckung
SPF richtet sich bei Salesforce nicht aus. Es versendet Bounces von seiner eigenen Return-Path-Domain, sodass das SPF-include zwar autorisiert, sich aber nie zu Ihrer From-Adresse ausrichtet - DMARC stützt sich vollständig auf DKIM. Das include ohne aktiven DKIM-Schlüssel hinzuzufügen verschafft Ihnen KEIN DMARC-Bestehen.
- Abdeckung
Das Feld Domain des DKIM-Schlüssels ist dauerhaft. Nach dem Speichern können Sie die Domain (oder die Selektoren) nicht mehr bearbeiten - Sie müssten einen neuen Schlüssel anlegen. Machen Sie es gleich richtig und decken Sie mit dem Domain Match Pattern die Domains ab, von denen Sie tatsächlich senden.
- DNS-Einrichtung
Sie können DKIM nicht aktivieren, bevor beide CNAMEs auflösen. Der Activate-Button funktioniert nicht, solange das DNS noch propagiert; warten Sie (bis zu 48-72 Stunden) und prüfen Sie mit einem DNS-Lookup erneut, bevor Sie es noch einmal versuchen.
- Abdeckung
Die Deliverability-Zugriffsstufe blockiert Sendungen stillschweigend. Wenn „Access to Send Email" auf „System email only" oder „No access" steht (in Sandboxes häufig), verwirft Salesforce Ihre ausgehende Mail unabhängig vom DNS - setzen Sie sie unter Setup - Deliverability auf „All email".
- Abdeckung
Email Relay umgeht das DKIM-Signieren von Salesforce. Wenn Sie ausgehende Mail über Ihren eigenen SMTP-Server via Setup - Email Relay leiten, signiert Salesforce die Mail nicht - Ihr Relay ist für SPF und DKIM verantwortlich, und diese Salesforce-Records gelten für diesen Pfad nicht.
- DNS-Einrichtung
Dies deckt Salesforce Core (Sales/Service/Platform) ab, nicht Marketing Cloud oder Pardot. Marketing Cloud Engagement verwendet sein eigenes Sender Authentication Package (SAP) mit anderen CNAMEs, und Account Engagement (Pardot) hat sein eigenes Setup - jede Produktfamilie authentifiziert sich separat.
- Bricht die Authentifizierung
Behalten Sie einen SPF-Record. Führen Sie include:_spf.salesforce.com in Ihre eine v=spf1-Zeile ein - zwei SPF-TXT-Records auf derselben Domain sind ein PermError, der SPF für jeden Versender kaputt macht.
Erstellen Sie Ihren SPF-Eintrag
Salesforce ist unten bereits vorausgewählt. Fügen Sie alle weiteren Plattformen hinzu, über die Sie versenden, und veröffentlichen Sie anschließend den einen zusammengeführten Eintrag.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSalesforce SPF — FAQ
Weiterführende Lektüre
Sobald der Eintrag veröffentlicht ist, prüfen Sie mit dem Domain-Health-Check, ob alles korrekt aufgelöst wird, und lesen Sie mit der DMARC-Berichtsanalyse nach, wer in Ihrem Namen versendet. Durchsuchen Sie alle Versandquellen im Generator. Authentifizierung ist allerdings nur die halbe Zustellbarkeit — eine gelistete Absender-IP oder -Domain bringt Sie unabhängig davon, wie sauber Ihr SPF ist, im Spam-Ordner unter, deshalb lohnt es sich, mit Blacklist-Überwachung die Blacklists im Blick zu behalten.
Authentifiziert — jetzt die Liste sauber halten
SPF, DKIM und DMARC zu bestehen bringt Sie in den Posteingang; eine saubere Liste hält Sie dort. Verifizieren Sie Ihre — starten Sie kostenlos mit 100 Credits, ohne Kreditkarte.