SPF, DKIM & DMARC für SMTP.com.
SMTP.com ist ein SMTP-Relay mit E-Mail-API — Sie richten Ihre App, Ihr CRM oder Ihren Mailserver darauf aus, und SMTP.com stellt in Ihrem Namen zu. Deshalb muss Ihre eigene Domain den Dienst autorisieren. Die Einrichtung besteht aus drei DNS-Einträgen plus einem Schalter auf Kontoseite: ein echter SPF-include (include:_spf.smtp.com), den Sie in Ihren Root-SPF integrieren, ein DKIM-CNAME für Ihre eigene Domain auf dem Selektor smtpkey, den SMTP.com zusätzlich in Ihrem Konto aktivieren muss, damit E-Mails als Ihre Domain statt als die geteilte Domain signiert werden, und ein DMARC-Richtlinieneintrag, den Sie selbst veröffentlichen. Sind alle drei aufeinander abgestimmt, relayt SMTP.com vollständig authentifiziert in Ihrem Namen — mit DKIM, das auf Ihre From-Domain ausgerichtet ist, sodass DMARC besteht, statt sich auf die geteilte Signierdomain von SMTP.com zu stützen.
Warum SMTP.com authentifizieren?
Ob Ihre E-Mails im Posteingang landen, entscheidet sich daran, ob Sie die Domain authentifizieren, über die Sie via SMTP.com relayen — und bei einem Relay mit hohem Volumen steht mehr auf dem Spiel als bei einem Postfach-Hoster. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob ab 5.000 Nachrichten pro Tag), dass er SPF, DKIM und DMARC mit Alignment besteht, und Microsoft hat 2025 begonnen, dasselbe für E-Mail mit hohem Volumen an Outlook.com/Hotmail/Live durchzusetzen — genau die Volumina, für die Menschen SMTP.com einsetzen. Der relay-spezifische Haken: Standardmäßig signiert SMTP.com Ihre ausgehende Post per DKIM mit einer seiner eigenen geteilten Domains (d=smtpsend.com) und wickelt Bounces über seinen eigenen Return-Path ab, sodass weder SPF noch DKIM auf Ihre From-Domain ausgerichtet ist. Das bedeutet: Eine nicht konfigurierte SMTP.com-Domain hat überhaupt keinen ausgerichteten Mechanismus — DMARC kann nicht bestehen, Empfänger können einen Hinweis "via smtpsend.com" anzeigen, und die Versandreputation, für deren Aufbau Sie bezahlen, vermischt sich mit der jedes anderen nicht authentifizierten Versenders auf der geteilten Infrastruktur. Erst das Aktivieren des SPF-include und — entscheidend — von DKIM für die eigene Domain macht die Post kryptografisch zu Ihrer eigenen, lässt DMARC bestehen und sorgt dafür, dass sich Reputation unter Ihrer eigenen Domain aufbaut.
Die SPF-Realität bei SMTP.com
SMTP.com ist ein echter "include"-Anbieter: Sie fügen einen geteilten Mechanismus, include:_spf.smtp.com, dem einzigen SPF-TXT-Eintrag auf Ihrer Root-Domain hinzu, was v=spf1 include:_spf.smtp.com ~all ergibt. Es ist ein echter geteilter include — jeder SMTP.com-Kunde nutzt denselben — und er ist schlank: Der include löst zu einem flachen Eintrag auf, der nur zwei IPv4-Bereiche und seinen eigenen Softfail enthält (v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all), sodass er nur EINEN Ihrer 10 SPF-DNS-Lookups kostet — nicht zwei oder drei, wie manche gecachten Checker melden. Hier ist jedoch die ehrliche Feinheit, über die viele stolpern: Dieser include autorisiert die versendenden IPs von SMTP.com, aber er sorgt für sich allein noch nicht dafür, dass DMARC besteht. Standardmäßig relayt SMTP.com mit seiner eigenen Envelope-Sender-/Return-Path-Domain (es verarbeitet Ihre Bounces), und SPF wird immer gegen diese Envelope-Domain geprüft — die Prüfung besteht also gegenüber der Infrastruktur von SMTP.com, statt auf Ihre From-Domain ausgerichtet zu sein. Der include ist trotzdem der korrekte, dokumentierte, empfohlene SPF-Schritt (er verhindert rohe SPF-Fehler und ist das, was die Einrichtung von SMTP.com erwartet), weshalb Sie ihn veröffentlichen sollten — aber der Mechanismus, der Ihren DMARC-Pass tatsächlich trägt, ist der DKIM-CNAME für Ihre eigene Domain, der als d=yourdomain.com signiert. Behandeln Sie den include als notwendig, aber nicht hinreichend: Veröffentlichen Sie ihn und verlassen Sie sich dann auf DKIM für das Alignment (der einzige andere Weg zu einem ausgerichteten SPF wäre, mit SMTP.com eine eigene Return-Path-/Bounce-Domain unter Ihrer eigenen Domain einzurichten, was die meisten Konten zugunsten von DKIM überspringen). Und behalten Sie genau einen SPF-Eintrag auf der Domain — wenn Sie auch über Google Workspace, Microsoft 365 oder ein anderes Tool versenden, führen Sie include:_spf.smtp.com in dieser einen v=spf1-Zeile zusammen, statt einen zweiten SPF-TXT zu veröffentlichen (zwei SPF-Einträge sind ein PermError).
Schritt für Schritt
- 1
Bestimmen Sie die Domain, als die Sie relayen
Melden Sie sich beim SMTP.com Control Panel an und notieren Sie die From-Domain, als die Ihre App/API versendet (die Domain in Ihrem From:-Header, z. B. yourdomain.com). SMTP.com relayt Post für jede From-Adresse, die Sie setzen, sodass die Authentifizierung auf dieser organisatorischen Domain erfolgt — nicht auf einem SMTP.com-eigenen Host. Hier befinden sich auch Ihre Sender-/Relay-Zugangsdaten und die Einstellungen des Reputation Defender.
- 2
SPF-include hinzufügen oder zusammenführen
Erstellen Sie bei Ihrem DNS-Host EINEN TXT-Eintrag auf der Root (Host @ oder leer) mit v=spf1 include:_spf.smtp.com ~all. Falls bereits ein v=spf1-Eintrag existiert (Google Workspace, Microsoft 365, ein anderes Relay), fügen Sie keinen zweiten hinzu — führen Sie include:_spf.smtp.com neben den anderen Mechanismen in diesen einen Eintrag ein. Behalten Sie den Softfail ~all, den SMTP.com verwendet, sofern Sie nicht sicher sind, dass jeder Versender aufgeführt ist.
- 3
DKIM-Signierung für die eigene Domain aktivieren
Standardmäßig signiert SMTP.com mit seiner geteilten Domain (d=smtpsend.com), die sich NICHT ausrichtet. Damit Post als d=yourdomain.com auf dem Selektor smtpkey signiert wird, muss die DKIM-Signierung für die eigene Domain in Ihrem Konto aktiviert werden — das ist ein Schalter auf Kontoseite. Fordern Sie ihn also über den SMTP.com-Support oder Ihren Account-Manager an und bestätigen Sie den genauen Selektor/das genaue Ziel, das man Ihnen zuweist (das weithin veröffentlichte Paar steht unten).
- 4
DKIM-CNAME hinzufügen
Erstellen Sie einen CNAME-Eintrag: Host smtpkey._domainkey (also smtpkey._domainkey.yourdomain.com), der auf smtpcustomer._domainkey.smtpsend.com zeigt. Das ist eine Delegation — SMTP.com hält den privaten Schlüssel hinter diesem geteilten Ziel und signiert in Ihrem Namen. Behalten Sie den Typ CNAME; ändern Sie ihn nicht zu TXT oder A.
- 5
DMARC-Eintrag veröffentlichen
SMTP.com erstellt DMARC nicht für Sie. Fügen Sie einen TXT-Eintrag unter Host _dmarc mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com hinzu. p=none ist reiner Überwachungsmodus, sodass sich nichts an der Zustellung ändert, während Sie bestätigen, dass die Post von SMTP.com signiert und ausgerichtet wird; Sie verschärfen ihn später.
- 6
Host-Verdopplung und den Cloudflare-Proxy beheben
Wenn Ihr Registrar die Domain automatisch anhängt, geben Sie nur das Label ein (smtpkey._domainkey, und @ für SPF), damit Sie nicht bei smtpkey._domainkey.yourdomain.com.yourdomain.com landen. Setzen Sie den DKIM-CNAME bei Cloudflare auf 'DNS only' (graue Wolke) — ein per orangefarbener Wolke geproxyter CNAME löst nicht zu smtpsend.com auf, und die DKIM-Validierung schlägt fehl.
- 7
Testnachricht senden und die Header lesen
Sobald das eigene DKIM aktiviert ist und die Einträge propagiert sind (meist Minuten, bis zu 24–72 Stunden), relayen Sie eine Testnachricht über SMTP.com an eine Gmail-Adresse, öffnen sie und wählen ⋮ → Original anzeigen. Sie möchten DKIM: PASS mit d=yourdomain.com und Selektor smtpkey (das verräterische Fehlerzeichen ist d=smtpsend.com, was bedeutet, dass die eigene Signierung noch nicht aktiv ist), SPF: PASS und DMARC: PASS.
- 8
Bestätigen, dass jeder Eintrag auflöst
Prüfen Sie Ihre Domain mit Qualisends Domain-Health-Check, um zu bestätigen, dass der SPF bei einem Eintrag unter dem 10-Lookup-Limit bleibt, der CNAME smtpkey._domainkey zu smtpsend.com auflöst und der DMARC-Eintrag vorhanden ist. Sobald Aggregat-Berichte eintreffen, laden Sie einen in den DMARC-Berichtsanalysator, um SMTP.com als ausgerichtete, bestehende Quelle erscheinen zu sehen.
Einzutragende Einträge
SMTP.com 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.smtp.com ~allRoot-SPF — behalten Sie genau EINEN SPF-Eintrag; führen Sie diesen include zusammen, falls Sie bereits eine v=spf1-Zeile haben. include:_spf.smtp.com löst flach auf (zwei ip4-Bereiche + ~all) und kostet damit 1 DNS-Lookup. Autorisiert die IPs von SMTP.com, richtet sich aber standardmäßig nicht aus. |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comDKIM für die eigene Domain (der ausgerichtete Mechanismus). Illustrativ — dies ist das weithin dokumentierte geteilte Ziel, aber bestätigen Sie den genauen Selektor/das genaue Ziel, das SMTP.com Ihrem Konto zuweist. SMTP.com muss ZUSÄTZLICH die eigene Signierung auf Kontoseite aktivieren, sonst tut der CNAME nichts. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu — SMTP.com erstellt ihn nie. Ein DMARC-Eintrag pro Domain; beginnen Sie bei p=none und verschärfen Sie dann auf quarantine/reject, sobald DKIM sich sauber ausrichtet. |
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 SMTP.com von diesem Budget verbraucht.
SMTP.com verbraucht 1 Ihrer 10 Lookups; ip4:- und ip6:-Mechanismen sind kostenlos.
DKIM
DKIM ist der Teil, der Ihren DMARC-Pass bei SMTP.com tatsächlich verdient, und es ist der Schritt, den die meisten übersehen, weil SMTP.com bereits signiert, bevor Sie überhaupt etwas tun — nur eben mit der falschen Domain. Standardmäßig signiert das Relay Ihre ausgehende Post per DKIM mit einer seiner eigenen geteilten Domains (d=smtpsend.com). Diese Signatur ist kryptografisch gültig, aber weil es nicht Ihre Domain ist, richtet sie sich nicht aus und tut daher nichts für DMARC auf yourdomain.com. Um das zu beheben, aktivieren Sie DKIM für die eigene Domain, was aus zwei aufeinander abgestimmten Aktionen besteht: (1) Veröffentlichen Sie einen CNAME unter smtpkey._domainkey.yourdomain.com, der auf smtpcustomer._domainkey.smtpsend.com zeigt, und (2) lassen Sie SMTP.com Ihr Konto so umstellen, dass es mit Ihrer Domain auf dem Selektor smtpkey signiert — das ist ein Schalter auf Kontoseite, der üblicherweise über den SMTP.com-Support oder Ihren Account-Manager eingerichtet wird. Öffnen Sie also ein Ticket und bestätigen Sie den genauen Selektor/das genaue Ziel, das man Ihnen ausgibt (manche Konten erhalten möglicherweise ein anderes Paar). Da der Eintrag ein CNAME ist (kein TXT-Schlüssel, den Sie einfügen), hält SMTP.com den privaten Schlüssel hinter diesem geteilten Ziel und kann ihn rotieren, ohne dass Sie das DNS erneut anfassen müssen — der Kompromiss des Modells mit geteiltem Ziel besteht darin, dass der Schlüssel nicht einzigartig für Sie ist, aber Alignment hängt nicht von der Einzigartigkeit des Schlüssels ab: Entscheidend ist, dass der d=-Wert der Signatur Ihre organisatorische Domain ist, was er wird, sobald die eigene Signierung aktiv ist. Der veröffentlichte Eintrag auf Ihrer Seite ist klein und statisch; die eigentliche Arbeit (das tatsächliche Signieren) geschieht auf den Servern von SMTP.com. Bis SOWOHL der CNAME auflöst ALS AUCH die eigene Signierung aktiviert ist, wird Original anzeigen weiterhin d=smtpsend.com melden und DMARC keinen ausgerichteten Mechanismus haben.
DMARC
DMARC ist ein separater Richtlinien-TXT-Eintrag auf Ihrer Domain, den SMTP.com nicht erstellt — Sie veröffentlichen ihn bei Ihrem DNS-Host. Fügen Sie einen TXT-Eintrag unter _dmarc.yourdomain.com hinzu, der mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com beginnt. p=none ist reiner Überwachungsmodus: Es ändert nichts an der Zustellung, weist Empfänger aber an, Ihnen Aggregat-Berichte (rua) zu senden, damit Sie bestätigen können, dass die SMTP.com-Post DKIM besteht, ausgerichtet auf Ihre Domain, bevor Sie irgendetwas durchsetzen. Dieser Überwachungsschritt ist bei SMTP.com wichtiger als üblich, gerade weil sein SPF sich standardmäßig nicht ausrichtet — über die Berichte prüfen Sie, ob der eigene DKIM-CNAME das Alignment tatsächlich trägt. Beobachten Sie sie ein bis zwei Wochen, stellen Sie sicher, dass jede legitime Quelle (SMTP.com plus alle anderen Versender) authentifiziert, und verschärfen Sie dann die Richtlinie auf p=quarantine und schließlich p=reject. Gehen Sie NICHT direkt zu einer strengen Richtlinie über, bevor Sie bestätigt haben, dass DKIM als d=yourdomain.com signiert — ist die eigene Signierung noch nicht aktiviert, wird ein p=reject-Eintrag Ihre eigene relayte Post zurückweisen. Behalten Sie genau einen _dmarc-Eintrag für die gesamte Domain, unabhängig davon, wie viele Versender Sie nutzen; fügen Sie niemals einen zweiten DMARC-Eintrag speziell für SMTP.com hinzu.
Prüfen, ob es wirklich funktioniert hat
Vertrauen Sie nicht allein dem Control Panel oder einem Propagierungs-Timer — bestätigen Sie die Authentifizierung an einer echten Nachricht. Relayen Sie eine Testnachricht über SMTP.com an ein Gmail- (oder Outlook-)Postfach, öffnen Sie sie und wählen Sie ⋮ → Original anzeigen. Sie möchten DKIM: PASS mit d=yourdomain.com und Selektor smtpkey — wenn Sie d=smtpsend.com sehen, ist die eigene Signierung noch nicht aktiv, der CNAME ist also veröffentlicht, aber SMTP.com hat Ihr Konto nicht umgestellt. Sie möchten außerdem SPF: PASS (es wird bestehen, aber denken Sie daran, dass es auf die Envelope-Domain von SMTP.com ausgerichtet ist, nicht auf Ihre Domain, sofern Sie keinen eigenen Return-Path eingerichtet haben) und DMARC: PASS, was hier durch das DKIM-Alignment verdient werden sollte. Lieber ein vollständiger Bericht? Senden Sie eine Testnachricht an check-auth@verifier.port25.com, und es kommt eine zeilenweise Aufschlüsselung per E-Mail zurück. Prüfen Sie die Domain anschließend mit Qualisends Domain-Health-Check, um zu bestätigen, dass Ihr SPF ein einziger Eintrag unter dem 10-Lookup-Limit ist, der CNAME smtpkey._domainkey sauber zu smtpsend.com auflöst und DMARC vorhanden ist — und sobald Aggregat-Berichte eintreffen, laden Sie einen in den DMARC-Berichtsanalysator, um SMTP.com als ausgerichtete, bestehende Quelle erscheinen zu sehen.
Häufige Stolperfallen
- DNS-Einrichtung
Der SPF-include besteht, richtet sich aber standardmäßig NICHT aus. Standardmäßig relayt SMTP.com mit seiner eigenen Return-Path-/Envelope-Domain, sodass include:_spf.smtp.com die IPs autorisiert und die rohe SPF-Prüfung gegen SMTP.com besteht — nicht gegen Ihre From-Domain. Den include allein hinzuzufügen verschafft Ihnen keinen DMARC-Pass; das tut der eigene DKIM-CNAME.
- Bricht die Authentifizierung
Von Haus aus signiert DKIM als d=smtpsend.com (die geteilte Domain von SMTP.com), was gültig ist, sich aber nicht ausrichtet. Sie müssen DKIM für die eigene Domain aktivieren, damit Post als d=yourdomain.com auf dem Selektor smtpkey signiert wird — sonst hat DMARC überhaupt keinen ausgerichteten Mechanismus.
- Bricht die Authentifizierung
Eigenes DKIM ist ein Schalter auf Kontoseite, nicht nur ein DNS-Eintrag. Das Veröffentlichen des CNAME smtpkey._domainkey bewirkt nichts, bis SMTP.com die eigene Signierung für Ihr Konto aktiviert — öffnen Sie ein Support-Ticket / fragen Sie Ihren Account-Manager und bestätigen Sie dann den genauen Selektor und das genaue Ziel, das man Ihnen zuweist.
- DNS-Einrichtung
Das Ziel des DKIM-CNAME ist ein geteilter Host (smtpcustomer._domainkey.smtpsend.com), und das ist so gewollt, kein Copy-Paste-Fehler. SMTP.com hält den privaten Schlüssel dahinter und rotiert ihn für Sie; das Alignment funktioniert trotzdem, weil das d= der Signatur Ihre Domain ist. Behalten Sie es als CNAME — niemals als TXT.
- DNS-Einrichtung
Der Cloudflare-Proxy zerstört den DKIM-CNAME. Setzen Sie smtpkey._domainkey auf 'DNS only' (graue Wolke) — ein per orangefarbener Wolke geproxyter CNAME löst nicht zu smtpsend.com auf, und die DKIM-Aktivierung schlägt fehl.
- Bricht die Authentifizierung
Behalten Sie genau EINEN SPF-TXT-Eintrag auf der Root. Wenn Sie bereits über Google Workspace, Microsoft 365 oder ein anderes Relay versenden, führen Sie include:_spf.smtp.com in diese eine v=spf1-Zeile ein — zwei SPF-Einträge sind selbst ein PermError.
- DNS-Einrichtung
Verdopplung im Host-Feld: Viele Registrare hängen Ihre Domain automatisch an, sodass die Eingabe von smtpkey._domainkey.yourdomain.com zu smtpkey._domainkey.yourdomain.com.yourdomain.com wird. Geben Sie nur das Label ein (smtpkey._domainkey, und @ für den SPF-Eintrag), falls das Panel die Domain für Sie anhängt.
- Abdeckung
Verwenden Sie das ~all, mit dem der include von SMTP.com ausgeliefert wird, sofern Sie nicht jeden Versender inventarisiert haben. Ein verfrühtes -all kann legitime Post von einem Tool, das Sie derselben SPF-Zeile hinzuzufügen vergessen haben, hart abweisen.
Erstellen Sie Ihren SPF-Eintrag
SMTP.com 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 listSMTP.com 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.