Sie haben einen kostenlosen SPF-Record-Generator gefunden, alle Optionen ausgewählt, darunter Google Workspace, Mailchimp und Ihr CRM, und die Ausgabe direkt in DNS eingefügt. Zwei Wochen später weist Gmail Ihre Rechnungen mit 550 5.7.26 zurück. Outlook meldet 550 5.7.515, und die Supportwarteschlange wächst.
Der SPF-Record-Generator hat eine syntaktisch gültige Ausgabe erzeugt, aber keinen nachweislich funktionsfähigen Eintrag. Genau diese Lücke kann die Zustellbarkeit beeinträchtigen. Wenn Sie noch den vollständigen DNS-Stack aufbauen, beginnen Sie mit der Einrichtung von E-Mail auf Ihrer Domain. SPF ist Teil eines größeren Zusammenspiels mit MX, DKIM und DMARC.
Dieser Leitfaden erklärt, warum automatisierte Generatoren im Produktivbetrieb scheitern können, wie Sie ihre Ausgabe in fünf Minuten mit vorhandenen Werkzeugen prüfen und wie ein produktionsgeeigneter SPF-Eintrag aussieht.
Was ein SPF-Record-Generator tatsächlich macht
Ein SPF-Record-Generator ist ein Webwerkzeug, das anhand ausgewählter Optionen anbieterspezifische include:-Mechanismen zu einem TXT-DNS-Eintrag zusammenfügt. Sie wählen die Absender und erhalten eine Zeichenfolge. Das Werkzeug fragt weder Ihr aktives DNS ab noch zählt es rekursive Abfragen oder kennt bereits vorhandene SPF-Einträge Ihrer Domain.
Viele kostenlose SPF-Generatoren sind im Kern Zeichenfolgen-Builder. Sie erzeugen eine plausibel aussehende Ausgabe, ohne deren Funktion in Ihrer DNS-Umgebung zu prüfen. Syntaktisch korrekt ist nicht gleich betrieblich korrekt.
Die 3 Fehlerarten, die SPF-Generatoren übersehen
Schwere SPF-Probleme im Produktivbetrieb lassen sich häufig auf eines von drei Themen zurückführen. Ein gewöhnlicher Generator erkennt sie nicht, weil ihm aktive DNS-Daten und die Abfragelogik der Empfänger fehlen.
1. PermError durch doppelte Einträge
Eine Domain darf genau einen SPF-Eintrag haben. RFC 7208 ist eindeutig: Findet der Empfangsserver zwei TXT-Einträge, die mit v=spf1 beginnen, gibt er PermError zurück. Gmail und Yahoo können PermError wie einen fehlenden SPF-Eintrag behandeln. Nachrichten werden dann möglicherweise zurückgewiesen oder als Spam eingeordnet.
Generatoren prüfen gewöhnlich nicht auf bestehende Einträge. Eine seit mehreren Monaten aktive Domain hat wahrscheinlich schon einen, etwa vom Registrar, früheren Hoster oder einer älteren Google-Workspace-Einrichtung. Wer die Generatorausgabe ungeprüft veröffentlicht, kann ein Duplikat anlegen und eine zuvor funktionierende Konfiguration beschädigen.
2. Das Limit rekursiver Abfragen
RFC 7208 begrenzt die SPF-Auswertung auf genau 10 DNS-Abfragen. Dazu zählen jedes include:, a, mx, exists und redirect sowie alle verschachtelten Abfragen, die Includes auslösen. Ein Generator zählt meist die ausgewählten Mechanismen, nicht jedoch deren Inhalt.
| Ausgewählter Anbieter | Generatorzählung | Tatsächliche Abfragen |
|---|---|---|
| Google Workspace | 1 | 4 (verschachtelt: _netblocks.google.com usw.) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| Gesamt | 4 | 10-12 -> PermError |
Der Generator zeigt 4 Abfragen. Der Empfangsserver erreicht #11 und bricht ab. Dadurch kann SPF für Nachrichten Ihrer Domain fehlschlagen, ohne dass die Generatoroberfläche warnt. Oft fällt das Problem erst durch Rückmeldungen von Empfängern auf.
3. Das Limit leerer Abfragen (RFC 7208 §11.1)
Zusätzlich dürfen höchstens 2 DNS-Abfragen ein leeres Ergebnis (NXDOMAIN) liefern. Schon ein Tippfehler in einem include: erzeugt eine leere Abfrage. Zwei solche Fehler können den gesamten SPF-Eintrag ungültig machen, obwohl die Syntaxprüfung des Generators bestanden wurde.
Beispiel:
include:spf.trekmaill.net(zusätzliches 'l'). Die Syntax ist gültig, und der Generator kann den Eintrag als korrekt markieren. Der Empfangsserver fragt ihn ab und findet nichts: leere Abfrage #1. Ein zweites fehlerhaftes Include lässt den Eintrag scheitern.
Generatorausgabe vor der Veröffentlichung prüfen
Führen Sie vor der Veröffentlichung der Generatorausgabe diese drei Prüfungen gegen das aktive DNS durch. Sie benötigen etwa fünf Minuten und erkennen kritische Probleme, die der Generator übersehen kann: Duplikate, zu viele rekursive Abfragen und fehlerhafte Syntax. Die Befehle funktionieren unter macOS, Linux und in der Windows-Eingabeaufforderung.
Schritt 1: Auf vorhandenen Eintrag prüfen
Führen Sie vor jeder DNS-Änderung diesen Befehl aus:
nslookup -type=txt yourdomain.comWenn zwei Zeilen mit v=spf1 beginnen, liegt ein Duplikat vor. Führen Sie beide manuell zu einem Eintrag zusammen, bevor Sie etwas Neues veröffentlichen.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allSchritt 2: Rekursive Abfragen zählen
Fragen Sie für jedes include: im Eintrag dessen Inhalt ab:
dig +short txt _spf.google.comAusgabe:
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"Dieses eine include:_spf.google.com löst 4 tatsächliche Abfragen aus. Wiederholen Sie die Prüfung für jeden Anbieter und addieren Sie die Werte. Liegt die Summe über 10, sollten Sie die Struktur ändern, typischerweise durch Verschieben transaktionaler E-Mails auf eine Subdomain (send.yourdomain.com) mit einem eigenen kürzeren Eintrag.
Schritt 3: Mechanismen prüfen
Vergleichen Sie die vom Generator erzeugte Zeichenfolge mit dieser Tabelle:
| Mechanismus | Status | Maßnahme |
|---|---|---|
ptr | Veraltet | Entfernen. RFC 7208 rät ausdrücklich davon ab; der Mechanismus ist langsam und unzuverlässig. |
+all | Unsicher | Entfernen. Damit darf das gesamte Internet unter Ihrer Domain senden. |
ip4: 1.2.3.4 | Ungültige Syntax | Leerzeichen entfernen. Erforderlich ist ip4:1.2.3.4. |
?all | Schwach | Vermeiden. Eine neutrale Richtlinie bietet keinen wirksamen Spoofing-Schutz. |
~all | Akzeptabel | SoftFail. Nur während Migrationen verwenden, nicht dauerhaft. |
-all | Korrekt | HardFail. Nicht autorisierte Absender können abgelehnt werden; für den Produktivbetrieb geeignet. |
Checkliste zur SPF-Syntax
Unabhängig davon, ob der erste Entwurf aus einem Generator stammt oder manuell erstellt wurde, sollten Sie diese Punkte vor einer DNS-Änderung prüfen. Sie decken Probleme ab, die ein Generator nicht erkennen kann, von Duplikaten über rekursive Abfragen bis zu unsicheren Richtlinien.
- Ein Eintrag pro Domain. Vorhandene Duplikate zusammenführen und keinen zweiten veröffentlichen.
- Beginn mit
v=spf1. Keine Variante, sondern genau diese Zeichenfolge. - Ende mit
-alloder~all. Nicht+alloder?all. - IPs vor Includes.
ip4:undip6:kosten keine DNS-Abfrage. Für eine schnellere Auswertung zuerst aufführen. - Kein Selbstverweis.
include:yourdomain.comerzeugt eine Endlosschleife und muss entfernt werden. - Keine manuelle IP-Abflachung, sofern keine Automatisierung den Eintrag aktuell hält. Wechselt Google IPs und Sie aktualisieren nicht, kann der Versand unbemerkt ausfallen.
- Gesamtabfragen ≤ 10. Alles einschließlich verschachtelter Includes zählen.
Ein produktionsgeeigneter Eintrag:
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allIPs zuerst ohne Abfragekosten, danach Includes und am Ende Hard Fail. Mehr ist nicht erforderlich.
Warum Agenturen und KMU über Generatoren hinauswachsen
Ein SPF-Record-Generator eignet sich für eine einzelne Domain mit einem oder zwei Absendern. Bei zunehmender Größe, etwa Agenturen mit vielen Kunden oder KMU mit umfassendem SaaS-Stack, wird er ohne zentrale Sicht auf Abfragezahlen und Duplikate im gesamten Bestand zu einem wiederkehrenden Betriebsrisiko.
Der alte Weg: ein eigener SPF-Eintrag je Kunde, jeweils aus einer anderen Generatorsitzung und ohne Prüfprotokoll. Eine Domain erreicht das Abfragelimit, und drei Tage lang bemerkt es niemand. Die Zustellreputation des Kunden kann darunter leiden.
Einen vollständigen Überblick zum Schutz der E-Mail-Infrastruktur im Unternehmen bietet unser Leitfaden zum Absichern geschäftlicher E-Mails. Er behandelt die Grundlage über SPF hinaus.
Wie TrekMail das Generatorproblem reduziert
SPF wird komplex, wenn mehrere Drittanbieter verwaltet werden und das Limit von 10 Abfragen einzuhalten ist. TrekMail kann beide Aufgaben für die primäre Mailinfrastruktur vereinfachen. Für die zentrale Versanddomain müssen Sie dann nicht bei jeder Änderung einen Generator ausführen, verschachtelte Abfragen zählen oder Mechanismen erneut prüfen.
Für KMU: Ein Include, wenig Wartung
Im Starter-Tarif von TrekMail ($3.50/mo) läuft die ausgehende Zustellung über das verwaltete SMTP von TrekMail. Der SPF-Eintrag besteht aus einer Zeile:
v=spf1 include:spf.trekmail.net -allTrekMail verwaltet IP-Wechsel und Absenderreputation hinter diesem Include. Dadurch sind spätere Änderungen am Kerneintrag seltener nötig. Auch eine neue Generatorprüfung oder Abfrageprüfung nach dem Hinzufügen eines SaaS-Werkzeugs kann für diesen Versandpfad entfallen.
Für Agenturen: Eine Vorlage für Kunden
Der alte Weg: 100 Kunden, 100 SPF-Einträge aus 100 Generatorläufen, jeweils mit eigenem Risiko rekursiver Abfragen. Jeder Eintrag kann ohne unmittelbare Warnung ausfallen.
Der TrekMail-Ansatz: eine Vorlage für die Kundendomains:
v=spf1 include:spf.trekmail.net -allIm Agency-Tarif ($23.25/mo) können Sie 1,000+ Domains in einem Dashboard verwalten. Die Standardisierung auf TrekMail für Unternehmensmail kann das rekursive Abfrageproblem im zentralen Kommunikationskanal reduzieren. Wie sich die Verwaltung bei wachsender Domainzahl verändert, zeigt unser Leitfaden zum Multi-Domain-E-Mail-Hosting.
Welche DNS-Einträge TrekMail neben SPF erwartet, darunter MX, DKIM und DMARC, beschreibt die Dokumentation zu den erforderlichen DNS-Einträgen an einer Stelle.
FAQ zum SPF-Record-Generator
Diese Fragen entstehen oft, wenn die erste Generatorsitzung einen nicht funktionierenden Eintrag liefert. Sie betreffen die Lücke zwischen syntaktischer Prüfung durch den Generator und betrieblicher Prüfung, für die aktives DNS untersucht werden muss.
Kann ich die Ausgabe mit zwei Generatoren vergleichen?
Das ist möglich, behebt aber das Grundproblem nicht. Zwei Werkzeuge können zwei unterschiedliche Zeichenfolgen liefern. Keines muss Duplikate im aktiven DNS erkennen oder rekursive Abfragen korrekt zählen. Die oben beschriebenen CLI-Schritte prüfen diese Punkte zuverlässiger.
Der Generator nennt den Eintrag gültig. Warum bouncen E-Mails?
Bei einem Generator bedeutet "gültig" meist nur korrekte Syntax, nicht Funktion in Ihrer Umgebung. Häufige Ursachen dieser Abweichung sind ein doppelter Eintrag mit PermError oder mehr als 10 rekursive Abfragen. Beide erfordern eine Prüfung des aktiven DNS, nicht nur der Oberfläche.
Wann verwende ich -all und wann ~all?
Verwenden Sie im Produktivbetrieb -all (HardFail), damit nicht autorisierte Absender abgelehnt werden können. ~all (SoftFail) eignet sich für eine Migrationsphase, in der noch nicht sicher alle Absender aufgeführt sind. Es sollte ein Übergangszustand bleiben. Ein Generator, der ?all oder +all vorgibt, priorisiert möglicherweise eine scheinbar funktionierende Ausgabe vor wirksamer Zustellkontrolle.
Kurzfassung
Ein kostenloser SPF-Record-Generator ist ein sinnvoller Ausgangspunkt für einen Entwurf, aber keine ausreichende Endkontrolle für den Produktivbetrieb. Die drei übersehenen Fehlerarten, Duplikate, zu viele rekursive Abfragen und leere Abfragen, können Bounces und PermErrors verursachen, deren Diagnose Stunden beansprucht.
Die Lösung ist nicht zwingend ein besserer Generator, sondern eine fünfminütige CLI-Prüfung: Duplikate suchen, verschachtelte Abfragen zählen und Mechanismen kontrollieren. Erst danach sollten Sie veröffentlichen.
Wenn Sie den Generatorprozess vermeiden möchten, bündelt TrekMail den ausgehenden Versand auf ein einzelnes include:. Damit bleibt eine DNS-Zeile, ohne laufende Abfragearithmetik und mit weniger PermError-Diagnose.
14-day kostenlose Testphase starten. Eine Kreditkarte ist erforderlich; eine Kündigung ist gemäß den aktuellen Bedingungen möglich.
