Kostenloser SPF Generator: SPF Record einfach erstellen oder ändern

Was ein SPF-Record technisch prüft

SPF beantwortet eine klar definierte Frage: Darf der Server, der diese E-Mail gerade zustellt, laut DNS-Regelwerk für die prüfende Domain senden? Geprüft wird dabei nicht einfach die sichtbare Absenderadresse im Posteingang, sondern in erster Linie die Domain aus dem technischen Envelope-From beziehungsweise dem Return-Path.

Wenn ein empfangender Mailserver eine Nachricht annimmt, kennt er die IP-Adresse des einliefernden Systems. Danach ruft er den SPF-Record der relevanten Domain ab und arbeitet ihn von links nach rechts durch. Sobald ein Mechanismus auf die sendende IP passt, ist das SPF-Ergebnis grundsätzlich entschieden. Wenn kein Mechanismus greift, bestimmt meist die abschließende all-Regel das Resultat.

Daraus folgt ein wichtiger Grundsatz: SPF bewertet nicht den Inhalt der Nachricht und auch nicht die Seriosität eines Unternehmens. SPF bewertet ausschließlich, ob die technische Versandquelle nach den veröffentlichten DNS-Regeln autorisiert ist.

Der typische Aufbau eines SPF-Records

Ein SPF-Record ist immer ein TXT-Record und beginnt stets mit der Versionsangabe:

v=spf1

Danach folgen die Mechanismen, die erlaubte Versandquellen definieren, und am Ende normalerweise eine Abschlussregel.

v=spf1 ip4:203.0.113.20 include:spf.protection.outlook.com -all

Dieser Record bedeutet: Die IP-Adresse 203.0.113.20 darf senden, zusätzlich dürfen die Versandsysteme senden, die vom referenzierten Microsoft-365-SPF abgedeckt werden, und alle anderen Quellen sind nicht autorisiert.

Der entscheidende Unterschied zwischen include, a, mx, ip4 und ip6

Viele Erklärungen nennen die SPF-Mechanismen nur in Listenform. Für die Praxis ist das zu wenig. Wirklich relevant ist, welche Art von Aussage jeder Mechanismus trifft. Nur dann lässt sich entscheiden, welcher Baustein fachlich passend ist.

ip4 und ip6: die präziseste Form der Freigabe

ip4 und ip6 sind die direktesten SPF-Mechanismen. Sie erlauben exakt die Adressen oder Netze, die ausdrücklich genannt werden. Die Domain sagt damit nicht „mein Hostname darf senden“ oder „mein Provider darf senden“, sondern ganz konkret: Diese IP darf senden.

v=spf1 ip4:203.0.113.20 -all

Dieser Record ist fachlich eindeutig. Es wird weder ein externer SPF ausgewertet noch ein Hostname zusätzlich aufgelöst. Genau deshalb sind ip4 und ip6 immer dann ideal, wenn eine Versandquelle stabil, bekannt und unter Kontrolle ist. Das gilt zum Beispiel für einen eigenen SMTP-Server, ein festes Relay oder ein klar definiertes Transaktionssystem mit statischer IP.

Der Vorteil liegt in der Präzision. Der Nachteil liegt in der Pflege: Ändert sich die IP-Adresse, muss auch der SPF-Record angepasst werden. Für große Cloud-Dienste mit vielen oder wechselnden Versandservern wäre das unpraktisch und fehleranfällig.

a: Freigabe über den Hostnamen statt über eine feste IP

Der Mechanismus a wirkt zunächst ähnlich wie ip4, ist logisch aber etwas anderes. Mit a werden nicht direkt IP-Adressen eingetragen, sondern die IPs autorisiert, auf die ein bestimmter Hostname per A- oder AAAA-Record zeigt.

v=spf1 a:mail.example.de -all

Die Aussage lautet hier: Die IP-Adresse(n) des Hosts mail.example.de dürfen senden. Das ist eine indirekte Freigabe über DNS-Auflösung. Ändert sich der A-Record dieses Hosts, ändert sich auch die SPF-Wirkung. Genau das kann gewollt sein, wenn ein Hostname stabil bleiben soll, während sich die dahinterliegende IP gelegentlich ändert.

a ist sinnvoll, wenn ein definierter Mailhost freigegeben werden soll. Es ist dagegen keine gute pauschale Abkürzung für „mein Server“. Wer a auf die Root-Domain setzt, erlaubt damit die IPs des A- oder AAAA-Records der Domain selbst. Wenn dort nur der Webserver liegt, wird unter Umständen ein System autorisiert, das aus fachlicher Sicht gar nicht als legitimer Mailsender gedacht war.

mx: Freigabe der Empfangsserver

Mit mx werden die IP-Adressen der Server freigegeben, die im MX-Record der Domain als zuständige Mailserver für den Empfang hinterlegt sind.

v=spf1 mx -all

Der kritische Punkt liegt in der Architektur: Ein MX-Record beschreibt zunächst nur, wer E-Mails für die Domain entgegennimmt. Er sagt nicht automatisch, wer E-Mails im Namen der Domain versendet. In älteren oder einfacheren Umgebungen kann das identisch sein. In modernen Setups ist das oft nicht der Fall. Der Empfang läuft etwa über Microsoft 365 oder ein vorgeschaltetes Gateway, während Formularmails vom Webserver, Transaktionsmails vom Shop oder Marketing-Mails von einem externen SaaS-Dienst versendet werden.

Genau deshalb ist mx nur dann fachlich sauber, wenn die im MX hinterlegten Systeme tatsächlich auch legitime Outbound-Sender sind. Wer mx aus Bequemlichkeit nutzt, riskiert eine Freigabe von Servern, die nur empfangen, aber nicht senden sollten.

include: Freigabe eines extern gepflegten SPF-Regelraums

include ist der wichtigste Mechanismus für externe Maildienste. Er bedeutet nicht, dass der Text eines fremden SPF-Records einfach in den eigenen eingefügt wird. Vielmehr sagt die Domain: Für diese Prüfung soll zusätzlich bewertet werden, ob die sendende IP nach dem SPF-Regelwerk der referenzierten Domain autorisiert ist.

v=spf1 include:spf.protection.outlook.com -all

Das ist fachlich eine Delegation. Die Domain übernimmt damit nicht einzelne IP-Adressen manuell, sondern vertraut auf die SPF-Pflege des jeweiligen Dienstanbieters. Genau deshalb ist include die richtige Wahl für Microsoft 365, Google Workspace, Helpdesk-Plattformen, Newsletter-Dienste, CRM-Systeme oder andere Anbieter mit verteilter und sich ändernder Versandinfrastruktur.

Der Vorteil liegt in der Wartbarkeit. Ändert ein Anbieter seine Versandserver, muss nicht jeder Kunde seinen SPF-Record händisch aktualisieren. Der Nachteil liegt in der Komplexität: Jeder include verursacht DNS-Lookups und belastet das SPF-Limit. Zu viele Includes oder verschachtelte Konstruktionen führen schnell zu unnötiger Komplexität.

Welche Aussage die Mechanismen jeweils treffen

Genau an dieser Stelle wird der fachliche Unterschied greifbar: ip4 und ip6 sind direkte Freigaben, a und mx sind DNS-abhängige Freigaben über Host- oder Empfangsrollen, und include ist eine Delegation an einen fremden, extern gepflegten SPF-Raum.

So wird ein SPF-Record fachlich sauber aufgebaut

Ein sauberer SPF-Record beginnt nicht im DNS, sondern mit einer vollständigen Bestandsaufnahme aller legitimen Versandquellen. Dazu gehören typischerweise Benutzer-Mailsysteme, Webserver, Shop-Systeme, Newsletter-Tools, CRM-Plattformen, Ticketsysteme, Scanner, Monitoring-Software oder ERP-Lösungen mit Mailfunktion. Erst wenn klar ist, welche Systeme tatsächlich Nachrichten im Namen der Domain versenden, kann die passende SPF-Logik aufgebaut werden.

Die wichtigste fachliche Frage lautet dann nicht „Welchen Text muss ich eintragen?“, sondern: Welche Art von Versandquelle liegt vor?

• Ein eigener Server mit stabiler IP wird in der Regel per ip4 oder ip6 freigegeben.
• Ein definierter Mailhost kann per a autorisiert werden, wenn die Kopplung an den Hostnamen bewusst gewünscht ist.
• mx ist nur dann fachlich passend, wenn Empfangs- und Versandserver identisch sind.
• Ein externer SaaS- oder Cloud-Dienst wird meist per include eingebunden.

Erst danach werden die Bausteine in einem einzigen SPF-Record zusammengeführt. Mehrere SPF-Records für dieselbe Domain sind nicht zulässig und führen zu fehlerhaften Ergebnissen.

Beispiel für einen fachlich sauberen SPF-Record

Angenommen, eine Domain nutzt Microsoft 365 für Benutzerkommunikation, einen Webserver mit fester IP für Formularmails und einen externen Newsletter-Dienst. Dann könnte ein sinnvoller SPF-Record so aussehen:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.20 include:_spf.newsletterdienst.de -all

Die dahinterstehende Logik ist sauber getrennt: Microsoft 365 wird per include abgedeckt, weil dessen Versandinfrastruktur extern gepflegt wird. Der eigene Webserver wird per ip4 freigegeben, weil seine Versandadresse konkret bekannt ist. Der Newsletter-Dienst wird ebenfalls per include eingebunden, weil er seinen eigenen SPF-Regelraum pflegt. Genau so entsteht ein professioneller SPF-Record: nicht durch möglichst viele Mechanismen, sondern durch die fachlich passende Zuordnung jeder einzelnen Quelle.

Die Rolle von all, -all und ~all

Der Mechanismus all steht typischerweise am Ende des SPF-Records und greift für alle Quellen, die von keiner vorherigen Regel erfasst wurden. Entscheidend ist der vorangestellte Qualifier.

Für produktive Umgebungen ist -all langfristig meist die richtige Zielkonfiguration. Wer jedoch noch nicht sicher ist, ob wirklich alle legitimen Sender erfasst wurden, kann vorübergehend mit ~all arbeiten und nach sauberer Validierung auf -all umstellen.

Das 10-Lookup-Limit: die meist unterschätzte SPF-Grenze

SPF ist nicht unbegrenzt komplex. Während der Auswertung dürfen nur maximal zehn DNS-Lookups ausgelöst werden. Dieses Limit ist in der Praxis entscheidend, weil vor allem include, a, mx und bestimmte weitere Mechanismen zusätzliche DNS-Abfragen verursachen. Wer zu viele Dienste in einem SPF-Record verschachtelt oder alte Versandplattformen nicht entfernt, erreicht diese Grenze schneller als erwartet.

Die Folge ist kein kosmetischer Schönheitsfehler, sondern ein echter SPF-Fehler. Genau deshalb sollte ein SPF-Record nicht nur inhaltlich richtig, sondern auch strukturell schlank sein. Jeder nicht mehr benötigte Include, jede unnötige DNS-abhängige Freigabe und jede historisch gewachsene Sonderregel erhöht die Wahrscheinlichkeit, dass das Regelwerk irgendwann technisch kippt.

Typische Fehler in der Praxis

• Mehrere SPF-Records für dieselbe Domain: Erlaubt ist genau ein konsolidierter SPF-TXT-Record.
• mx aus Bequemlichkeit: Empfangsserver werden freigegeben, obwohl sie gar keine legitimen Outbound-Sender sind.
• a ohne Architekturprüfung: Der Webserver der Domain wird autorisiert, obwohl er gar keine E-Mails versendet.
• Zu viele Includes: Das Lookup-Limit wird überschritten oder der Record wird unnötig kompliziert.
• Vergessene Versandquellen: Webformulare, CRM-Systeme, Shops oder Scan-to-Mail-Geräte fehlen im SPF und erzeugen Fehlschläge.
• Veraltete Dienstfreigaben: Alte Anbieter bleiben im Record, obwohl sie längst nicht mehr genutzt werden.

Best Practices für einen professionellen SPF-Record

• Jede Versandquelle fachlich klassifizieren: Eigener Server, definierter Host, MX-basierte Umgebung oder externer Dienst.
• Direkte IP-Freigaben dort einsetzen, wo Stabilität und Kontrolle vorhanden sind.
• Includes nur dort verwenden, wo externe Anbieter ihren SPF selbst pflegen.
• mx nur nutzen, wenn die MX-Server tatsächlich auch senden.
• Den Record regelmäßig überprüfen, sobald neue Tools oder Plattformen Mailversand übernehmen.
• SPF immer zusammen mit DKIM und DMARC denken.

FAQ zum SPF-Record