Defaults.Exposed › Behebungen › Guides
SPF scheitert bei Ihren SaaS-Tools? Warum das passiert und die Lösungsreihenfolge — Europa-Edition (2026)
Veröffentlicht 2026-07-08
Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.
Wenn ein SaaS-Tool „SPF nicht besteht“, ist Ihr Eintrag meist nicht das Problem: Die Mail scheitert am DMARC-Alignment, oder Ihre Include-Kette hat SPFs 10-DNS-Lookup-Limit gesprengt. 2.119.539 von 138.927.207 SPF-veröffentlichenden Domains stehen bei 9–10 Lookups — einen SaaS-Include vom Abgrund entfernt —, laut dem Defaults.Exposed-Zensus über 261.086.232 Domains.
Im Folgenden: wie Sie erkennen, welches der beiden Probleme Sie haben, dann die Lösungsreihenfolge — zuerst scannen, die Domain finden, von der das Tool wirklich sendet, den Anbieter auf Custom-Domain-DKIM umstellen, und einen SPF-Include nur hinzufügen, wo er wirklich hilft — plus die Besonderheiten für HubSpot, Salesforce, Mailchimp und SendGrid.
Warum scheitert Mail von einem SaaS-Tool an SPF?
Drei Muster decken fast jeden Fall ab:
| Was der Bericht oder Bounce sagt | Was wirklich falsch ist | Die Lösung |
|---|---|---|
| SPF besteht, DMARC scheitert trotzdem | Alignment: Das Tool hat SPF auf seiner Bounce-Domain bestanden, nicht Ihrer | Schalten Sie das Custom-Domain-DKIM des Anbieters ein (CNAMEs) |
SPF permerror | Ihre Include-Kette überschreitet SPFs 10-DNS-Lookup-Limit | Includes ausdünnen; siehe die Zu-viele-Lookups-Lösung |
SPF fail / softfail | Das Tool sendet wirklich mit Ihrem Return-Path und steht nicht in Ihrem Eintrag | Den Include des Anbieters hinzufügen oder dessen Custom-Bounce-Domain aktivieren |
Datenstand: 2026-06-29.
Die fett gedruckte Zeile ist, wo die meisten Leute stehen. include:-Zeilen für jedes Tool hinzuzufügen ändert daran nichts — und jede Zeile bringt Sie näher an die zweite Zeile: Mindestens 797.263 Domains haben das 10-Lookup-Limit bereits überschritten, und ihr SPF liefert jetzt einen PermError, der nichts schützt. Vollständige Zahlen im SPF-PermError-Bericht.
Welche Domain prüft SPF eigentlich?
Nicht die in Ihrem From-Header. Empfänger bewerten SPF gegen die Return-Path-Domain (die RFC5321.MailFrom, auch Bounce- oder Envelope-From-Adresse genannt) — der From-Header, den Ihr Empfänger sieht, spielt in der SPF-Prüfung selbst keine Rolle.
Diese eine Tatsache erklärt die meisten „SaaS-SPF-Fehler“. Ihre Marketing-Plattform sendet mit einem Return-Path wie [email protected]; SPF wird gegen anbieter.com geprüft und besteht sauber. Dann fragt DMARC, ob diese SPF-geprüfte Domain mit Ihrer From-Domain übereinstimmt. Tut sie nicht, also scheitert das SPF-Bein von DMARC, und Ihr Dashboard sagt „SPF scheitert“. Ihren eigenen SPF-Eintrag zu bearbeiten kann das nicht reparieren — Ihr Eintrag wurde nie konsultiert.
Was ist die Lösungsreihenfolge?
- Führen Sie zuerst den kostenlosen Scan durch. Er sagt Ihnen in einem Durchgang, ob Ihr SPF fehlt, doppelt vorhanden, über dem Lookup-Limit oder in Ordnung ist, und wo DMARC steht — bevor Sie DNS anfassen.
- Finden Sie den Return-Path, den das Tool tatsächlich nutzt. Senden Sie sich selbst eine Testmail vom Tool und lesen Sie den Return-Path-Header (und Authentication-Results) in der Rohnachricht. Das sagt Ihnen, in welcher Zeile der Tabelle oben Sie stehen.
- Schalten Sie das Custom-Domain-DKIM des Anbieters ein. Jedes ernstzunehmende SaaS-Tool bietet „Domain-Authentifizierung“: ein paar CNAME-Einträge, die es DKIM-signieren lassen als Ihre Domain. Diese Signatur aligned mit Ihrer From-Domain, sodass DMARC über DKIM besteht — dauerhaft, und auch wenn Mail weitergeleitet wird. Das ist die Lösung, die hält.
- Fügen Sie den SPF-Include des Anbieters nur hinzu, wenn er Ihren Return-Path nutzt — Sie haben seine Custom-Bounce-Domain aktiviert, oder er sendet wirklich mit Ihrer Domain im Umschlag. Ein Include für einen Anbieter, der über seine eigene Domain bounct, bringt nichts und verbraucht Ihr Lookup-Budget.
- Zählen Sie Ihre DNS-Lookups vor dem Speichern. Das Limit sind 10 aufgelöste Lookups, Includes zählen rekursiv, und 2.119.539 Domains stehen bereits bei 9–10 — das p99 des Zensus liegt bei 9. Nah am Rand? Entfernen Sie zuerst Includes für Tools, die Sie nicht mehr nutzen. Gerade den E-Mail-Anbieter gewechselt? Prüfen Sie auf einen übrig gebliebenen zweiten Eintrag — zwei SPF-Einträge ergeben einen PermError.
- Erneut scannen und bestätigen. SPF besteht auf der richtigen Domain, DKIM aligned, DMARC besteht. Die vollständige Referenz steht unter wie man SPF repariert; Anbieter-Anleitungen wie SPF bei GoDaddy und DMARC bei IONOS behandeln die DNS-Panel-Klicks.
Was sollten Sie bei HubSpot, Salesforce, Mailchimp und SendGrid tun?
HubSpot. Verbinden Sie Ihre sendende Domain in den HubSpot-Einstellungen und veröffentlichen Sie die beiden ausgegebenen DKIM-CNAMEs (hs1-… / hs2-…). Das aligned DKIM mit Ihrer From-Domain. Sie brauchen keinen HubSpot-SPF-Include, außer Sie haben HubSpot so konfiguriert, dass es Ihre eigene Bounce-Domain nutzt.
Salesforce. Erstellen Sie einen DKIM-Schlüssel im Salesforce-Setup und veröffentlichen Sie das generierte CNAME-Paar. Sendet Salesforce mit dem Return-Path Ihrer Organisation, fügen Sie include:_spf.salesforce.com hinzu und konfigurieren Sie die Bounce-Domain — das ist das eine große CRM, bei dem der SPF-Include oft wirklich gebraucht wird.
Mailchimp. Authentifizieren Sie Ihre Domain und veröffentlichen Sie die DKIM-CNAMEs k2 / k3. Mailchimp-Alignment ist Nur-DKIM — es gibt keinen SPF-Include mehr hinzuzufügen, und einen aus einem alten Tutorial hinzuzufügen verschwendet nur Lookups.
SendGrid. Vervollständigen Sie die Domain-Authentifizierung („automated security“): drei CNAMEs, die sowohl DKIM als auch den Return-Path auf Ihrer eigenen Subdomain abwickeln. Kein SPF-Include nötig. Von den 740.321 Domains, deren SPF sendgrid.net autorisiert, haben nur 18,0% durchsetzendes DMARC (Datenstand 2026-06-29) — die meisten SendGrid-Absender bleiben einen Schritt davor stehen.
Zendesk und alles andere: dasselbe Muster. Finden Sie die „Domain-Authentifizierung“-Seite des Tools, veröffentlichen Sie seine DKIM-CNAMEs, und fassen Sie SPF nur an, wenn das Tool dokumentiert, dass es Ihren Return-Path nutzt.
Ist SPF für europäische Unternehmen anders?
Nein — SPF, DKIM und DMARC funktionieren überall identisch. Was sich in Europa unterscheidet, ist der Kontext: wer fragt, und was Ihre Nachbarn bereits getan haben.
Ihre ccTLD setzt die lokale Messlatte. Europäische ccTLDs veröffentlichen SPF deutlich über den .com-Quoten, aber die Domains, die den Job abschließen — eine durchsetzende DMARC-Richtlinie obendrauf — sind überall die Minderheit:
| TLD | SPF-Verbreitung (der bewerteten Domains) | Durchsetzendes DMARC (der bewerteten Domains) |
|---|---|---|
| .nl | 75,91% | 29,43% |
| .ie | 70,89% | 8,79% |
| .de | 64,67% | 21,38% |
| .dk | 50,42% | 19,88% |
| .com | 54,14% | 9,50% |
Datenstand: 2026-06-29. Frankreich: 13,65% durchsetzendes DMARC; Italien: 5,24%.
Der Standardwert Ihres europäischen Hosters zählt. 4.346.526 Domains autorisieren IONOS’ EU-Mailserver (_spf-eu.ionos.com) in ihrem SPF — und nur 0,3% enden auf striktes -all, mit 1,0% DMARC-durchgesetzt. OVHs 2.132.049 schneiden bei der Strenge besser ab (43,7%), aber nur 2,2% setzen DMARC durch (Datenstand 2026-06-29). Haben Sie Ihren Eintrag nie angefasst, stehen Sie auf diesen Standardwerten.
Regulierer benennen das jetzt. NIS2 Artikel 21(2)(j) verlangt von betroffenen Einrichtungen, ihre Kommunikation abzusichern, und die Durchführungsverordnung (EU) 2024/2690 der Kommission konkretisiert E-Mail- und DNS-Sicherheitsmaßnahmen. E-Mail-Authentifizierung ist das konkrete, prüfbare Stück — und, ungewöhnlich für Compliance, kostenlos zu reparieren.
Zur Datenresidenz: Der Defaults.Exposed-Scanner und -Zensus laufen in AWS eu-west-1, wir veröffentlichen nur Aggregatzahlen, und ein Scan prüft nur die Domain, nach der Sie fragen.
Häufig gestellte Fragen
Mein SPF-Checker sagt „pass“, aber das Dashboard des Tools sagt, SPF scheitere — warum? Der Checker hat Ihren Eintrag getestet; der Empfänger hat die Return-Path-Domain getestet, die das Tool tatsächlich nutzte, dann hat DMARC sie mit Ihrer From-Domain verglichen. Das ist ein Alignment-Fehler, kein Eintrags-Fehler — repariert mit dem Custom-Domain-DKIM des Anbieters, nicht mit SPF-Änderungen.
Sollte ich einfach den SPF-Include für jedes genutzte Tool hinzufügen? Nein. Jeder Include verbraucht einen Teil von SPFs 10-Lookup-Budget, rekursiv: 2.119.539 der 138.927.207 SPF-veröffentlichenden Domains stehen bei 9–10 Lookups, und mindestens 797.263 sind darüber — ihr SPF liefert PermError und schützt nichts (Datenstand 2026-06-29).
Repariert der Include auch DMARC? Nur, wenn das Tool mit Ihrem Return-Path sendet, sodass SPF besteht und aligned. Bei den meisten SaaS-Tools tut es das nicht — weshalb aligned DKIM, nicht SPF, das Bein ist, das DMARC für SaaS-Mail bestehen lässt.
Ist das eine rechtliche Anforderung in der EU? Für Einrichtungen im NIS2-Anwendungsbereich machen Artikel 21(2)(j) und die Durchführungsverordnung (EU) 2024/2690 E-Mail-Sicherheit zur Pflicht. Auch außerhalb des Anwendungsbereichs fragen Versicherer und Kundenfragebögen zunehmend danach — und Stand 2026-06-29 bringt keine EU-ccTLD auch nur ein Drittel ihrer Domains zu einer durchsetzenden DMARC-Richtlinie (29,43% in .nl im besten Fall; 5,24% in .it).
Senden Sie dem Inhaber den Bericht
Sobald die CNAMEs live sind, führen Sie den Scan erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber oder Kunden weiter. Er zeigt in klarer Sprache, was gescheitert ist, was Sie repariert haben und wo die Domain jetzt steht — genau der Beleg, den er für die Versicherungsverlängerung oder den Kunden-Sicherheitsfragebogen braucht, schriftlich statt auf Ihr Wort.
Prüfen Sie Ihre Domain kostenlos
Sehen Sie genau, welches Bein von SPF, DKIM und DMARC scheitert — privat und nur für den Inhaber.
Prüfen Sie Ihre Domain → · SPF reparieren → · SPF PermError: „too many DNS lookups“ → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.