SPF, DKIM & DMARC für SocketLabs.
SocketLabs authentifiziert Ihre Domain innerhalb seines On-Demand-Portals, und die Einrichtung unterscheidet sich grundlegend von Anbietern, bei denen man nur "diese eine SPF-Zeile einfügt". Jede Nachricht, die Sie versenden, ist bereits SPF-authentifiziert und DKIM-signiert, sobald sie die Plattform verlässt — aber standardmäßig gehört diese Authentifizierung zu SocketLabs' eigener Domain, email-od.com. Deshalb trägt unkonfigurierte Post einen "via email-od.com"-Hinweis und kann für DMARC nicht zu Ihrer Domain ausgerichtet werden. Damit SocketLabs im Namen Ihrer Domain sendet, fügen Sie unter Configuration → Domain Management zwei Records hinzu: ein Custom Bounce Domain CNAME (der den Return-Path auf Ihre eigene Subdomain verschiebt, sodass SPF ausgerichtet ist) und einen DKIM-Record (ein einzelnes CNAME oder ein generierter TXT-Selector, sodass DKIM im Namen Ihrer Domain signiert). Eine separate DMARC-Policy vervollständigt das Set. Der entscheidende Kniff: Der von SocketLabs empfohlene SPF-Weg ist das Bounce-Domain-CNAME, nicht das Hinzufügen von include:email-od.com zu Ihrem Root-SPF.
Warum SocketLabs authentifizieren?
Die Authentifizierung von SocketLabs ist keine Formsache — sie entscheidet darüber, ob Ihre Post überhaupt den Posteingang erreicht. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob ab 5.000 Nachrichten pro Tag), dass SPF, DKIM und DMARC mit Alignment bestanden werden, und Microsoft begann 2025 damit, dasselbe für Post mit hohem Volumen an Outlook.com/Hotmail durchzusetzen. Der für SocketLabs spezifische Haken: Standardmäßig authentifiziert es SPF gegen seine Bounce-Domain email-od.com und signiert DKIM mit d=email-od.com. Beide Prüfungen bestehen (PASS) auf email-od.com, aber keine ist zu Ihrer From-Domain ausgerichtet, sodass DMARC das Alignment nicht besteht, Empfänger einen "via email-od.com"-Tag sehen und die Versandreputation, die Sie aufbauen, sich mit jedem anderen nicht authentifizierten SocketLabs-Versender vermischt, statt auf Ihre eigene Domain anzuwachsen. Das Einrichten einer Custom Bounce Domain (SPF wird ausgerichtet) plus Custom DKIM (DKIM wird ausgerichtet) schließt diese Lücke in zwei Records — DMARC besteht dann über beide Mechanismen, der "via"-Tag verschwindet, und Ihre Domain besitzt ihre eigene Reputation.
Die SPF-Realität bei SocketLabs
SocketLabs ist technisch gesehen ein "include"-Anbieter — include:email-od.com existiert und wird per DNS verifiziert (es löst zu einem einzigen flachen Record auf, v=spf1 ip4:142.0.176.0/20 ip4:… ~all, mit ausschließlich ip4-Bereichen und ohne verschachtelte includes, sodass es genau EINEN Ihrer 10 SPF-Lookups kosten würde) — aber es ist NICHT der von SocketLabs empfohlene SPF-Weg und erzeugt für sich allein kein DMARC-Alignment. Der Grund: SPF wird gegen die Return-Path-Domain (Bounce/Envelope) ausgewertet, nicht gegen Ihre sichtbare From-Adresse. Standardmäßig ist SocketLabs' Return-Path email-od.com, sodass die SPF-Prüfung auf den Record von email-od.com trifft und Ihr Root-SPF für SocketLabs-Post nie herangezogen wird. SocketLabs implementiert SPF stattdessen über eine Custom Bounce Domain: Sie veröffentlichen ein CNAME auf einer Subdomain Ihrer eigenen Domain — z. B. email.yourdomain.com CNAME tracking.socketlabs.com — und weil tracking.socketlabs.com selbst v=spf1 include:email-od.com ~all veröffentlicht, wird durch das Verschieben des Return-Path auf Ihre Subdomain SPF sowohl BESTANDEN (es erbt SocketLabs' Whitelisted-IPs über dieses CNAME) ALS AUCH zu Ihrer organisatorischen Domain AUSGERICHTET, und das alles, ohne Ihren bestehenden Root-SPF-Record zu bearbeiten. Deshalb fügt das empfohlene Setup Ihrem Root-SPF null Lookups hinzu. Der include:email-od.com-Mechanismus ist eine Doppelt-hält-besser-Option: Sie können ihn zu Ihrem Root-SPF hinzufügen (er autorisiert die versendenden IPs auch dort, zum Preis eines Lookups), aber er verschafft für sich allein kein Alignment und ist nicht erforderlich, sobald die Custom Bounce Domain eingerichtet ist. Halten Sie wie immer genau EINEN SPF-TXT-Record pro Domain — wenn Sie den include hinzufügen, führen Sie ihn in Ihre einzige v=spf1-Zeile zusammen, statt einen zweiten Record zu veröffentlichen.
Zwei Wege zur Einrichtung
Custom Bounce Domain CNAME (empfohlen)
- Verschiebt den Return-Path auf eine Subdomain Ihrer Domain, sodass SPF sowohl besteht als auch für DMARC AUSGERICHTET ist
- Fügt Ihrem Root-SPF null DNS-Lookups hinzu — es gibt nichts zusammenzuführen oder zu flatten
- Das CNAME auf tracking.socketlabs.com erbt SocketLabs' Whitelisted-IPs automatisch; Sie bearbeiten es bei IP-Änderungen nie neu
- Dasselbe Subdomain-CNAME lässt sich wiederverwenden, um Ihre Öffnungs-/Klick-Tracking-Links für Engagement mit White-Label zu versehen
include:email-od.com in Ihrem Root-SPF (optional)
- Sie fügen v=spf1 include:email-od.com ~all selbst zu Ihrem Root-SPF hinzu
- Kostet einen Ihrer 10 SPF-DNS-Lookups (email-od.com ist ein flacher, reiner ip4-Record, also genau einer)
- Autorisiert die versendenden IPs unter Ihrer Domain, richtet SPF aber für sich allein NICHT aus — der Return-Path ist weiterhin email-od.com, sofern Sie nicht zusätzlich das Bounce-CNAME setzen
- Bestenfalls eine Ergänzung, niemals ein Ersatz für die Custom Bounce Domain
Schritt für Schritt
- 1
Domain Management öffnen
Melden Sie sich beim On-Demand-Portal an, klicken Sie im linken Menü auf Configuration, wählen Sie Domain Management und wählen Sie dann die Versanddomain aus, die Sie authentifizieren möchten (oder klicken Sie, um sie hinzuzufügen). Alles Weitere unten befindet sich auf der Karte dieser Domain.
- 2
Custom Bounce Domain & SPF starten
Öffnen Sie auf der Domain "Custom Bounce Domain and SPF Authentication". SocketLabs erzeugt einen CNAME-Record auf einer Subdomain Ihrer Domain (etwa email.yourdomain.com oder bounce.yourdomain.com), dessen Ziel tracking.socketlabs.com ist. So implementiert SocketLabs SPF — es verschiebt Ihren Return-Path auf Ihre eigene Domain, sodass SPF ausgerichtet ist.
- 3
Das Bounce-Domain-CNAME veröffentlichen
Erstellen Sie bei Ihrem DNS-Host ein CNAME: Host = die von SocketLabs angezeigte Subdomain (z. B. email), Value = tracking.socketlabs.com. Ändern Sie es nicht in einen TXT- oder A-Record, und lassen Sie Ihren bestehenden Root-SPF-Record unberührt — dieses CNAME ist es, das SPF trägt.
- 4
Ihre DKIM-Methode wählen
Öffnen Sie zurück auf der Domain den DKIM-Abschnitt. Sie haben zwei Optionen: die CNAME-DKIM-Signing-Funktion (am einfachsten — SocketLabs besitzt und rotiert den Schlüssel für Sie) oder die Advanced/TXT-Methode über den DKIM Key Generator (Sie wählen einen Selector und veröffentlichen einen TXT-Record mit dem öffentlichen Schlüssel). Wählen Sie eine; Sie brauchen nicht beide.
- 5
Den DKIM-Record veröffentlichen
Für die CNAME-Methode fügen Sie ein CNAME hinzu: Host = dkim._domainkey, Value = dkim._domainkey.email-od.com. Für die TXT-Methode fügen Sie einen TXT-Record unter Host = <selector>._domainkey hinzu (der im Generator gewählte Selector, alphanumerisch und unter 10 Zeichen) mit dem Wert v=DKIM1; k=rsa; p=…, den SocketLabs anzeigt. So oder so signiert DKIM nun im Namen Ihrer Domain.
- 6
Den DMARC-Record hinzufügen
SocketLabs erstellt DMARC nicht für Sie. Fügen Sie einen TXT-Record unter Host = _dmarc mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com hinzu. p=none ist reiner Monitor-Modus, sodass sich an der Zustellung nichts ändert, während Sie das Alignment bestätigen — Sie verschärfen es später.
- 7
Im Portal verifizieren
Kehren Sie zu Domain Management zurück und klicken Sie auf "Verify Bounce" für die Custom Bounce Domain und auf "Verify" für DKIM. Der Status der Bounce-Domain sollte authenticated anzeigen und DKIM sollte active anzeigen. Die Propagation dauert meist Minuten, aber SocketLabs kann bis zu 24–48 Stunden brauchen, um die Records zu bestätigen.
- 8
Einen Test senden und die Header lesen
Senden Sie eine Nachricht von einer Adresse auf der konfigurierten Domain an ein Gmail-Konto, öffnen Sie sie und wählen Sie ⋮ → Original anzeigen. Sie wollen SPF: PASS mit Ihrer Bounce-Subdomain (nicht email-od.com), DKIM: PASS mit d=yourdomain.com und DMARC: PASS sehen. Der "via email-od.com"-Hinweis sollte verschwunden sein.
Einzutragende Einträge
SocketLabs erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| CNAME | tracking.socketlabs.comCustom Bounce Domain — dies ist es, was SPF trägt und AUSRICHTET. Das Subdomain-Label (email/bounce/…) ist das, was SocketLabs zuweist; verwenden Sie es auch für das White-Labeling des Engagement-Trackings wieder. | |
| CNAME | dkim._domainkey | dkim._domainkey.email-od.comCNAME DKIM (empfohlen, am einfachsten) — SocketLabs besitzt und rotiert den Schlüssel. Der Selector ist dkim; d= wird zu Ihrer Domain, sodass DKIM ausgerichtet ist. |
| TXT | sl2026._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…(public key from the DKIM Key Generator)Alternative zur CNAME-Methode — nutzen Sie den Advanced/TXT-DKIM-Weg nur, wenn Sie den Schlüssel kontrollieren möchten. Der Selector (hier sl2026) ist Ihre Wahl: alphanumerisch, unter 10 Zeichen. Beispielwert — der Generator verwendet standardmäßig einen 2048-Bit-Schlüssel, pro Konto erzeugt. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu — SocketLabs erstellt ihn nie. Einer pro Domain; beginnen Sie bei p=none, verschärfen Sie dann auf quarantine/reject. |
| TXT | @ | v=spf1 include:email-od.com ~allNUR OPTIONALES Doppelt-hält-besser. Nicht erforderlich, wenn Sie die Custom Bounce Domain eingerichtet haben, und richtet SPF für sich allein nicht aus. Kostet 1 Lookup; führen Sie es in Ihre einzige Root-SPF-Zeile zusammen, falls Sie es nutzen. |
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 SocketLabs von diesem Budget verbraucht.
Die empfohlene Einrichtung von SocketLabs fügt 0 Lookups hinzu — alle 10 bleiben frei für die Absender, die tatsächlich ein include benötigen.
DKIM
SocketLabs signiert standardmäßig jede Nachricht, aber mit d=email-od.com, was nicht zu Ihrer Domain ausgerichtet ist — Custom DKIM ist also das, was DKIM tatsächlich für Sie funktionieren lässt, und es gibt zwei Wege der Einrichtung. Die CNAME-DKIM-Signing-Funktion ist die einfachste: Sie veröffentlichen ein einzelnes CNAME, Host = dkim._domainkey.yourdomain.com, das auf dkim._domainkey.email-od.com zeigt, und weil es ein CNAME ist (kein Schlüssel, den Sie einfügen), behält SocketLabs die Kontrolle sowohl über den privaten als auch den öffentlichen Schlüssel und rotiert sie für Sie — Sie bearbeiten das DNS nie wieder. Der Selector ist schlicht dkim, und sobald verifiziert, signiert SocketLabs Ihre Post mit d=yourdomain.com, sodass DKIM ausgerichtet ist. Die Advanced/TXT-Methode gibt Ihnen mehr Kontrolle: In Domain Management führen Sie den DKIM Key Generator aus, wählen einen Selector (alphanumerisch, weniger als 10 Zeichen, z. B. sl2026), und SocketLabs erzeugt das Schlüsselpaar — speichert den privaten Schlüssel in Ihrem Konto und übergibt Ihnen den öffentlichen Schlüssel zur Veröffentlichung als TXT-Record unter <selector>._domainkey.yourdomain.com in der Form v=DKIM1; k=rsa; p=…. Der Generator verwendet standardmäßig einen 2048-Bit-Schlüssel (eine 1024-Bit-Option existiert, aber belassen Sie es bei 2048 — der stärkere Schlüssel ist der moderne Standard und SocketLabs empfiehlt, ihn nicht zu verringern). Es gibt außerdem eine "Bring your own TXT record"-Variante, bei der Sie einen extern erzeugten privaten Schlüssel bereitstellen. Eine harte Anforderung des TXT-Wegs: Das Portal lässt Sie erst speichern, wenn es Ihren veröffentlichten öffentlichen Schlüssel aus dem DNS auflösen kann, und nach dem Speichern wird der öffentliche Schlüssel im Portal nicht mehr angezeigt — veröffentlichen Sie ihn also zuerst. Ein Vorbehalt, der für BEIDE Methoden gilt: Ihre Custom-DKIM-Signatur wird nur auf Nachrichten angewendet, deren From-Adresse (die Purported Responsible Address) exakt mit der konfigurierten Domain übereinstimmt — Post, die von einer anderen From-Domain gesendet wird, fällt auf die Standard-Signatur email-od.com zurück und wird nicht ausgerichtet. Konfigurieren Sie DKIM daher für jede Domain, von der Sie senden.
DMARC
DMARC ist ein separater Policy-TXT-Record, den SocketLabs nicht erstellt — Sie veröffentlichen ihn selbst bei Ihrem DNS-Host. Fügen Sie einen TXT-Record unter _dmarc.yourdomain.com hinzu, beginnend mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist reiner Monitor-Modus: An der Zustellung ändert sich nichts, während Sie die aggregierten (rua-)Berichte beobachten, um zu bestätigen, dass SocketLabs-Post SPF und DKIM ausgerichtet zu Ihrer Domain besteht. Weil die Custom Bounce Domain Ihnen SPF-Alignment und Custom DKIM Ihnen DKIM-Alignment verschafft, besteht eine korrekt konfigurierte SocketLabs-Domain DMARC über BEIDE Mechanismen — das belastbare Setup, das Weiterleitungen übersteht, denn eine Weiterleitung, die SPF bricht, hinterlässt immer noch eine ausgerichtete DKIM-Signatur. Beobachten Sie die Berichte ein bis zwei Wochen lang, stellen Sie sicher, dass jeder legitime Versender (SocketLabs plus alle anderen Tools auf der Domain) authentifiziert, und verschärfen Sie dann die Policy auf p=quarantine und schließlich p=reject. Halten Sie genau einen _dmarc-Record für die gesamte organisatorische Domain, egal wie viele Versender Sie nutzen; fügen Sie niemals einen zweiten DMARC-Record nur für SocketLabs hinzu.
Prüfen, ob es wirklich funktioniert hat
Vertrauen Sie nicht allein den Badges "authenticated" und "active" des Portals — bestätigen Sie es an einer echten Nachricht. Senden Sie einen Test von einer Adresse auf der konfigurierten Domain an ein Gmail-Postfach, öffnen Sie ihn und wählen Sie ⋮ → Original anzeigen: Sie wollen SPF: PASS mit Ihrer Bounce-Subdomain (z. B. email.yourdomain.com, NICHT email-od.com), DKIM: PASS mit d=yourdomain.com und DMARC: PASS sehen. Das verräterische Fehlersignal ist SPF/DKIM, das weiterhin email-od.com anzeigt — das bedeutet, dass die Bounce-Domain und/oder Custom DKIM noch nicht aktiv sind, oder dass Sie von einer nicht konfigurierten From-Domain gesendet haben. Sie können die Roh-Records stichprobenartig prüfen mit dig CNAME email.yourdomain.com (sollte zu tracking.socketlabs.com auflösen), dig CNAME dkim._domainkey.yourdomain.com (oder dig TXT <selector>._domainkey.yourdomain.com für die TXT-Methode) und dig TXT _dmarc.yourdomain.com. Lassen Sie Ihre Domain anschließend durch Qualisends Domain-Health-Check laufen, um zu bestätigen, dass jeder Record sauber auflöst, und sobald DMARC-Aggregatberichte eintreffen, geben Sie einen in den DMARC-Report-Analyzer — SocketLabs sollte als ausgerichtete, vollständig bestehende Quelle erscheinen.
Häufige Stolperfallen
- Abdeckung
Der standardmäßige "via email-od.com"-Tag bedeutet, dass Sie noch nicht ausgerichtet sind: Bis Sie SOWOHL eine Custom Bounce Domain ALS AUCH Custom DKIM eingerichtet haben, authentifiziert SocketLabs als email-od.com, sodass SPF und DKIM bestehen, DMARC das Alignment aber nicht besteht. Der Tag verschwindet erst, wenn beide auf Ihre Domain zeigen.
- DNS-Einrichtung
include:email-od.com zu Ihrem Root-SPF hinzuzufügen ist für sich allein NICHT die Lösung. Es autorisiert die versendenden IPs, aber der Return-Path ist weiterhin email-od.com, sofern Sie nicht das Bounce-Domain-CNAME veröffentlichen — und es ist das Bounce-CNAME, nicht der include, das SPF tatsächlich ausrichtet. Überspringen Sie das CNAME nicht in der Annahme, der include decke es ab.
- Abdeckung
Custom DKIM signiert nur Post, deren From-Adresse exakt mit der konfigurierten Domain übereinstimmt (die Purported Responsible Address). Senden Sie von einer anderen From-Domain, fällt SocketLabs stillschweigend auf die Standard-Signatur email-od.com zurück, sodass DKIM nicht ausgerichtet wird — konfigurieren Sie jede Versanddomain.
- DNS-Einrichtung
Manche DNS-Anbieter akzeptieren keinen Unterstrich in einem CNAME-Host, was die dkim._domainkey-CNAME-Methode blockiert. Wenn Ihrer ihn ablehnt, nutzen Sie stattdessen den Advanced/TXT-DKIM-Weg (DKIM Key Generator) — der TXT-Record mit dem öffentlichen Schlüssel umgeht die Unterstrich-CNAME-Beschränkung.
- DNS-Einrichtung
Der Cloudflare-Proxy bricht beide CNAMEs: Stellen Sie das Bounce-Domain-CNAME und das DKIM-CNAME auf "DNS only" (graue Wolke). Ein per Orange-Cloud proxytes CNAME löst nicht zu tracking.socketlabs.com / email-od.com auf und die Verifizierung schlägt fehl.
- Abdeckung
Subaccounts authentifizieren separat. SocketLabs' Subaccount-Modell bedeutet, dass jeder Subaccount seine eigene Custom Bounce Domain und DKIM-Authentifizierung braucht — die Authentifizierung des Master-Accounts deckt sie nicht ab.
- DNS-Einrichtung
Die Verifizierung kann 24–48 Stunden hinterherhinken. Die Propagation dauert meist Minuten, aber SocketLabs prüft das CNAME/TXT verzögert erneut, sodass "authenticated"/"active" möglicherweise nicht sofort umspringt, selbst wenn Ihr DNS bereits korrekt ist — verifizieren Sie mit Original anzeigen, statt auf das Badge zu warten.
- DNS-Einrichtung
Host-Feld-Verdopplung: Registrare, die Ihre Domain automatisch anhängen, machen aus dkim._domainkey.yourdomain.com ein dkim._domainkey.yourdomain.com.yourdomain.com. Geben Sie nur das Label ein (email, dkim._domainkey, <selector>._domainkey), wenn Ihr Panel die Domain für Sie ergänzt.
- Bricht die Authentifizierung
Halten Sie genau einen SPF- und einen DMARC-Record pro Domain. Wenn Sie den optionalen include:email-od.com hinzufügen, führen Sie ihn in Ihre einzige v=spf1-Zeile zusammen — zwei SPF-Records sind ein PermError, und ein zweiter _dmarc-Record ebenso.
Erstellen Sie Ihren SPF-Eintrag
SocketLabs benötigt kein SPF-include: auf Ihrer Root-Domain — nutzen Sie den Generator, um für Ihre übrigen Absender einen sauberen Eintrag zusammenzustellen, und halten Sie ihn auf einer einzigen Zeile.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
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).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- 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 listSocketLabs 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.