SPF

Definition

SPF steht für Sender Policy Framework und ist ein DNS-basierter Standard, der festlegt, welche Mailserver im Namen einer Domain E-Mails versenden dürfen. Empfänger prüfen damit, ob eine eingehende Nachricht von einer autorisierten Quelle stammt. SPF ist ein Grundbaustein für Zustellbarkeit und schützt vor dem Missbrauch einer Domain durch Spoofing.

Technisch wird SPF als TXT-Record im DNS veröffentlicht. Er wirkt nicht „in“ der E-Mail, sondern als Regelwerk, das empfangende Systeme beim Zustellprozess abfragen.

Bedeutung im B2B-Vertrieb

Im B2B-Vertrieb entscheidet Zustellbarkeit darüber, ob Follow-ups, Terminbestätigungen, Sequenzen und Angebotsmails überhaupt gesehen werden. Schlechte Authentifizierung führt zu Spam-Ordnern, Soft Bounces oder Reputation-Schäden, die sich über Wochen ziehen können. SPF trägt dazu bei, Vertrauen zu schaffen, weil empfangende Systeme schneller erkennen, dass der Absender technisch legitim ist.

Gerade bei Outbound-Sequenzen ist SPF nicht optional. Wer regelmäßig Kampagnen fährt, braucht ein sauberes Setup aus SPF, DKIM und DMARC. SPF allein löst nicht alles, aber ohne SPF wird es unnötig schwer, konstant in der Inbox zu landen.

Auch intern ist SPF relevant: Wenn unterschiedliche Tools (CRM, Sequencer, Support, Newsletter) unter derselben Domain senden, sorgt SPF für Ordnung und reduziert technische Überraschungen.

Wie es funktioniert

SPF wird als TXT-Record im DNS der Domain veröffentlicht. Darin stehen Regeln, welche IPs oder Systeme (z. B. Google Workspace, Microsoft 365, ein Versanddienst) berechtigt sind, E-Mails zu versenden. Beim Eingang einer E-Mail vergleicht der Empfänger die sendende IP mit dem SPF-Record der Absenderdomain.

• Pass: Die IP ist autorisiert, SPF besteht.
• Fail: Die IP ist nicht autorisiert, SPF schlägt fehl.
• Softfail/Neutral: Uneindeutig, wird je nach Empfänger-Policy interpretiert.
• Permerror: Technischer Fehler, oft durch zu viele DNS-Lookups oder falsche Syntax.

Typisch ist ein Record wie: v=spf1 include:_spf.google.com include:sendgrid.net -all. Das bedeutet: Erlaubt sind Google und SendGrid, alles andere ist nicht erlaubt. Das abschließende -all ist eine harte Regel, ~all ist weicher (Softfail). Welche Variante passt, hängt von Reifegrad und Fehlersicherheit ab.

Wichtig im Alltag: SPF bewertet die Envelope From-Domain (Return-Path), nicht zwingend die sichtbare From-Adresse. Deshalb kann SPF „pass“ sein, obwohl die sichtbare Absenderdomain eine andere ist. Genau hier kommen DKIM und DMARC ins Spiel.

Typische Fehler und Missverständnisse

• Zu viele SPF-Lookups: SPF erlaubt maximal 10 DNS-Lookups. Zu viele include, a oder mx führen zu permerror.
• Mehrere SPF-Records: Pro Domain sollte es genau einen SPF-TXT-Record geben. Mehrere führen zu Fehlern oder uneinheitlichem Verhalten.
• SPF für die falsche Domain: Häufig wird SPF auf der Root-Domain gesetzt, obwohl über Subdomains versendet wird (oder umgekehrt).
• Weiterleitungen: Bei Mail-Forwarding kann SPF brechen, weil sich die sendende IP ändert. Hier helfen SRS oder eine DMARC-Strategie, die das berücksichtigt.
• SPF ist kein Inhaltsfilter: SPF sagt nichts über den Inhalt aus. Schlechte Texte bleiben problematisch.
• „SPF = Zustellung garantiert“: Reputation, Engagement, Volumen, Beschwerderaten und Listenqualität sind genauso wichtig.

Ein häufiger Praxisfehler ist, dass im Laufe der Zeit neue Tools dazukommen, der SPF-Record aber nicht gepflegt wird. Das führt zu sporadischen Ausfällen: Manche Mails kommen an, andere nicht, und die Ursachenanalyse dauert unnötig lang.

Anwendung im Vertrieb (konkret)

Szenario: Ein Sales-Team nutzt Google Workspace für 1:1-Outreach und zusätzlich einen Sequencing-Anbieter. Ziel ist, dass alle Mails technisch konsistent wirken und die Domain-Reputation stabil bleibt.

Schritt 1: Sender-Inventar

• Welche Systeme versenden E-Mails im Namen der Domain? (Mailbox, CRM, Sequencer, Support-Tool, Newsletter, Rechnungssoftware)
• Welche Domain wird dabei genutzt? Root, Subdomain oder separate Versanddomain?

Schritt 2: SPF konsolidieren

• Alle erlaubten Sender in einen Record bringen, doppelte oder alte Includes entfernen.
• Auf Lookup-Limit achten. Bei Bedarf SPF „flattening“ oder konsolidierte Anbieter-Records nutzen.

Schritt 3: Härten und überwachen

• Mit ~all starten, wenn noch Unsicherheit besteht, dann nach Monitoring auf -all umstellen.
• DMARC-Reports nutzen, um unbekannte Sender zu erkennen und zu stoppen.

Schritt 4: Vertriebspraxis an Technik koppeln

• Neue Tools dürfen erst nach SPF/DKIM/DMARC-Abnahme genutzt werden.
• Sequenzen über Subdomains (z. B. outbound.example.com) trennen, um Hauptdomain zu schützen, wenn das Setup es vorsieht.
• Bei Zustellproblemen zuerst Auth-Checks und Bounce-Kategorien prüfen, dann Inhalte und Volumen.

Minimal-Check vor Kampagnenstart: SPF ohne permerror, DKIM signiert, DMARC aktiv (mindestens „none“), Versandvolumen sauber geramped, Listenqualität und Bouncerisiko reduziert.

Kurzfazit

• SPF definiert im DNS, wer für eine Domain senden darf, und schützt vor Spoofing.
• Für Outbound und Sequenzen ist SPF ein Basis-Signal für bessere Zustellbarkeit.
• Die größten Stolperfallen sind Lookup-Limits, mehrere Records und ungepflegte Sender-Listen.

Typische Fehler und Missverständnisse (Details aus der Praxis)

SPF-Alignment wird unterschätzt: Viele Versandtools setzen eine eigene Return-Path-Domain. Dann kann SPF zwar technisch „pass“ sein, aber DMARC später trotzdem scheitern, wenn die sichtbare From-Domain nicht ausgerichtet ist. Deshalb sollte das Setup immer als Paket betrachtet werden.

Tool-Wildwuchs: Wenn verschiedene Teams eigenständig Tools aktivieren, entstehen „Schatten-Sender“. Ein einziger vergessener Dienst kann SPF/DMARC-Reports und Reputation dauerhaft verschlechtern.

Subdomains als Schutz: In vielen Setups ist es sinnvoll, Outbound über eine Subdomain zu versenden (z. B. mail.example.com), während die Hauptdomain für 1:1-Kommunikation sauber bleibt. Das ist kein Muss, aber ein gängiger Weg, Risiken zu trennen.

Anwendung im Vertrieb (konkret) – Troubleshooting

Wenn Mails plötzlich im Spam landen: Nicht sofort Texte umschreiben. Erst die technischen Signale prüfen: Hat sich ein Tool geändert? Wurde ein DNS-Record überschrieben? Gibt es SPF permerror? Sind DKIM-Signaturen vorhanden?

• Symptom: Viele Soft Bounces oder „unauthenticated“ Hinweise – Check: SPF/DKIM/DMARC, Return-Path, Absenderdomain.
• Symptom: Gute Zustellung bei manchen Empfängern, schlechte bei anderen – Check: Reputation und Empfänger-Policies, zusätzlich Engagement und Volumen.
• Symptom: Nur Sequencer-Mails betroffen – Check: Versanddomain/Subdomain, ob der Sequencer im SPF fehlt.

Faustregel: SPF ist ein Hygiene-Faktor. Wenn er falsch ist, verschwendet man Zeit an Symptomen. Wenn er richtig ist, kann man an den echten Hebeln arbeiten: Segmentierung, Inhalte, Versandrhythmus und Listenqualität.

Weiterführend

Wissensbereich Übersicht | Cluster: Deliverability

Weiterführend: Deliverability · Warum Vertriebsdruck im B2B kontraproduktiv ist · Warum viele B2B-Vertriebsteams trotz hoher Aktivität · DKIM