SPF für All-Inkl einrichten
Schritt-für-Schritt-Anleitung: SPF-Record im KAS anlegen, den schwachen ?all-Qualifier auf -all upgraden und typische All-Inkl-Fallstricke vermeiden.
SPF für All-Inkl (KAS)
All-Inkl empfiehlt standardmäßig den SPF-Record v=spf1 mx a ?all — der mx- und a-Mechanismus verbrauchen zusammen 2 DNS-Lookups und autorisieren den Mailserver der Domain. Der schwache Qualifier ?all (Neutral) sollte nach der Verifikation auf -all (Hard Fail) geändert werden. Die DNS-Verwaltung erfolgt ausschließlich über das KAS (Kunden-Administrations-System) unter kasapi.kasserver.com.
NIS2 Art. 21 und BSI TR-03182 fordern SPF als technische Schutzmaßnahme — mit 22 von 165 Punkten ist SPF ein gewichtiger Faktor im Wolf-Agents Email Security Check. Der ?all-Qualifier kostet Punkte — Wolf-Agents bewertet nur Qualifier mit tatsächlicher Ablehnungswirkung als vollständig konform.
Hardening-Pfad: Nach SPF folgt als nächster Schritt DKIM für All-Inkl — gemeinsam bilden SPF + DKIM die Grundlage für DMARC.
SPF-Record im KAS anlegen
Melden Sie sich im KAS an und legen Sie unter DNS-Einstellungen einen TXT-Record für Ihre Domain an. Der mx-Mechanismus autorisiert den im MX-Record eingetragenen Mailserver, der a-Mechanismus die A-Record-IP der Domain.
ihre-domain.de. IN TXT "v=spf1 mx a -all"Menüpfad im KAS
- Melden Sie sich im KAS an (kas.all-inkl.com)
- Wählen Sie das gewünschte Hosting-Paket aus
- Navigieren Sie zu DNS-Einstellungen
- Klicken Sie auf Neuen Eintrag hinzufügen
- Typ: TXT, Subdomain: leer lassen (für die Haupt-Domain), Wert:
v=spf1 mx a -all - Klicken Sie auf Speichern
Fügen Sie alle Quellen in einen einzigen SPF-Record zusammen. Pro Domain ist nur ein SPF-Record zulässig. Beispiel mit einem externen Versanddienst:
v=spf1 mx a include:mailing-service.example -allAll-Inkl propagiert DNS-Änderungen typischerweise innerhalb von 15–30 Minuten. Prüfen Sie die Verbreitung nach spätestens einer Stunde mit dig TXT ihre-domain.de.
Qualifier von ?all auf -all upgraden
All-Inkl empfiehlt in seiner Dokumentation ?all (Neutral) — dieser Qualifier hat keine Schutzwirkung: Empfangsserver dürfen E-Mails von nicht autorisierten Quellen trotzdem zustellen. Der sichere Standard für produktive Domains ist -all (Hard Fail).
Unterschied der Qualifier im Überblick
- ?all (Neutral): Keine Aussage — Empfangsserver ignorieren nicht autorisierte Quellen in der Praxis meist. Kein Spam-Schutz.
- ~all (SoftFail): E-Mails von nicht autorisierten Quellen werden zugestellt, aber als verdächtig markiert. Geeignet als Übergangslösung.
- -all (Hard Fail): E-Mails von nicht autorisierten Quellen werden abgelehnt. Empfohlen für alle produktiven Domains.
- Upgraden Sie erst auf -all, wenn Sie sicher sind, dass alle sendenden Server im SPF-Record eingetragen sind.
- Prüfen Sie mit
dig TXT ihre-domain.de +short, ob der aktualisierte Record korrekt propagiert wurde.
# All-Inkl-Standard (schwach — kein Schutz)
v=spf1 mx a ?all
# Empfehlung Wolf-Agents (Hard Fail — voller Schutz)
v=spf1 mx a -allSPF-Record verifizieren
Nach dem Speichern im KAS prüfen Sie die korrekte Propagierung des SPF-Records. All-Inkl propagiert DNS-Änderungen in der Regel innerhalb von 15–30 Minuten.
# Linux / macOS
dig TXT ihre-domain.de +short
# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
# Erwartete Ausgabe:
# "v=spf1 mx a -all"Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser prüft SPF auf 22 Einzelkriterien inklusive Qualifier-Bewertung, Lookup-Zählung und RFC-7208-Konformität.
Häufige Fehler bei All-Inkl
Die folgenden drei Fehler treten bei All-Inkl-Konfigurationen am häufigsten auf. Jeder einzelne kann dazu führen, dass SPF fehlschlägt oder keinen wirksamen Schutz bietet.
KAS erlaubt nur einen TXT-Record pro Domain — Konflikt beim Zusammenführen
Problem: Das KAS lässt pro Subdomain bzw. Domain nur einen TXT-Record desselben Typs zu. Wer bereits einen SPF-Record hat und einen weiteren anlegt (z. B. nach dem Hinzufügen eines Newsletters), erhält entweder einen Fehler oder überschreibt den bestehenden Record — beides führt zu einem PermError.
Lösung: Alle sendenden Dienste in einem einzigen SPF-Record zusammenführen. Den bestehenden Record im KAS bearbeiten (nicht neu anlegen) und alle Mechanismen und Includes kombinieren: v=spf1 mx a include:mailing-service.example -all
?all (Neutral) statt -all (Hard Fail) — All-Inkl-Standard ohne Schutzwirkung
Problem: All-Inkl empfiehlt in seiner Dokumentation ?all als Standard. Dieser Qualifier teilt Empfangsservern mit, dass nicht autorisierte Absender weder angenommen noch abgelehnt werden — de facto kein Schutz vor Spoofing. Der Wolf-Agents Email Security Check wertet ?all als unvollständige SPF-Konfiguration.
Lösung: Den Qualifier auf -all upgraden, sobald alle sendenden Server im Record eingetragen sind. Als Übergangslösung bietet sich ~all an, das E-Mails von nicht autorisierten Quellen markiert, aber noch zustellt.
KAS-API ist SOAP, nicht REST — automatisierte SPF-Dienste funktionieren nicht
Problem: Das KAS bietet eine SOAP-basierte API (kasapi.kasserver.com). Automatisierte SPF-Management-Dienste und DNS-Automatisierungstools setzen fast ausschließlich REST-APIs voraus und unterstützen All-Inkl nicht. DNS-Änderungen via API sind dadurch nur mit eigenen SOAP-Clients möglich.
Lösung: Delegieren Sie Ihre DNS-Zone zu einem modernen DNS-Provider mit REST-API, zum Beispiel Cloudflare (kostenlos). Im KAS die Nameserver auf die Cloudflare-Nameserver umstellen — danach können alle SPF-Records über die Cloudflare-API oder das Dashboard verwaltet werden, ohne All-Inkl zu verlassen.
SPF-Anleitung auch für:
Wie steht Ihre Domain bei SPF?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.