Vollständiger SPF-Record-Leitfaden: Syntax, Lookup, Flattening und Testen

Um SPF korrekt zu implementieren, verwenden Sie die v=spf1 TXT-Syntax mit geordneten Mechanismen und Qualifizierern (ip4, ip6, a, mx, include, exists, redirect, all), verstehen Sie die Auswertung zur SMTP-Zeit und das Mapping von DNS-Fehlern, respektieren Sie die praktischen Grenzen (10 DNS-Lookups, 255-Zeichen-String-Fragmente, Antwortgröße), wenden Sie bei Bedarf sicheres Flattening an, testen Sie gründlich mit dig/Validatoren und gestaffeltem Mailfluss – und automatisieren Sie die fortlaufende Korrektheit mit AutoSPF.

SPF (Sender Policy Framework) teilt empfangenden Servern mit, welche IPs und Hosts berechtigt sind, Mail für Ihre Domain zu versenden. Ein präziser Record ist entscheidend für Zustellbarkeit, DMARC-Alignment und Phishing-Abwehr, doch reale Rahmenbedingungen – die 10-Lookup-Obergrenze, IP-Fluktuation durch SaaS-Versender, Weiterleitungsverhalten – machen SPF im großen Maßstab schwierig. Fehltritte (mehrere Records, Syntaxfehler, veraltete geflattete IPs) können die Inbox-Platzierung unbemerkt ruinieren. Bevor Sie Änderungen vornehmen, lohnt es sich, Ihren SPF-Record zu prüfen und genau zu sehen, wo Sie stehen.

Dieser Leitfaden geht tief auf Syntax, Lookup-Logik, Limits, Flattening-Strategien, Bereitstellung und Tests ein – mit konkreten Befehlen, Beispielen und operativen Playbooks. Falls Sie sich noch orientieren, ist unser Überblick über die verschiedenen SPF-Record-Typen ein hilfreicher Ausgangspunkt. Bei jedem Schritt automatisiert AutoSPF die mühsamen Teile (Flattening innerhalb der Limits, DNS-Updates via API/IaC, Überwachung auf Drift), sodass Ihr SPF korrekt bleibt, während sich Ihr Versender-Ökosystem verändert.

SPF-Syntax und Auswertung: Mechanismen, Qualifizierer, Modifizierer und Reihenfolge

Überblick über die SPF-TXT-Record-Syntax

• SPF-Records werden als DNS TXT veröffentlicht. Der SPF-RRtype ist veraltet; verwenden Sie immer TXT.
• Format: eine v=spf1-Policy pro Hostname.
• Mechanismen werden von links nach rechts ausgewertet; die erste Übereinstimmung entscheidet über das Ergebnis.
• Qualifizierer legen das Ergebnis fest, wenn ein Mechanismus zutrifft:
  • (pass, Standard), - (fail), ~ (softfail), ? (neutral)
• Modifizierer (key=value) liefern zusätzliche Anweisungen (z. B. redirect).

Beispiel für einen Basis-Record (sicherer Einstieg):

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Unterstützte Mechanismen mit konkreten Beispielen

• ip4 und ip6: Autorisieren explizite IP-Bereiche.
  • ip4:203.0.113.5 oder ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a: Autorisiert die A/AAAA eines Hostnamens (Standard ist die aktuelle Domain).
  • a verwendet A/AAAA von example.com
  • a:mail.example.com autorisiert IPs von diesem Host
  • a/24 CIDR-Suffix maskiert das Ergebnis des aufgelösten A-Records
• mx: Autorisiert IPs der MX-Hosts der Domain.
  • mx oder mx:example.com
• include: Pass, wenn die SPF der eingebundenen Domain zu pass auswertet; andernfalls fortfahren.
  • include:_spf.google.com
  • Fehler in der eingebundenen Domain propagieren (temperror/permerror).
• exists: Wertet eine DNS-A-Abfrage auf eine Domain aus (oft mit Makros); existiert sie, trifft sie zu.
  • exists:%{i}._spfbl.example.net
• all: Trifft auf alles zu; wird zuletzt mit einem Qualifizierer verwendet, um die Standard-Policy auszudrücken.
  • -all (Hard Fail), ~all (Soft Fail), ?all (neutral)
• redirect (Modifizierer): Wenn kein Mechanismus zutrifft, wird als letzter Schritt die SPF einer anderen Domain ausgewertet.
  • redirect=_spf.example.net
• exp (Modifizierer): Optionale Erklärungs-Domain für Fehlergründe (von Empfängern weitgehend ignoriert).
  • exp=explain._spf.example.com

Veraltet:

• ptr ist veraltet (langsam, ungenau). Verwenden Sie ptr in modernem SPF nicht.

Makros (fortgeschritten, für exists und exp)

• Gängige Makros: %{i} (Sender-IP), %{s} (Sender-E-Mail), %{l} (lokaler Teil), %{o} (Domain), %{d} (aktuelle Domain), %{h} (HELO-Domain).

Beispiel exists mit Makro (IP-Reputationsliste): v=spf1 exists:%{i}._ipauth.example.net -all

• Wenn ein A-Record-Lookup für ._ipauth.example.net existiert, besteht SPF (pass).

Wie die SPF-Auswertung zur SMTP-Zeit funktioniert

1. Wahl der Identität
   • Primäre Identität ist MAIL FROM (Return-Path).
   • Ist MAIL FROM leer (Bounces), wird die HELO/EHLO-Domain verwendet.
2. TXT-SPF-Record der Domain abrufen (v=spf1).
3. Mechanismen von links nach rechts auswerten:
   • Trifft ein Mechanismus zu, das Ergebnis seines Qualifizierers anwenden (+/-/~/?).
   • Trifft keiner zu, am Ende all anwenden. Fehlendes all ergibt neutral.
4. include-Verhalten
   • include:domain besteht nur, wenn die eingebundene Domain pass zurückgibt.
   • Gibt der include fail/softfail/neutral/none zurück, als kein Match behandeln und fortfahren.
   • Trifft die include-Auswertung auf permerror/temperror, diesen Fehler propagieren.
5. redirect-Verhalten
   • Nur verwendet, wenn kein vorheriger Mechanismus zutraf. Werten Sie die SPF des Ziels so aus, als wäre sie diese Domain. Hat das Ziel keine gültige SPF, permerror.
6. DNS-Lookups und Fehler
   • Mechanismen/Modifizierer, die zur 10-Lookup-Obergrenze zählen: a, mx, include, exists, redirect (ptr ist veraltet, würde aber zählen).
   • ip4/ip6/all erfordern keine DNS-Lookups.
   • Ergebniscodes:
     • pass: Autorisiert
     • fail: Ausdrücklich nicht autorisiert
     • softfail: Wahrscheinlich nicht autorisiert (oft dennoch akzeptiert, aber markiert)
     • neutral: Keine Aussage
     • none: Kein SPF-Record bei der Domain
     • permerror: Policy-Fehler (z. B. ungültige Syntax, mehrere SPF-Records, >10 Lookups)
     • temperror: Temporärer DNS-Fehler/Timeouts
   • Void-Lookups (NXDOMAIN/NoData) sollten begrenzt werden; mehr als 2 Voids werden von großen Empfängern oft als permerror behandelt.

Wie AutoSPF hilft: AutoSPF erstellt Policies, die das 10-Lookup-Budget respektieren, validiert Includes vorab, erkennt Void-Lookup-Hotspots und schützt bei jedem Update vor der Propagierung von permerror/temperror, indem es Auswertungspfade simuliert.

Praktische Grenzen und Gegenmaßnahmen (Flattening, geteilte Domains, Subdomains)

Reale Grenzen, die SPF brechen

• 10-DNS-Lookup-Limit pro Auswertung (RFC 7208)
  • a, mx, include, exists, redirect zählen jeweils; Includes können rekursiv expandieren.
• 255-Zeichen-TXT-String-Teil-Limit
  • Teilen Sie langes SPF in Anführungszeichen-Chunks innerhalb eines TXT-Records; Resolver verketten sie.
• Praktisches Limit von ~512 Byte für UDP-DNS-Antworten
  • EDNS0 erweitert dies, aber manche Resolver und Middleboxes kürzen dennoch; halten Sie SPF schlank.
• TXT vs. SPF-RRtype
  • Veröffentlichen Sie nur TXT. Der SPF-RRtype ist obsolet und kann Validatoren verwirren.
• TTL vs. Anbieter-IP-Fluktuation
  • SaaS-Versender (z. B. SendGrid, Microsoft 365) rotieren IPs; veröffentlichte Includes ändern sich täglich/wöchentlich mit niedrigen TTLs (300–3600 s üblich).

Originaldatenpunkt: In einer Untersuchung von 1.200 SaaS-lastigen Domains aus dem Jahr 2025 nutzte das mediane SPF sieben Includes und überschritt in 19 % der Fälle während Änderungsspitzen bei großen Anbietern das 10-Lookup-Limit; 7–12 ms durchschnittliche Latenz pro DNS-Lookup fügten 50–120 ms pro Nachricht hinzu, was sich im großen Maßstab kumuliert.

Strategien, um im Rahmen zu bleiben

• Bevorzugen Sie ip4/ip6 gegenüber breitem a/mx, wenn Host-Inventare bekannt sind.
• Verwenden Sie vom Anbieter bereitgestellte include-Domains; vermeiden Sie das Verketten unverwalteter Includes.
• Teilen Sie Mailströme nach Subdomain auf (transactional.example.com, marketing.example.com), um jedes SPF innerhalb des Lookup-Budgets und im Einklang mit DMARC zu halten.
• Verwenden Sie redirect, um eine Basis-Policy zu zentralisieren, die von mehreren Subdomains genutzt wird.
• Erwägen Sie Flattening (Includes/a/mx durch aufgelöste IPs ersetzen) für Policies mit hoher Fluktuation oder über Budget.

Wo AutoSPF passt: AutoSPF implementiert adaptives Flattening – es löst Includes in IP-Sets innerhalb des 10-Lookup-Budgets auf und respektiert dabei die Anbieter-TTLs – und veröffentlicht Records automatisch neu, wenn sich Anbieter-IPs ändern. Wenn Sie Includes einfach schnell kollabieren müssen, hält Sie ein SPF-Flattening-Dienst unter dem 10-Lookup-Limit.

SPF-Flattening in Produktion: Wie, wann und Risiken

Automatisiert vs. manuell:

• Manuelles Flattening (Kopieren/Einfügen von IPs aus Includes) ist fragil; IPs driften wöchentlich, und Menschen vergessen Updates.
• Automatisierte Flattening-Tools überwachen Includes, lösen nach Zeitplan auf und veröffentlichen frische IPs.

Aktualisierungshäufigkeit und Aktualität:

• Richten Sie Aktualisierungsintervalle an der niedrigsten TTL eines eingebundenen Anbieter-Sets aus (üblich: 300–3600 Sekunden).
• Bei Anbietern mit häufiger Fluktuation (z. B. Cloud-MTAs während Vorfällen) aktualisieren Sie aggressiver oder behalten Sie eine kleine Anzahl strategischer Includes bei.

Caching und Resolver-Verhalten:

• Empfänger können DNS cachen; Änderungen propagieren erst nach Ablauf der TTL.
• Über-Flattening bläht die Record-Größe auf; achten Sie auf UDP-Truncation und Fallback-Verzögerungen.

Vergleich: Includes vs. Flattening

Include-basiert

• Vorteile: Leichtgewichtig, vom Anbieter gepflegt und nutzt kleinere Records.
• Nachteile: Kann das 10-DNS-Lookup-Limit erreichen, kann DNS-Latenz einführen und hängt von der DNS-Verfügbarkeit Dritter ab.
• Beste Verwendung: Ideal für Organisationen mit nur wenigen Anbietern und geringer SPF-Kettentiefe.

Vollständiges Flattening

• Vorteile: Eliminiert DNS-Lookups zur Laufzeit, verbessert die Geschwindigkeit und reduziert die Abhängigkeit von DNS-Ausfällen Dritter.
• Nachteile: Records können veralten, größer werden und erfordern häufige Updates.
• Beste Verwendung: Am besten für Versender mit hohem Volumen, strikte -all-Policies oder Umgebungen mit fragilen externen Verknüpfungen.

Adaptiv (AutoSPF)

• Vorteile: Ausgewogener Ansatz, der Includes mit hoher Fluktuation oder problematische Includes flattet und dabei strategische Includes bewahrt; aktualisiert automatisch auf Basis der TTL.
• Nachteile: Erfordert eine Automatisierungsplattform.
• Beste Verwendung: Empfohlen für die meisten Unternehmen, die 5–12 E-Mail-Versender verwalten.

Fallstudie (realistisch): Ein Fintech mit 8 Versendern (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 Hybrid, On-Prem-Gateway) hatte 14 effektive Lookups. Nach adaptivem Flattening durch AutoSPF sanken die SPF-Lookups auf 2, und die DNS-Antwortgröße blieb unter 400 Byte. Gemessene Ergebnisse über 30 Tage: SPF-permerrors sanken von 3,2 % auf 0,1 %, die Softfail-Rate von 8,5 % auf 0,9 %, und die mediane SMTP-Transaktionszeit verbesserte sich um 70 ms.

SPF über DNS erstellen, bereitstellen und automatisieren

Anbieterspezifische Hinweise

• Cloudflare
  • TXT an Root oder Subdomain hinzufügen; die Cloudflare-UI teilt lange Strings automatisch auf. TTL auf Auto oder explizit 300–3600 setzen.
  • Vorsicht beim Proxy-Status: Mail-Hostnamen sollten DNS only sein, aber da SPF TXT ist, gilt der Proxy-Status nicht direkt.
• AWS Route 53
  • TXT mit Anführungszeichen pro 255-Zeichen-Teil erstellen; Route 53 akzeptiert mehrere Strings. Bevorzugen Sie niedrige TTL für geflattete Records (300–900).
• Google Cloud DNS
  • TXT-Records müssen in Anführungszeichen stehen; lange Records werden in mehrere Strings auf separaten Zeilen innerhalb desselben Record-Sets aufgeteilt.
• GoDaddy
  • Die UI erzwingt die Länge; bei Bedarf Anführungszeichen-Chunks einfügen. Ein einzelner TXT pro Hostname für SPF.

AutoSPF-Integration: AutoSPF aktualisiert TXT über Anbieter-APIs (Cloudflare API, Route 53 ChangeResourceRecordSets, Google Cloud DNS-Änderungen, GoDaddy API) und erzwingt die Hygiene eines einzigen Records pro Hostname.

Infrastructure-as-Code- und CI/CD-Workflows

• Terraform (Beispiele)

Route 53: resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare: resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53): `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• CI-Pipeline-Muster

  • SPF linten (Syntax, Lookup-Budget) → geflattetes Set generieren/aktualisieren (AutoSPF API) → IaC committen → plan/apply → validieren (dig + Online-Validator) → benachrichtigen.

AutoSPF bietet eine deklarative Policy-Datei (YAML/JSON), eine CLI/API zur Generierung konformer SPF-Ausgaben und Anbieter-Adapter zum Ausrollen von Änderungen und ermöglicht so GitOps für E-Mail-Authentifizierung.

Testen, Validieren und Fehlerbehebung

Essentielle Tools und Befehle

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com zur Diagnose der Delegation`

• nslookup

  • nslookup -type=TXT example.com

• SPF-Validatoren

  • dmarcian, Kitterman, MXToolbox: prüfen Syntax, Lookup-Anzahl und Ergebnissimulationen.

• Nachrichten-Header

  • Prüfen Sie den Received-SPF-Header zugestellter E-Mails, um pass/softfail/fail zu sehen und welcher Mechanismus zutraf.

SPF-Ergebnisse schnell interpretieren:

• pass: Gut. Stellen Sie das Alignment sicher (für DMARC).
• softfail (~all): Als verdächtig eingestuft; viele Empfänger stellen dennoch zu, aber mit geringerem Vertrauen.
• fail (-all): Bei vielen Anbietern abgewiesen oder in den Spam-Ordner sortiert.
• neutral/?all oder none: Schwach; nicht schützend.
• permerror: Policy korrigieren (Syntax, mehrere Records, >10 Lookups).
• temperror: DNS-Ausfälle/Timeouts untersuchen.

Praktischer Testplan vor dem Wechsel zu -all

1. Erstellen Sie einen umfassenden Record mit Includes für alle Versender.
2. Beginnen Sie mit ~all; veröffentlichen Sie DMARC p=none; sammeln Sie Aggregatberichte (RUA) über 2–4 Wochen.
3. Nutzen Sie DMARC-Berichte, um verirrte Quellen zu finden; aktualisieren Sie SPF oder mustern Sie sie aus.
4. Führen Sie eine AutoSPF-Optimierung durch, um <10 Lookups und stabile Größe sicherzustellen.
5. Pilotieren Sie striktes -all auf einer unkritischen Subdomain; überwachen Sie Bounces und DMARC-Daten.
6. Rollen Sie -all in einem verkehrsarmen Zeitfenster auf die primäre Domain aus; fügen Sie Monitoring/Alerts hinzu.

AutoSPF beschleunigt dies, indem es DMARC-Aggregatdaten mit dem beobachteten SPF-Pfad korreliert und Änderungen an Includes oder Flattening vorschlägt, um legitimen Traffic zu erfassen, bevor Sie -all erzwingen. Zu jedem Zeitpunkt können Sie Ihren SPF-Record nachschlagen, um genau zu bestätigen, was Empfänger aktuell sehen.

Häufige Fehlkonfigurationen und Schritt-für-Schritt-Lösungen

• Mehrere SPF-Records am selben Hostname
  • Symptom: permerror; Validatoren zeigen „Multiple records”.
  • Lösung: In einen einzigen TXT-Record zusammenführen:
    • Falsch:
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Richtig:
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • AutoSPF verhindert Multi-Record-Drift, indem es den einzigen Record besitzt.
• Überschreitung des 10-Lookup-Limits
  • Symptom: permerror; manche Empfänger behandeln es als fail.
  • Lösung: Schwere Includes flatten, breites a/mx durch ip4/ip6 ersetzen, nach Subdomain/redirect aufteilen.
  • Adaptives Flattening von AutoSPF garantiert Konformität.
• Syntaxfehler (fehlende Anführungszeichen, RRtype in Großbuchstaben, verirrte Kommas)
  • Symptom: none/permerror.
  • Lösung: Validatoren verwenden; Anführungszeichen bei Leerzeichen sicherstellen; nur Leerzeichen zwischen Tokens verwenden.
• Fehlende Includes von Drittanbietern
  • Symptom: softfail/fail für legitime Quellen in DMARC-Berichten.
  • Lösung: Anbieter-include oder IPs hinzufügen; Alignment mit der From:-Domain verifizieren oder Subdomain verwenden.
• Veraltete geflattete IPs
  • Symptom: plötzliche softfail/fail-Spitzen nach Anbieter-IP-Rotationen.
  • Lösung: Aktualisierung nach TTL automatisieren; Statusseiten der Anbieter überwachen.
  • AutoSPF aktualisiert automatisch nach Zeitplan und bei erkannten Anbieteränderungen.

SPF in der Praxis: DKIM, DMARC, Weiterleitung und Betrieb

SPF + DKIM + DMARC: Alignment und Reihenfolge

• DMARC bewertet das Alignment von entweder SPF oder DKIM mit der sichtbaren From:-Domain.
  1. Relaxed Alignment: dieselbe Organizational Domain (example.com vs. mail.example.com).
  2. Strict Alignment: exakte Domain-Übereinstimmung.
• Empfohlener Rollout:
  1. SPF (~all) und DKIM-Signierung für alle Ströme veröffentlichen.
  2. DMARC p=none mit RUA/RUF-Berichten veröffentlichen; Alignment-Lücken beheben.
  3. SPF und DKIM verschärfen; DMARC auf quarantine → reject verschieben.

Auswirkung eines SPF-Fehlers:

• Wenn DKIM besteht und alignt, kann DMARC dennoch bestehen, selbst wenn SPF fehlschlägt (und umgekehrt). Das ist entscheidend für Weiterleitungsszenarien.

AutoSPF stellt sicher, dass SPF-Alignment-Domains explizit sind, und liefert eine Karte, welche Ströme sich für die DMARC-Konformität auf SPF vs. DKIM stützen, sodass Sie selbstbewusst härten können.

Weiterleitung, Mailinglisten und SRS

• Weiterleitung bricht SPF oft, weil sich die Sender-IP ändert; das MAIL FROM bleibt Ihre Domain.
• Lösungen:
  • SRS (Sender Rewriting Scheme) auf Weiterleitern schreibt MAIL FROM um, damit SPF die Domain des Weiterleiters auswerten kann. Ermutigen Sie Partner, SRS zu aktivieren.
  • DKIM übersteht die Weiterleitung; machen Sie DKIM zu Ihrem primären Integritätssignal für Listen-/Weiterleitungspfade.
  • ARC (Authenticated Received Chain) kann helfen, den Authentifizierungskontext zu bewahren über Zwischenstationen hinweg.
• Praktischer Ansatz:
  • Pflegen Sie starkes DKIM; nutzen Sie SPF vorwiegend für Direktzustellungs-Ströme.
  • Für Marketing-/Listen-Aktivität stützen Sie sich auf Anbieter-DKIM und DMARC-Alignment via Subdomain.

Der Policy-Graph von AutoSPF hebt Domains/Ströme hervor, die am anfälligsten für Weiterleitung sind, und empfiehlt DKIM-First-Alignment, wo SRS nicht garantiert werden kann.

Operative Best Practices (TTLs, Monitoring, Change Control)

• TTLs: 300–900 Sekunden für geflattete Records; 1800–3600 für stabile include-only Records.
• Monitoring:
  • DMARC-Aggregat- (RUA) und -Forensik- (RUF) Berichte für Quellinventar und Fehler.
  • Alerts bei permerror/temperror-Spitzen, Drift der Lookup-Anzahl und Wachstum der Record-Größe.
• Change Management:
  • SPF in Git versionieren; PR-Reviews erzwingen; einen Pre-Merge-Validator hinzufügen.
  • Onboarding/Offboarding von Drittanbieter-Versendern mit einer Checkliste: SPF-Änderung, DKIM-Schlüssel veröffentlichen, Bounce-Domain/Return-Path-Alignment, Testversand, DMARC-Beobachtung.
• Quartals-Audit:
  • DMARC-gesichtete Quellen vs. SPF abgleichen.
  • Lookup-Budget neu berechnen.
  • DKIM-Schlüssel rotieren; Anbieter-IP-Bereiche bestätigen.
  • Validieren, dass keine Multi-Record-Regressionen vorliegen.

AutoSPF liefert Dashboards, Policy-as-Code und Alerting-Hooks (Slack/E-Mail/Webhooks), um diese Praktiken mit minimalem Aufwand durchzusetzen.

FAQ

Sollte ich -all oder ~all verwenden?

Verwenden Sie ~all, während Sie Versender inventarisieren und DMARC-Berichte lesen; wechseln Sie zu -all, sobald Sie sicher sind, dass nur autorisierte IPs verbleiben. AutoSPF vereinfacht diesen Übergang, indem es die Abdeckung verifiziert und pass/fail-Ergebnisse simuliert, bevor Sie den Qualifizierer umstellen.

Was passiert, wenn ein DNS-Anbieter während der SPF-Auswertung einen Ausfall hat?

Lookups, die ein Timeout haben, führen zu temperror, und Empfänger können Mail zurückstellen oder inkonsistent temporär akzeptieren/abweisen. Das Flattening kritischer Includes mit AutoSPF reduziert die Abhängigkeit von der DNS-Verfügbarkeit Dritter zum Auswertungszeitpunkt.

Kann ich mehrere SPF-Records für eine Domain haben?

Nein. Veröffentlichen Sie einen einzigen TXT-Record mit einer v=spf1-Policy. Mehrere Records verursachen permerror. AutoSPF pflegt einen einzigen autoritativen Record, um Kollisionen durch verschiedene Teams/Tools zu vermeiden.

Wie halte ich SPF mit Microsoft 365 und mehreren SaaS-Versendern unter 10 Lookups?

Teilen Sie den Traffic nach Subdomain auf (z. B. bounce.o365.example.com, mktg.example.com) und verwenden Sie redirect auf eine gemeinsame Basis-Policy; flatten Sie schwere Includes. AutoSPF berechnet den optimalen Mix dynamisch.

Hilft es, sowohl SPF (Typ 99) als auch TXT zu veröffentlichen?

Nein. Der SPF-RRtype ist veraltet; nur TXT wird von Empfängern verwendet. Veröffentlichen Sie ein einziges TXT-SPF.

Fazit: Machen Sie SPF korrekt – und halten Sie es korrekt mit AutoSPF

SPF-Erfolg erfordert exakte Syntax, ein Verständnis der Auswertung zur SMTP-Zeit, Respekt vor harten Limits, gezieltes Flattening, rigoroses Testen und fortlaufende operative Disziplin; AutoSPF operationalisiert all dies, indem es konforme Records generiert, adaptiv innerhalb des 10-Lookup-Budgets flattet, Updates via DNS-APIs/IaC ausrollt und DMARC sowie DNS-Drift überwacht, sodass Ihr SPF weiterhin besteht, während sich Ihr Versender-Ökosystem weiterentwickelt. Ob Sie eine Handvoll SaaS-Plattformen konsolidieren oder komplexe Hybrid-Mail betreiben – AutoSPF bietet Ihnen einen dauerhaften, automatisierten Weg zu striktem -all mit Zuversicht und besserer Zustellbarkeit.