SPF-Eintrag erstellen: Absender ordnen und DNS-Abfragen prüfen

Wenn Sie für eine Domain einen SPF-Eintrag erstellen müssen, ist das Ziel einfach: die richtigen Absender zulassen, ohne ein DNS-Chaos aufzubauen, das ein halbes Jahr später Probleme macht. Meist beginnt es gleich. Ein Anbieter kommt hinzu, dann ein weiterer. Schließlich meldet Microsoft 550 5.7.515, Google meldet 550 5.7.26, und Sie durchsuchen um 11 Uhr abends Ihre TXT-Einträge.

Genau darin liegt das Problem. SPF wirkt einfach, bis es das nicht mehr ist. Der Eintrag der Hauptdomain wird zur Sammelstelle, rekursive Includes häufen sich, und ein zusätzlicher DNS-auslösender Term kann die Auswertung in einen PermError kippen. Bei einer Firmendomain, einer Kundenumgebung oder mehreren Marken ist das mehr als eine Kleinigkeit: Je nach Empfängerrichtlinie können Nachrichten scheitern. Einen umfassenderen Überblick zur Domaineinrichtung bietet zunächst Business-E-Mail für kleine Unternehmen.

Dieser Leitfaden zeigt ein belastbares Muster: Firmenpost bleibt auf der Hauptdomain, Massen- und Anwendungsmails werden über Subdomains getrennt, und das Lookup-Budget wird als begrenzte Ressource behandelt. So lassen sich SPF-Einträge anlegen, die seltener grundsätzlich umgebaut werden müssen, auch wenn regelmäßige Prüfungen weiterhin nötig bleiben.

Warum so viele SPF-Einträge Probleme machen

SPF begrenzt bei der Auswertung die Anzahl der DNS-auslösenden Terme, nicht einfach alle einzelnen DNS-Pakete. Wenn Sie zu viele Includes auf einer Domain sammeln, kann die Prüfung das Limit überschreiten und PermError liefern. Je nach Richtlinie des Empfängers kann die Nachricht dann abgelehnt werden, selbst wenn die Syntax auf den ersten Blick stimmt.

RFC 7208 ist hier eindeutig. Zu den DNS-auslösenden Termen zählen include, a, mx, ptr, exists und redirect. Empfänger müssen diese während der Auswertung, einschließlich rekursiver Auswertungen, auf 10 begrenzen. Eine Überschreitung führt zu einem permanenten Fehler, nicht bloß zu einer Warnung. Mehrere SPF-Einträge für denselben Hostnamen verursachen laut RFC ebenfalls PermError; andere, unabhängige TXT-Einträge sind dagegen zulässig.

Deshalb reicht der übliche Rat nicht aus. Allgemeine Anleitungen empfehlen, alle Absender in einen TXT-Wert bei @ zu packen. Das wirkt ordentlich, schafft aber gemeinsame Infrastruktur für Newsletter, Supportsysteme, App-Benachrichtigungen, Akquiseprogramme und persönliche Postfächer. Vergrößert ein Anbieter seine Include-Kette, kann das die SPF-Auswertung der gesamten Hauptdomain beeinträchtigen.

Ungünstiges Muster: Ein SPF-Eintrag auf der Hauptdomain soll jedes jemals eingesetzte Firmenwerkzeug autorisieren.

Auch Googles Absenderrichtlinien betonen operativ eine saubere Authentifizierung und Domainausrichtung, insbesondere beim Massenversand. SPF ist nur ein Teil davon, doch fehlerhaftes SPF ist häufig das erste sichtbare Problem.

Die tatsächliche Grenze: Das Budget von 10 Lookups

Die feste Regel lautet: Für die SPF-Auswertung stehen höchstens 10 DNS-auslösende Terme zur Verfügung. Dieses Budget gilt rekursiv. Wird ein Include ausgewertet und enthält es weitere solche Terme, zählen auch diese mit. Ein guter DNS-Anbieter kann eine überladene SPF-Struktur nicht ausgleichen.

Zum Budget zählen:

• include
• a
• mx
• ptr (nicht verwenden)
• exists
• redirect

Nicht zum Budget zählen:

• ip4
• ip6
• all

Auch erfolglose DNS-Abfragen, sogenannte Void Lookups, verdienen Aufmerksamkeit. RFC 7208 empfiehlt Empfängern, diese auf zwei zu begrenzen. Ein Tippfehler im Include-Ziel kann einen Teil dieses Spielraums verbrauchen. Fehlerhafte Verweise können bei Überschreitung der empfohlenen Grenze einen weiteren PermError verursachen; das bloße Erreichen der Grenze genügt dafür nicht.

Wenn eine Domain über vier oder fünf Anbieter versendet, lohnt sich eine genaue Budgetprüfung bereits früh. Nicht weil SPF grundsätzlich instabil wäre, sondern weil rekursive Anbieterketten die Architektur belasten können.

SPF-Einträge mit einer getrennten Versandarchitektur erstellen

Ein robustes Muster trennt persönliche Post von Massen- und Anwendungsmails. Der primäre Postfachanbieter bleibt auf der Hauptdomain; Marketing, Supportplattformen und Anwendungen verwenden Subdomains. Eigene SPF-Budgets entstehen allerdings nur, wenn die tatsächliche MAIL-FROM- beziehungsweise Return-Path-Domain entsprechend konfiguriert ist. Eine andere sichtbare From-Adresse allein schafft keine Trennung. DMARC benötigt weiterhin passend ausgerichtetes SPF oder DKIM; dabei unterscheiden sich strikte und gelockerte Ausrichtung.

Das Muster:

1. Hauptdomain @ für die persönliche Korrespondenz.
2. Subdomains für Newsletter, Support, Transaktionsmeldungen und andere spezialisierte Absender, mit passender Envelope-Domain.
3. Ein SPF-Eintrag pro Hostname. Keine doppelten SPF-Einträge oder Altlasten; unabhängige TXT-Einträge dürfen bleiben.

Beispiel für die Hauptdomain bei verwaltetem Versand über TrekMail, sofern aktuell vom Anbieter vorgesehen:

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

Übersichtlich: ein Include und eine klare Richtlinie. Prüfen Sie dennoch dessen rekursive Auswertung und alle tatsächlichen Absender.

Beispiel für eine Marketing-Subdomain:

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

Diese Anbieterwerte sind Beispiele, keine universelle Konfiguration. Prüfen Sie die aktuellen offiziellen Vorgaben von Mailchimp und HubSpot und richten Sie gegebenenfalls eine unterstützte eigene MAIL-FROM-Domain ein. Nur wenn SPF tatsächlich für marketing.example.com ausgewertet wird, bleibt dessen Budget vom Budget der Firmenpost unter example.com getrennt.

Hier kann auch TrekMail gut hineinpassen. Die Domaineinrichtungsdokumentation nennt include:spf.trekmail.net als Basis-Include, und der DNS-Prüfer kann Konflikte erkennen helfen. Er ersetzt keine vollständige Kontrolle aller Absender. Wenn Sie Postfächer und DNS noch einrichten, helfen Eine Domain zu TrekMail hinzufügen und DNS-Status prüfen; maßgeblich sind die aktuellen Einrichtungsvorgaben.

Schritt für Schritt: SPF-Einträge ohne Rätselraten erstellen

Für wartbare SPF-Einträge erfassen Sie zuerst alle Absender, ordnen sie dem richtigen Hostnamen zu und erstellen erst danach den TXT-Eintrag. Beginnen Sie nicht im DNS, sondern bei der Zuständigkeit für den Versand. So sammeln sich keine beliebigen Includes auf der Hauptdomain.

Gehen Sie so vor:

1. Erfassen Sie jeden Dienst, der im Namen Ihrer Domain versendet.
2. Ordnen Sie ihn Firmenpost, Transaktionen, Support oder Marketing zu.
3. Legen Sie den Hostnamen und die tatsächliche MAIL-FROM-Domain fest.
4. Verwenden Sie die kleinste gültige SPF-Richtlinie für diese Domain.
5. Veröffentlichen Sie pro Hostname genau einen SPF-TXT-Eintrag; andere TXT-Zwecke bleiben unabhängig.

Erstellen Sie anschließend den eigentlichen Eintrag entsprechend den offiziellen Anbieterangaben und der verwendeten Envelope-Domain.

Beispiel für verwaltetes TrekMail-SMTP:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Kombinationsbeispiel für TrekMail und eigenes SMTP im Nano-Tarif oder in hybriden Umgebungen, nur wenn beide Versandwege tatsächlich autorisiert werden müssen:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

Bei eigenem SMTP autorisieren Sie den tatsächlich verwendeten SMTP-Anbieter für dessen Envelope-Domain, nicht automatisch TrekMail und Amazon SES oder fremde Includes. Prüfen Sie besonders bei SES die aktuellen Vorgaben zur eigenen MAIL-FROM-Domain. Im hier beschriebenen Nano-Modell benötigen Sie einen eigenen SMTP-Anbieter für ausgehende Post. Das dokumentierte Angebot nennt kostenpflichtige Tarife ab $3.50/Monat mit verwaltetem SMTP und einen dauerhaft kostenlosen Nano-Tarif. Für kostenpflichtige Tarife wird eine kostenlose Testphase von 14 Tagen mit erforderlicher Kreditkarte genannt. Diese Angaben unterliegen den aktuellen Tarifbedingungen. Einrichtungshinweise finden Sie unter Eigenes SMTP (BYO) und Verwaltetes TrekMail-SMTP.

Den Eintrag veröffentlichen und prüfen

Veröffentlichen Sie den SPF-Wert als TXT-Eintrag und prüfen Sie anschließend die öffentlich abrufbaren DNS-Antworten. Verlassen Sie sich nicht allein auf die Registrar-Oberfläche, zwischengespeicherte Dashboardwerte oder ein grünes Symbol. Die folgenden Abfragen nutzen in der Regel einen Resolver und können gecachte Antworten liefern; sie garantieren keine direkte Abfrage der autoritativen Server. Prüfen Sie auf genau einen gültigen SPF-Eintrag und berücksichtigen Sie Cache-Laufzeiten.

Mac oder Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Gesucht ist genau ein SPF-Wert, der mit v=spf1 beginnt. Keine doppelten SPF-Werte und kein aktueller Eintrag neben einem vor drei Jahren bei einer Migration vergessenen. Andere TXT-Einträge sind kein SPF-Konflikt.

Kurze Prüfliste:

• Beginnt mit v=spf1
• Endet mit -all, wenn Tests und die vollständige Absenderinventur abgeschlossen sind
• Enthält nur die tatsächlich benötigten Absender
• Existiert als SPF-Eintrag genau einmal pro Hostname

Bei einem Anbieterwechsel bleiben häufig alte MX- und SPF-Einträge zurück. TrekMails DNS-Dokumentation weist auf solche Konflikte hin; prüfen Sie die für Ihre Migration geltenden Schritte. Für einen umfassenderen Plattformwechsel helfen E-Mail mit eigener Domain erstellen und E-Mail-Hosting für mehrere Domains.

Häufige SPF-Fehler und schnelle Gegenmaßnahmen

Typische SPF-Probleme sind zu viele DNS-auslösende Terme, mehrere SPF-Einträge, falsche Versanddomains oder Tippfehler in Includes. Mit einer klaren Absenderübersicht lassen sie sich leichter erkennen. Ohne diese Übersicht wird die Fehlersuche schnell aufwendig.

Zwei praktische Regeln ersparen viel Aufwand:

1. Verwenden Sie ip4 für vollständig kontrollierte Absender mit statischer Adresse. Das verbraucht keine DNS-auslösenden Terme im SPF-Budget.
2. Lassen Sie Marketing nicht ohne guten Grund dieselbe Envelope-Domain wie die Geschäftsleitung nutzen; die sichtbare Absenderadresse allein ist hier nicht entscheidend.

Googles Absenderdokumentation benennt das eigentliche Ziel: Authentifizierung und Domainausrichtung, nicht SPF für sich allein. SPF kann bestehen und die Nachricht trotzdem eine Richtlinienprüfung verfehlen, wenn die authentifizierte Domain nicht zur sichtbaren From-Domain passt. DMARC akzeptiert passend ausgerichtetes SPF oder DKIM nach dem konfigurierten strikten oder gelockerten Modus. Bei Problemen mit Massenmails hilft Googles FAQ zu den Richtlinien für E-Mail-Absender.

Wann TrekMail die Einrichtung vereinfachen kann

TrekMail kann helfen, SPF-Konfigurationen über mehrere Domains übersichtlich zu halten. Die hier beschriebenen operativen Vorteile sind ein TrekMail-Include, gemeinsamer Speicher, keine Abrechnung pro Nutzer, integrierte IMAP-Migration und je nach Tarif und Versandmodell eigenes oder verwaltetes SMTP. Verfügbarkeit, Grenzen und Einrichtung richten sich nach dem aktuellen Angebot; auch ein einzelnes Include muss rekursiv geprüft werden.

Für Einzelgründer kann das eine einfache Struktur bieten: saubere Firmenpost, TrekMail als Postfachhoster und keine tarifliche Abrechnung pro Sitzplatz. Teams können von einheitlichem Onboarding profitieren. Agenturen und MSPs können dasselbe Muster für zahlreiche Domains wiederverwenden, müssen jedoch Anbieteranforderungen und Domains jeweils prüfen.

Statt für jeden Kunden eine andere empfindliche SPF-Struktur aufzubauen, lässt sich mit einer wiederholbaren Architektur, einem Dashboard und einem überprüften Hauptdomain-Include arbeiten. Das verbessert den Betrieb, nicht nur den TXT-Wert, beseitigt aber nicht die laufende Wartung.

Das hier beschriebene Nano-Angebot nennt 10 Domains, 5GB gemeinsamen Speicher und eigenes SMTP ohne erforderliche Kreditkarte. Für verwalteten Versand und höhere Grenzen werden kostenpflichtige Tarife ab $3.50/Monat mit einer kostenlosen Testphase von 14 Tagen und erforderlicher Kreditkarte genannt. Prüfen Sie vor Ihrer Entscheidung die aktuellen Leistungen, Limits und Bedingungen unter TrekMail-Preise.

Fazit: SPF strukturiert anlegen und seltener umbauen

Für langlebige SPF-Einträge denken Sie nicht an eine riesige Zulassungsliste auf der Hauptdomain, sondern an die Architektur: Hauptdomain für persönliche Post, passende Envelope-Subdomains für spezialisierte Absender, möglichst wenige Includes, explizites -all nach vollständiger Absenderprüfung und DNS-Kontrolle nach der Veröffentlichung.

Dieses Vorgehen kann das Lookup-Budget schonen, unerwartete Ausfälle reduzieren und Anbieterwechsel erleichtern. Es ist keine Garantie für wartungsfreies SPF. Wenn Sie Ihre Mailumgebung ohnehin neu aufbauen, sehen Sie sich TrekMail an und prüfen Sie, ob das aktuelle Angebot zu Ihrem Wachstum passt.