SPF – wer in deinem Namen E-Mails verschicken darf

SPF nennt die Server, die in deinem Namen E-Mails verschicken dürfen. Wir zeigen den Aufbau des Eintrags, die Zehn-Abfragen-Grenze und jeden Befund im Einzelnen.

Stell dir eine Veranstaltung mit Gästeliste vor. Am Eingang steht jemand mit dieser Liste und gleicht ab, wer hereindarf. SPF ist genau das für deine Domain: eine Liste von Servern, die E-Mails mit deiner Adresse verschicken dürfen. Steht ein Server nicht darauf, weiß der Empfänger, dass hier jemand in deinem Namen auftritt, der nicht dazugehört.

Die Liste ist ein einziger Textbaustein im DNS deiner Domain – dort, wo auch steht, unter welcher Adresse deine Website liegt. Jeder empfangende Mailserver liest ihn beim Eintreffen einer Nachricht in Sekundenbruchteilen aus. Du merkst davon nichts. Deine Kunden merken es erst, wenn etwas fehlt: Rechnungen landen im Spam, oder jemand verschickt Zahlungsaufforderungen mit eurem Absender, und niemand kann es unterbinden.

SPF ist eines von drei Verfahren, die ineinandergreifen. SPF sagt, wer senden darf. DKIM beweist, dass eine Nachricht unterwegs nicht verändert wurde. DMARC sagt, was passieren soll, wenn die beiden nicht greifen. Ohne SPF fehlt DMARC eine der beiden Säulen, auf denen es steht.

Wie der Eintrag aussieht

Ein SPF-Eintrag ist ein TXT-Eintrag auf der Domain selbst – nicht auf einer Unteradresse:

beispiel-gmbh.de.   TXT   "v=spf1 include:spf.protection.outlook.com include:spf.brevo.com ip4:212.227.126.200 ~all"

Bestandteil für Bestandteil:

Der Abschluss ist der Teil, an dem die meiste Wirkung hängt:

Die Zehn-Abfragen-Grenze

Hier scheitern in der Praxis die meisten Einträge, und zwar lautlos. Ein SPF-Eintrag darf beim Auswerten höchstens zehn DNS-Abfragen auslösen. Jedes include:, jedes a, mx, ptr, exists und redirect zählt – auch innerhalb der eingebundenen Einträge. Wer vier Dienste einbindet, hat selten vier Abfragen, sondern oft sieben.

Diese Zahlen haben wir im DNS nachgesehen, nicht geschätzt:

Eine typische Firmendomain: Microsoft 365 (1) + IONOS für den alten Shop (2) + Brevo (1) + Rapidmail (2) + SendGrid (2) + a (1) + mx (1) macht zehn. Ein weiterer Dienst, und der Eintrag ist ungültig. Empfänger werten ihn dann nicht etwa vorsichtig aus, sondern gar nicht. Von außen sieht der Eintrag weiterhin tadellos aus – das ist das Tückische daran.

Was dagegen hilft, in dieser Reihenfolge: Dienste herauswerfen, die du nicht mehr benutzt (der Newsletter-Anbieter von 2019 steht erstaunlich oft noch drin). a und mx durch die konkreten ip4:-Adressen ersetzen, wenn die sich ohnehin nie ändern. Und Massenversand auf eine eigene Versanddomain umziehen – news.deine-domain.de hat ihre eigenen zehn Abfragen.

So richtest du es ein

Diese Bausteine haben wir am Tag der Veröffentlichung im DNS abgefragt. Jeder davon liefert eine gültige Antwort:

Zwei Namen, die in Anleitungen im Netz herumgeistern, gibt es nicht: _spf.ionos.com und _spf.strato.de antworten im DNS mit nichts. Wer sie einträgt, hat einen Eintrag, der ins Leere zeigt.

So legst du den Eintrag bei IONOS an – dem verbreitetsten Anbieter im deutschsprachigen Raum:

1. Im IONOS-Konto anmelden und zu Domains & SSL gehen.
2. Bei der betreffenden Domain das Zahnrad öffnen und DNS wählen.
3. In der Liste nach einem vorhandenen TXT-Eintrag suchen, dessen Wert mit v=spf1 beginnt. Ist einer da: diesen bearbeiten, keinen zweiten anlegen.
4. Ist keiner da: Eintrag hinzufügen, Typ TXT, Hostname leer lassen oder @ eintragen.
5. Als Wert alle Bausteine hintereinander in eine Zeile schreiben, beginnend mit v=spf1 und endend mit ~all.
6. Speichern. Die Änderung ist meist nach wenigen Minuten sichtbar, spätestens nach der Gültigkeitsdauer des alten Eintrags.
7. Domain erneut im Mail-Check prüfen.

Bei STRATO, All-Inkl und Host Europe heißt der Bereich anders, der Weg ist derselbe: Domainverwaltung, DNS-Einstellungen, TXT-Eintrag auf der Domain selbst.

Die Befunde im Einzelnen

Kein SPF-Eintrag

Gemessen: Auf deiner Domain steht kein TXT-Eintrag, der mit v=spf1 beginnt.

Empfänger haben damit keinen Anhaltspunkt, welche Server für dich sprechen dürfen. Gefälschte Absender mit deinem Namen sind nicht von echten zu unterscheiden, und deine eigene Post wird strenger bewertet – bei Gmail und Outlook merkbar.

Was zu tun ist: Schreib auf, über welche Wege heute Post mit deiner Adresse hinausgeht: Postfach-Anbieter, Newsletter, Shop, Kontaktformular, Warenwirtschaft, Buchhaltung. Dann setz für jeden Weg den passenden Baustein aus der Tabelle oben zusammen und schließ mit ~all ab.

Mehrere SPF-Einträge

Gemessen: Zwei oder mehr TXT-Einträge auf der Domain beginnen mit v=spf1.

Erlaubt ist genau einer. Bei zweien verwerfen empfangende Server SPF vollständig – der Schutz fällt aus, obwohl beide Einträge für sich genommen richtig aussehen.

Was zu tun ist: Die Bausteine aller Einträge in eine Zeile zusammenführen, doppelte include: nur einmal übernehmen, dann die übrigen Einträge löschen. Danach zählen: Bleibt die Summe unter zehn Abfragen?

SPF überschreitet die Abfragegrenze

Gemessen: Die Auswertung deines Eintrags löst mehr als zehn DNS-Abfragen aus.

Das Ergebnis ist ein Fehler, und der Eintrag wird ignoriert – ein stiller Ausfall, den man ihm nicht ansieht. DMARC verliert damit eine seiner beiden Säulen.

Was zu tun ist: Nicht mehr genutzte include: entfernen. a und mx durch feste ip4:-Adressen ersetzen, wo das geht. Bleiben zu viele Dienste übrig, den Massenversand auf eine eigene Versanddomain umstellen.

SPF endet auf +all

Gemessen: Der Eintrag schließt mit +all ab.

Damit erklärt deine Domain jeden Server der Welt für versandberechtigt. Der Eintrag ist vorhanden, schützt aber vor nichts – und bei DMARC besteht dann jede Fälschung die SPF-Prüfung.

Was zu tun ist: +all durch ~all ersetzen. Wenn alle Versandwege belegt sind und die Berichte das bestätigen, später auf -all.

SPF endet auf ?all

Gemessen: Der Eintrag schließt mit ?all ab.

„Neutral" heißt: keine Aussage. Empfänger werten den Eintrag dann so, als gäbe es ihn nicht. Das ist häufig ein Rest aus einer Einführungsphase, den niemand mehr angefasst hat.

Was zu tun ist: ?all durch ~all ersetzen und die DMARC-Berichte ein bis zwei Wochen beobachten. Taucht kein eigener Versandweg als Durchfaller auf, geht -all.

SPF ohne Abschluss

Gemessen: Im Eintrag fehlt der all-Mechanismus am Ende.

Damit bleibt offen, wie Empfänger mit nicht aufgeführten Servern umgehen sollen. Jeder entscheidet es anders, und du hast keine Kontrolle darüber.

Was zu tun ist: Den Eintrag mit ~all abschließen. Der Abschluss gehört ans Ende – was dahinter steht, wird nicht mehr ausgewertet.

SPF verwendet ptr

Gemessen: Der Eintrag enthält den ptr-Mechanismus.

ptr gilt seit Jahren als überholt. Viele Empfänger werten ihn nicht aus, manche behandeln ihn als Fehler, und er kostet zusätzliche Abfragen aus deinem Zehnerbudget.

Was zu tun ist: ptr entfernen und die betroffenen Server stattdessen über ip4: oder ip6: aufnehmen. Wenn du die Adressen nicht kennst: Der Anbieter des Servers nennt sie.

SPF verweist ins Leere

Gemessen: Mehrere eingebundene Einträge liefern selbst keinen SPF-Eintrag zurück.

Ab zwei solchen Fehlgriffen gilt der gesamte Eintrag als fehlerhaft. Typische Ursache: ein Dienst, der abgeschaltet wurde, oder ein Name aus einer veralteten Anleitung – genau wie _spf.ionos.com, den es nie gab.

Was zu tun ist: Die betroffenen include: entfernen. Brauchst du den Dienst noch, hol dir den aktuellen Baustein aus seiner Dokumentation und prüf die Domain danach erneut.

SPF-Eintrag sehr lang

Gemessen: Der Eintrag überschreitet die Länge, die ein DNS-Textbaustein am Stück fasst.

Lange Einträge werden im DNS in Stücke zerlegt. Das ist zulässig, aber einzelne Anbieteroberflächen setzen die Stücke falsch wieder zusammen – dann fehlt mittendrin ein Zeichen.

Was zu tun ist: Aufräumen. Meist stecken in langen Einträgen einzelne ip4:-Adressen, die längst zu einem der eingebundenen Dienste gehören, oder Reste alter Server.

SPF verweist im Kreis

Gemessen: Ein eingebundener Eintrag verweist wieder auf einen, der schon besucht wurde.

Die Auswertung bricht an dieser Stelle ab. Alles, was hinter der Schleife stünde, wirkt nicht mehr.

Was zu tun ist: Die Verschachtelung auflösen. Häufig bindet eine Versanddomain die Hauptdomain ein, während die Hauptdomain die Versanddomain einbindet. Eine der beiden Richtungen muss weg.

Eingebundene Domain hat mehrere SPF-Einträge

Gemessen: Eine Domain, die du per include: einbindest, hat selbst mehr als einen SPF-Eintrag.

Auch dort ist nur einer erlaubt. Der ganze Zweig gilt als fehlerhaft – der Fehler liegt beim Dienst, die Folgen trägst du.

Was zu tun ist: Den Betreiber des Dienstes darauf hinweisen; das ist für ihn eine Kleinigkeit. Bis zur Behebung kannst du die Adressbereiche des Dienstes vorübergehend direkt als ip4: eintragen, wenn er sie nennt.

Unbekannter Bestandteil im SPF-Eintrag

Gemessen: Im Eintrag steht ein Bestandteil, den der SPF-Standard nicht kennt.

Strenge Empfänger werten den gesamten Eintrag dann als fehlerhaft. Meist ist es ein Tippfehler (includ:), ein hineingerutschtes Semikolon oder ein Fragment aus einem anderen Eintragstyp.

Was zu tun ist: Den Bestandteil prüfen. Gehört er nicht dazu, entfernen. Trennzeichen zwischen den Bausteinen sind einfache Leerzeichen, nichts anderes.

Häufige Fragen

Reicht SPF allein aus?

Nein. SPF bricht, sobald eine Nachricht weitergeleitet wird: Der weiterleitende Server steht nicht auf deiner Liste. Deshalb braucht es DKIM daneben – die Signatur übersteht die Weiterleitung – und DMARC, damit eines von beidem genügt.

Muss ich den Eintrag ändern, wenn mein Anbieter neue Server bekommt?

Wenn du include: benutzt, nicht: Der Anbieter pflegt seine Liste selbst. Bei einzeln eingetragenen ip4:-Adressen musst du hinterher sein. Das ist der eigentliche Grund, warum include: trotz der Abfragegrenze meistens die bessere Wahl ist.

Wie lange dauert es, bis eine Änderung wirkt?

So lange, wie die Gültigkeitsdauer des alten Eintrags läuft – üblich sind ein bis 24 Stunden. Vor einer geplanten Umstellung lohnt es, diese Dauer vorher herunterzusetzen und danach wieder anzuheben.

Wir versenden gar keine E-Mails über diese Domain. Brauchen wir trotzdem SPF?

Gerade dann. Eine Domain ohne Postfächer ist ein bequemes Ziel für Fälschungen. v=spf1 -all sagt unmissverständlich: Von hier kommt nichts. Mehr dazu unter Posteingang.

Warum meldet der Mail-Check einen Fehler, obwohl unsere E-Mails ankommen?

Weil SPF still ausfällt. Ein Eintrag über der Abfragegrenze wird ignoriert, nicht abgelehnt – ankommende Post beweist also nichts. Gefährlich wird es erst, wenn du DMARC verschärfst oder ein großer Empfänger seine Regeln nachzieht.