Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung publiziert deine bei Hetzner gehostete DNS-Zone einen korrekten SPF-Record für deinen Mailserver. Empfangende Server erkennen damit, wer in deinem Namen senden darf.

Voraussetzungen

  • Eine DNS-Zone bei Hetzner (Hetzner Console; Bestandszonen ggf. noch in der älteren DNS Console)
  • Du weißt, welche Server E-Mails für deine Domain versenden (eigener Mailserver, Hoster-Postfach, Newsletter-Dienst)

Was ist SPF?

SPF (Sender Policy Framework) ist ein TXT-Record im DNS deiner Domain. Hetzners eigene Doku bringt es auf den Punkt: In der Zonendatei wird ein TXT-Record eingetragen, der die berechtigten SMTP-Server der Domain nennt. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob der einliefernde Server auf dieser Liste steht. Ohne SPF kann jeder beliebige Server Mails in deinem Namen verschicken — und deine legitimen Mails landen schneller im Spam.

Zur Einordnung: SPF allein ist noch kein vollständiger Schutz. Erst zusammen mit DKIM und DMARC wird daraus ein belastbares Fundament. SPF ist aber der einfachste Einstieg.

Die Ausgangslage bei Hetzner

Hetzner DNS ist ein reiner DNS-Dienst: Anders als bei Shared-Hostern gibt es keinen vorgefertigten SPF-Schalter, weil Hetzner nicht weiß, wo dein Mail läuft. Du schreibst den Record selbst — was hier gut passt, denn typischerweise betreibst du als Hetzner-DNS-Nutzer ohnehin eigene Infrastruktur.

Ausnahme: Nutzt du konsoleH (Hetzner Webhosting) mit konsoleH-Nameservern, setzt das System automatisch einen Standard-SPF-Record — dort musst du nur aktiv werden, wenn externe Dienste mitsenden sollen.

Schritt-für-Schritt-Anleitung

1. Prüfen, ob SPF schon aktiv ist

Am schnellsten im Terminal:

dig TXT beispiel.de +short | grep spf1

Alternativ wirf deine Domain in den kostenlosen MXAudit-Scanner — der prüft den Record gleich auf Syntax und Lookup-Limit mit.

2. Den Record für dein Setup bauen

Der Klassiker, wenn dieselben Server senden, die auch empfangen (dein MX zeigt auf deinen Mailserver):

v=spf1 mx -all

Der mx-Mechanismus autorisiert die IP-Adressen aller MX-Hostnamen deiner Domain — ändert sich die Server-IP, bleibt der SPF-Record automatisch korrekt, solange der MX-Record stimmt.

Senden zusätzliche Maschinen, die nicht im MX stehen (z. B. ein separater Versand-Host), ergänzt du sie explizit — Hetzners Beispiel aus der Doku:

v=spf1 mx ip4:213.133.98.98 a:test.example.com -all
MechanismusWirkung
mxerlaubt die Server hinter den MX-Records deiner Domain
ip4: / ip6:erlaubt eine feste IP-Adresse oder ein Subnetz
a:hosterlaubt die IP hinter dem A-/AAAA-Record des angegebenen Hostnamens
-allHardfail: nur die explizit gelisteten Server dürfen senden

Bei eigener Infrastruktur ist -all die richtige Wahl — du kennst deine Versandwege. Wenn du dir beim Umbau unsicher bist, starte mit ~all und ziehe nach ein paar Tagen auf -all an.

3. Record in der Hetzner Console eintragen

Öffne deine DNS-Zone und lege einen neuen Record an:

FeldWert
TypeTXT
Name@ (für die Hauptdomain)
Value"v=spf1 mx -all"

Zwei Hetzner-Eigenheiten aus der Doku: Für die Hauptdomain gehört @ ins Name-Feld, und der TXT-Wert muss in Anführungszeichen stehen.

4. Externe Versanddienste ergänzen (falls nötig)

Newsletter-Tool, CRM oder Ticketsystem brauchen ihren include:-Wert im selben Record (aus der Doku des jeweiligen Dienstes, suche nach “SPF”). Es gilt: pro Domain nur ein SPF-Record — bestehenden bearbeiten, nie einen zweiten anlegen. Das gilt genauso in konsoleH: externe Dienste müssen dem automatisch gesetzten Record hinzugefügt werden.

5. Warten, bis die Änderung aktiv ist

DNS-Änderungen brauchen Zeit: Je nach TTL und Caching kann es einige Stunden dauern, bis alle Server weltweit den neuen Record sehen.

Weiterleitungen: warum SPF dort bricht — und was SRS damit zu tun hat

Hetzners Doku erklärt einen Punkt ausführlicher als die meisten Hoster: Automatische Weiterleitungen funktionieren mit SPF nur, wenn der weiterleitende Server die Absenderadresse im Envelope umschreibt — sonst prüft der Endempfänger deinen SPF-Record gegen die IP des Weiterleitungsservers und lehnt ab. Das standardisierte Umschreibeverfahren heißt SRS (Sender Rewriting Scheme). Betreibst du selbst einen weiterleitenden Mailserver, aktiviere SRS; als Absender kannst du gegen fremde, schlecht konfigurierte Weiterleitungen nichts tun — dafür sind DKIM und DMARC da.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen MXAudit-Scanner — er zeigt dir sofort, ob dein SPF-Record syntaktisch korrekt ist und wie viele DNS-Lookups er verbraucht (das Limit liegt bei 10).

Oder direkt im Terminal:

dig TXT beispiel.de +short | grep spf1

Die Ausgabe muss genau einen Record mit v=spf1 enthalten.

Häufige Fehler

Anführungszeichen vergessen. In der Hetzner Console muss der TXT-Wert in Anführungszeichen stehen — ohne sie wird der Record nicht korrekt angelegt.

Zwei SPF-Records. Zwei TXT-Einträge mit v=spf1 führen zu permerror — empfangende Server werten SPF dann gar nicht mehr aus. Alle Quellen gehören in einen einzigen Record.

mx ohne passende MX-Records. v=spf1 mx -all autorisiert exakt die Server aus deinen MX-Records. Sendet eine Maschine, die dort nicht auftaucht (etwa ein Cron-Job auf dem Webserver), wird sie abgelehnt — ergänze sie per ip4: oder a:.

+all am Ende. Ein +all erlaubt jedem Server das Senden und macht den gesamten Record wirkungslos — nicht übernehmen.

DNS-Lookup-Limit überschritten. SPF erlaubt maximal 10 DNS-Lookups pro Prüfung; mx, a: und jedes include: zählen. Bei vielen externen Diensten wird es eng — MXAudit zählt für dich mit.