SPF einrichten — Allgemeine Anleitung
Providerunabhängige Schritt-für-Schritt-Anleitung: Sendende Server ermitteln, SPF-Record zusammenbauen, DNS-Eintrag anlegen und mit dig verifizieren.
SPF rein DNS-basiert einrichten
SPF (Sender Policy Framework) ist ein DNS-TXT-Record, der festlegt, welche Server E-Mails im Namen Ihrer Domain versenden dürfen — unabhängig davon, welchen Mail-Provider Sie nutzen. Diese Anleitung zeigt den providerunabhängigen Weg: Sie bauen den Record aus den richtigen Mechanismen zusammen und legen ihn direkt bei Ihrem DNS-Hoster an. Kein Admin-Panel eines Mail-Providers erforderlich.
Unabhängig vom Provider ist SPF eine nach NIS2 Art. 21 und BSI TR-03182 geforderte Schutzmaßnahme für E-Mail-Authentifizierung. Der Wolf-Agents Email Security Check prüft Ihren SPF-Record auf 22 Kriterien — einschließlich Lookup-Zählung, Qualifier-Bewertung und Syntaxvalidierung — für jede Domain, ohne Registrierung.
Hardening-Pfad: Nach SPF folgt als nächster Schritt DKIM provider-unabhängig — gemeinsam bilden SPF + DKIM die Grundlage für DMARC.
Sendende Server ermitteln
Bevor Sie den SPF-Record schreiben, müssen Sie wissen, welche Server E-Mails im Namen Ihrer Domain versenden. Jeder fehlende Server führt dazu, dass seine E-Mails SPF-Prüfungen nicht bestehen.
Eigene Mailserver (Postfix, Exim, Exchange) mit fester IP-Adresse, Hosting-Provider (IONOS, Strato, All-Inkl.) mit eigenem SPF-Include, externe Dienste (Newsletter, CRM, Ticketing) mit eigenem Include-Wert sowie MX-Server der Domain, wenn diese auch zum Senden genutzt werden.
RFC 7208 erlaubt maximal 10 DNS-Lookups pro SPF-Auswertung. Jedes include:, a, mx und redirect verbraucht einen Lookup — verschachtelte Includes addieren sich. ip4: und ip6: kosten keinen Lookup. Planen Sie das Budget, bevor Sie Dienste hinzufügen.
SPF-Record zusammenbauen
Ein SPF-Record beginnt immer mit v=spf1, gefolgt von Mechanismen für jeden autorisierten Sender, und endet mit dem Qualifier -all (Hard Fail) oder ~all (Soft Fail).
Aufbau des Records
v=spf1 [MECHANISMEN] -allNur Hosting-Provider
Ihr Hosting-Provider stellt einen SPF-Include bereit — fragen Sie ihn nach dem genauen Wert.
v=spf1 include:spf.ihres-providers.de -allEigener Mailserver mit fester IP
Sie betreiben einen eigenen Server (Postfix, Exim) mit einer bekannten öffentlichen IP.
v=spf1 ip4:203.0.113.10 -allMX-Server senden auch aus
Die MX-Records der Domain zeigen auf Server, die auch ausgehende E-Mails versenden.
v=spf1 mx -allKombiniert (typisch für eigene Infrastruktur)
MX-Server, eigene IP und Provider-Include in einem einzigen Record zusammengefasst.
v=spf1 mx ip4:203.0.113.10 include:spf.ihres-providers.de -all-all) statt Soft Fail (~all) Verwenden Sie im Produktivbetrieb immer -all. Soft Fail (~all) markiert E-Mails von nicht autorisierten Servern nur als verdächtig, lehnt sie aber nicht ab. Hard Fail ist die einzig wirksame Einstellung, wenn Ihr DMARC-Record auf p=reject zielt.
DNS-Record anlegen
Melden Sie sich bei Ihrem DNS-Provider an und legen Sie einen neuen TXT-Record für Ihre Domain an. Der Record-Name ist Ihr Domainname (oder @ als Kürzel), der Typ ist TXT.
# Format bei den meisten DNS-Hostern:
# Name: ihre-domain.de (oder @ für die Apex-Domain)
# Typ: TXT
# TTL: 3600 (1 Stunde — für die Ersteinrichtung empfohlen)
# Wert: v=spf1 mx ip4:203.0.113.10 include:spf.ihres-providers.de -all
ihre-domain.de. 3600 IN TXT "v=spf1 mx ip4:203.0.113.10 include:spf.ihres-providers.de -all"RFC 7208 erlaubt genau einen v=spf1-Record pro Domain. Existiert bereits ein SPF-Record, müssen Sie diesen bearbeiten — nicht einen zweiten anlegen. Zwei v=spf1-Records erzeugen einen PermError und brechen die Authentifizierung für alle E-Mails.
Nach dem Anlegen des Records dauert die weltweite Propagierung je nach DNS-Provider und TTL zwischen 5 Minuten und 24 Stunden. Warten Sie vor der Verifikation mindestens 15 Minuten.
SPF-Record verifizieren
Prüfen Sie nach der DNS-Propagierung den Record mit Kommandozeilen-Tools und dem Wolf-Agents Email Security Check auf korrekte Syntax, Lookup-Zählung und Qualifier.
Verifikation per Kommandozeile
# Linux / macOS — SPF-Record abfragen
dig TXT ihre-domain.de +short
# Erwartete Ausgabe: "v=spf1 mx ip4:203.0.113.10 include:spf.ihres-providers.de -all"
# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
# Mehrere SPF-Records prüfen (darf nur einer erscheinen)
dig TXT ihre-domain.de +short | grep "v=spf1"Der Wolf-Agents Email Security Check prüft Ihren SPF-Record auf 22 Einzelkriterien — inklusive verschachtelter Lookup-Zählung, Qualifier-Bewertung und syntaktischer Korrektheit. Kostenlos, ohne Registrierung.
Häufige SPF-Fehler (providerunabhängig)
Diese drei Fehler treten unabhängig vom genutzten Mail-Provider auf — und sind die häufigsten Ursachen für SPF-Fehler in der Praxis.
Mehrere SPF-Records statt einem kombinierten
Problem: Zwei separate v=spf1-Records für dieselbe Domain — etwa wenn ein zweiter Provider-Include versehentlich als neuer Record angelegt wurde. RFC 7208 erlaubt genau einen SPF-Record. Zwei Records erzeugen einen PermError, alle E-Mails von dieser Domain scheitern an der SPF-Prüfung.
Lösung: Alle Includes, IP-Adressen und Mechanismen in einem einzigen Record zusammenführen: v=spf1 include:provider-a.de include:provider-b.de ip4:203.0.113.10 -all. Den zweiten Record löschen.
SPF nach Provider-Wechsel nicht aktualisiert
Problem: Nach einer Migration (z. B. von IONOS zu Hetzner) enthält der SPF-Record noch den alten include: des ehemaligen Providers. Der neue Provider ist nicht autorisiert, E-Mails der Domain werden von strikten Empfangsservern abgewiesen. Besonders tückisch: Der Fehler fällt oft erst Wochen später auf, wenn erste Bounces eintreffen.
Lösung: Nach jeder Provider-Migration den SPF-Record aktualisieren: alten Include entfernen, neuen Include des Providers eintragen. Mit dem Wolf-Agents Email Security Check lässt sich prüfen, ob alle autorisierten Server korrekt abgedeckt sind.
Fehlender SPF-Record auf Subdomains
Problem: Der SPF-Record der Hauptdomain gilt nicht automatisch für Subdomains. mail.ihre-domain.de oder newsletter.ihre-domain.de haben kein SPF, wenn dort kein eigenständiger TXT-Record angelegt wurde. Ohne SPF ergibt die Prüfung ein Neutral-Ergebnis — mit DMARC p=reject werden diese E-Mails abgelehnt.
Lösung: Für jede Subdomain, über die E-Mails versendet werden, einen eigenen SPF-Record anlegen. Subdomains, über die keine E-Mails versendet werden sollen, explizit sperren: subdomain.ihre-domain.de IN TXT "v=spf1 -all".
SPF-Anleitung auch für:
Wie steht Ihre Domain bei SPF?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.