Stand: Juli 2026

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

Voraussetzungen

  • Eine öffentliche Hosted Zone in Amazon Route 53
  • Du weißt, welche Server E-Mails für deine Domain versenden (eigener Mailserver, Amazon SES, Newsletter-Dienst)

Was ist SPF?

SPF (Sender Policy Framework) ist ein TXT-Record im DNS deiner Domain. Er nennt die SMTP-Server, die für deine Domain senden dürfen. 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 Route 53

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

Ein AWS-spezifischer Hinweis vorweg: Route 53 hatte einmal einen eigenen SPF-Record-Typ, den AWS aber ausgemustert hat. Die Doku ist eindeutig: „Instead of an SPF record, we recommend that you create a TXT record that contains the applicable value.” Du veröffentlichst SPF also immer als TXT-Record — nie als den alten SPF-Typ.

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.

AWS’ eigenes, dokumentiertes Konsolen-Beispiel für einen festen IP-Bereich sieht so aus:

v=spf1 ip4:192.168.0.1/16 -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 Hostnamens
include:bindet das SPF eines Versanddienstes ein (z. B. Amazon SES)
-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 Route-53-Konsole eintragen

Melde dich in der AWS Management Console an und öffne die Route-53-Konsole. Wähle im Navigationsbereich Hosted zones, öffne deine Zone und klicke auf Create record:

FeldWert
Record name(für die Root-Domain leer lassen)
Record typeTXT
Value"v=spf1 mx -all"

Die Route-53-Eigenheit aus der Doku: „A TXT record contains one or more strings that are enclosed in double quotation marks” — der Wert gehört also in doppelte Anführungszeichen ins Value-Feld. Danach auf Create records klicken.

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

Newsletter-Tool, CRM oder Amazon SES 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.

5. Warten, bis die Änderung aktiv ist

Route 53 ist hier schnell: Laut AWS-Doku gilt „Changes generally propagate to all Route 53 name servers within 60 seconds.” Nachgelagerte Resolver können die alte Antwort trotzdem bis zum Ablauf der TTL zwischenspeichern.

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

Den alten SPF-Record-Typ nutzen. Route 53 zeigt zwar noch einen SPF-Typ, AWS rät aber davon ab — veröffentliche SPF stattdessen als TXT-Record.

Anführungszeichen vergessen. Im Value-Feld von Route 53 gehört der String in doppelte Anführungszeichen.

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, 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.