SPF für mehrere Absender: 10-Lookup-Limit vermeiden

Mit einem Absender funktioniert Ihre SPF-Einrichtung problemlos. Dann kommen Google Workspace, Mailchimp, Zendesk und eine API für Transaktionsmails hinzu, und Microsoft weist Nachrichten möglicherweise mit 550 5.7.515 ab. Der anfangs übersichtliche Eintrag hat das Limit von 10 DNS-Abfragen überschritten, sodass ausgehende Nachrichten die Authentifizierung nicht mehr zuverlässig bestehen.

Das ist die Falle. SPF besitzt eine feste Protokollgrenze, die viele Teams bereits mit dem dritten oder vierten Versanddienst erreichen. Die übliche Lösung, noch ein include: einzufügen, funktioniert gerade dann nicht mehr. Die Syntaxgrundlagen erklärt unser Leitfaden zum SPF-Eintrag für E-Mail. Hier geht es um die Architektur: eine SPF-Struktur für mehrere Absender, die Anbieterwechsel verkraftet und nicht jedes Quartal neu geschrieben werden muss.

Warum SPF mit mehreren Absendern scheitert

Nach RFC 7208 darf die SPF-Auswertung pro Eintrag höchstens 10 DNS-Abfragen auslösen. Jeder Mechanismus vom Typ include, a, mx, exists oder redirect zählt, und zwar rekursiv. Verweist das Include eines Anbieters intern auf drei weitere, werden auch diese angerechnet. Bei 11 können Empfänger PermError zurückgeben und die Nachricht ablehnen.

Das Muster ähnelt sich: Anfangs gibt es zwei Includes und genügend Spielraum. Das Marketing ergänzt HubSpot, der Support Freshdesk und die Entwicklung SendGrid für Anwendungshinweise. Die Include-Ketten sind tiefer als erwartet. Plötzlich entstehen 12 Abfragen, und Google antwortet auf jede Nachricht mit 550 5.7.26.

Die Rechnung ist einfach, bleibt aber unsichtbar, bis etwas ausfällt. Deshalb beginnt eine skalierbare SPF-Einrichtung mit Architektur statt mit Kopieren und Einfügen.

SPF vor jeder Ergänzung prüfen

Entfernen Sie zuerst, was nicht mehr benötigt wird. Viele Domains enthalten Includes von Diensten, die vor Monaten oder Jahren gekündigt wurden. Jedes davon verbraucht Abfragebudget. Erst aufräumen, dann erweitern.

Prüfen Sie den öffentlich veröffentlichten Eintrag:

dig txt yourdomain.com +short

Verfolgen Sie anschließend jedes Include und seine Verschachtelung:

dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +short

Vergleichen Sie das Ergebnis mit Ihren DMARC-Aggregatberichten. Wenn von den IPs eines Anbieters tatsächlich kein Verkehr kommt, ist das Include unnötig und kann nach sorgfältiger Prüfung entfernt werden.

Drei schnelle Verbesserungen bei der Prüfung:

1. Ersetzen Sie mx durch die tatsächliche IP mit ip4:, das spart eine Abfrage.
2. Entfernen Sie Includes nicht mehr verwendeter Dienste.
3. Suchen Sie nach doppelten SPF-Einträgen. Zwei TXT-Einträge mit v=spf1 auf derselben Domain verursachen sofort PermError.

Damit lassen sich oft 2-3 Abfragen freigeben. Ausführliche Schritte finden Sie im Leitfaden zur SPF-Einrichtung.

Subdomain-Aufteilung: Die skalierbare SPF-Architektur

Eine zuverlässige Methode für mehrere Absender ohne Überschreitung des 10-Lookup-Limits ist die Aufteilung nach Subdomains. SPF wertet die Return-Path-Domain aus, nicht den sichtbaren From-Header. Verschieben Sie nicht geschäftliche Versandströme auf Subdomains, erhält jeder Strom ein eigenes Budget von 10 Abfragen.

Das Muster sieht so aus:

Root-Domain, nur persönliche Geschäftspost

Halten Sie die Root-Domain übersichtlich. Hier steht nur Ihr primärer Postfachanbieter.

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

Ein Include, eine Abfrage. Ein neues Marketingwerkzeug gefährdet damit nicht automatisch die persönliche Geschäftspost.

Marketing-Subdomain, Kampagnen und Newsletter

; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -all

HubSpot und Mailchimp verbrauchen das Budget von news.example.com statt das der Root-Domain. Wird diese Subdomain gedrosselt, kann die Geschäftspost weiterlaufen, wobei die genaue Reputationsverknüpfung vom Empfänger abhängt.

Support-Subdomain, Ticketsysteme

; help.example.com
v=spf1 include:mail.zendesk.com -all

Transaktions-Subdomain, Anwendungshinweise und Belege

; alerts.example.com
v=spf1 include:amazonses.com -all

Sendet Zendesk als support@help.example.com, fragt der Empfänger DNS für help.example.com ab. Der SPF-Eintrag der Root-Domain wird nicht ausgewertet. Genau darum geht es.

SPF-Flattening als letzter Ausweg

Müssen sämtliche Nachrichten zwingend von der reinen Domain kommen und sind Subdomains ausgeschlossen, bleibt SPF-Flattening. Dabei werden Anbieter-Includes in IP-Adressen aufgelöst und als ip4:-Mechanismen aufgeführt, die keine Abfrage kosten. Das funktioniert, erzeugt aber Wartungsaufwand.

Das Risiko sind veraltete Daten. SaaS-Anbieter wechseln regelmäßig ihre IPs. Ergänzt SendGrid morgen einen Bereich und enthält Ihr abgeflachter Eintrag nur die gestrigen Adressen, kann SPF fehlschlagen. Führen Sie Flattening nicht manuell durch, wenn Sie es nicht täglich prüfen. Nutzen Sie einen vertrauenswürdigen dynamischen SPF-Dienst, der Anbieter-IPs überwacht und TXT-Einträge kontrolliert aktualisiert.

Flattening ist eine Umgehung und kein gutes Grunddesign. Die Aufteilung nach Subdomains ist die eigentliche Lösung. Verwenden Sie Flattening nur, wenn andere Möglichkeiten wirklich ausscheiden.

SPF-Einrichtung überprüfen

Prüfen Sie nach jeder Änderung, was das öffentliche DNS tatsächlich liefert. Verlassen Sie sich nicht allein auf Registrar-Dashboards, zwischengespeicherte Anzeigen oder grüne Häkchen in Anbieteroberflächen. Fragen Sie die Domain direkt ab und stellen Sie sicher, dass pro Hostname genau ein gültiger SPF-Eintrag existiert.

# Check the root record
dig txt example.com +short

# Check a subdomain
dig txt news.example.com +short

# Verify DMARC while you're at it
dig txt _dmarc.example.com +short

Pro Hostname sollte genau ein TXT-Eintrag mit v=spf1 beginnen, nicht zwei und auch nicht ein aktueller plus ein Rest einer Migration von vor zwei Jahren.

Senden Sie danach eine Testmail an Gmail, öffnen Sie das Drei-Punkte-Menü, wählen Sie die Anzeige des Originals und suchen Sie nach:

SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASS

FAIL oder SOFTFAIL weist auf ein Problem hin, das vor größerem Versand behoben werden sollte. Zustellbarkeit hängt dennoch von weiteren Signalen ab. Der Beitrag über Absenderreputation erklärt das Gesamtbild.

Wie TrekMail SPF für mehrere Domains vereinfacht

SPF für eine Domain ist lästig. Bei 50 Kundendomains mit unterschiedlichen Anbietern, DNS-Diensten und Altlasten entsteht erheblicher Aufwand. TrekMail hält seinen SPF-Anteil klein und vorhersehbar, damit Platz für andere Absender bleibt.

Das zentrale Include lautet include:spf.trekmail.net. Es beansprucht eine Abfrage und verwendet nach aktueller Architektur keine verschachtelten Redirects oder unvorhersehbaren Erweiterungsketten. Microsoft 365 kann dagegen durch interne Weiterleitungen 2-3 Abfragen benötigen, Google Workspace kann je nach Region variieren. Prüfen Sie die tatsächlichen Werte stets direkt.

Einzelgründer behalten damit auch nach einem Marketingtool eine einfache Struktur. Teams vermeiden eher DNS-Fehler beim Einstieg. Agenturen können eine Vorlage wiederholen: TrekMail-Include ergänzen, andere Anbieter auf Subdomains verteilen und das Risiko einer Überschreitung deutlich reduzieren. Regelmäßige Prüfungen bleiben notwendig. Mehr zum Gesamtaufbau unter E-Mail-Hosting für mehrere Domains.

Die DNS-Statusprüfung von TrekMail weist im Dashboard auf SPF-Konflikte hin, bevor daraus Produktionsfehler werden. Die vollständige Einrichtung erklärt die Dokumentation zu erforderlichen DNS-Einträgen.

Fazit: SPF einmal richtig aufbauen

Gute SPF-Einrichtung beginnt mit Architektur statt Syntax. Entfernen Sie tote Includes. Verteilen Sie Absender auf Subdomains, damit jeder Strom ein Budget von 10 Abfragen erhält. Halten Sie die Root-Domain sauber: ein Postfachanbieter, ein Include und ein -all. Prüfen Sie mit dig statt nur im Dashboard.

Für eine oder hundert Domains bietet TrekMail nach aktueller Beschreibung pauschales Multi-Domain-Hosting, ein übersichtliches SPF-Include, gemeinsamen Speicher und eine DNS-Prüfung. Nano umfasst 10 Domains mit eigenem SMTP, ohne Kreditkarte und dauerhaft kostenlos. Kostenpflichtige Tarife beginnen bei Starter mit $3.50/mo, verwaltetem SMTP und einer 14-tägigen Testphase, Kreditkarte erforderlich. Preise und Bedingungen können sich ändern; aktuelle Angaben finden Sie unter trekmail.net/pricing.