SPF-Eintrag richtig einrichten: Beispiele und Prüfungen

Wenn Sie in 2026 eine Mailinfrastruktur aufbauen, gehört Ihr SPF-Eintrag zu den wichtigen Grundlagen. Fehler können nicht nur Spamplatzierung, sondern auch Ablehnungen verursachen. SPF allein entscheidet jedoch nicht bei jedem Empfänger über die Zustellung.

Seit Februar 2024 gelten bei Google und Yahoo strengere Authentifizierungsanforderungen für die jeweils betroffenen Absender. Fehlendes oder ungültiges SPF kann unter passenden Empfängerrichtlinien zu SMTP 550 führen, muss aber nicht jede Nachricht automatisch noch während der Übertragung blockieren.

Für einen Gründer mit einer einzelnen Domain kann ein SPF-Fehler bedeuten, dass die Präsentation den Investor nicht erreicht. Bei einem MSP mit 500 Kundendomains können daraus am Montag zahlreiche Anfragen wie „Warum kann ich nicht an Gmail schreiben?“ werden. Sorgfältige Einrichtung und Kontrolle verringern solche Risiken, verhindern aber nicht jedes Zustellproblem.

Dieser Leitfaden erklärt, was SPF leistet, wie Sie einen passenden Eintrag aufbauen, welche weniger sichtbaren Fehler die Zustellung beeinflussen und wie sich die Konfiguration für viele Domains nachvollziehbar verwalten lässt.

Was SPF ist und was nicht

Sender Policy Framework (SPF) ist ein DNS-basiertes Autorisierungsverfahren aus RFC 7208. Der Eintrag veröffentlicht erlaubte Versandquellen für die geprüfte Domain. Er sagt dem Empfangsserver, welche IP-Adressen autorisiert sind. Das ist kein allgemeiner Sicherheitsschutz, sondern eine klar begrenzte Prüfung.

So funktioniert die Prüfung

Wenn Gmail eine Nachricht von alice@yourcompany.com empfängt, ist für SPF nicht einfach die im Programm sichtbare From-Adresse maßgeblich. Geprüft wird gewöhnlich die Domain des Envelope-Absenders, der später als Return-Path erscheint und für Rückmeldungen verwendet wird; in entsprechenden Fällen wird HELO geprüft. Dafür ruft der Empfänger die SPF-Richtlinie ab und vergleicht die verbindende IP.

Passt eine autorisierende Regel, kann die Prüfung erfolgreich sein. Andernfalls kann die abschließende Regel etwa SoftFail (~all) oder Fail (-all) ergeben. Der Wert ist nicht selbst eine verbindliche Zustellungsentscheidung des Empfängers.

Der wichtige Unterschied: From-Header und Return-Path

Die im Ausgangstext genannten 90% sind keine belegte allgemeine Fehlerquote, illustrieren aber einen häufigen Irrtum. SPF prüft nicht die in Outlook oder Apple Mail sichtbare From-Adresse, sondern die passende technische Envelope-Domain.

Der Fallstrick: Bei Mailchimp-Newslettern kann Return-Path eine Dienstleisterdomain wie bounce-mc.us1.mailchimp.com verwenden, damit der Dienst Rückläufer verarbeitet. Dann prüft der Empfänger Mailchimps SPF und nicht den Eintrag Ihrer sichtbaren Absenderdomain. Ihr eigener Eintrag kann richtig sein, ohne in diesem Versandpfad ausgewertet zu werden.

Diese Frage des Alignments ist ein Grund, SPF nicht isoliert zu betrachten. Das Zusammenspiel mit DKIM und DMARC erklärt unser Leitfaden zur Einrichtungsreihenfolge der E-Mail-Authentifizierung.

Warum SPF dennoch wichtig ist

Auch mit DKIM und DMARC kann fehlendes SPF gegen anwendbare Absenderanforderungen verstoßen. Microsoft kann bei betroffenen Versandfällen beispielsweise 550 5.7.515 Access Denied zurückgeben. Das ist kein für alle Microsoft-Empfänger identisches Verhalten. Prüfen Sie SPF und die übrigen Anforderungen trotzdem sorgfältig.

Grundmuster mit einem Versanddienst

Sendet ein kleines Unternehmen überwiegend über einen Anbieter wie TrekMail, Google Workspace oder Microsoft 365 und vielleicht noch ein Marketingwerkzeug, ist eine übersichtliche einzelne SPF-Richtlinie je geprüfter Domain ein gutes Ziel. Der Aufbau ist meist überschaubar, ein typischer Fehler aber ebenso häufig.

Grundregel: An einem DNS-Namen darf genau ein SPF-Eintrag veröffentlicht sein.

Beim Hinzufügen eines Dienstes wird manchmal ein zweiter TXT-Eintrag angelegt, statt die SPF-Richtlinie zusammenzuführen. Findet die SPF-Auswertung zwei passende SPF-Einträge am selben Namen, entsteht PermError. Das ist ein Richtlinienfehler, nicht die getrennte Auswertung zweier gültiger Richtlinien.

Die Bestandteile eines passenden Eintrags

Die Beispiele sind illustrative Ausgangswerte; aktuelle Anbieterangaben und Ihren Senderbestand müssen Sie vor Übernahme prüfen. Einen schrittweisen Ablauf bietet der Leitfaden zur SPF-Einrichtung.

TrekMail für kleine Unternehmen einordnen

Der Ausgangstext vergleicht Google Workspace mit $6-$18 je Nutzer und Monat. Für zehn Nutzer nennt er $720-$2,160 jährlich. TrekMails Starter wird mit $3.50 monatlich pauschal und bis zu 100 Nutzern dargestellt. Diese Preise und Grenzen sind Momentaufnahmen und aktuell zu prüfen. include:spf.trekmail.net kann bei passender Versandkonfiguration Bestandteil des Eintrags sein, ersetzt aber weder die vollständige Senderliste noch DNS- und Authentifizierungsprüfungen. Lizenz- und Vertragsmodelle sind im konkreten Angebot zu vergleichen.

Mehrere Versanddienste bei Agenturen

Bei MSPs und Agenturen nutzen Kunden oft mehrere Dienste: HubSpot für Vertrieb, Zendesk für Support, Klaviyo für Marketing und TrekMail für Unternehmensmail. Ob ein Dienst im SPF Ihrer Domain erscheinen muss, hängt von der tatsächlich verwendeten Envelope-Domain und seiner aktuellen Konfiguration ab.

Die notwendigen Autorisierungen müssen in eine Richtlinie passen, ohne eine wichtige RFC-Grenze zu überschreiten: das Budget von 10 DNS-abfragenden Termen.

Das Limit von 10 DNS-abfragenden Termen

RFC 7208 §4.6.4 begrenzt die ausgewerteten relevanten DNS-abfragenden Mechanismen und Modifikatoren einschließlich Verschachtelung auf 10. Gemeint sind nicht schlicht alle DNS-Pakete. Die Begrenzung reduziert missbräuchliche Belastung und kann auch legitime umfangreiche Konfigurationen betreffen.

Was das Budget beansprucht: include:, a, mx, exists, redirect, soweit auf dem ausgewerteten Pfad relevant. Auch der nicht empfohlene ptr-Mechanismus zählt dazu.

Was dieses Budget nicht beansprucht: ip4:, ip6:, all.

Verschachtelte Includes

Sie fügen include:bluehost.com hinzu. Das sieht nach 1 Term aus. Die historische Beispielkette kann aber spf.protection.outlook.com und mail.bluehost.com einbinden, sodass aus einem Eintrag drei relevante Auswertungen werden. Auch spf.protection.outlook.com kann weitere Verweise haben. Tatsächliche aktuelle Werte und den ausgewerteten Pfad müssen Sie prüfen.

Überschreitet die relevante Kette 10, entsteht PermError. Das kann legitime Nachrichten beeinträchtigen, bedeutet aber nicht zwingend endgültige Ablehnung ohne Rückmeldung: Empfängerregeln und andere Authentifizierungsergebnisse sind ebenfalls relevant.

Das Budget prüfen

Verlassen Sie sich nicht auf Schätzungen. Nutzen Sie ein geeignetes Kommandozeilenwerkzeug oder einen nachvollziehbaren Visualisierer. Auf Mac/Linux können Sie beginnen mit:

dig +short txt yourdomain.com

Rufen Sie anschließend die Domains jedes include: rekursiv ab und untersuchen Sie auch andere relevante Terme und den tatsächlichen Prüfpfad. Der Leitfaden zu SPF-Abfragelimits erklärt die Prüfung und häufige Überschreitungen.

Flattening oder Subdomain-Aufteilung

Droht eine Überschreitung des Budgets von 10, was bei Agenturen vorkommen kann, aber nicht zwangsläufig ist, kommen unter anderem zwei Ansätze infrage.

Option 1: SPF-Flattening mit Wartungsrisiko

Flattening ersetzt aufgelöste include:-Ketten durch konkrete IP-Adressen als ip4:-Mechanismen. ip4: benötigt null relevante DNS-abfragende Terme. Auch hunderte Adressen können so unter dem Budget bleiben, müssen aber weitere Größen- und Gültigkeitsgrenzen erfüllen; ursprüngliche Semantik und andere Adressarten bleiben zu prüfen.

Der Haken: HubSpot, Klaviyo und andere ESPs können Versandadressen ändern. Eine fest eingetragene Liste veraltet dann. Nach einigen Monaten kann ein zuvor erfolgreicher Versand SPF verfehlen, weil neue Adressen fehlen oder alte weiterhin autorisiert sind.

Flattening verlangt zuverlässige laufende Überwachung, kontrollierte DNS-Aktualisierungen und einen Umgang mit Fehlern. Ein automatisiertes Skript kann helfen, ist aber nicht allein eine Sicherheitsgarantie. Ohne belastbare Wartung wird daraus erhebliche technische Schuld.

Option 2: Versand über Subdomains aufteilen

Eine Alternative ist, nicht sämtliche Dienste unter der Hauptdomain zusammenzufassen. SPF prüft die tatsächliche Envelope-Domain, die im Return-Path erscheint. Diese kann eine Subdomain sein.

Muss Marketing sichtbar von team@company.com senden, oder passt news@marketing.company.com? Die sichtbare Adresse allein ändert die SPF-Prüfung nicht.

Hauptdomain (company.com): Halten Sie die nötigen Autorisierungen übersichtlich, etwa für Unternehmensmail und wesentliche Infrastruktur.

v=spf1 include:spf.trekmail.net -all

Marketing-Subdomain (marketing.company.com): Dafür können die entsprechenden Dienste separat eingerichtet werden.

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Ein eigener SPF-Prüfpfad kann ein separates Budget von 10 nutzen, wenn der Dienst tatsächlich diese Envelope-Subdomain verwendet. Das Beispiel marketing.company.com bildet keine Reputationsfirewall: Empfänger können organisatorische Domains und gemeinsame IPs zusammen bewerten. Prüfen Sie auch relaxed oder strict DMARC-Alignment und aktuelle Anbieterwerte, statt die Beispiele ungeprüft einzusetzen.

Weitere Ausgangsmuster stehen in den SPF-Einrichtungsvorlagen. Das Zusammenspiel mehrerer Absender erläutert der Leitfaden zur Konfiguration für mehrere Versanddienste.

Prüfablauf nach der Veröffentlichung

Nach „Speichern“ im DNS-Editor ist die Prüfung nicht abgeschlossen. Mit folgendem Ablauf können Sie die Veröffentlichung und die tatsächliche Verwendung untersuchen.

1. DNS-Verfügbarkeit und Caches prüfen

DNS-Änderungen erscheinen nicht überall sofort. Je nach TTL, bestehenden Caches und Anbieter dauert es Minuten oder Stunden. Prüfen Sie neben lokalen und autoritativen Antworten auch einen öffentlichen Resolver:

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 fragt Googles öffentlichen Resolver statt des lokalen ISP-Resolvers ab. Auch dieser besitzt Caches. Eine Antwort dort beweist nicht, dass alle weltweiten Resolver bereits denselben Stand haben.

2. Syntax validieren

SPF verlangt genaue Syntax. Häufige Stolperstellen sind:

• Ein Leerzeichen vor v=spf1
• ip4: 192.1.1.1: Das Leerzeichen nach dem Doppelpunkt ist ungültig.
• Mehrere all-Mechanismen: Der erste passt bereits; spätere Mechanismen werden auf diesem Pfad nicht ausgewertet.
• Doppelte include:-Einträge: Nicht zwingend ein Syntaxfehler, aber unnötiger Budgetverbrauch, wenn sie ausgewertet werden.

Prüfen Sie die Syntax, bevor Sie die Einrichtung abschließen. Der nach aktuellen Funktionen verfügbare DNS-Assistent kann Hinweise geben, ersetzt jedoch keine vollständige Prüfung.

3. Leere DNS-Antworten prüfen

RFC 7208 beschreibt eine weitere Grenze: empfohlen sind höchstens 2 DNS-Abfragen ohne Ergebnis, also NXDOMAIN oder erfolgreiche Antworten ohne passende Daten. Die maßgebliche Implementierung und Fehlerart müssen berücksichtigt werden.

Beispielsweise kann include:spf.trekmaill.net mit einem zusätzlichen „l“ keine passende Antwort liefern. Das kann 1 leere Abfrage sein; ein Include ohne gültige SPF-Richtlinie kann zudem unmittelbar PermError ergeben. Zwei Tippfehler sind nicht erst wegen Erreichens der empfohlenen Grenze automatisch deren Überschreitung.

Prüfen Sie deshalb nicht nur Syntax, sondern auch die aufgelösten Ziele und Ergebnisarten. Solche Fehler sind im Text allein leicht zu übersehen.

4. Header des tatsächlichen Versands prüfen

Senden Sie an ein kontrolliertes Gmail-Konto, öffnen Sie das Drei-Punkte-Menü und „Original anzeigen“. Suchen Sie das vom vertrauenswürdigen Empfangssystem eingefügte Authentication-Results. Ein mögliches Ergebnis ist:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral oder spf=softfail verdienen im Kontext Ihres erwarteten Versandpfads eine Prüfung, beweisen aber nicht dieselbe Ursache. Vergleichen Sie IP, geprüfte Domain und Richtlinie. Die Anleitung DNS-Status prüfen unterstützt die DNS-Prüfung; untersuchen Sie zusätzlich vertrauenswürdige Header.

Häufige Fehler und ihre Folgen

Die folgenden Muster begegnen häufig bei SPF-bezogenen Supportfällen. Ihre Kenntnis erleichtert die Diagnose, ohne eine allgemeine Häufigkeitsquote festzulegen.

1. SPF bei Weiterleitung

SPF prüft die verbindende Versand-IP. Darin liegt auch eine Grenze des Verfahrens.

Alice schreibt Bob, der an Charlie weiterleitet. Charlie sieht Bobs Server-IP statt Alices. Bleibt der ursprüngliche Envelope-Absender bestehen und ist Bobs IP dort nicht autorisiert, kann SPF scheitern, obwohl die ursprüngliche Nachricht legitim ist.

SPF allein löst diesen Fall nicht. DKIM signiert ausgewählte Header und den Nachrichtenkörper. Die Signatur kann bei unverändert gültigen signierten Daten Weiterleitung überstehen, hängt aber auch von Schlüssel und weiteren Prüfbedingungen ab. Für DMARC muss sie ausgerichtet sein. Verlassen Sie sich deshalb nicht ausschließlich auf SPF.

Wie DKIM und SRS in solchen Fällen helfen können, erklärt Domainmail weiterleiten und Zustellung prüfen. Keines davon garantiert alle Weiterleitungsfälle.

2. Der Mechanismus ptr

Anfang der 2000er war der SPF-Mechanismus ptr für Reverse-DNS-Prüfungen verbreitet:

v=spf1 ptr -all

Verwenden Sie ihn nicht für neue Konfigurationen. Der RFC rät von ptr ab, da er aufwendig und unzuverlässig sein kann. Daraus folgt keine universelle Gmail-Strafe oder automatische Missachtung des gesamten Eintrags. Ersetzen Sie geerbtes ptr nach Prüfung durch passende Autorisierungen; Reverse-DNS-Anforderungen der Versand-IP bleiben davon getrennt.

3. Die Gefahr von +all

Auch diese problematische Konfiguration kommt vor:

v=spf1 include:spf.google.com +all

Die Qualifizierer bedeuten:

• -all = Fail für verbleibende, zuvor nicht passende Quellen; Behandlung nach Empfängerregeln.
• ~all = SoftFail für verbleibende Quellen; keine verbindliche Annahme mit Markierung.
• +all = Pass für jede verbleibende Quelle.

Ein erreichtes +all autorisiert somit beliebige IPs für die geprüfte Domain und schwächt SPF erheblich. Eine Richtlinie mit +all kann Missbrauch begünstigen, garantiert aber keine Phishingzustellung. Enthält Ihre Richtlinie +all, prüfen Sie rasch den Senderbestand und ersetzen Sie es durch eine passende Regel, etwa -all, ohne legitime Quellen zu übersehen.

4. Unpassender Return-Path bei externen Diensten

Ohne eigenen Return-Path verwenden Marketingdienste häufig ihre eigene Bounce-Domain. Eine Tracking-Domain ist nicht automatisch dasselbe. Ihr eigener SPF-Eintrag wird dann nicht für diesen Envelope ausgewertet. SPF kann beim Anbieter erfolgreich sein, aber für DMARC fehlt unter Umständen die Ausrichtung zur sichtbaren From-Domain. DMARC kann dennoch über gültiges ausgerichtetes DKIM bestehen.

Unterstützt der ESP eine eigene Bounce-Subdomain wie bounce.yourcompany.com, können Sie sie passend konfigurieren. Relaxed-Alignment kann dieselbe organisatorische Domain erlauben; strict verlangt genaue Übereinstimmung. Details stehen unter DMARC-Alignment und Domainreputation.

Generatoren sinnvoll und vorsichtig einsetzen

SPF-Generatoren unterscheiden sich stark. Manche erleichtern nachvollziehbare Prüfungen, andere erzeugen unpassende Konfigurationen.

Hilfreiche Werkzeuge

Visualisierer für die vollständige include:-Kette helfen bei der Budgetprüfung vor einer Überschreitung. Geeignete Werkzeuge für E-Mail-Zustellung können solche Ansichten anbieten; prüfen Sie auch die übrigen Terme.

Syntaxprüfer können fehlende Doppelpunkte und unzulässige Zeichen aufdecken. Leere DNS-Antworten und ungültige Zielrichtlinien erfordern zusätzlich tatsächliche DNS-Auflösung und SPF-Auswertung. Nutzen Sie die Prüfungen nach Änderungen und kontrollieren Sie anschließend den tatsächlichen Versand.

Problematische Ergebnisse

Ein-Klick-Assistenten können ?all als Neutral-Regel ausgeben. Neutral ist keine positive Autorisierung für verbleibende Quellen, aber auch nicht automatisch ein Konfigurationsfehler. Wählen Sie nach vollständiger Senderaufnahme eine passende Regel wie -all oder vorübergehend ~all; übernehmen Sie keinen Standardwert blind.

Generatoren für aufgeteilte Einträge: Eine Zeichenkette in DNS-TXT hat eine Grenze von 255 Bytes. Längere SPF-Inhalte können auf mehrere zitierte Zeichenketten innerhalb desselben TXT-Eintrags verteilt werden, nicht auf zwei separate SPF-TXT-Einträge:

• Beabsichtigte Aufteilung: "v=spf1 include:a..." "include:b... -all" als zwei Zeichenketten in einem Eintrag; im tatsächlichen Inhalt braucht die Grenze ein trennendes Leerzeichen.
• Falsch: Zwei getrennte SPF-TXT-Einträge ergeben bei Auswertung PermError.

Die Zeichenketten werden ohne automatisch eingefügtes Leerzeichen verbunden. Das gezeigte verkürzte Beispiel darf deshalb nicht unverändert als gültiger SPF-Inhalt übernommen werden. Prüfen Sie den tatsächlich veröffentlichten Inhalt und die Syntax jedes Generatorergebnisses.

Weitere Kriterien und Einrichtungsabläufe bietet der Leitfaden zu SPF-Generatoren und Einrichtung.

Konfiguration mit TrekMail vereinheitlichen

Große Office-Suiten sind nicht grundsätzlich schlechte Produkte. Ihre Bündelung und nutzerabhängige Preise passen aber nicht zu jedem Kunden. Vergleichen Sie den tatsächlich benötigten Funktionsumfang und Vertrag.

Für passende TrekMail-Versandpfade kann folgendes illustratives SPF-Muster verwendet werden. Prüfen Sie vor Veröffentlichung aktuelle Werte und weitere Sender:

v=spf1 include:spf.trekmail.net -all

Diese Zeile ist nur dann vollständig, wenn sie sämtliche nötigen Quellen der geprüften Domain korrekt autorisiert. Managed SMTP kann IP-Infrastruktur, PTR und verfügbare Feedback-Prozesse betreuen. BYO SMTP hat andere Zuständigkeiten. Senderaufnahme, zulässige Mengen, Listenpflege und Monitoring bleiben nötig; eine Autorisierung garantiert keine Zustellung.

Bei einem MSP mit 50 gleich konfigurierten Kundendomains können 50 gleiche SPF-Einträge die Verwaltung vereinfachen. Tarife und Kundenkonfigurationen müssen trotzdem geprüft werden. Eine neue Domain kann dieselbe Ausgangszeile wie hundert frühere nutzen, wenn ihre tatsächlichen Sender übereinstimmen. Standardisierung ersetzt nicht die Einzelprüfung.

Für einen Anbieterwechsel erklären die IMAP-Migrationsübersicht und die Anleitung zu erforderlichen DNS-Einträgen wichtige Schritte. IMAP betrifft erreichbare Mailboxdaten, nicht automatisch DNS, Anwendungen oder Reputation, und garantiert weder verlustfreie noch unterbrechungsfreie Umstellung. Bereiten Sie SPF, DKIM und DMARC vor und prüfen Sie Versand und Migration, bevor Sie MX umstellen. Verfügbarkeit und Bedingungen eines Dashboard-Massenimports beschreibt Domains gesammelt importieren.

Eine belastbare SPF-Praxis

Die Anforderungen an E-Mail-Authentifizierung wurden in 2024 verschärft. Ein unpassender SPF-Eintrag kann legitimen Versand gefährden. Google und Microsoft berücksichtigen SPF nach ihren jeweiligen Regeln; daraus folgt keine universelle identische Ablehnung.

Die wichtigsten Schritte im Überblick:

1. Jetzt prüfen. Rufen Sie dig +short txt yourdomain.com auf und zählen Sie die SPF-Richtlinien am jeweiligen Namen, nicht sämtliche TXT-Einträge. Mehr als eine SPF-Richtlinie führt bei SPF-Auswertung zu PermError.
2. Eine Richtlinie veröffentlichen. Führen Sie nötige Autorisierungen in einem SPF-TXT-Eintrag zusammen; mehrere Zeichenketten innerhalb dieses Eintrags sind möglich.
3. Das Budget zählen. Verwenden Sie geeignete Prüfwerkzeuge. Bei mehr als 10 relevanten Termen können echte Envelope-Subdomains eine Alternative zu wartungsintensivem Flattening sein.
4. -all bewusst wählen. Ersetzen Sie ~all nach vollständiger Senderaufnahme, Tests und passender Richtlinienentscheidung. +all verlangt zügige Prüfung und Korrektur.
5. Return-Path-Alignment prüfen. Bei Mailchimp oder HubSpot kann eine eigene Bounce-Domain SPF ausrichten. Für DMARC genügt alternativ gültiges ausgerichtetes DKIM; nicht beide Verfahren müssen gleichzeitig erfolgreich sein.
6. SPF nicht isolieren. Weiterleitung kann SPF beeinträchtigen und auch DKIM ändern. Nutzen und prüfen Sie alle drei Verfahren: SPF, DKIM und DMARC.

Ein im Beispiel 50 Bytes langer SPF-Eintrag ist kein sinnvoller Anlass für vermeidbare Kundenprobleme. Richten Sie ihn passend ein, prüfen Sie ihn mindestens im jährlichen Beispielrhythmus und zusätzlich bei Sender- oder Anbieteränderungen. Einmalige Einrichtung macht ihn nicht dauerhaft korrekt.

DNS nachvollziehbar verwalten. TrekMail kostenlos ausprobieren: Prüfen Sie aktuelle Testbedingungen, Pauschaltarife und Unterstützung für SPF, DKIM und DMARC Ihrer Domains.