E-Mail-Spoofing ist einer der häufigsten Angriffsvektoren im Internet. Jemand verschickt eine E-Mail, die scheinbar von deiner Domain stammt, in Wirklichkeit aber von einem völlig anderen Server. Der Empfänger sieht deinen Firmennamen im "Von"-Feld und vertraut darauf. SPF (Sender Policy Framework) ist die erste Verteidigungslinie dagegen, und es korrekt einzurichten, ist eines der wichtigsten Dinge, die du für die E-Mail-Sicherheit deiner Domain tun kannst.

Diese Anleitung führt dich durch alles, was du über SPF-Records wissen musst: was sie sind, wie sie funktionieren und wie du einen für deine Domain einrichtest.

Was ist SPF und warum ist es wichtig?#

SPF, oder Sender Policy Framework, ist ein E-Mail-Authentifizierungsprotokoll, das in RFC 7208 definiert ist. Es erlaubt Domain-Inhabern festzulegen, welche Mailserver berechtigt sind, E-Mails im Namen ihrer Domain zu versenden. Wenn ein empfangender Mailserver eine E-Mail erhält, die vorgibt, von deiner Domain zu stammen, prüft er deinen SPF-Record, um zu verifizieren, dass der sendende Server tatsächlich autorisiert ist.

Warum SPF wichtig ist#

Ohne SPF-Record kann jeder E-Mails verschicken, die scheinbar von deiner Domain kommen. Das schafft mehrere ernste Probleme:

E-Mail-Spoofing und Phishing: Angreifer können sich als deine Marke ausgeben, um deine Kunden, Partner oder Mitarbeiter dazu zu bringen, sensible Informationen preiszugeben oder auf bösartige Links zu klicken.
Deliverability-Probleme: Große E-Mail-Anbieter wie Gmail, Outlook und Yahoo nutzen SPF als Signal, wenn sie entscheiden, ob eine E-Mail in den Posteingang oder in den Spam-Ordner geht. Domains ohne SPF-Record landen mit ihren legitimen E-Mails häufiger im Spam.
Schaden an der Markenreputation: Wenn Spammer deine Domain für Massenmüllmail nutzen, sinkt der Reputationswert deiner Domain in den Netzwerken der E-Mail-Anbieter. Das beeinträchtigt die Deliverability für alle E-Mails, die du verschickst – auch für legitime Geschäftskommunikation.
Compliance-Anforderungen: Viele Branchenstandards und Regularien erwarten, dass Organisationen E-Mail-Authentifizierung einsetzen. SPF ist die Basis.

Wie SPF funktioniert#

Die Mechanik von SPF zu verstehen, hilft dir, es korrekt einzurichten und Probleme zu beheben, wenn sie auftauchen.

Der SPF-Prüfprozess#

Deine Organisation versendet eine E-Mail von du@deinedomain.com über deinen autorisierten Mailserver.
Der empfangende Mailserver extrahiert die Domain aus dem Envelope-Sender (dem Return-Path-Header, nicht dem From-Header).
Der empfangende Server führt einen DNS TXT Lookup auf deinedomain.com aus, um den SPF-Record abzurufen.
Der Server vergleicht die IP-Adresse des sendenden Servers mit der Liste der autorisierten IPs und Hostnamen im SPF-Record.
Basierend auf dem Vergleich liefert der Server eines dieser Ergebnisse zurück:
- Pass: Der sendende Server ist autorisiert. Die E-Mail wird normal weitergeleitet.
- Fail: Der sendende Server ist nicht autorisiert, und der Domain-Inhaber hat ausdrücklich gesagt, dass nicht autorisierte Absender abgelehnt werden sollen.
- SoftFail: Der sendende Server ist nicht autorisiert, aber der Domain-Inhaber ist sich nicht sicher genug, um eine direkte Ablehnung zu verlangen. Die E-Mail wird typischerweise akzeptiert, aber markiert.
- Neutral: Der Domain-Inhaber trifft keine Aussage über den sendenden Server.

Das SPF-Record-Format#

Ein SPF-Record ist ein DNS TXT record, der auf deiner Domain veröffentlicht wird. Er folgt einer bestimmten Syntax:

v=spf1 [mechanisms] [qualifier]

v=spf1 ist erforderlich und identifiziert den Record als SPF Version 1.
Mechanismen definieren, welche Server autorisiert sind.
Der Qualifier am Ende definiert die Standard-Richtlinie für Server, die zu keinem Mechanismus passen.

Hier ist ein Beispiel aus der Praxis:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Dieser Record sagt: Erlaube Googles Mailservern, SendGrids Mailservern und der spezifischen IP-Adresse 203.0.113.50, E-Mails für diese Domain zu senden. Lehne alle anderen ab.

Schritt-für-Schritt-SPF-Einrichtung#

Folge diesen Schritten, um einen SPF-Record für deine Domain zu erstellen und zu veröffentlichen.

Schritt 1: Identifiziere alle deine E-Mail-Versanddienste#

Bevor du deinen SPF-Record schreibst, brauchst du eine vollständige Liste jedes Dienstes und Servers, der E-Mails im Namen deiner Domain versendet. Das ist der am häufigsten übersehene Schritt, und eine fehlende Versandquelle führt dazu, dass diese E-Mails die SPF-Prüfung nicht bestehen.

Häufige E-Mail-Versandquellen sind:

Dein E-Mail-Anbieter: Google Workspace, Microsoft 365, Zoho Mail, ProtonMail usw.
Transaktions-E-Mail-Dienste: SendGrid, Mailgun, Amazon SES, Postmark, Resend usw.
Marketing-E-Mail-Plattformen: Mailchimp, HubSpot, ActiveCampaign, ConvertKit usw.
Dein Webserver: Wenn deine Website direkt E-Mails versendet (Kontaktformular-Einsendungen, Passwort-Resets, Bestellbestätigungen).
CRM- und Support-Tools: Zendesk, Freshdesk, Intercom, Salesforce usw.
Andere SaaS-Tools: Jede Anwendung, die E-Mails über deine Domain verschickt.

Schreibe jeden Dienst auf. Frage in verschiedenen Abteilungen deiner Organisation nach. Marketing nutzt vielleicht eine Plattform, von der Engineering nichts weiß, und umgekehrt.

Schritt 2: Sammle die SPF-Include-Werte#

Jeder E-Mail-Dienstleister veröffentlicht seine eigene SPF-Include-Domain. Hier sind die Include-Werte für gängige Anbieter:

Anbieter	SPF Include
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
SendGrid	`include:sendgrid.net`
Mailgun	`include:mailgun.org`
Amazon SES	`include:amazonses.com`
Mailchimp	`include:servers.mcsv.net`
Postmark	`include:spf.mtasv.net`
Zoho Mail	`include:zoho.com`
HubSpot	`include:hubspot-email.com`
Freshdesk	`include:email.freshdesk.com`

Prüfe die Dokumentation deines Anbieters, um den genauen Include-Wert zu finden. Anbieter aktualisieren diese gelegentlich, also verifiziere immer mit den aktuellen Docs.

Schritt 3: Baue deinen SPF-Record#

Kombiniere das Versions-Tag, alle deine Include-Mechanismen und einen Qualifier zu einem einzigen Record.

Vorlage:

v=spf1 [include:provider1] [include:provider2] [ip4:your.server.ip] [qualifier]

Beispiel für ein Unternehmen, das Google Workspace und SendGrid nutzt:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Beispiel für ein Unternehmen, das Microsoft 365, Mailchimp und einen eigenen Mailserver nutzt:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 -all

Schritt 4: Wähle deinen Qualifier#

Der Qualifier am Ende deines SPF-Records definiert, was passiert, wenn eine E-Mail von einem Server kommt, der nicht in deinem Record gelistet ist:

-all (Fail): Nicht autorisierte Server sollen abgelehnt werden. Das ist die empfohlene Einstellung für maximalen Schutz. Sie sagt empfangenden Servern, dass du dir bei deiner Liste sicher bist und jede E-Mail von einem nicht gelisteten Server betrügerisch ist.
~all (SoftFail): Nicht autorisierte Server sollen mit Misstrauen behandelt, aber nicht direkt abgelehnt werden. Nutze das während der ersten Einrichtung oder beim Testen, wenn du noch nicht sicher bist, ob du alle legitimen Versandquellen aufgeführt hast.
?all (Neutral): Es wird keine Aussage getroffen. Das bietet kaum Schutz und wird nicht empfohlen.
+all (Pass): Jeder ist autorisiert. Das hebelt den Sinn von SPF komplett aus. Verwende das niemals.

Empfehlung: Beginne mit ~all während deines initialen Rollouts und der Testphase. Sobald du bestätigt hast, dass alle legitimen E-Mails die SPF-Prüfungen bestehen, wechsle für vollen Schutz zu -all.

Schritt 5: Veröffentliche den Record im DNS#

Logge dich bei deinem DNS-Anbieter ein (Cloudflare, Route53, GoDaddy, Namecheap usw.) und füge den TXT record hinzu oder aktualisiere ihn:

Navigiere zur DNS-Verwaltungsseite deiner Domain.
Füge einen neuen TXT record hinzu (oder bearbeite den bestehenden SPF-Record, falls einer existiert).
Setze Host/Name auf @ (das repräsentiert deine Root-Domain).
Setze Wert/Inhalt auf deinen vollständigen SPF-Record-String.
Setze TTL auf 3600 (1 Stunde) oder den Standardwert deines Anbieters.
Speichere den Record.

DNS-Änderungen können bis zu 48 Stunden brauchen, um sich global zu verteilen, die meisten Änderungen sind aber innerhalb von 15 Minuten bis einer Stunde sichtbar.

Schritt 6: Verifiziere deinen SPF-Record#

Verifiziere nach der Veröffentlichung, dass der Record korrekt konfiguriert ist. Du kannst den Nova Uptime Email Health Checker nutzen, um eine umfassende Prüfung der E-Mail-Konfiguration deiner Domain durchzuführen, einschließlich SPF-Validierung. Das Tool prüft die Syntax deines SPF-Records, bewertet deine Qualifier-Policy, zählt DNS-Lookups und identifiziert potenzielle Probleme.

Du kannst auch über die Kommandozeile verifizieren:

dig TXT yourdomain.com +short

oder

nslookup -type=TXT yourdomain.com

Suche nach dem TXT record, der mit v=spf1 beginnt. Bestätige, dass alle erwarteten Include-Mechanismen vorhanden sind und der Qualifier korrekt ist.

SPF-Mechanismen verstehen#

SPF-Records unterstützen mehrere Mechanismus-Typen, die dir Flexibilität bei der Definition autorisierter Absender geben.

`include`

Verweist auf den SPF-Record einer anderen Domain. Das ist der häufigste Mechanismus, weil so E-Mail-Dienstleister ihre autorisierten IP-Bereiche veröffentlichen.

include:_spf.google.com

Wenn der empfangende Server darauf trifft, führt er einen zusätzlichen DNS-Lookup aus, um Googles SPF-Record abzurufen, und prüft die sendende IP gegen Googles autorisierte Bereiche.

`ip4` und `ip6`

Spezifiziert einzelne IP-Adressen oder CIDR-Bereiche, die zum E-Mail-Versand autorisiert sind.

ip4:203.0.113.50
ip4:198.51.100.0/24
ip6:2001:db8::/32

Nutze das für deine eigenen Mailserver oder Dienste, bei denen du die spezifischen IP-Adressen kennst.

`a`

Autorisiert die IP-Adresse, auf die der A-Record deiner Domain zeigt. Wenn dein Webserver auch E-Mails verschickt, ist das eine kompakte Möglichkeit, ihn zu autorisieren.

`mx`

Autorisiert die IP-Adressen der MX-Server (Mail Exchange) deiner Domain. Da deine MX-Server E-Mails empfangen, müssen sie oft auch E-Mails senden (Antworten, Bounces, Weiterleitungen).

mx

`redirect`

Verweist komplett auf den SPF-Record einer anderen Domain und ersetzt deinen eigenen. Anders als include, weil er ersetzt statt ergänzt.

redirect=_spf.example.com

Häufige SPF-Fehler und wie du sie vermeidest#

Fehler 1: Das 10-DNS-Lookup-Limit überschreiten#

Die SPF-Spezifikation (RFC 7208) begrenzt die Gesamtzahl der DNS-Lookups auf 10. Jeder include, a, mx und redirect Mechanismus zählt als ein Lookup. Verschachtelte Includes (ein Include, der selbst Includes enthält) zählen ebenfalls auf dieses Limit.

Wenn dein Record 10 Lookups überschreitet, liefert die SPF-Prüfung ein PermError-Ergebnis zurück, und viele empfangende Server behandeln das genauso, als hättest du gar keinen SPF-Record.

So behebst du es:

Ersetze include-Mechanismen wo möglich durch ip4/ip6 (IP-Mechanismen zählen nicht als DNS-Lookups).
Nutze SPF-Flattening-Tools, um Includes in ihre zugrunde liegenden IP-Adressen aufzulösen.
Konsolidiere E-Mail-Dienste, wo es möglich ist.
Entferne Includes für Dienste, die du nicht mehr nutzt.

Fehler 2: Mehrere SPF-Records veröffentlichen#

Eine Domain darf genau einen SPF-Record haben. Wenn du zwei TXT records veröffentlichst, die beide mit v=spf1 beginnen, liefert die SPF-Prüfung ein PermError zurück. Das passiert häufig, wenn jemand einen neuen SPF-Record hinzufügt, ohne den bestehenden zu entfernen oder zu aktualisieren.

So behebst du es: Führe alle deine autorisierten Absender in einem einzigen SPF-Record zusammen.

Falsch:

v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all

Richtig:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Fehler 3: `+all` verwenden

+all als Qualifier zu setzen bedeutet, dass jeder Server der Welt autorisiert ist, E-Mails als deine Domain zu verschicken. Das hebt den Sinn von SPF komplett auf und ist ein ernstes Sicherheitsrisiko.

Fehler 4: Vergessen zu aktualisieren nach Anbieterwechsel#

Wenn du E-Mail-Anbieter wechselst, Marketing-Plattformen migrierst oder neue SaaS-Tools hinzufügst, muss dein SPF-Record aktualisiert werden. Alte Includes für nicht mehr genutzte Dienste verschwenden DNS-Lookups, und fehlende Includes für neue Dienste führen dazu, dass legitime E-Mails durchfallen.

Fehler 5: Nach Änderungen nicht testen#

Jedes Mal, wenn du deinen SPF-Record änderst, teste ihn. Versende Test-E-Mails von all deinen Diensten und verifiziere, dass sie SPF-Prüfungen bestehen. Nutze Tools wie den Nova Uptime Email Health Checker, um die Syntax und Konfiguration deines Records zu validieren.

SPF und das größere Bild der E-Mail-Authentifizierung#

SPF ist eines von drei großen E-Mail-Authentifizierungsprotokollen. Für umfassenden Schutz solltest du alle drei einsetzen:

SPF + DKIM + DMARC#

SPF verifiziert, dass der sendende Server für die Domain autorisiert ist.
DKIM (DomainKeys Identified Mail) fügt ausgehenden E-Mails eine kryptografische Signatur hinzu und verifiziert, dass die Nachricht beim Transit nicht verändert wurde und von einer autorisierten Partei stammt.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) verbindet SPF und DKIM mit einer Policy, die empfangenden Servern sagt, was zu tun ist, wenn die Authentifizierung fehlschlägt. Es liefert auch Reportings, sodass du sehen kannst, wer E-Mails als deine Domain verschickt.

Zusammen bieten diese drei Protokolle robusten Schutz gegen E-Mail-Spoofing und Phishing. SPF allein ist ein starker Anfang, aber am wirksamsten ist es in Kombination mit DKIM und DMARC.

Deinen SPF-Record testen#

Nachdem du deinen SPF-Record eingerichtet hast, ist gründliches Testen unerlässlich. Hier ist eine Test-Checkliste:

DNS-Verifikation: Bestätige mit DNS-Lookup-Tools, dass der Record existiert und syntaktisch korrekt ist.
Test-E-Mails versenden: Versende E-Mails von jedem autorisierten Dienst und prüfe die E-Mail-Header auf der Empfängerseite auf spf=pass.
Lookup-Anzahl prüfen: Stelle sicher, dass deine gesamten DNS-Lookups bei 10 oder weniger liegen.
Verifiziere, dass nur ein SPF-Record existiert: Prüfe, dass du keine doppelten SPF TXT records hast.
Mit unautorisiertem Server testen: Wenn möglich, versende eine E-Mail von einer nicht autorisierten Quelle und bestätige, dass sie SPF nicht besteht oder soft-failed.

Der Nova Uptime Email Health Checker automatisiert die meisten dieser Prüfungen. Gib deine Domain ein und erhalte einen sofortigen Report zu deinem SPF-Record, einschließlich der spezifischen Policy-Stärke, etwaiger Syntax-Probleme und Verbesserungsempfehlungen. Er prüft auch deine DKIM- und DMARC-Konfiguration, sodass du deinen kompletten E-Mail-Authentifizierungsstatus an einem Ort sehen kannst.

Deinen SPF-Record pflegen#

SPF ist keine Einrichten-und-vergessen-Konfiguration. Plane regelmäßige Reviews ein:

Quartalsweise Audits: Vergleiche deinen SPF-Record mit deiner aktuellen Liste der E-Mail-Versanddienste. Entferne alte Includes und füge neue hinzu.
Nach jeder Infrastruktur-Änderung: Wann immer du einen E-Mail-Dienstleister hinzufügst, entfernst oder änderst, aktualisiere deinen SPF-Record sofort.
Nach Deliverability-Problemen: Wenn du bemerkst, dass E-Mails im Spam landen, prüfe zuerst deinen SPF-Record. Eine fehlkonfigurierte Konfiguration ist eine der häufigsten Ursachen.
Automatisiertes Monitoring: Nutze ein E-Mail-Health-Monitoring-Tool, um deine SPF-Konfiguration laufend zu prüfen und dich zu alerten, wenn sie kaputt geht.

Zusammenfassung#

SPF korrekt einzurichten gehört zu den wirkungsvollsten und gleichzeitig am wenigsten aufwändigen Verbesserungen, die du für die E-Mail-Sicherheit und Deliverability deiner Domain umsetzen kannst. Zusammenfassend:

Liste jeden Dienst auf, der E-Mails als deine Domain versendet.
Sammle die SPF-Include-Werte für jeden Dienst.
Baue einen einzigen SPF-Record, der alle autorisierten Absender vereint.
Beginne mit ~all und steige auf -all um, sobald du bestätigt hast, dass alles funktioniert.
Veröffentliche den TXT record im DNS.
Verifiziere mit dem Nova Uptime Email Health Checker.
Überprüfe und aktualisiere quartalsweise.

Deine E-Mail-Reputation wird über Monate aufgebaut und kann in Tagen zerstört werden. Ein korrekt konfigurierter SPF-Record ist das Fundament, das sie schützt.

Häufig gestellte Fragen#

Wie prüfe ich meinen SPF-Record?#

Nutze ein kostenloses SPF-Checker-Tool, um deinen SPF-Record nachzuschlagen und zu validieren. Gib deine Domain ein, und das Tool fragt DNS nach deinem TXT record ab, validiert die Syntax, zählt DNS-Lookups (max. 10 erlaubt) und prüft deine Enforcement-Policy. Du kannst auch mit dig TXT yourdomain.com oder nslookup -type=TXT yourdomain.com prüfen.

Was macht ein SPF-Check?#

Ein SPF-Check verifiziert, dass der Server, der E-Mails im Namen deiner Domain versendet, in deinem SPF DNS Record autorisiert ist. Empfangende Mailserver führen diese Prüfung automatisch durch. Wenn die sendende IP nicht in deinem SPF-Record gelistet ist, kann die E-Mail je nach DMARC-Policy als Spam markiert oder abgelehnt werden.

Wie teste ich meinen SPF-Record?#

Nachdem du deinen SPF-Record veröffentlicht hast, teste ihn, indem du: (1) einen kostenlosen SPF-Check ausführst, (2) eine Test-E-Mail an Gmail schickst und in den "Original anzeigen"-Headern auf spf=pass prüfst, oder (3) mit nslookup -type=TXT yourdomain.com verifizierst, dass der Record korrekt veröffentlicht ist.

Was ist das SPF-10-Lookup-Limit?#

SPF-Records sind auf 10 DNS-Lookups limitiert. Jeder include:, a:, mx:, ptr: und redirect= Mechanismus zählt als ein Lookup. Wird dieses Limit überschritten, gibt es einen permanenten SPF-Fehler (permerror), was bedeutet, dass alle deine E-Mails SPF nicht bestehen. Nutze den SPF Checker, um deine aktuellen Lookups zu zählen.

Sollte ich -all oder ~all in meinem SPF-Record verwenden?#

Nutze -all (Hard Fail) für maximalen Schutz – es sagt empfangenden Servern, dass sie E-Mails aus nicht autorisierten Quellen ablehnen sollen. Nutze ~all (Soft Fail) während der initialen Einrichtung oder Migration. Sobald du bestätigt hast, dass alle legitimen Absender enthalten sind, wechsle zu -all. Unser Email Health Checker prüft deine SPF-Policy und empfiehlt die passende Einstellung.