Muss ich include:sparkpostmail.com zu meinem SPF-Record hinzufügen?

Für DMARC nicht. SparkPost besitzt den Envelope/Return-Path (die Standard-Bounce-Domain ist sparkpostmail.com), sodass ein Root-SPF-include für Ihre Domain nie ausgewertet wird und sich nicht ausrichten kann. Richten Sie stattdessen den DKIM-scph-TXT-Record und eine benutzerdefinierte Bounce Domain ein — das ist, was DMARC tatsächlich bestehen lässt. Der include existiert weiterhin und löst auf, aber er ist Altlast und optional, und hätten Sie ihn hinzugefügt, würde er zwei Ihrer zehn SPF-Lookups für nichts kosten (den include plus das exists-Makro im Record von SparkPost).

Warum besteht meine SparkPost-Post SPF, scheitert aber trotzdem an DMARC?

Weil der SPF-Pass nicht ausgerichtet ist. Mit der Standard-Bounce-Domain von SparkPost ist der Return-Path sparkpostmail.com, sodass SPF auf der Domain von SparkPost besteht, nicht auf Ihrer — und DMARC zählt SPF nur, wenn es sich mit Ihrer From-Domain ausrichtet. Fügen Sie eine benutzerdefinierte Bounce Domain hinzu (eine Subdomain, die per CNAME auf sparkpostmail.com zeigt), sodass der Envelope auf Ihrer Domain liegt, und stellen Sie sicher, dass Ihr DKIM-scph-Record verifiziert ist, damit auch DKIM sich ausrichtet.

Ist das DKIM von SparkPost ein CNAME oder ein TXT-Record?

Ein TXT-Record. SparkPost erzeugt einen RSA-Schlüssel und gibt Ihnen ein TXT unter scphNNNN._domainkey.yourdomain.com mit einem Wert v=DKIM1; k=rsa; h=sha256; p=…. Anders als bei CNAME-Delegationsanbietern veröffentlichen Sie den tatsächlichen Schlüssel, behalten Sie also den Record-Typ TXT bei und rotieren Sie ihn bei Bedarf manuell. Weil der Standardschlüssel 2048 Bit hat, muss der Wert auf manchen DNS-Panels möglicherweise in mehrere in Anführungszeichen gesetzte Strings aufgeteilt werden.

Was ist der Unterschied zwischen strict und relaxed Bounce-Ausrichtung?

Relaxed alignment (die Voreinstellung von DMARC) verwendet eine verwandte Subdomain — z. B. bounces.yourdomain.com oder mail.yourdomain.com als Return-Path, während Ihr From auf yourdomain.com liegt. Es besteht, solange die Bounce-Subdomain und Ihr From dieselbe Organisationsdomain teilen, und ist damit die praktische Wahl für die meisten Versender. Strict alignment verlangt, dass die Return-Path-Domain exakt mit Ihrer From-Domain übereinstimmt — bei SparkPost erreichen Sie das, indem Sie exakt Ihre Versand-Subdomain (z. B. mail.yourdomain.com) sowohl als Versanddomain als auch als Bounce Domain verwenden. Lassen Sie DMARC auf relaxed (aspf=r), es sei denn, Sie haben einen bestimmten Grund, strict zu erzwingen.

Wie richte ich SparkPost in der EU-Region ein?

SparkPost EU ist ein vollständig separater Stack. Melden Sie sich bei app.eu.sparkpost.com an, versenden Sie über smtp.eu.sparkpostmail.com / api.eu.sparkpost.com und zeigen Sie Ihren benutzerdefinierten Bounce-Domain-CNAME auf eu.sparkpostmail.com statt sparkpostmail.com. Das DKIM-scph-TXT und der DMARC-Record funktionieren gleich, aber dieselbe in US und EU registrierte Domain sind zwei unabhängige Konten mit ihren eigenen DNS-Records — veröffentlichen Sie die Records, die Ihnen das EU-Dashboard zeigt, nicht die US-Records.

Rotiert SparkPost meinen DKIM-Schlüssel automatisch?

Nein. Weil das DKIM von SparkPost ein TXT-Record ist, den Sie veröffentlichen (kein CNAME, der zu SparkPost zurückdelegiert wird), halten Sie den veröffentlichten öffentlichen Schlüssel, und es gibt keine stille Rotation. Um zu rotieren, erzeugen Sie in Configuration → Sending Domains einen frischen Schlüssel, veröffentlichen das neue scph-TXT, verifizieren es und entfernen dann den alten Record, sobald die Signierung umgeschaltet hat. Ab und zu zu rotieren ist gute Hygiene, aber es ist ein manueller Schritt.

Meine SparkPost-Domain oder Bounce Domain lässt sich nicht verifizieren — was ist falsch?

Meist eine von wenigen Sachen: DNS hat noch nicht propagiert (geben Sie ihm bis zu 24–48 Stunden); Ihr Registrar hat den Host verdoppelt (scph0421._domainkey.yourdomain.com wurde zu …yourdomain.com.yourdomain.com — geben Sie nur das Label ein); ein 2048-Bit-DKIM-Schlüssel, der aufgeteilt werden musste, wurde fehlerhaft eingefügt; oder, bei der Bounce Domain, ein per Orange-Cloud proxied CNAME auf Cloudflare, der nie zu sparkpostmail.com auflöst. Setzen Sie den Bounce-CNAME auf DNS only, prüfen Sie das Host-Feld erneut und klicken Sie dann noch einmal auf Verify.

SPF-Einrichtungsanleitung

SPF, DKIM & DMARC für SparkPost.

SparkPost (jetzt Teil von Bird, früher MessageBird) authentifiziert Ihre Domain unter Configuration → Sending Domains. Dort wird ein DKIM-Schlüssel erzeugt, den Sie als TXT-Record auf Ihrer Versanddomain veröffentlichen. Diese DKIM-Signatur — signiert als d=yourdomain.com — ist der Mechanismus, der Ihren DMARC-Pass tatsächlich trägt. SPF ist der SparkPost-spezifische Haken: Standardmäßig versendet SparkPost den Bounce-/Envelope-Absender von seiner eigenen geteilten Domain (sparkpostmail.com), sodass eine einfache SPF-Prüfung zwar auf der Domain von SparkPost besteht, aber niemals mit Ihrer ausgerichtet ist. Die Lösung ist eine benutzerdefinierte Bounce Domain — ein CNAME, der eine Subdomain von Ihnen auf sparkpostmail.com zeigt und zu Ihrem Return-Path wird, sodass auch SPF ausgerichtet ist. Fügen Sie einen DMARC-Policy-Record hinzu, und Sie haben alle drei — ausgerichtet, ohne dass Ihrem Root-SPF etwas hinzugefügt wird.

SPF-include

Your DNSAdd the CNAME / TXT records

SparkPostSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Warum SparkPost authentifizieren?

Die Authentifizierung Ihrer SparkPost-Domain ist keine Formsache — sie entscheidet darüber, ob Ihre transaktionale und Marketing-Post mit hohem Volumen überhaupt den Posteingang erreicht. 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 private Outlook-/Hotmail-/Live-Postfächer durchzusetzen — genau die Volumen, für die SparkPost gebaut ist. Solange Sie sich nicht authentifizieren, signiert SparkPost Ihre Post mit einem geteilten Schlüssel und lässt sie von sparkpostmail.com bouncen: Ihre From-Adresse gehört kryptografisch nicht Ihnen, DMARC kann nicht bestehen, und Ihre Reputation wird mit jedem anderen nicht authentifizierten Absender auf dieser Infrastruktur zusammengeworfen. Es gibt eine SparkPost-spezifische Besonderheit, die DKIM unverzichtbar macht: Weil SparkPost den Return-Path standardmäßig besitzt, besteht SPF zwar, ist aber nicht mit Ihrer Domain ausgerichtet — DKIM ist also der einzige Mechanismus, der Ihren DMARC-Pass trägt, bis Sie zusätzlich eine benutzerdefinierte Bounce Domain einrichten. DKIM plus eine Bounce Domain richtet beide Mechanismen auf Sie aus, beseitigt die Zweifel der Empfänger an Ihrer Identität, lässt DMARC bestehen und baut Versandreputation unter Ihrem eigenen Namen auf statt im geteilten Pool.

Die SPF-Realität bei SparkPost

SparkPost ist nominell ein "include"-Anbieter — include:sparkpostmail.com (und include:_spf.sparkpostmail.com, das denselben Record auflöst) existieren beide und lassen sich per DNS verifizieren — aber diesen include zu Ihrem Root-SPF hinzuzufügen, ist Altlast und lässt DMARC NICHT bestehen. Hier ist der Grund. Der aktive Record lautet v=spf1 exists:%{i}._spf.sparkpostmail.com ~all — ein exists:-Makro, das die ausgehenden IPs von SparkPost pro IP autorisiert (%{i} ist die sendende IP, geprüft gegen eine Wildcard-Zone), statt feste ip4:-Bereiche aufzulisten. SPF wird immer gegen die Envelope-Domain MAIL FROM / Return-Path ausgewertet, und diese Domain ist standardmäßig sparkpostmail.com, die SparkPost gehört. SPF wird also auf der Domain von SparkPost aufgelöst und besteht dort, richtet sich aber niemals mit Ihrer organisatorischen From-Domain aus — und DMARC zählt SPF nur, wenn es ausgerichtet ist. include:sparkpostmail.com auf Ihrer eigenen Root-Domain zu veröffentlichen, ändert daran nichts, denn Ihre Root-Domain ist niemals die Envelope-Domain; es verbrennt lediglich zwei Ihrer zehn SPF-Lookups (den include selbst plus den verschachtelten exists-Mechanismus im Record von sparkpostmail.com) ohne jeglichen Ausrichtungsvorteil. Der ausgerichtete SPF-Pfad ist eine benutzerdefinierte Bounce Domain: Sie zeigen eine Subdomain von Ihnen (z. B. bounces.yourdomain.com) per CNAME auf sparkpostmail.com, SparkPost verwendet diese Subdomain als Return-Path, und nun läuft die SPF-Prüfung gegen Ihre Subdomain (relaxed-aligned zu Ihrer Organisationsdomain), während sie über den CNAME weiterhin das SPF von sparkpostmail.com erbt. Deshalb gibt Ihnen der eigene Ablauf von SparkPost einen DKIM-TXT-Record und einen Bounce-Domain-CNAME, keine SPF-Zeile zum Einfügen an Ihrer Apex. Reservieren Sie Ihren Root-SPF-Record für Versender, die Ihre Domain tatsächlich in den Return-Path setzen (Google Workspace, Microsoft 365, ein Relay, das Sie kontrollieren), und lassen Sie den Bounce-CNAME + DKIM die Arbeit von SparkPost erledigen.

Zwei Wege zur Einrichtung

Benutzerdefinierte Bounce Domain + DKIM (empfohlen, ausgerichtet)

DKIM-TXT mit einem scph-Selector signiert Post als d=yourdomain.com — der Mechanismus, der DMARC tatsächlich bestehen lässt
Ein benutzerdefinierter Bounce-Domain-CNAME (z. B. bounces.yourdomain.com → sparkpostmail.com) richtet auch SPF auf Ihre Domain aus
Fügt Ihrem Root-SPF null DNS-Lookups hinzu — der Bounce-Record liegt auf seiner eigenen Subdomain, nicht auf Ihrer Apex
Funktioniert bei SparkPost US und EU gleich (bei EU zeigt der CNAME einfach auf eu.sparkpostmail.com)

Veraltet

Root-SPF-include (Altlast, richtet nicht aus)

Sie fügen v=spf1 include:sparkpostmail.com ~all selbst zu Ihrem Root-SPF hinzu
SparkPost besitzt den Envelope (Standard-Bounce = sparkpostmail.com), sodass dieses SPF sich niemals mit Ihrer Domain ausrichtet
Es bringt DMARC nichts — DKIM und die Bounce Domain erledigen weiterhin die gesamte Arbeit
Kostet zwei Ihrer 10 SPF-Lookups (den include plus den verschachtelten exists-Mechanismus) ohne Ausrichtungsvorteil; kann bedenkenlos ganz weggelassen werden

Schritt für Schritt

In SparkPost

1
Sending Domains öffnen und Ihre Domain hinzufügen
Melden Sie sich bei SparkPost an (app.sparkpost.com oder app.eu.sparkpost.com für EU-Konten) und gehen Sie zu Configuration → Sending Domains → Add Domain. Geben Sie die Domain oder Subdomain ein, von der Sie versenden werden (eine Subdomain wie mail.yourdomain.com ist üblich und hält die Versandreputation getrennt), und speichern Sie.
2
Den DKIM-Record kopieren, den SparkPost erzeugt
Auf dem Einrichtungsbildschirm der Domain zeigt SparkPost unter 'Set up for DKIM signing' einen DKIM-Record an. Es ist ein TXT-Record: Der Host ist ein automatisch erzeugter Selector wie scph0421._domainkey.yourdomain.com, und der Wert beginnt mit v=DKIM1; k=rsa; h=sha256; p=… gefolgt von Ihrem öffentlichen Schlüssel. SparkPost verwendet standardmäßig einen 2048-Bit-Schlüssel, daher ist der Wert lang — kopieren Sie das Ganze exakt.

In Ihrem DNS

3
Den DKIM-TXT-Record veröffentlichen
Erstellen Sie bei Ihrem DNS-Host einen TXT-Record mit dem Host scph0421._domainkey (unter Ihrer Versanddomain/-subdomain) und fügen Sie den vollständigen v=DKIM1…-Wert ein. Behalten Sie den TXT-Record bei — SparkPost-DKIM ist kein CNAME. Weil es ein 2048-Bit-Schlüssel ist, begrenzen manche Panels einen TXT-String auf 255 Zeichen und verlangen, ihn in mehrere in Anführungszeichen gesetzte Strings aufzuteilen — teilen Sie ihn auf, lassen Sie keine Zeichen weg. Wenn Ihr Panel die Domain automatisch anhängt, geben Sie nur das Label (scph0421._domainkey) ein, um eine Verdopplung zu vermeiden.

In SparkPost

4
Die Versanddomain verifizieren
Zurück auf dem Sending-Domains-Bildschirm setzen Sie das Häkchen zur Bestätigung, dass Sie den Record hinzugefügt haben, und klicken auf Verify Domain. Sobald er aufgelöst ist, wird die Domain als verifiziert angezeigt und 'DKIM Signing' gilt als bereit — SparkPost signiert erst mit Ihrem Schlüssel, wenn dies umschlägt. Die Propagation dauert in der Regel Minuten, kann aber bis zu 24–48 Stunden in Anspruch nehmen.
5
Eine benutzerdefinierte Bounce Domain hinzufügen
Gehen Sie zu Configuration → Bounce Domains (oder wählen Sie die Option Bounce Domain beim Hinzufügen einer Domain) und fügen Sie eine Subdomain hinzu, die den Return-Path besitzt — z. B. bounces.yourdomain.com für relaxed alignment oder verwenden Sie exakt Ihre Versand-Subdomain (mail.yourdomain.com) für strict alignment erneut. Das ist der Schritt, der Ihnen SPF-Ausrichtung verschafft.

In Ihrem DNS

6
Den Bounce-Domain-CNAME veröffentlichen
Erstellen Sie einen CNAME-Record: Host = Ihre Bounce-Subdomain (bounces), Wert = sparkpostmail.com (für SparkPost EU zeigen Sie ihn stattdessen auf eu.sparkpostmail.com). Bei Cloudflare setzen Sie den Record auf 'DNS only' (graue Wolke) — ein per Orange-Cloud proxied CNAME löst nicht zu SparkPost auf, und die Verifizierung schlägt fehl.

In SparkPost

7
Die Bounce Domain verifizieren
Kehren Sie zu Bounce Domains zurück und klicken Sie zum Verifizieren. Sobald es grün ist, verwendet SparkPost Ihre Subdomain als Envelope MAIL FROM, sodass SPF nun besteht UND sich mit Ihrer Organisationsdomain ausrichtet — ein zweiter ausgerichteter Mechanismus neben DKIM.

In Ihrem DNS

8
Einen DMARC-Policy-Record hinzufügen
SparkPost erstellt DMARC nicht für Sie. Fügen Sie einen TXT-Record beim Host _dmarc mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com hinzu. p=none ist reiner Überwachungsmodus, sodass sich an der Zustellung nichts ändert, während Sie bestätigen, dass SparkPost SPF und DKIM ausgerichtet besteht; Sie verschärfen es später.

Verifizieren

9
Einen Test senden und die Header lesen
Senden Sie sich über SparkPost eine Nachricht von einer Adresse auf der authentifizierten Domain, öffnen Sie sie in Gmail und wählen Sie ⋮ → Original anzeigen. Sie wollen DKIM: PASS, signiert von yourdomain.com (Selector scph…), SPF: PASS mit dem mailfrom auf Ihrer Bounce-Subdomain (nicht sparkpostmail.com), und DMARC: PASS. Bestätigen Sie dann mit einem {healthCheck}, dass jeder Record auflöst.

Einzutragende Einträge

SparkPost 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	scph0421._domainkey	v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIM — der ausgerichtete Mechanismus, der DMARC bestehen lässt. Der scph-Selector wird pro Konto automatisch erzeugt (z. B. scph0421, scph0717); Wert nur zur Veranschaulichung — kopieren Sie den exakten Record aus Configuration → Sending Domains. SparkPost verwendet standardmäßig einen 2048-Bit-Schlüssel, teilen Sie ihn also über mehrere in Anführungszeichen gesetzte Strings auf, wenn Ihr Panel TXT auf 255 Zeichen begrenzt. Veröffentlichen Sie ihn unter Ihrer Versanddomain/-subdomain, z. B. scph0421._domainkey.mail.yourdomain.com.
CNAME	bounces	sparkpostmail.comBenutzerdefinierte Bounce Domain (Return-Path) — das ist, was SPF auf Ihre Domain AUSRICHTET. Verwenden Sie eine Subdomain, nicht Ihre Apex. SparkPost EU zeigt diese auf eu.sparkpostmail.com. Setzen Sie bei Cloudflare 'DNS only' (graue Wolke).
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu — SparkPost erstellt ihn nie. Einer pro Domain; starten Sie bei p=none, steigern Sie dann auf quarantine/reject.
TXT	@	v=spf1 include:sparkpostmail.com ~allALTLAST / OPTIONAL — erzeugt KEINE DMARC-Ausrichtung, weil SparkPost den Envelope besitzt. Der obige Bounce-CNAME ist der ausgerichtete SPF-Pfad; fügen Sie diesen nur hinzu, wenn Sie möchten, dass Ihr reines SPF auf SparkPost verweist, und wenn ja, führen Sie ihn in Ihren einzigen Root-SPF-Record zusammen. Er kostet zwei Lookups — den include plus das verschachtelte exists-Makro im Record von sparkpostmail.com.

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 SparkPost von diesem Budget verbraucht.

SPF 10-lookup budget0 used · 10 free

Die empfohlene Einrichtung von SparkPost fügt 0 Lookups hinzu — alle 10 bleiben frei für die Absender, die tatsächlich ein include benötigen.

DKIM

DKIM ist der tragende Record für SparkPost, denn es ist der Mechanismus, der sich standardmäßig ausrichtet. Wenn Sie eine Versanddomain hinzufügen, erzeugt SparkPost ein RSA-Schlüsselpaar (standardmäßig 2048 Bit) und zeigt Ihnen einen TXT-Record zum Veröffentlichen: Der Host ist ein automatisch erzeugter Selector der Form scphNNNN._domainkey.yourdomain.com (zum Beispiel scph0421._domainkey — die vier Ziffern werden pro Konto/Schlüssel vergeben), und der Wert ist v=DKIM1; k=rsa; h=sha256; p=<Ihr öffentlicher Schlüssel>. Sie veröffentlichen dieses TXT bei Ihrem DNS-Host; SparkPost hält den passenden privaten Schlüssel und signiert damit jede ausgehende Nachricht, sodass die DKIM-Signatur d=yourdomain.com trägt und sich mit Ihrer From-Adresse ausrichtet. Zwei Dinge heben das DKIM von SparkPost von CNAME-Delegationsanbietern (SendGrid, Mailchimp, Klaviyo) ab. Erstens ist es ein TXT-Record, den Sie einfügen — kein CNAME —, sodass das Veröffentlichen eines CNAME dort, wo das scph-TXT erwartet wird, die Signierung bricht; behalten Sie den Record-Typ TXT bei. Zweitens gibt es, weil Sie den veröffentlichten Schlüssel halten statt ihn zu delegieren, keine automatische Schlüsselrotation: Wenn Sie jemals rotieren müssen, erzeugen Sie in SparkPost einen frischen Schlüssel und veröffentlichen das neue scph-TXT selbst neu. Eine praktische Feinheit der 2048-Bit-Voreinstellung: Der öffentliche Schlüssel überschreitet das TXT-Limit von 255 Zeichen pro Einzelstring, sodass viele DNS-Panels verlangen, ihn in mehrere in Anführungszeichen gesetzte Strings aufzuteilen (SparkPost kann stattdessen einen 1024-Bit-Schlüssel ausstellen, falls Ihr Host kein Multi-String-TXT verarbeiten kann). Den Record zu veröffentlichen, reicht allein nicht — Sie müssen zu Configuration → Sending Domains zurückkehren und auf Verify Domain klicken, damit die Domain als verifiziert angezeigt wird und 'DKIM Signing' als bereit gilt; SparkPost signiert erst mit Ihrem Schlüssel, wenn dies umschlägt.

DMARC

DMARC ist ein separater Policy-Record, den Sie selbst hinzufügen — SparkPost erstellt ihn nicht. Veröffentlichen Sie einen TXT-Record unter _dmarc.yourdomain.com, der mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com beginnt. p=none ist reiner Überwachungsmodus: Es ändert nichts an der Zustellung, während Empfänger Ihnen aggregierte (rua-)Berichte per E-Mail senden, sodass Sie bestätigen können, dass SparkPost-Post SPF und DKIM besteht, ausgerichtet auf Ihre Domain. Hier zahlt sich das zweiteilige SparkPost-Setup aus — sobald Ihr DKIM-scph-Record verifiziert ist, erhalten Sie DKIM-Ausrichtung, und sobald Ihre benutzerdefinierte Bounce Domain verifiziert ist, erhalten Sie auch SPF-Ausrichtung, sodass eine korrekt konfigurierte SparkPost-Domain DMARC über beide Mechanismen besteht, statt sich allein auf DKIM zu stützen. Beobachten Sie die Berichte ein bis zwei Wochen, stellen Sie sicher, dass jeder legitime Versender (SparkPost plus alles andere, das Sie nutzen) authentifiziert, und verschärfen Sie dann auf p=quarantine und schließlich p=reject. Behalten Sie genau einen _dmarc-Record für die gesamte Organisationsdomain, egal wie viele Versender Sie betreiben — veröffentlichen Sie niemals einen zweiten DMARC-Record speziell für SparkPost.

Prüfen, ob es wirklich funktioniert hat

Vertrauen Sie nicht allein den grünen Häkchen im Dashboard — bestätigen Sie es an einer echten Nachricht. Senden Sie sich über SparkPost eine Testnachricht von einer Adresse auf der authentifizierten Domain, öffnen Sie sie in Gmail und wählen Sie ⋮ → Original anzeigen. Sie wollen DKIM: PASS, signiert von yourdomain.com mit dem scph-Selector (nicht einer geteilten SparkPost-Domain), SPF: PASS, wobei der mailfrom/Return-Path Ihre Bounce-Subdomain zeigt (bounces.yourdomain.com — das verräterische Fehlersignal ist ein mailfrom, der noch auf sparkpostmail.com liegt, was bedeutet, dass Ihre benutzerdefinierte Bounce Domain nicht eingerichtet ist), und DMARC: PASS. In SparkPost sollte Configuration → Sending Domains die Domain als verifiziert mit DKIM Signing bereit anzeigen, und Bounce Domains sollte Ihre Bounce-Subdomain als verifiziert anzeigen. Führen Sie Ihre Domain dann durch den {healthCheck} von Qualisend, um zu bestätigen, dass das DKIM-TXT, der Bounce-CNAME und der DMARC-Record alle sauber auflösen, und sobald DMARC-Aggregatberichte eintreffen, werfen Sie einen davon in den {dmarcAnalyzer} — SparkPost sollte als ausgerichtete, bestehende Quelle erscheinen.

Domain-Health-Check DMARC-Berichtsanalyse

Häufige Stolperfallen

DNS-Einrichtung
Die große Falle: include:sparkpostmail.com zu Ihrem Root-SPF hinzuzufügen, lässt DMARC NICHT bestehen. SparkPost besitzt den Envelope (Standard-Bounce-Domain = sparkpostmail.com), sodass Ihr Root-SPF für SparkPost-Post nie herangezogen wird. Die Ausrichtung kommt vom DKIM-scph-TXT plus einem benutzerdefinierten Bounce-Domain-CNAME — nicht von einem SPF-include.
Abdeckung
Mit der Standard-Bounce-Domain besteht SPF auf sparkpostmail.com, richtet sich aber nicht auf Sie aus, sodass DMARC vollständig auf DKIM lehnt. Fügen Sie eine benutzerdefinierte Bounce Domain hinzu, um einen ausgerichteten zweiten Mechanismus zu erhalten und strengere Empfänger zu überstehen.
DNS-Einrichtung
SparkPost-DKIM ist ein TXT-Record (scph-Selector), kein CNAME. Wechseln Sie den Typ nicht — ein CNAME dort, wo das scph-TXT hingehört, bricht die DKIM-Signierung. Und es gibt keine automatische Schlüsselrotation: Um zu rotieren, erzeugen Sie in SparkPost einen neuen Schlüssel und veröffentlichen das TXT neu.
DNS-Einrichtung
SparkPost verwendet standardmäßig einen 2048-Bit-DKIM-Schlüssel, dessen Wert länger ist als das TXT-Limit von 255 Zeichen. Manche DNS-Panels zwingen Sie, ihn in mehrere in Anführungszeichen gesetzte Strings aufzuteilen — teilen Sie ihn auf, kürzen Sie ihn nicht und fügen Sie keine versehentlichen Leerzeichen im p=-Wert ein.
DNS-Einrichtung
Der Cloudflare-Proxy bricht den Bounce-CNAME. Setzen Sie den Bounce-Domain-Record auf 'DNS only' (graue Wolke) — ein per Orange-Cloud proxied CNAME löst nicht zu sparkpostmail.com auf, und die Domain wird nicht verifiziert.
DNS-Einrichtung
Sie können Ihre Root/Apex nicht als Bounce Domain verwenden — ein CNAME auf der Apex kollidiert mit Ihren anderen Records. Verwenden Sie eine Subdomain (bounces.yourdomain.com für relaxed alignment oder verwenden Sie exakt Ihre Versand-Subdomain für strict alignment erneut).
DNS-Einrichtung
SparkPost EU ist ein separater Stack: Melden Sie sich bei app.eu.sparkpost.com an, versenden Sie über smtp.eu.sparkpostmail.com / api.eu.sparkpost.com und zeigen Sie den Bounce-CNAME auf eu.sparkpostmail.com (nicht sparkpostmail.com). Dieselbe Domain in US und EU sind zwei unabhängige Registrierungen mit ihren eigenen DNS-Records.
Bricht die Authentifizierung
Behalten Sie genau ein SPF-TXT und ein _dmarc-TXT auf Ihrer Domain. Falls Sie das Altlast-SparkPost-include aus irgendeinem Grund behalten, führen Sie es in Ihre einzige v=spf1-Zeile zusammen — zwei SPF-Records sind selbst ein PermError.
DNS-Einrichtung
Verifizieren Sie nach der Veröffentlichung im Dashboard — SparkPost signiert erst per DKIM, wenn Configuration → Sending Domains die Domain als verifiziert anzeigt. Die Propagation kann bis zu 24–48 Stunden dauern; wenn die Verifizierung hängt, prüfen Sie den Record-Host erneut auf eine angehängte/verdoppelte Domain.

Erstellen Sie Ihren SPF-Eintrag

SparkPost 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).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

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 list

SparkPost SPF — FAQ

Weiterführende Lektüre

SPF, DKIM & DMARC erklärtWie die drei Records zusammenarbeiten — und warum Ausrichtung, nicht nur ein Pass, das ist, was DMARC tatsächlich prüft.So richten Sie DMARC einVeröffentlichen Sie Ihren _dmarc-Record und wechseln Sie von p=none zur Durchsetzung, ohne legitime SparkPost-Post zu blockieren.So lesen Sie DMARC-BerichteVerstehen Sie das rua-Aggregat-XML, damit Sie bestätigen können, dass SparkPost als ausgerichtete, bestehende Quelle auftaucht.Absenderanforderungen von Google & YahooDie Massenversender-Regeln von 2024, die ausgerichtetes SPF, DKIM und DMARC bei SparkPost-Volumen unverzichtbar machen.SPF, DKIM & DMARC bei CloudflareFügen Sie das DKIM-TXT und den Bounce-CNAME in Cloudflare korrekt hinzu, einschließlich den Bounce-Record auf DNS-only (graue Wolke) zu halten.Domain-ZustandsprüfungBestätigen Sie, dass das DKIM-scph-TXT, der Bounce-CNAME und Ihr DMARC-Record nach dem Setup alle sauber auflösen.

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.

Verifizierung starten