Ein SPF-Record ist ein einzelner DNS-Texteintrag Ihrer Domain, der auflistet, welche Mailserver in Ihrem Namen versenden dürfen. Empfangende Systeme wie Microsoft 365 oder Gmail schlagen bei jeder eingehenden E-Mail automatisch diesen Eintrag nach und vergleichen ihn mit dem tatsächlich sendenden Server. Stimmt er nicht überein, gilt die Mail als nicht autorisiert – unabhängig davon, wie seriös ihr Inhalt ist.
Was im DNS tatsächlich steht
Ein SPF-Record ist ein TXT-Eintrag auf Ihrer Domain, keine separate Datei und kein Login irgendwo. Er sieht typischerweise so aus:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~allJedes Element hat eine feste Bedeutung:
| Baustein | Bedeutung |
|---|---|
v=spf1 | Kennzeichnet den Eintrag als SPF, Version 1 |
ip4: / ip6: | Eine konkrete Server-Adresse, die senden darf |
include: | Verweist auf den SPF-Record eines Dienstleisters (z. B. Ihr Newsletter-Tool) |
~all | Softfail: alles Übrige gilt als verdächtig, wird aber meist trotzdem zugestellt |
-all | Hardfail: alles Übrige wird konsequent abgelehnt |
Die Reihenfolge der Einträge spielt keine Rolle, das Präfix vor all dagegen schon – es bestimmt, wie streng nicht gelistete Server behandelt werden.
Welche Absenderadresse SPF prüft — und welche nicht
SPF prüft den Envelope-Sender, also die Adresse, die der sendende Server im SMTP-Dialog als MAIL FROM nennt. Diese Adresse ist Teil des Transportprotokolls und wird dem Empfänger im Postfach nie angezeigt. Die Absenderadresse, die Ihr Kunde tatsächlich liest, steht im From-Header der Nachricht – und die kann eine völlig andere Domain tragen, ohne dass SPF das bemerkt.
Daraus folgt die praktische Grenze des Verfahrens: Ein Absender kann eine Domain im Envelope verwenden, für die er sauber autorisiert ist, und im sichtbaren From-Feld trotzdem Ihre Firma nennen. SPF meldet «pass». Erst DMARC verlangt, dass die geprüfte Domain zur sichtbaren passt.
Wie Sie Ihren SPF-TXT-Eintrag im DNS abfragen
Sie brauchen kein Spezialwerkzeug, ein einfacher DNS-Abfragebefehl genügt:
dig TXT ihredomain.ch +shortUnter Windows funktioniert nslookup -type=TXT ihredomain.ch ebenso. Das Ergebnis kann mehrere TXT-Einträge zeigen – gesucht ist die Zeile, die mit v=spf1 beginnt. Prüfen Sie darin jeden include:, ob der jeweilige Dienst tatsächlich noch aktiv genutzt wird, und jede ip4:-Adresse, ob der dahinterliegende Server noch existiert.
Warum die meisten SPF-Fehler erst nach dem Einrichten entstehen
Die meisten SPF-Probleme entstehen nicht beim Einrichten, sondern beim Vergessen danach:
- Verwaiste
include:-Einträge. Ein Newsletter-Anbieter wird gewechselt, der alte Eintrag bleibt aber im Record stehen. - Das 10-Lookup-Limit. SPF erlaubt maximal 10 DNS-Abfragen pro Prüfung (jedes
include:zählt, teils mehrfach verschachtelt). Wird das überschritten, gilt der gesamte Record als ungültig – auch die korrekten Einträge werden dann ignoriert. +allstatt~alloder-all. Das erlaubt praktisch jedem Server, in Ihrem Namen zu senden – das Gegenteil von Schutz.- Zwei SPF-Records gleichzeitig. Pro Domain ist nur ein SPF-TXT-Eintrag zulässig; ein zweiter macht beide ungültig.
Ein konkretes Beispiel: Ein Treuhandbüro wechselt von einem lokalen Mailserver zu Microsoft 365, vergisst aber, den alten ip4:-Eintrag zu entfernen und den neuen include:spf.protection.outlook.com zu ergänzen. Ergebnis: Ausgehende Mails über Microsoft 365 werden bei manchen Empfängern als nicht autorisiert markiert, weil der SPF-Record noch den stillgelegten Server nennt und Microsoft fehlt.
Ein SPF-Record ohne DKIM und DMARC schützt nur die technische Versandroute – nicht die sichtbare Absenderadresse, die Ihre Kunden tatsächlich lesen.
Was SPF prüft und was erst DKIM und DMARC abdecken
Die drei Verfahren werden oft in einem Atemzug genannt, prüfen aber verschiedene Dinge und greifen an verschiedenen Stellen der Nachricht an:
| Prüfkriterium | SPF | DKIM | DMARC |
|---|---|---|---|
| Was wird geprüft? | Die IP-Adresse des sendenden Servers | Die kryptografische Signatur der Nachricht | Ob SPF oder DKIM zur sichtbaren Absenderdomain passen |
| Welche Absenderadresse ist massgeblich? | Envelope-Sender (MAIL FROM), für den Empfänger unsichtbar | Signaturdomain im Header (d=) | Die Domain im From-Feld, die der Empfänger liest |
| Erkennt nachträgliche Änderungen am Inhalt? | Nein | Ja | Nur mittelbar, über das DKIM-Ergebnis |
| Übersteht eine Weiterleitung? | In der Regel nicht – der weiterleitende Server sendet mit eigener IP | Ja, solange die Nachricht unverändert bleibt | Ja, sofern DKIM hält |
| Legt eine Reaktion bei Fehlschlag fest? | Nur als Empfehlung (~all / -all) | Nein, der Empfänger entscheidet | Ja – p=none, p=quarantine, p=reject |
| Wo liegt der DNS-Eintrag? | TXT auf der Domain selbst | TXT auf selector._domainkey.ihredomain.ch | TXT auf _dmarc.ihredomain.ch |
Die Zeile «Übersteht eine Weiterleitung?» erklärt, warum SPF allein nie genügt: Sobald eine Mail über eine Weiterleitung läuft, ist der ursprüngliche Absenderserver nicht mehr derjenige, den der Empfänger sieht.
Wie Sie Ihren Record prüfen und die 10-Lookup-Kette auszählen
Der SPF-Record ist in zwei Minuten abgefragt – die Arbeit steckt darin, die verschachtelten include:-Ketten aufzulösen und zu zählen. Diese Reihenfolge führt zum Ziel:
- Den eigenen Record holen.
dig TXT ihredomain.ch +shortund die Zeile mitv=spf1herausgreifen. Kommt mehr als eine solche Zeile zurück, ist das bereits der Befund: zwei SPF-Records machen beide ungültig. - Jedes
include:einzeln nachschlagen. Für jeden Eintragdig TXT _spf.google.com +short(bzw. die jeweilige Domain) ausführen. Enthält das Ergebnis selbst wiederinclude:, geht es eine Ebene tiefer – genau hier wächst die Kette unbemerkt. - Die Lookups zählen. Zählend sind
include:,a,mx,ptr,existsundredirect. Nicht zählend sindip4:undip6:– sie brauchen keine Abfrage. Die Spezifikation erlaubt maximal 10 DNS-Abfragen pro Prüfung; alles darüber ergibt einenpermerror. - Das Ergebnis an einer echten Mail gegenprüfen. Schicken Sie eine Mail von jedem produktiven Versandweg an ein externes Postfach und sehen Sie sich im Quelltext den Header
Authentication-Resultsan. Dort stehtspf=pass,spf=fail,spf=softfailoderspf=permerror– zusammen mit der Domain, gegen die geprüft wurde. - Die Versandwege inventarisieren, bevor Sie
-allsetzen. Mailserver, Newsletter-Tool, CRM, Buchhaltungssoftware, Formular-Plugin der Website, Monitoring-Dienste. Was hier fehlt, wird von-allzuverlässig abgewiesen.
Zwei Fallstricke, an denen es in der Praxis scheitert:
- Weiterleitungen brechen SPF – und zwar korrekt. Leitet ein Empfänger Ihre Mail automatisch an ein anderes Postfach weiter, verschickt sie der weiterleitende Server mit seiner IP-Adresse, während der Envelope-Sender Ihre Domain bleibt. Die SPF-Prüfung am Ziel schlägt fehl, obwohl niemand etwas gefälscht hat. Umgehen lässt sich das nur vom weiterleitenden Server aus (etwa mit SRS), nicht von Ihnen. Genau deshalb darf
-allnie das einzige Standbein sein: DKIM übersteht die Weiterleitung, SPF nicht. - Das 10-Lookup-Limit wird von Dienstleistern verbraucht, nicht von Ihnen. Ein einziges
include:eines grossen Anbieters kann intern mehrere weitereinclude:nachziehen. Ihr Record sieht kurz aus und ist trotzdem über dem Limit. Wer die Kette per «SPF-Flattening» durch festeip4:-Listen ersetzt, umgeht das Limit – handelt sich aber ein neues Problem ein: Ändert der Anbieter seine Server-Adressen, erfährt Ihr eingefrorener Record nichts davon, und der Versand bricht ohne erkennbaren Anlass ab. Flattening braucht darum zwingend eine Automatik, die den Record nachführt.
Ein vergessener Eintrag entscheidet, ob Ihre Rechnung im Posteingang landet
Wenn in einem Betrieb plötzlich Mails nicht mehr ankommen, ist der erste Verdacht fast immer der Empfänger: dessen Spamfilter, dessen Postfach, dessen IT. In den Fällen, die ich mir ansehe, liegt die Ursache regelmässig auf der eigenen Seite – in einem Eintrag, den vor Jahren jemand gesetzt und seither niemand mehr angeschaut hat.
Dieser Eintrag ist eine Art Gästeliste. Er sagt der ganzen Welt, welche Server im Namen Ihrer Firma E-Mails verschicken dürfen. Jeder Empfänger liest diese Liste automatisch mit, bevor er Ihre Nachricht zustellt. Steht der Server, der gerade sendet, nicht darauf, gilt Ihre Mail als nicht autorisiert – auch wenn sie die harmloseste Rechnung der Welt enthält.
Das Tückische daran: Die Liste veraltet leise. Sie wechseln den Newsletter-Dienst, führen eine neue Buchhaltungssoftware ein, ziehen zu einem anderen Mail-Anbieter um – und jedes Mal müsste die Liste nachgeführt werden. Wird sie das nicht, funktioniert der Versand oft monatelang trotzdem, weil viele Empfänger kulant sind. Bis einer es nicht ist.
Wer in Ihrem Namen Mails verschicken darf, steht öffentlich abrufbar im Netz
SPF
SPF steht für «Sender Policy Framework» – ein Regelwerk, mit dem eine Firma öffentlich bekannt gibt, welche Server E-Mails in ihrem Namen verschicken dürfen. Empfangende Mailserver schlagen diese Liste bei jeder Nachricht nach und vergleichen sie mit dem Server, von dem die Mail tatsächlich kam. Was SPF nicht prüft: ob die Nachricht unterwegs verändert wurde und ob die Absenderadresse stimmt, die Sie im Postfach sehen.
DNS-TXT-Eintrag
DNS steht für «Domain Name System» – das Adressverzeichnis des Internets, in dem steht, welcher Server zu welchem Namen gehört; ein TXT-Eintrag ist nichts anderes als ein Texteintrag in diesem Verzeichnis. Es handelt sich also um eine Textzeile, die zu Ihrer Domain gehört und die jeder im Internet abfragen kann – dasselbe Verzeichnis, das auch Ihre Website auffindbar macht. Die SPF-Gästeliste ist genau so eine Zeile. Sie liegt nicht in Ihrer Website und nicht in Ihrem Mailprogramm, sondern bei der Stelle, die Ihre Domain verwaltet.
Envelope-Sender
Die Absenderadresse, die zwei Mailserver beim Übergeben einer Nachricht untereinander austauschen – vergleichbar mit der Adresse auf dem Transportcouvert. Genau diese prüft SPF. Die Adresse, die Sie im Postfach als Absender sehen, steht dagegen auf dem Brief im Couvert und kann eine andere sein. Dass diese beiden auseinanderfallen können, ist die Lücke, die SPF allein nicht schliesst.
Warum ich vor jeder SPF-Änderung die Liste der Versanddienste verlange
Ich fasse einen SPF-Record nicht an, bevor ich weiss, wer alles im Namen der Firma sendet. Diese Liste ist fast nie vollständig, wenn ich danach frage – der Mailserver ist allen präsent, das Newsletter-Tool meistens, die Buchhaltungssoftware, die Rechnungen direkt verschickt, praktisch nie. Und genau die fällt heraus, sobald der Eintrag scharf gestellt wird.
Das ist der Grund, warum ich vom strengsten Setting abrate, solange diese Inventur nicht gemacht ist. Technisch ist die Sache klein: eine Zeile im DNS, geändert in fünf Minuten. Betriebswirtschaftlich hängt an dieser Zeile aber Ihre Rechnungsstellung. Ein zu strenger Eintrag, der einen vergessenen Versandweg abwürgt, kostet Sie mehr als der Zustand vorher – und er kostet es unsichtbar, weil abgewiesene Mails niemandem auffallen, der auf eine Antwort wartet.
Die ehrliche Grenze: SPF prüft, welcher Server gesendet hat, sonst nichts. Es sieht nicht, was in der Nachricht steht, und es sieht nicht, welchen Absender Ihr Kunde am Bildschirm liest. Eine Mail kann SPF sauber bestehen und trotzdem Ihren Firmennamen fälschen. Wer diese Lücke schliessen will, braucht zwei weitere Verfahren dazu: die Signatur DKIM, kurz für «DomainKeys Identified Mail», und die Regel DMARC, kurz für «Domain-based Message Authentication, Reporting and Conformance». SPF allein ist die halbe Miete, nicht die ganze.
Häufige Fragen
Reicht SPF allein als Schutz vor gefälschten Mails aus?
Nein. SPF prüft nur, ob der versendende Server autorisiert ist – nicht, ob die Nachricht unterwegs verändert wurde, und nicht, ob die im «From»-Feld sichtbare Adresse mit dem geprüften Server übereinstimmt. Dafür braucht es DKIM und DMARC zusätzlich.
Was ist der Unterschied zwischen `~all` und `-all`?
~all (Softfail) markiert nicht autorisierte Absender als verdächtig, viele Empfänger stellen die Mail trotzdem zu, meist im Spam-Ordner. -all (Hardfail) verlangt eine konsequente Ablehnung. Der Wechsel zu -all lohnt sich erst, wenn Sie sicher sind, dass alle legitimen Versandwege im Record erfasst sind.
Was passiert, wenn ich das 10-Lookup-Limit überschreite?
Der SPF-Record wird als permerror gewertet und von vielen Empfängern wie ein fehlender Record behandelt – der Schutz entfällt vollständig, obwohl der Eintrag vorhanden ist. Grössere Organisationen mit vielen Drittdiensten (CRM, Newsletter, Ticketsystem) stossen daran schneller, als man denkt.
Warum kommen weitergeleitete Mails trotz korrektem SPF nicht an?
Weil bei einer Weiterleitung nicht mehr Ihr Server sendet, sondern der des Weiterleitenden – mit dessen IP-Adresse, die naturgemäss nicht in Ihrem Record steht. Die SPF-Prüfung schlägt korrekt fehl, obwohl nichts gefälscht wurde. Das ist eine bekannte Eigenschaft des Verfahrens und einer der Gründe, warum DKIM danebenstehen sollte: Eine DKIM-Signatur übersteht die Weiterleitung.
Wie oft muss ich meinen SPF-Record pflegen?
Bei jedem Wechsel eines Mail- oder Versanddienstes – Hosting, Newsletter-Tool, CRM mit E-Mail-Funktion. Ein jährlicher Check reicht als Minimum, um verwaiste Einträge zu finden.
